The Decision Latency Scorecard: A One-Page Diagnostic

Most scorecards begin by asking people to rate the organisation. Is data governance mature? Is analytics trusted? Are decisions fast? The answers produce a coloured grid, but not a path anyone can repair.

A useful decision latency scorecard starts with evidence from five real questions. It records when each question was asked, when the first answer appeared, when the answer became trusted, and when someone acted. Then it identifies the repeated wait and gives it an owner.

The one-page constraint is deliberate. I have seen diagnostics become workshops, workshops become programmes, and programmes disappear before the same question returns next month. If the scorecard cannot be updated in one short meeting, it will not become part of the operating rhythm.

How do you assess how slow your decisions are?

Assess decision speed by tracing five recent business questions from the initial ask to an acted-on answer. Record the first answer, trusted answer, action, decision window, handoffs, and reopenings. Mark whether each question closed inside its window, identify the primary delay layer, and assign one owner to repair the repeated bottleneck.

This is not a company-wide maturity rating. It is a compact view of whether a small set of consequential questions closed while the answer could still change the outcome. The scorecard makes time, trust, ownership, and closure visible on the same page.

The scorecard in one sentence

Put five recurring questions in five rows. Give each row a decision window, four timestamps, a status, a primary delay layer, and a repair owner. Review the pattern monthly.

Five questions are enough to reveal a repeated constraint without pretending to be a benchmark. One question can be explained away as an exception. Fifty questions turn the first pass into a research project. Five keep the evidence legible to the people who own the decision.

The full decision latency audit explains how to select those questions and reconstruct their paths. The scorecard is the repeatable readout that remains after the first audit.

What belongs on the one-page scorecard

1. The exact business question

Copy the wording from the meeting agenda, message, email, or ticket. Do not improve it after the fact. “Why is revenue down?” and “Which controllable changes caused net revenue to miss the September plan?” create different investigations. Ambiguity is part of the evidence.

Use questions that recur and could change action: a weekly pipeline question, a monthly margin question, an operational exception, a forecast input computed by two functions, and one question that quietly disappeared without closure.

2. The decision, owner, and useful window

Name the decision the answer was meant to support, the person authorised to act, and the latest time action would still preserve value. The window must be set before judging the result. Otherwise every late answer can be declared “good enough” after the opportunity has passed.

The useful window differs by question. A service recovery may have hours. A forecast adjustment may have several days. A strategic investment may justify weeks. The scorecard compares each question with its own window rather than imposing a universal turnaround benchmark.

3. Four timestamps

Record asked at, first answer at, trusted answer at, and acted at. These four events preserve the most important distinctions without turning the page into a process map.

• Asked at starts the clock when the question enters a consequential forum or channel.
• First answer at shows when a plausible number or explanation first became available.
• Trusted answer at records when the accountable people accepted the definition, source, and limitations.
• Acted at stops the clock when a named person or system changed something because of the answer.

If no action occurred, leave the endpoint open and count the age of the question. Do not substitute “presented to leadership” for action. A deck is a handoff, not closure.

4. Coordination evidence

Add three small counts: systems consulted, handoffs, and reopenings. These are not targets by themselves. They help explain why two questions with similar elapsed time require different repairs.

A question that touched five systems may have a retrieval problem. A question that reopened three times may have an unsigned metric contract. A question with one source and six approvals probably has an authority problem. The counts point back to the path.

5. The primary delay layer

Force each row to name one primary layer. Secondary observations can sit in notes, but the repair needs one owner.

• Governed foundation: the required evidence was missing, unreliable, inaccessible, or too late.
• Semantic contract: teams disputed the definition, scope, source, exclusions, or change rule.
• Resolution workflow: the question waited in retrieval, handoffs, tickets, meetings, or delivery.
• Human interpretation and accountability: the answer existed, but authority, judgment, approval, or action remained unclear.

These layers follow the broader decision latency framework. The point is not to produce an impressive taxonomy. It is to stop sending every slow question back to the data team.

6. One repair owner and one retest date

End each row with the smallest repair that can change the path and the person who owns it. Examples include writing the pipeline definition, naming the revenue owner, removing an approval, delivering the answer into the weekly review, or fixing a missing event in the source.

Set a retest date for the next occurrence of the same question. The scorecard becomes useful when it shows a before-and-after path, not when it produces a polished diagnosis once.

Use status rules, not an invented maturity score

A single score out of 100 looks precise and hides the problem. A question can close quickly through executive heroics, or slowly through a stable process that simply has the wrong cadence. Adding arbitrary weights to systems, handoffs, and owners does not make those situations comparable.

Use three operational statuses instead:

• Green: action occurred inside the predefined decision window, the answer was not reopened, and a named owner closed it.
• Amber: the question remains inside its window but is waiting, or it closed inside the window after a definition or trust issue reopened the path.
• Red: the decision window was missed, no authorised owner exists, or the question disappeared without an acted-on answer.

These colours are routing rules, not grades. Green means preserve and reuse the path. Amber means intervene before the window closes. Red means leadership must choose whether to repair the path, narrow the question, delegate authority, or stop pretending the answer is still useful.

Five summary measures at the top of the page

The five rows carry the evidence. A compact header lets leaders see whether the pattern changed:

• Median end-to-end latency: the middle question-to-action time across the five, shown with the individual rows still visible.
• Decision-window miss rate: the share of questions that acted after their useful window or never acted.
• Median trust delay: the middle time from first answer to trusted answer.
• Reopen rate: the share of questions whose definition, source, or answer was reopened after a first response.
• Closure rate: the share that ended in a named action rather than a presentation, deferral, or disappearance.

These measures align with the wider measurement system without copying every diagnostic onto the page. Keep the scorecard small. Use the full set of decision latency metrics when instrumentation and volume justify it.

Why the header uses a median

With five questions, one unresolved path can dominate an average and make ordinary performance look worse than it is. The median gives a stable centre while the red row remains visible underneath. That is the important condition: never publish the summary without the five paths that explain it.

Do not use the median to set a universal service target. The operational exception and the monthly forecast have different windows. The header shows whether the selected portfolio is moving. Each row still determines whether the organisation acted in time for that specific decision.

A worked example: eleven days to four hours

Consider a recurring pipeline question with a one-business-day decision window. In the original path, three functions brought defensible versions of the number. The first answer arrived quickly, but reconciliation and approval stretched the path to eleven days. The row is red because the useful window was missed.

The primary delay layer is the semantic contract. The repair is not “improve data quality.” It is to agree what qualified pipeline includes, name the business owner, permit one source to compute it, and record how changes are approved.

After that repair, the same class of question closed in four hours. The row becomes green if action occurred inside the window without reopening. The scorecard preserves the operating evidence: which wait disappeared, who owned the repair, and whether it held on the next cycle.

How to run the monthly review in 30 minutes

The first scorecard may take ninety minutes because the team has to reconstruct evidence. The recurring review should not.

• Minutes 0 to 10: update the four timestamps and status for the five questions.
• Minutes 10 to 15: confirm the primary delay layer for every amber or red row.
• Minutes 15 to 20: compare the current pattern with the previous review.
• Minutes 20 to 25: choose one repeated bottleneck and one repair owner.
• Minutes 25 to 30: set the retest event and date, then close the meeting.

Do not spend the meeting redesigning every decision. The scorecard is a triage device. It should identify the repeated wait worth taking into a separate working session.

Common ways the scorecard fails

It scores opinions instead of questions

A data maturity scorecard asks whether people believe analytics is trusted. A decision latency scorecard shows which answer was reopened, when, and why. Perception can explain the context, but the row must remain anchored in observable events.

It stops at the trusted answer

Trust is not the endpoint. If the answer was accepted on Tuesday and no one acted before the Friday window closed, the organisation still lost the decision. Keep decision-to-action delay visible.

It averages away the broken path

A median is useful in the header and dangerous on its own. Five operational questions may close in hours while one forecast question remains open for three weeks. Keep every row visible so leaders cannot celebrate the average and ignore the decision that matters.

It becomes a tool inventory

Systems consulted are evidence, not the subject. The scorecard should not turn into a warehouse, BI, catalog, or AI assessment. A modern stack can still support slow decisions when meaning and ownership are contested.

It produces three causes and no owner

Most slow paths contain several imperfections. Choose the delay that consumed the most useful time and can be changed by one accountable person. If the diagnosis names four teams, it has described the landscape rather than selected a constraint.

What the scorecard can and cannot tell you

The scorecard can show whether recurring questions close inside their useful windows, where trust and action wait, whether definitions reopen, and whether repairs survive the next cycle. It gives leadership diagnostic language tied to evidence.

It cannot prove decision quality, replace regulatory review, or establish an external benchmark. A green row means the operating path met its own window and closure rules. It does not mean the choice was correct. Quality, speed, execution, and effort remain distinct dimensions of decision effectiveness.

It also cannot resolve missing evidence through facilitation. If the organisation never captured the required event or the source is materially wrong, mark the governed foundation and fix the data problem. Do not use a workshop to manufacture certainty.

Keep the diagnostic small enough to become a habit

The purpose of the scorecard is not to score the enterprise. It is to keep five decision paths visible long enough for a repeated wait to become an owned repair.

Start with the existing interactive Decision Latency Audit. It runs in the browser, requires no email, and can be printed or saved as a one-page working record. Use the article to understand the status rules, then use the sheet in the meeting.

The strongest signal is not a higher maturity score. It is a question that moved from red to green because one definition was written, one owner was named, or one approval queue was removed. Keep that evidence on one page. Run it again next month.