Skip to content

How to Run a Decision Latency Audit in Five Questions

Yagnesh Ramalingam, founder of ZerentroYagnesh RamalingamFounder & CEO, Zerentro

12 min readUpdated

Business data analysis workflow showing spreadsheets, databases, cloud data, research, validation, time delays, and measurable growth.

A revenue question lands in the leadership meeting at 10:05 on Monday. The first chart appears before lunch. By Thursday, Finance and Sales are still comparing definitions. The following Monday, someone makes a call using the same judgement they had a week earlier. The data was fast. The decision was not.

That gap is decision latency: the elapsed time between a business question being asked and a trusted, sourced answer being acted on. Most companies cannot say how long that path takes because they timestamp reports, tickets and refreshes, not the question or the action.

A useful audit does not begin with a warehouse inventory, a dashboard catalogue or a maturity model. It begins with five questions the business already asks. Trace them end to end in one afternoon. The delay will usually make itself visible before anyone opens the data stack.

How do you audit decision latency in a company?

Choose five recurring business questions and reconstruct each path from the moment it was asked to the moment someone acted on an answer they trusted. Record the handoffs, definition disputes, source checks, approvals and idle time. Compare the five paths, find the longest repeated delay, assign one owner and rerun the audit in 30 days.

The point is not to produce a company-wide score on the first pass. It is to find one repeatable delay that leaders can see, own and shorten. One question is an anecdote. Five questions are enough to reveal a pattern without turning the audit into a consulting programme.

What the audit measures

Decision latency starts when the question is asked, not when an analyst receives a ticket. It stops when someone with the authority to act commits to an intervention. A deck delivered to a meeting is an intermediate event. So is a dashboard refresh. If the room still asks which number is right, the answer does not yet exist in an operational sense.

For each question, reconstruct six timestamps: when the question was asked, when an owner accepted it, when the first answer appeared, when the definition and source were agreed, when the answer was trusted, and when action followed. You do not need perfect system logs. Calendar invitations, Slack or Teams messages, email threads, ticket history, versioned spreadsheets and meeting notes usually give you enough evidence to establish the sequence.

The wider research points in the same direction. Bain measures decision effectiveness across quality, speed, yield and effort, not speed alone. McKinsey found that fewer than half of surveyed managers considered decisions timely, while 61 percent said at least half the time spent making decisions was ineffective. The five-question audit is deliberately narrower. It traces where that effort and waiting enter one real answer path.

This is why reporting lag is not decision latency. Reporting lag can explain how long data took to arrive. It cannot explain the four days spent deciding whether booked revenue and recognised revenue were answering the same question.

Choose five questions that expose different kinds of delay

Do not ask teams to invent representative questions in the workshop. People clean up hypothetical workflows. Use sentences that appeared in real meetings during the previous month, then choose a mix that crosses functions and cadences.

1. A weekly revenue or pipeline question

Choose a question such as, “Why did pipeline coverage fall in the enterprise segment?” It should recur often enough that the organization ought to have a stable definition and response path. Weekly questions expose a hard truth: repetition does not automatically create resolution. Teams can rebuild the same answer every Monday because nobody owns the definition between meetings.

2. A monthly cost or margin question

Choose a question that requires Finance and an operating function to work together, such as, “Why did gross margin miss plan in the West region?” Monthly questions reveal waits hidden by the close calendar: allocation rules, late adjustments, offline models and the final approval from someone who is not in the working session.

3. An operational exception

Choose something that should trigger a response, not a report. Examples include a service-level breach, an inventory risk or a sudden rise in customer cancellations. Operational exceptions show whether an answer reaches the person who can intervene while the window is still open. A correct explanation delivered after the recovery window has closed is historical reporting.

4. A forecast input computed by two functions

Choose an input that Finance and another team calculate separately, such as hiring capacity, conversion, demand or churn. These questions isolate semantic delay. If both teams can defend their numbers, the problem is rarely a careless analyst. It is that the metric was never written as an organizational contract with one owner, one logic and explicit change rules.

5. A question that quietly disappeared

Find a question that was asked once, discussed and never formally closed. This is often the most revealing of the five. The organization may have stopped asking because the path was too expensive, not because the issue stopped mattering. Those unresolved questions accumulate as answer debt, and they return when the consequence becomes large enough to force another investigation.

Run the audit in one afternoon

The audit needs a small room, a visible timeline and people who were actually involved. Invite the person who owns the meeting where the question was asked, one person who assembled the answer and one person who had to trust it. Add a functional owner only when the path crosses their area. Ten observers will make the reconstruction slower and less honest.

Step 1: Write the exact question

Copy the sentence from the message, agenda or meeting notes. Do not improve it. Ambiguous wording is part of the evidence. “What happened to revenue?” and “Which controllable changes caused net revenue to miss the September plan?” are not the same request. If the question changed during analysis, mark the point where it changed.

Step 2: Name the decision and the owner

Ask what decision the answer was supposed to support and who had the authority to make it. If nobody can name either, stop the clock and record an ownership failure. Analysis without a decision owner can remain open indefinitely because no event closes it.

Step 3: Reconstruct the timestamps

Work from evidence rather than memory wherever possible. Find the first ask, the first response, the first usable number, the moment competing definitions surfaced, the sign-off and the action. Round to the nearest useful unit. Hours are enough for an operational exception. Days may be enough for a monthly planning question. False precision adds work without changing the diagnosis.

Step 4: Mark waiting separately from working

For every gap, ask whether someone was actively doing the work or the question was waiting in a queue. A six-hour calculation and a three-day wait for approval are different constraints. So are a missing source and an unresolved definition. Combining them into one duration produces a number but no remedy.

Step 5: Record the action, not the presentation

The endpoint is a named action with an owner and a date. “Shared with leadership” is not an action. “The sales leader changed territory coverage on Thursday” is. If the answer was accepted but no action followed, record the decision-to-action delay rather than pretending the path ended at sign-off.

Use a one-page audit sheet

Create one row for each of the five questions. Keep the sheet plain enough to use again next month. The minimum fields are:

  • The exact business question and the decision it was meant to support.
  • The person who owned the question and the person authorized to act.
  • Asked at, first answer at, trusted answer at and action at.
  • Sources used, metric definition used and any competing definition that appeared.
  • Every handoff, approval and period of idle waiting.
  • The longest delay, its cause and the owner of the repair.

Add one sentence at the end of each row: “This question was slow because...” Force a single primary cause. You can keep secondary observations, but the repair needs one owner. If the sentence contains three departments and four tools, the group has described the landscape instead of choosing the constraint.

Read the pattern, not just the total time

Two questions can both take six days and require completely different repairs. The useful output is the shape of the delay.

The first answer is slow

If most time passes before any answer appears, inspect the governed foundation: source access, data quality, lineage and ownership. This is the one case where pipeline, modelling or collection work may be the primary fix. Confirm that the delay is repeatable before turning a single hard query into a platform programme.

The first answer is fast, but trust is slow

If a number appears quickly and the meeting spends days reconciling it, the failure sits in the semantic contract. Write what the metric includes, excludes, which date counts, which source may compute it and who can approve a change. Metric definitions are organizational contracts, not notes attached to a dashboard.

The answer is trusted, but action is slow

If everyone accepts the answer and nothing changes, the constraint is decision ownership. Name the person allowed to act, the threshold that triggers action and the exceptions that require escalation. Do not send this problem back to the data team. The warehouse cannot shorten an approval chain.

The same question restarts every cycle

If the team reconstructs the answer each week, the organization has treated a recurring decision as a one-off analysis. Store the definition, source, owner and response rule where the next question will be asked. Building another chart without fixing those contracts adds dashboard entropy rather than shortening the path.

What not to fix first

Do not begin with a tool selection. The audit is diagnostic evidence, not a disguised requirements workshop. A new BI layer may improve access. An analytics agent may reduce retrieval time. Neither will decide which definition Finance and Sales must use or who is allowed to sign the answer.

Do not use dashboard adoption as a proxy. A frequently opened dashboard can still feed a week-long argument. A rarely opened one may be perfectly useful for a quarterly decision. Measure the path around a real question, not clicks on the artifact.

Do not average the five questions into a single number too early. A mean hides the operational exception that was fast and the forecast question that never closed. Keep each path visible until the repeated constraint is obvious. The later measurement system can be more sophisticated. The first audit should remain legible to the people who own the decisions.

Turn the result into a 30-day repair

Choose the delay that appears in at least two of the five paths and is narrow enough for one owner to change. Then run a short repair cycle:

  1. Week 1: confirm the decision, definition and owner for one recurring question.
  2. Week 2: agree the permitted source, the evidence required for trust and the escalation rule.
  3. Week 3: put the answer into the channel or meeting where the question already appears.
  4. Week 4: run the same question again and compare the timestamps.

The output is not “latency improved.” It is a before-and-after path that names what changed. Perhaps the team removed two approval waits. Perhaps Finance and Sales adopted one conversion definition. Perhaps an operational answer now reaches the accountable manager before the daily review. Specific repairs are what turn a framework into an operating habit.

The audit is allowed to come back quiet

If the five questions move quickly from ask to trusted action, do not invent a transformation programme. You may have a local collection problem, a capacity constraint or no material problem at all. A diagnostic earns trust when it can conclude that the proposed cure is unnecessary.

More often, the audit reveals that the visible data work was not the long part. The wait accumulated in interpretation, competing definitions, ownership and blessing. That is useful news. Those are operating choices, and a leadership team can start changing them before the next platform budget exists.

Start with five real questions. Keep the timestamps honest. Fix the longest repeated wait. Then run the same audit again.

Decision Latency: How to Diagnose and Measure takes the neighbouring argument.

Sources

Questions about this article

How do you audit decision latency in a company?

Select five recurring business questions and reconstruct each path from the first ask to a trusted answer and named action. Record timestamps, handoffs, definition disputes, source checks, approval waits and idle time. Compare the five paths and assign one owner to the longest repeated delay.

How long does a decision latency audit take?

A first audit can be completed in one afternoon if you limit it to five recent questions and use existing evidence such as meeting notes, messages, tickets and spreadsheet versions. The aim is a credible baseline and one repair, not a perfect map of every decision in the company.

Who should run the audit?

The person who owns the meeting or operating rhythm where the questions are asked should sponsor it. An analyst can help reconstruct the path, but the meeting owner must resolve ownership, approval and action delays that the data team cannot fix.

Do you need access to the data warehouse?

No. The first pass can use calendars, Slack or Teams messages, email threads, tickets, meeting notes and versioned files. Warehouse evidence becomes useful when the audit shows that retrieval, data quality or lineage is the repeated constraint.

What if the data needed for the answer does not exist?

Record a collection problem and stop that path. Decision latency can only be timed once there is evidence to retrieve and interpret. Missing data needs a capture or source decision before semantic, workflow or analytics work can shorten the path.

Topics

Decision latency
Yagnesh Ramalingam, founder of Zerentro
Yagnesh Ramalingam

Founder & CEO, Zerentro

Is your team stuck on a number like this? Talk it through with me in a free 30-minute call.

Book a 30-minute call