Process Bottleneck Analyst
Finds where work waits, not where people work
Approval holds cases for 24h on average and accounts for 54% of all waiting.
10 cases through 5 steps: 48.5h from first arrival to last finish on average, of which 44.4h is waiting and 4.1h is work.
Flow efficiency is 8%: only that share of the time is spent working on the case.
Billing is next, with 26% of the waiting.
Why cases queue (capacity, approvals, hand-offs) is not in the data; times are calendar time as written, so nights and weekends count as waiting.
Average time per step
Share of all waiting time (%)
- Intake1%
- Review6%
- Approval54%
- Fulfilment13%
- Billing26%
Steps
| Step | Cases | Avg wait | 90th pct wait | Avg work | Efficiency |
|---|---|---|---|---|---|
| Intake | 10 | 0.3h | 0.4h | 0.3h | 42% |
| Review | 10 | 2.8h | 3.5h | 0.8h | 21% |
| Approval | 10 | 24h | 30h | 0.3h | 1% |
| Fulfilment | 10 | 5.6h | 7.2h | 2.3h | 29% |
| Billing | 10 | 11.7h | 15.2h | 0.4h | 3% |
What to do this week
- Look at Approval first: cases wait 24h there and only 0.3h is work. Find who or what releases them.
- Then Billing: 11.7h average wait, 26% of all waiting.
- Set a service level for the wait at Approval, for example no case waits more than 30h, and track it daily.
Do
- Map who releases a case at the bottleneck and how often they look at the queue.
Don't
- Don't add capacity to steps that are not the bottleneck: it will not shorten the end-to-end time.
How to improve
- Add working hours per step so the next report can exclude nights and weekends from waiting.
- Add case type and value so the next report can see which cases wait longest.
Demo
Overview
Ask a team how long their process takes and they will add up the work: an hour to review, twenty minutes to approve, half a day to prepare. Measure it end to end and it takes eleven days. The difference is queue time — work sitting in an inbox, waiting for a batch run, waiting for a meeting that happens on Tuesdays, waiting for the one person who can do that step.
Almost every improvement effort targets touch time, because that is what people can see themselves doing. It is usually under a tenth of the total, so halving it changes end-to-end time by almost nothing, and everyone concludes the process is simply complicated.
Queue time is visible in timestamps every workflow system already records, and it is rarely spread evenly. It concentrates at one step, usually for a structural reason: a single approver, a step that only runs with a batch, a handover between teams in different time zones, or a rejection loop where work goes backwards and rejoins the queue at the end.
That last one is the finding people miss most, because rework is invisible in a throughput number — the item eventually completes.
This agent reports where the time actually goes, names the structural cause of each queue, and says what removing it would change. It alters no workflow and never assesses an individual.
Benefits
Effort aimed at the real constraint
Rather than at the part everyone can see themselves doing.
Days removed, not minutes
Because the queue is where the days are.
Rework finally counted
It is usually the second largest cost and it appears in no report.
What it does
Separates queue time from touch time
Touch time is usually under a tenth of the total. Halving it changes nothing, and that is why improvement efforts disappoint.
Names the structural cause
A single approver, a batch window, a time-zone handover. Not "this step is slow".
Measures rework loops
Work that goes backwards and rejoins the queue. Invisible in throughput, because the item eventually completes.
Finds single points of dependency
One person who can do a step, and what the process does the week they are away.
Says what removing each queue would buy
In days off the end-to-end time, so the fixes can be compared.
Assesses no individual
A queue at one person's step is a capacity and design finding. Measuring people's speed changes what gets recorded, not what happens.
What this changes
What this changes about your week
- It takes over
- Measuring where end-to-end time actually goes in a process.
- Done today by
- Estimated by adding up the work, which misses the waiting entirely.
- How often
- Whenever someone complains it is slow.
- Typical manual effort
- Queue time only exists in timestamps nobody reads end to end.
Why Operations in particular. Touch time is usually under a tenth of the total, so every improvement effort targets the visible part and changes almost nothing. And rework is invisible in throughput, because the item eventually completes.
Runs unattended
Started by you or by an event, and it finishes on its own. Nothing waits for someone to be at a desk.
The same standard every time
The two-hundredth item is held to the bar the first one was. Consistency is the part people cannot sustain.
It cannot act on its own
Process Bottleneck Analyst has no path to sending, spending or committing. That limit is why its output is safe to act on.
How it runs
This agent runs server-side through the PROMIVO runtime. Each run is logged step by step and every tool call is permission-checked before it executes.
- 1InputValidated against the agent input schema
- 2Modelclaude-opus-5 with automatic fallback
- 3Toolsextract_structured_data
- 4PermissionsRuns READ actions automatically; anything higher waits for approval
- 5OutputStructured result matching the output schema
- 6LoggingTokens, duration and every step recorded
Requirements
Integrations
No integrations required.
Before you start
- Per-item step timestamps: entered, started, completed
- Which step each item moved to, including backwards moves
- Working hours or calendars, where they differ by step
- Requires the All-Access plan or higher
Use cases
A process everyone says is too slow
Where the time actually goes.
Before automating a step
Whether that step is the constraint or the visible one.
Service level problems
Which queue is causing the breaches.
After a process change
Whether the queue moved rather than disappeared.
Pricing
All-Access
Billed monthly through your PROMIVO subscription. Cancel at any time.
Runs consume your plan allowance for agent executions and tokens. See plan limits
FAQ
Does it measure how fast individuals work?
No, and it must not. A queue at one person's step is a capacity and design finding. Measuring people's speed changes what gets recorded rather than what happens, and it destroys the data this depends on.
Does it change our workflow?
No. It has no access to any workflow system and alters nothing. It reports where the time goes.
What data does it need?
Timestamps: when each item entered and left each step, and who or what handled it. Every workflow, ticketing and case system already records this, and almost nobody reads it end to end.
Reviews
Reviews open once customers have run this agent.
Need this agent to work differently?
Tell us what to change and our team will scope a customised version for your business.
Customize this agent