Business & Revenue OpsFree
Process Cycle Time and Bottleneck Review
Send ticket, task or workflow timestamps, and get every step split into work time and queue time, with the worst handoff named.
A dashboard reporting a 3.6-day average for IT access requests tells nobody where to intervene, because 3.6 days could be four evenly slow steps, or one broken handoff carrying the whole delay while the rest of the process runs fine. Bellwood Analytics, a 34-person software company, ran sixty access requests through exactly that split, work time against queue time, step by step, from raw ticket timestamps rather than a stopwatch estimate. Of the 86.6 hours an average request took start to finish, 0.6 hours was anyone actually doing anything.
Security review alone held 86 percent of that wait, 74.4 of the 86.6 hours, while the review itself took eight minutes once somebody opened it. The instinct when a step reads slow is to add a person to it. The arithmetic says otherwise: review work is eight minutes, so a second reviewer removes almost none of a 74.4-hour wait. The actual cause is a batching habit, one reviewer checking the queue Tuesday and Thursday, so a ticket filed Wednesday morning waits until Thursday regardless of headcount.
This tool takes ticket, task or workflow timestamps and produces that split for every step. Work time is the minutes or hours somebody was actually handling the item. Queue time is the hours or days it sat waiting for that handling to start. It ranks steps by how much of total lead time each one actually contributes, then names the specific handoff worth fixing and what fixing it would take. That is different from a single ticket's timeline or a percentile chart with no step attribution.
Why 'add headcount' is usually the wrong fix
Every generic cycle-time guide draws the same distinction Bellwood's numbers use: lead time is always greater than or equal to cycle time, and the gap between them is queue time sitting in a backlog rather than in anyone's hands. Where the standard treatment stops is the unit of analysis. A worked example from one lean guide splits a single support ticket into processing time and waiting time, finding that one ticket ran 67 percent wait. Nothing ranks which of several steps, aggregated across many tickets, is actually worth fixing first.
The ranking matters because the obvious suspect is often wrong. Manager Approval sounds like the bureaucratic step, and it does carry a real queue, 6.5 hours on average, enough to look like the problem in a casual review. But at 7.6 percent of total lead time against Security Review's 86.1 percent, fixing approval first would be solving the wrong problem competently. A step-by-step split, not one blended average, is what tells you which handoff actually earns the meeting. Once fixed, that step belongs in the procedure itself, not a one-time memo.
The fix has to match the cause, not just the symptom. A step that is mostly work time and overloaded genuinely needs another person. A step that is mostly queue time on a batching cadence needs a schedule change instead. Security Review's own numbers make the case for the second kind: eight minutes of work against 74.4 hours of wait means the position sits idle almost the entire time. Moving that one reviewer to a daily five-minute check, with no new hire, was enough to cut the average request from 3.6 days to about one.
How it works
List the steps
The stages the work passes through, in order, from whatever you'd call the start to whatever you'd call done.
Send the timestamps
A ticket export, a task tracker history, or a description of when each stage typically starts and ends.
Get the split
Every step broken into work time and queue time, ranked by contribution to the total, with the worst one named.
See the fix
Whether the bottleneck needs a person, a schedule change, or a different fix, and what closing the gap looks like.
What you get
- Every step split into work time and queue time, computed from the actual timestamps you provide
- Steps ranked by their share of total lead time, not by how slow they feel in conversation
- The one handoff creating the longest wait, named specifically rather than implied by a chart
- A verdict on whether the fix is headcount, a schedule change, or a different fix altogether
- The cycle-time distribution across every instance in your sample, so an outlier does not masquerade as the average
- A specific description of what removing the bottleneck would take for the step you actually have
Common questions
What counts as a timestamp I can use?
Anything that marks when an item entered a step and when it left, from a ticketing system, a task tracker, or an approval log. A CSV export with a status-change history works, and so does a rougher description of when each stage typically starts and ends if that is all you have.
What if I don't know which step is slow?
That's the normal starting point. Give the tool the process steps and whatever timestamp data exists, and it computes the split rather than asking you to guess first. Most requesters already suspect one step, and the arithmetic frequently points somewhere else entirely.
Isn't this the same as a cycle-time dashboard my tracker already has?
A tracker's built-in report usually gives one blended number, or a percentile across whole tickets. This splits each individual step into work time and queue time and ranks steps by their share of total lead time, which a single aggregate cannot show you.
Our slow step is slow because it's understaffed. Won't this just tell me to hire someone?
Only if the arithmetic supports it. A step with high work time and a real backlog behind it does point toward headcount. A step with minutes of work and hours or days of queue points toward a scheduling or batching fix instead, and the output states which case applies before recommending either.
How many tickets or tasks do I need for this to be reliable?
A few dozen recent instances of the same process is enough to see which step dominates the wait. Fewer than that still works as a first pass, it just makes any single unusual ticket carry more weight in the average.
What happens after I find the bottleneck?
The doc names the fix and what it would take, but making a fix stick is a separate problem: announcing it, handling whatever was mid-process under the old way, and checking it did not quietly revert. The rollout kit picks up there.
Does this replace documenting the process itself?
No. This tool assumes a process already exists and finds specifically where it runs slow. Deciding which undocumented processes are risky enough to write down in the first place, before they can even be measured this way, is a separate question the gap audit answers.
Process Cycle Time and Bottleneck Review
Fill in the form and your workspace opens with the work already underway.