The Tool Is Not the Problem
Most AI projects fail before the first line of code runs. They fail in the meeting where someone says 'we need AI for that' and everyone nods, and nobody has looked at where the actual time goes.
I have sat in procurement calls where a finance team wanted to automate document extraction because extraction 'felt slow.' We pulled timestamps before the demo. Extraction was taking eleven minutes per invoice. Review and exception routing was taking four days. They were about to spend significant budget shaving eleven minutes off a process that sat idle for ninety-six hours. The bottleneck was not extraction. It was the queue nobody wanted to talk about.
This is the rule I apply on every engagement before I recommend anything. Pull three timestamps per ticket from the last full quarter. Compute time in each stage. Read where work waits. Then decide what to build.
Why Three Timestamps and Not More
You want the minimum signal that reveals the shape of the process. Three timestamps give you two intervals, and two intervals are usually enough to find the dominant wait.
The timestamps you want are when the work item was created or received, when it first moved to active processing, and when it closed or handed off. Those three points expose two things that matter. The first interval shows you how long work sits before anyone touches it. The second interval shows you how long the actual work takes once someone engages.
In most operational processes I have measured, one of those intervals is three to ten times longer than the other. That ratio tells you whether your problem is intake and triage, or execution and completion. They require completely different interventions. An AI agent that speeds up execution does nothing for a triage bottleneck, and vice versa.
If your ticketing or ERP system logs more than three timestamps, pull them. But start with three. It forces you to think in stages rather than in features.
What the Numbers Look Like in Practice
In a regional distribution operation I worked with, the operations team was convinced their problem was in order picking. Pickers were slow, errors were high, and the floor supervisors wanted a computer vision system to guide pick paths.
We pulled timestamps for every order ticket over one quarter. Created, first scanned at pick station, closed at dispatch. The picking interval averaged twenty-two minutes. The created-to-first-scan interval averaged three hours and forty minutes. Orders were sitting in a digital queue waiting to be assigned to a pick run, and the assignment logic was manual, done twice a day by one coordinator.
The actual bottleneck was assignment scheduling, not picking speed. We built a lightweight prioritization agent that ran continuously and cut the queue wait to under thirty minutes. Picking speed was never touched. Throughput went up materially because we fixed the right stage.
In a field operations context in utilities, the team wanted AI to help technicians write job completion notes faster. Notes were taking technicians eight to twelve minutes on average. We pulled timestamps and found that the median time from job close to the next job dispatch was two hours and twenty minutes, mostly because dispatch was waiting on those notes to confirm asset status before releasing the next ticket. The note-writing time was real friction, but the dispatch wait was the constraint. Fixing note speed without fixing the dispatch dependency would have produced almost no throughput gain.
How to Run the Analysis Without a Data Team
You do not need a data science team to do this. You need someone who can write a basic query or export a spreadsheet, and someone who understands the process well enough to name the stages.
Here is the method I give to operations leads directly.
- Pick one ticket type that represents high volume or high pain. Not the most complex edge case, the common case.
- Export every ticket closed in the last quarter with at least three timestamp fields. Created, first status change to in-progress or equivalent, and closed.
- Compute two columns. Interval A is the difference between created and first in-progress. Interval B is the difference between first in-progress and closed.
- Compute the median and the 90th percentile for each interval. Do not use averages alone, they hide the long tail.
- Plot a simple histogram for each interval. Look at the shape. A bimodal distribution usually means two different populations of work are mixed together and should be separated.
- Compare the median of Interval A to the median of Interval B. Whichever is larger is your primary bottleneck stage.
- Look at the 90th percentile of each. If the 90th percentile is more than four times the median, you have a reliability problem in that stage, not just a speed problem.
This takes an afternoon. It costs nothing. It will almost certainly change what you think you need.
What the Bottleneck Stage Tells You to Build
Once you know which stage dominates, the intervention becomes much more obvious.
If Interval A is the problem, work is waiting before anyone touches it. The causes are almost always one of three things, intake is unstructured so routing is manual, volume is spiky and triage capacity does not scale, or priority logic is unclear so everything waits in a flat queue. AI agents that help here are classifiers, routers, and prioritization engines. They do not need to be sophisticated. They need to be fast and available continuously.
If Interval B is the problem, work is slow once someone engages. The causes are usually information lookup, approval chains, or output formatting. AI agents that help here are retrieval-augmented assistants, draft generators, and structured data extractors. These are the agents most vendors demo, because they are visible and satisfying to watch. They are also the ones most often bought to solve the wrong problem.
In a manufacturing quality context, I worked with a team where Interval B looked enormous until we broke it down further by adding a fourth timestamp at the point where the ticket was waiting on a second approver. That wait alone accounted for sixty percent of Interval B. The fix was not an AI agent at all. It was a policy change that allowed single-approver sign-off on a defined class of defect. The timestamp analysis made that visible. No vendor would have surfaced it.
Honest Limits of This Method
This method finds time-based bottlenecks in ticketed or transactional workflows. It does not find quality problems, it does not find bottlenecks in work that is not logged, and it does not tell you whether the work being done is the right work.
If your process has significant rework loops, three timestamps will undercount the true effort because rework often resets or duplicates records. In that case you need to look at ticket reopen rates or duplicate ticket volume alongside the timestamps.
If your team does a lot of work outside the system, in email threads, in spreadsheets, in verbal handoffs, the timestamps will show you a clean process that does not reflect reality. Before you trust the numbers, walk one ticket through the actual process with the person who does it. Ask where they go outside the system. That gap is often where the real time goes.
And be honest about sample size. One quarter of data is usually enough for a high-volume process. For a process that generates fewer than fifty tickets a month, you may need six months to get a stable picture.
Do This Before the Next Demo
The practical takeaway is simple. Before you take any vendor demo, before you write any requirements document, before you approve any AI project budget, run this analysis on the process you are trying to improve.
Pull three timestamps per ticket from last quarter. Compute the two intervals. Find the stage where time accumulates. Then ask whether the tool being demoed addresses that stage specifically.
If the vendor cannot tell you clearly which interval their product shortens, and by what mechanism, that is a signal worth taking seriously.
The teams I have seen get real operational value from AI agents are the ones who came to the problem knowing exactly which stage was costing them. They were not impressed by demos. They were looking for a specific fix to a specific wait. That clarity made every subsequent decision faster and cheaper.
Three timestamps. One afternoon. It is the cheapest engineering work you will do this quarter.