Verified against ChatGPT · 2026-08-10
Design a CFO dashboard around the decisions it needs to trigger, not every metric finance can pull
Builds a lean CFO dashboard spec — the metrics, thresholds, and review cadence — anchored to the specific decisions each metric is supposed to trigger, instead of a wall of KPIs nobody acts on.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Help me design the metric set for a CFO-level dashboard. The failure mode I'm trying to avoid is a dashboard with thirty metrics on it that nobody actually looks at every week because it's not clear which numbers are supposed to trigger which action.
BUSINESS MODEL
B2B SaaS, annual contracts with quarterly usage-based overage billing
CURRENT DECISION CADENCE
Monthly leadership review, quarterly board cycle, ad hoc hiring approvals in between
METRICS ALREADY TRACKED (if any)
MRR, gross churn, NPS, website traffic, headcount, total SaaS spend
BIGGEST BLIND SPOT RIGHT NOW
We don't notice a customer segment's usage-based overage revenue softening until the invoice lands a month later
For each metric you propose, you must state four things or the metric doesn't belong on the dashboard: what decision this number is supposed to inform, what threshold or trend would actually trigger that decision (not just "monitor closely" — a specific number or rate of change), how often it needs to be reviewed given how fast it can move, and who owns acting on it. Group metrics into three tiers: Weekly (fast-moving, needs frequent eyes because it can drift meaningfully in days), Monthly (structural, moves slower, monthly review is enough), and Trigger-only (doesn't need a standing review cadence at all, just an alert when it crosses a threshold). If a metric from the existing list doesn't clear the four-part bar above, flag it as a candidate to drop from the standing dashboard rather than silently keeping it, and explain what decision it fails to connect to. Address the stated blind spot directly — propose at least one metric specifically aimed at surfacing it earlier, and explain what signal it would have caught.
WHAT NOT TO DO
Do not propose a metric just because it's commonly tracked in this business model if it doesn't map to an actual decision this specific dashboard's audience makes. Do not set a threshold vaguely ("if it starts trending down") — commit to a specific number or rate, and note that it's a starting point to calibrate against actual historical volatility, not a claimed industry-standard figure.
OUTPUT FORMAT
A table: Metric | Tier | Decision It Triggers | Threshold | Owner | Review Cadence. Followed by a short "drop candidates" list with reasoning, and a closing note on the blind-spot metric specifically. End with one line noting thresholds are starting points to be calibrated against your own historical data, not fixed benchmarks.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Requiring a stated decision, threshold, owner, and cadence for every metric before it's allowed onto the dashboard is a forcing function against GPT-5.1's default tendency, when asked to "design a CFO dashboard," to produce a comprehensive best-practice metric list pulled from what's typically tracked in the stated business model — comprehensive and typical is exactly the failure mode described in the prompt, since a metric with no attached decision is dead weight that dilutes attention from the ones that matter. Tiering into weekly, monthly, and trigger-only forces an explicit judgment about volatility and review cost that a flat metric list never makes: a number that can swing meaningfully week to week genuinely needs different cadence than one that's structurally slow-moving, and collapsing everything into one "dashboard" without a cadence tier is how review meetings end up spending equal time on a number that hasn't moved in a quarter and one that just broke. The instruction to evaluate existing metrics against the same four-part bar and flag drop candidates matters because dashboards accrete metrics over time as different stakeholders request their pet number, and without an explicit instruction to prune, a model will simply add new metrics on top of the old list rather than doing the harder, more useful work of removing ones that no longer connect to a live decision. Directly addressing the named blind spot forces the model to reason backward from a real, admitted gap in visibility rather than only forward from generic best practice, which is what actually makes the output specific to this business instead of a template that would look the same for any SaaS company.
What you get back
Metric: Usage-based overage run-rate (trailing 7-day, projected to month-end) | Tier: Weekly | Decision: whether to flag an at-risk segment to sales before the invoice lands | Threshold: projected month-end overage revenue down >15% vs. same point last month | Owner: RevOps lead | Cadence: weekly, Monday. Drop candidate: NPS on the standing weekly dashboard — doesn't map to a weekly-cadence financial decision; recommend moving to the quarterly product review instead.
Verified against
ChatGPT GPT-5.1 · 2026-08-10
Changelog
- 2026-08-10 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
