A service can take days to complete even when the actual processing takes less than an hour. Adding staff may not solve the delay if cases spend most of their time waiting for information, approval or the next handover. Trace a small set of real cases before choosing the intervention.
Define where the clock starts and stops
Elapsed time is the duration between a defined start and end for a case. It includes time spent working on the case and time spent waiting. Choose one service and a clear boundary: for example, from receipt of a complete request to delivery of the confirmed outcome. Also record time before completeness if customers experience it. A narrow internal measure should not hide the wider customer journey.
State whether elapsed time means calendar time or working time. Define weekends, pauses and the treatment of requests awaiting customer information. Keep both the operational definition and the reason for it. The operational performance overview places timing alongside quality, cost and other measures.
Follow cases through the actual process
Record timestamps for receipt, readiness, processing, approvals, returns and completion. Include routine cases and exceptions. Observe actual work with the people who perform it; a procedure diagram may omit informal queues or repeated clarification. Protect customer information and use identifiers that do not expose unnecessary personal data.
Value-stream mapping (VSM) considers flows of work and information across a process. Use the idea to understand the whole service rather than optimising one desk in isolation. Record case volume and complexity so an unusual sample is not mistaken for normal performance.
Separate work, waiting and rework
Processing time is the time during which work is performed on a case. Waiting time is time without processing within the measured boundary. Rework means repeating or correcting work because of an error or missing information. Record it as a type of work; do not add its duration again if processing time already includes it.
In a hypothetical example for illustration, working minutes run from the start of intake to completion of approval. This example excludes delivery to the customer after approval. Intake takes 10 minutes, waiting for review takes 120, review takes 20, waiting for approval takes 60 and approval takes 10. Total elapsed working time is 220 minutes: 40 processing and 180 waiting. The example is arithmetic, not a sector benchmark.
This sequential example has no overlap or rework. Processing time here describes activity duration, not total staff effort. If 2 people work together for 10 minutes, the duration is 10 minutes and their combined effort is 20 person-minutes. In real processes, parallel activities require care: adding every task duration can exceed elapsed time. Mark rework separately, including the reason a case was returned. A queue before approval and a return caused by missing information may need different changes.
Record events before summarising time
For each case, record entry into a stage, the start and end of work, and the reason for moving on. If a system records when a screen closes, do not assume that this is when the customer receives the completed service. Check field definitions with system users and trace real cases from beginning to end. Different interpretations of an event can matter more than the difference you are trying to measure between teams.
The earlier sequential example can be shown as the following timeline. All values are fictional working minutes from the start of intake; they are neither performance targets nor actual ATMACSS results.
| Event | Minute from start |
|---|---|
| Intake started | 0 |
| Intake completed | 10 |
| Review started | 130 |
| Review completed | 150 |
| Approval started | 210 |
| Approval completed | 220 |
This makes the calculation checkable: waiting for review is 130 minus 10, while waiting for approval is 210 minus 150. If an end time precedes a start time, investigate data entry, time zones and field definitions before using the result. Automatically replacing implausible values with zero can conceal a data-quality problem.
Test the reason for the delay
Ask whether work arrives in batches, whether only one person can approve, whether information is incomplete or whether priorities change repeatedly. Check the evidence rather than assuming low effort. A busy team may be handling avoidable rework or responding to interruptions that are invisible in a summary report.
Compare arrival patterns and available capacity over relevant periods. Review long waits alongside the arithmetic mean: total case durations divided by the number of cases. A single figure can hide important variation between cases. Where priorities differ, explain the service rule rather than treating every case as equivalent.
Run a bounded improvement
- Select one observed cause and define the intended change.
- Assign an owner and an agreed trial period.
- Measure elapsed time, waiting and errors on comparable cases.
- Check the next stage for a displaced queue.
- Keep, adapt or reverse the change based on the evidence.
Possible changes include a clearer completeness check, an agreed approval window or a backup approver within delegated authority. These are options to test, not universal prescriptions. Do not remove a necessary safety, quality or financial control merely to shorten the measured time.
Compare the trial with similar cases
Select a comparison group that reflects request type, complexity, channel and operating period. Comparing a quiet trial day with a busy baseline day could mistake a change in demand for an improvement. Record workload, staffing and other relevant changes, and explain the limitations of a small sample. A before-and-after difference alone does not establish that the intervention caused it.
Review unfinished cases as well as completed ones. Completion time may look good because a team finishes easy requests while complex cases accumulate. Show the number and age of open requests and the reasons they are waiting alongside completion times. This can reveal an apparent improvement in a report that customers still waiting for service do not experience.
Check quality and the effect on the next stage too. Faster intake that passes on incomplete requests may move the delay to review and increase requests for customer clarification. Discuss the outcome with receiving teams: has rework decreased, or merely moved? A successful trial improves the overall flow within its stated boundary, rather than producing a better number at one point.
When adopting the change, specify who monitors whether the result lasts and when to reopen the review. Higher demand or a changed service may require different staffing arrangements or handover methods. Keep the measurement definition consistent, or document changes, so later comparisons remain interpretable and the team knows when another intervention is needed.
Make the improved flow maintainable
Update responsibilities, work instructions and escalation rules after a successful trial. Confirm that the improvement survives normal variation and does not depend on one unusually experienced employee. Continue tracking errors, customer follow-up and unfinished work alongside speed.
Start with clear measurement boundaries and reliable event records. Separate processing from waiting, then investigate the reason for delay. Test a limited change and compare similar cases while tracking quality and open requests. Add capacity when evidence supports the need, not simply because total time is long.
The Business and Operation Modelling service can help connect process boundaries, ownership and measures. The useful result is an understood delay and a tested response, not simply a more attractive process chart.