Five minutes of work. A week of waiting.

Ask an operations team how long it takes to handle a claim, open an account or resolve a service request, and you will usually get an honest answer measured in minutes. Ask a customer how long they waited, and the answer is measured in days.

Both numbers are true. The problem is that the business can explain the five minutes of work, but not the days the customer waited.

The task people show you and the work that actually happens

Sit with someone and ask them to show you how they process a case. What you will see is clean. Open the system, check the record, make the decision, update the file, close. Five minutes, start to finish, and everyone in the room agrees that is how the work is done.

That walkthrough may be accurate, but it does not show everything that happens around the case.

Between the start and the finish of a real case sit the things nobody demonstrates: the interruption from a different case, the email to someone in another team, the spreadsheet kept outside the system of record, the wait on a third party, the handoff to a colleague who picks it up tomorrow, the return of a case that came back wrong, the correction. 

The demonstrated task runs A to B to C. The real operation runs through interruptions, other cases, email, spreadsheets, waiting, handoffs and corrections: five minutes of work spread across days of elapsed time.

If the work in between is invisible, the business case for change is incomplete.

Why this matters more than it sounds

A service level is a promise about elapsed time. You tell a customer they will hear back within two days, or that a claim will be settled within ten. What you are promising is the whole journey, including every wait inside it.

But most operational measurements report active time, that is the minutes of work. When the two get treated as the same thing, an improvement program goes looking for savings inside the five minutes. Teams get trained, screens get simplified, a step gets automated. Active time drops. The customer still waits a week, because the week was never made of active time in the first place.

Three places the elapsed time actually goes

1. Waiting. The case sits between teams, between systems, or on somebody's approval. Nothing is being done to it, and nothing in the system record says so.
2. Handoffs. The case moves, and each move adds a queue at the other end. Two teams can each be fast and the journey between them still slow.
3. Rework. The case comes back. A rework loop rarely registers as a failure anywhere; it shows up as a case that was touched again, by someone else, later.

None of those three appear in a workshop, because nobody demonstrates a wait. Two of them barely appear in system logs either, because the system records the transaction, not the pause before it. 

What changes when you can see it

Once the work is visible end to end, the questions become practical. Where is the case waiting? Where is it moving backward? Where are people repeating work? Instead of arguing about whether the team is working hard enough, which is rarely the problem and mostly the wrong argument, you can point at the three places where the days are actually accumulating, and decide which of them you control.

Not all waiting is yours to fix. Some is internal: an approval, a queue between your own teams, or rework caused by an earlier step. Some sits outside the operation, such as a third party that has not responded. Knowing which is which keeps the improvement effort focused on the time your team can actually change.

Measured results at Pitney Bowes

At Pitney Bowes, Stereologic was used in back-office customer management. According to Stereologic’s published case study, customer-service response time was reduced by 56% and servicing errors fell from 20% to 0%. The project was completed in under 90 days and won the 2014 Process Excellence Award for Best Process Improvement Project under 90 days.
The published case study and the interview with Ronnie Mahabir, Senior Manager, North America Call Centre Operations, at the time of the engagement, are both available on request. 

Measure the process you actually have

Measuring this properly means measuring work as it is actually performed, not as it is described. That is a harder thing to do than running a workshop, and a harder thing to do than reading an event log, because the interesting material sits in neither place.

It sits between applications, in the moments a case is put down and picked up again, in the spreadsheet nobody mentions, and in the second attempt at something that failed the first time.

Automate the process you actually have, not the one on the wall.

Measuring the work in between gives you a baseline you can use to decide what should change and to measure what improves afterwards. The point is not to catch anyone out. It is that a service level you can attribute is a service level you can fix, and a business case built on the five minutes will keep under-delivering against a promise that was always made about the week. 

Where this goes next

If you are being asked to improve a service level you cannot fully explain, start with one operation. The 30-Day Value Leakage Audit gives you a defined way to measure it. Stereologic agrees the scope and metric with you, maps how the work is actually performed, quantifies value leakage in hours and dollars using your own assumptions, and hands back a measured baseline for what to improve, automate or transform next.