In this note
A team asks for an agent to write an invoice explanation faster. The reviewer spends a few minutes on the explanation, then waits for the current purchase order. A better draft could save some effort. It won't supply the missing record or make its owner answer sooner.
I'd trace the case before building that agent. When did it arrive? Who worked on it? What did they wait for? Include the spreadsheet and the follow-up email, not only the events in the main system.
Choose the start and finish first
For these cases, start the clock when an invoice enters the queue. Stop after the approved change is confirmed in the ledger. Finishing a draft or clicking approve happens earlier. Using either as the finish would leave some of the work out of the comparison.
Handling time counts active work: opening documents, comparing amounts, chasing a record, or correcting a field. Elapsed time counts the whole journey, including nights and weekends if you're using a calendar clock. Decide whether to count calendar time or business hours, then use the same clock throughout.
Keep effort separate from duration when people work at the same time. Two people working for ten minutes contribute twenty minutes of effort, while the case clock advances ten minutes. To find gaps in the case clock, mark the active intervals and count overlapping intervals once.
An entry check belongs inside the clock too. If the new design makes an invoice wait before review, count that wait. Keep unfinished cases in the report with their current age; otherwise the slowest work can disappear from your results.
Read the cases before calculating a rate
| Case and return reason | Declared time and returns |
|---|---|
| RX-1: evidence complete | 8 handling minutes; 20 elapsed minutes; 0 return events. |
| RX-2: purchase-order revision missing; two repeat requests | 14 handling minutes; 180 elapsed minutes; 2 return events. |
| RX-3: invoice and purchase-order amounts conflict | 12 handling minutes; 75 elapsed minutes; 1 return event. |
| RX-4: evidence complete; required approval is a forward handoff | 10 handling minutes; 30 elapsed minutes; 0 return events. |
Two cases came back for more work, so 50% of cases had a return. There were three returns in total because RX-2 came back twice. Three returns across four cases gives 0.75 returns per case. Calling that a 75% returned-case rate would count RX-2 twice.
The other two cases finished without going backward for repair. That gives 50% first-pass completion. They still needed review and approval. RX-4's required approval is a normal forward handoff, not a return or evidence of fully automated processing.
- Active handling
- 8 + 14 + 12 + 1044 minutes
- Elapsed durations
- 20 + 180 + 75 + 30305 minutes
- Difference
- 305 − 44261 case-minutes
The 261 case-minutes add up gaps across four cases that may overlap. You cannot turn that total into staff hours saved. It tells you where to look next, but not what caused the gaps. Four teaching cases also tell you nothing about the rate across a company's whole queue.
A gap needs a source and a question
RX-2 took 180 minutes, with 14 minutes of recorded handling. Where did the other 166 go? The record says a purchase-order revision was missing, but it doesn't show when each request and response happened. Some of the gap could be queueing, some could be waiting for purchasing, and some could be unrecorded work.
Put queue events on a timeline and walk through the case with its operator. Check permitted messages for missing steps. Mark unexplained gaps unknown and remembered times as estimates. An open browser window may include other work, and systems may use different time zones. Note how each time was obtained.
Decide why the step exists
For RX-2, try checking for the current purchase-order revision before review starts. If it's missing, hold the case and ask purchasing for it. A second change could keep the request and its status in one queue, so the reviewer no longer copies updates into a tracking sheet.
| Work to change | Disposition, owner, and check |
|---|---|
| Discover a missing source during review | Repair entry checks. Purchasing owns the source; missing or stale evidence stays held rather than producing a guessed proposal. |
| Repeat the request and copy its status into a sheet | Combine status tracking if the queue owner approves. Retain assignment, reminders, history, and escalation before removing duplicate entry. |
| Resolve conflicting amounts | Keep the decision and route unresolved conflicts to finance. A convincing explanation cannot override mismatched source values. |
| Approve, post, and verify the ledger | The designated reviewer still approves and posts the correction under current permissions. A separate ledger check must confirm the change before the case is complete. |
Ask why a repeated step exists before deleting it. The ledger check confirms that the change happened; approval records who allowed it. You might combine the screens while keeping both checks. The person responsible for the control needs to agree that the evidence is still there.
Compare the entry repair with faster review on the same kinds of cases. Ordinary code may be enough to check whether the required revision is present. A model might help interpret an explanation later, but a better explanation won't produce a missing purchase order or settle a disputed amount.
Keep the difficult cases in the comparison
The entry check could move RX-2's wait earlier without shortening it. Start both comparisons at the original arrival event, not after the holding queue. Show held and rejected cases, their ages, and their reasons. Agree how to count cases that are still open when the test ends.
Before testing, purchasing and the service owner need to agree which cases can enter and how results will be checked. Measure their work as well as the reviewer's. Include errors, unresolved cases, and support time. The repair hasn't helped if it saves the reviewer two minutes by adding ten minutes elsewhere.
Use the worksheet to trace one case your team is allowed to inspect. Take its longest unexplained gap to the people on either side of the handoff. Find out what they were waiting for before buying a faster model.