What a decision brief actually looks like

Most reporting projects fail quietly because nobody ever writes down the decision the report is supposed to improve.

A dashboard can be technically correct and commercially useless at the same time. That usually happens when the team built pages, visuals, and filters before it built a decision brief.

A decision brief is the plain-English contract between the business question and the reporting work.

At Data Disruption, we do not start with chart types. We start with five pieces of information that sound simple but change the entire engagement.

  1. The decision owner. Name the person who will act differently if this works. A board pack, an ops manager, and a commercial lead do not need the same brief.
  2. The moment of use. Monthly close, Monday morning operations, price review, service exception triage. Timing changes design.
  3. The trigger question. "What changed?", "why did margin move?", "is this an anomaly or normal noise?", "what should we do next?"
  4. The acceptable proof. What evidence makes the answer trustworthy enough to act on — cited transactions, tied-out measures, named business rules, or a human reviewer.
  5. The action window. If the answer arrives late, the decision is already gone. That sets the bar for automation.

When a client cannot answer those five things, the project usually needs diagnosis before delivery. That is often why the right first offer is a readiness sprint, not a bigger build.

When a client can answer them, the work becomes sharper immediately. The semantic model gets cleaner. The prompts get narrower. The eval set becomes possible. The sign-off path becomes obvious.

That is the practical difference between "we need a better dashboard" and "we need a better decision system."

Useful systems beat impressive theatre.