In brief
A long order journey does not necessarily mean an employee worked slowly. The order may have awaited customer confirmation, the next shift or a handoff between roles. Before asking AI to “find the bottleneck,” check what the dates in your system actually mean.
This guide is for an owner of a small service business or shop who wants to understand delays between accepting a request and delivering a result. The method below is Nadali’s proposed editorial workflow, not a pilot we have conducted. It helps choose something to investigate, rather than automatically rate employees.
1. Choose one journey and define its boundaries
Take a specific service, such as preparing a quotation after receiving a complete request. Define its start, finish and exceptions. “Email received,” “all required information received” and “calculation started” are different events. Confusing them changes the explanation of a delay.
Do not mix urgent and standard requests, or routine quotes and complex custom calculations. Record the analysis period and extraction time. Flag cases that began earlier or remain unfinished separately: a truncated history is not a complete duration.
2. Ask for event history, not a list of current statuses
You need a stable request identifier, an event name and its time. Preserve both start and completion times where the system records them. Microsoft’s documentation distinguishes event logs from activity logs this way. A current “completed” status cannot reconstruct earlier transitions; the documentation also warns that some relevant events may not be recorded.
For your working file, we suggest additional fields:
- the source event identifier, to distinguish a repeated export from a repeated action;
- the event time with its time zone and, where available, a separate recording time;
- request type and route: standard, clarification required or repeat review;
- role or team, without individual names for the initial analysis;
- reason for waiting, only when actually recorded;
- a history-completeness flag and a link to the protected original record.
Do not send customer emails, names or amounts to a model simply because the export includes them. Start with a permitted de-identified copy and an approved tool. Stable codes can still allow records to be linked to people: keep the lookup separately and restrict access.
3. Separate three different measures
Total request elapsed time runs from the agreed start to completion. Calendar time matters to customers. For operational comparison, you may also calculate time within business hours separately. Do not silently subtract nights or weekends.
Recorded stage duration runs from that stage’s start to completion. It is not always active labor: someone may open a card and switch to another task. Understand the recording rule.
The gap between stages runs from the previous stage’s completion to the next stage’s start, if they truly occur sequentially. Call it queue waiting only after checking its meaning: it may include customer actions or work outside the system.
Researchers Chapela-Campa and Dumas explain why recorded starts may differ from actual work: an employee can prepare materials before interacting with the system. Their 2022 paper concerns process simulation; it does not establish that a language model can recover missing facts in your log.
With only two completion timestamps, their difference does not reliably separate work from waiting. Do not ask AI to invent that split.
4. Example: an hour-long request with a ten-minute calculation
An imaginary request, Q-17, passes through sequential stages on one working morning. All times are Europe/Kyiv. This is a fictional teaching example.
- 09:00 — complete request received.
- 09:20 — calculation started.
- 09:30 — calculation finished.
- 09:55 — review started.
- 10:00 — quotation reviewed and sent.
Total elapsed time is 60 minutes. Recorded execution intervals are ten minutes for calculation and five for review, totaling 15. The gaps before the stages are 20 and 25 minutes, totaling 45. The sum, 15 + 45 = 60, reconciles only under the assumptions of this simple sequential example.
Suppose AI could shorten the calculation itself from ten to five minutes, while every other time component remained unchanged. Elapsed time would then become 55 minutes, not 30. This is conditional arithmetic, not a forecast: a different handoff time could also change the subsequent queue.
One case cannot establish a bottleneck for the whole business. It only suggests investigating the handoff to review. If calculation and review partly overlap, do not add all their durations as sequential intervals.
5. Give AI a task you can check
Use the model to propose event-name mappings, flag contradictions and explain already calculated measures. Perform calculations with reproducible formulas or a verified data query. Retain the formulas, export version and selection rules.
An example working brief:
“Use only the supplied de-identified table. Do not add missing events or reasons for delays. Propose a stage-name dictionary, but do not merge distinct statuses without explaining why. For every conclusion, identify the request numbers and source rows. Separate observations, hypotheses and checks needed. Flag incomplete histories and cases where execution cannot be separated from waiting.”
Before accepting the result, manually trace several ordinary cases and every type of exception identified. Check duplicates, reversed dates, identical timestamps, reopened requests and transitions between systems. This is an editorial checklist, not statistical proof that the entire export is correct.
6. Look for a recurring obstruction, not a “slow” employee
For one route, show counts of complete and incomplete cases, median elapsed time, the longest verified cases and open cases at the cutoff. Compare arrival times, work types and stages. A large average can reflect a few exceptions; short durations among completed cases can conceal an old open backlog.
A candidate problem should recur and have an explanation that can be investigated. For example: “These requests have their largest gap between calculation completion and review start; check how the reviewer is notified.” The same records do not justify “the reviewer is not working.”
Talk to the team and check selected cases against the original system. Possible explanations include batch processing, incomplete requests, dependency on another role or faulty logging. Do not use this analysis as the sole basis for employment decisions.
7. Change one rule and measure again
Choose a small, reversible change, such as an explicit handoff of ready requests to a review queue with an assigned owner. Record the expected effect and possible downside: frequent notifications can interrupt other work. Do not automate approval or sending commercial terms simply to shorten a chart.
After the change, compare similar requests using the same time boundaries. Track rework, unfinished cases and workload alongside elapsed time. Improvement after a change does not establish causation: demand or work complexity may also have changed.
Availability, limitations and the deliverable
A readable, permitted export and a spreadsheet are enough for an initial review; buying a dedicated platform is not necessary. History availability depends on your system and access rights. When the log does not record the events you need, the result is a plan for better recording, not a trustworthy waiting-time diagram.
The owner’s deliverable is one page: which route was examined, what the data shows, what is missing, which cause is only a hypothesis and which change the team will test. AI helps organize the review; the business remains responsible for event definitions and decisions.
Read also: how to measure time savings from AI and how to preserve codes and dates during CSV import.
Author: Nadali. Prepared using AI. Sources checked November 11, 2026. Cover: a conceptual AI illustration, not data from an actual business.
