Decision latency: the hidden cost in multi-site operations

Definition, and how it differs from data latency

For this guide, decision latency begins when the relevant signal is available to the business and ends when the chosen action completes. Data latency is the earlier delay between an event and usable information about it. Define both consistently; otherwise a faster data feed and a faster review can be confused.

Reporting, alerts, ownership and routing can each affect the result. Inspect the current process before choosing an intervention. A dashboard with useful alerts may solve detection, while a clearer approval route may solve the delay after the issue has been noticed.

Measure it: detect, decide, act

Detect is T1 minus T0; decide is T2 minus T1; act is T3 minus T2. Their sum is total decision latency. An alert being generated is not the same as a person reading it. Record notification time separately if that distinction matters to the workflow.

Use one time zone or normalise the timestamps before calculating. Decide whether the measure uses elapsed or working hours and apply that choice consistently. Missing observations should remain missing; an email timestamp is only a proxy for awareness unless someone confirms it.

An illustrative restaurant example

The following times are invented to explain the method. They are not customer results, an industry benchmark or a forecast of what AI will achieve. Assume a valid stock exception becomes available on Friday at 20:00 and the designated reviewer is the area manager.

A hypothetical current process

The long interval may include a weekend, unavailable evidence or transport constraints. Record those reasons. The table shows where to investigate; it does not establish that every hour can be removed.

A hypothetical revised process

Suppose an alert and review brief are prepared on Friday night. The area manager reads them on Saturday at 09:00, completes the necessary approval at 09:30 and the transfer completes at 13:30. Detect is still 13 hours, even if software generated the alert within minutes. Decide is 30 minutes and act is four hours, giving a total of 17.5 hours.

Those times illustrate a different process with an available reviewer and feasible transport. They do not prove that software caused the improvement. In a real pilot, changes to staffing, stock availability and logistics must be considered alongside the workflow.

Identify where each interval waits

• An exception is available but hidden in a report nobody is scheduled to review.
• The reviewer sees the issue but must gather missing context from several people.
• The decision waits for a person whose authority or availability is unclear.
• An approved action waits for a supplier, vehicle, system update or other external dependency.
• A completion message exists but does not establish that the intended outcome occurred.

Improve the measured bottleneck

First test whether an existing alert, a clearer owner or a better handover solves the delay. A workflow can help prepare evidence and route a review, but its data must be current and its output usable. Sending and record updates need their own authority and controls.

The dashboard comparison helps assess the gap. How a workflow runs explains Genaima's implementation approach, while the restaurant page describes candidate operational tasks.

Set targets from your baseline

Collect a representative set of instances and group comparable decisions. Report the sample size, median, range and incomplete cases. Separate routine decisions from exceptional ones, and elapsed hours from working hours if both matter.

Set an achievable target with the workflow owner. Measure review quality and action correctness alongside speed: an immediate incorrect decision is not an improvement. The pilot measurement template helps record the broader evaluation.

Common questions

Launch your autopilotDescribe a recurring decision and where your team believes it waits.