Which wait are you measuring?
People sometimes call the wait from available information to completed action 'decision latency.' There can be another wait before that: from the event happening to usable information reaching the business. Keep those two waits separate so you can see what has actually improved.
The delay may come from a late report, an alert no one sees, an unclear owner or a slow approval. Check the current process first. Your reporting tool may already be able to send the right alert; the harder problem may be deciding who responds.
Write down four times
| Time | Meaning | Where to check |
|---|---|---|
| 1. Information available | The relevant information is available in an agreed source. | Record or export timestamp. |
| 2. Manager aware | The designated reviewer becomes aware of the issue. | Acknowledgement or a documented observation. |
| 3. Decision made | The required decision and authorisation are complete. | The recorded decision. |
| 4. Work completed | The chosen action has actually been carried out. | Dispatch, update or completion evidence. |
Subtract each time from the next to see how long each stage took. Add those waits for the total time from available information to completed work. An alert being sent is not the same as a person reading it, so record both times if that difference matters.
Use the same time zone for every record. Decide whether to count all hours or only working hours, and stick to that choice. If you do not know when someone first saw the issue, say so; the time an email arrived does not prove when it was read.
A made-up 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.
Before changing the process
| Interval | Timestamps | Duration |
|---|---|---|
| Waiting to be seen | Friday 20:00 to Monday 09:00 | 61 hours |
| Waiting for a decision | Monday 09:00 to Tuesday 17:00 | 32 hours |
| Waiting for the work | Tuesday 17:00 to Thursday 08:00 | 39 hours |
| Total | Friday 20:00 to Thursday 08:00 | 132 hours |
Some of this wait may be a weekend, missing records or lack of transport. Write those reasons down. The table shows where to investigate; it does not mean every hour can be saved.
After changing the 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.
This version also assumes a manager is available and transport is possible. The numbers do not prove that software caused the difference. In a real test, consider changes to staffing, stock and deliveries too.
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.
Fix the part that actually causes the delay
First see whether an alert you already have, a named owner or a better handover solves the problem. Omni may help bring records together and send a review to the right person, but the records must be current. Sending messages or changing records needs separate approval.
The report guide helps you check what is missing. How Omni works explains the steps we take, and the restaurant page gives task examples.
Compare with how long it takes today
Collect several real examples of the same kind of decision. Show how many you measured, the typical wait, the shortest and longest waits, and cases with missing times. Keep ordinary and unusual cases separate.
Agree a realistic goal with the person responsible for the task. Check accuracy as well as speed: a quick wrong decision is not an improvement. The before-and-after worksheet helps you record the result.
Common questions
Does a faster alert mean faster detection?
Only if your detection definition is the software event. In this guide, detection ends when the designated reviewer is aware, so notification and awareness must be distinguished.
Do we need new systems to measure this?
Existing records and a simple worksheet may be enough. Confirm the meaning and reliability of each timestamp rather than assuming a message proves a decision or completion.
Must the tool make decisions by itself to save time?
No. Better data, prepared evidence, clearer ownership and routing may reduce delays while retaining the required review.
Talk through your taskDescribe a recurring decision and where your team believes it waits.