Verified against ChatGPT · 2026-08-11
Write the dashboard requirements doc that stops you from rebuilding it three times
Interviews the request behind a dashboard ask and produces a requirements doc — audience, decisions it needs to support, grain, and refresh cadence — pinned down before a single visual gets built.
The prompt
Ready to copy — highlighted parts are example details you can swap.
A stakeholder has asked for a dashboard. Before anything gets built, help me turn that request into an actual requirements document — most dashboard rebuilds happen because this step got skipped, not because the tool was wrong. ORIGINAL REQUEST (AS ASKED) "Can we get a dashboard that shows how the sales team is doing?" WHO ASKED AND WHO ELSE WILL USE IT The VP of Sales asked; the dashboard will also be checked weekly by regional sales managers and pulled up in the Monday leadership meeting. DATA AVAILABLE CRM export with deal stage, deal value, owner, close date; updated nightly, no real-time feed available. CONSTRAINTS Needs a first version ready in one week using existing Power BI licenses, no budget for a new data pipeline. Work through this: 1. Translate the original request into the actual decisions this dashboard needs to support — a request like "I want to see our sales numbers" is not a requirement, it's a topic; press for what decision gets made differently depending on what the dashboard shows, and if the request as given doesn't reveal that, list the clarifying questions you'd need answered first rather than guessing. 2. Define the grain of the dashboard's primary view (what one row/one data point represents) and the time granularity (daily, weekly, real-time) — justify the choice against the decisions identified in step 1, not against what's easiest to build. 3. List the minimum set of visuals needed to support those decisions, explicitly excluding anything that would be "nice to see" but doesn't change what anyone does — flag those separately as a phase-two candidate list instead of just leaving them out silently. 4. Define refresh cadence and acceptable data latency based on how the decisions actually get made (a weekly ops meeting doesn't need real-time data; a fraud-monitoring view might). 5. Name the one metric definition most likely to cause disagreement later (e.g. what counts as "active," how a cancelled order is treated) and propose a specific definition to lock in now, before multiple versions of that number start circulating. OUTPUT FORMAT - Decisions this dashboard must support (bullet list) - Grain and time granularity, with justification - Core visuals (minimum viable), one line each on what decision it supports - Phase-two candidates (explicitly deferred, not just omitted) - Refresh cadence and why - The one metric definition to lock in now, with a proposed definition
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Forcing the translation from a vague request into named decisions is the single highest-leverage move in this prompt, because "I want to see our sales numbers" genuinely contains no information about what should be built — a model asked to just design a dashboard from that sentence will invent a plausible generic sales dashboard (funnel, pipeline value, win rate) that may have nothing to do with what the VP actually needs to decide, and will do so confidently rather than flagging the ambiguity, since nothing in the prompt otherwise tells it that guessing is worse than asking. Requiring the grain and refresh cadence to be justified against the named decisions, not against ease of build, prevents the common default where a model (or a builder under time pressure) picks whatever granularity the source data happens to already be in, producing a dashboard that's technically accurate but wrong-grained for the actual use — a weekly leadership review doesn't need a daily-grain view, and building one anyway just adds noise the audience has to mentally filter out every time. The explicit phase-two list, rather than silent omission of nice-to-have visuals, matters politically as much as technically: stakeholders who asked for something and don't see it anywhere in the output tend to assume it was forgotten rather than deliberately deferred, and a visible phase-two list turns a scope cut into a stated plan rather than a perceived gap. Naming the single metric definition most likely to cause future disagreement front-loads the fight that would otherwise happen three months later when the sales team's "win rate" and finance's "win rate" turn out to be computed differently — catching this before the build means one definition gets built in from the start instead of two dashboards quietly disagreeing with each other.
What you get back
Decisions this dashboard must support: whether a regional manager needs to intervene on a rep's pipeline this week; whether the VP should flag a regional shortfall before the Monday leadership meeting. Grain: one row per open deal, rolled up to weekly snapshots by rep and region — daily is unnecessary since the only recurring decision cadence identified is the weekly manager check-in and Monday meeting. Metric to lock in now: define 'active pipeline' as deals not in Closed-Won or Closed-Lost stage with a close date in the current or next quarter, since 'active' is the term most likely to get redefined differently by different regional managers later.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — 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
