Where Cases Wait

The gap between one activity and the next is where most cycle time goes, and the log measures it exactly.

Measuring it

For every transition, the time between the end of one activity and the start of the next.

Where only one timestamp exists per event, the gap is the transition time and includes the working time of the second activity — a limitation worth stating.

Report as a distribution, not a mean. The median tells you the normal case; the ninetieth percentile tells you what people complain about.

Multiply median wait by transition volume to rank transitions by total delay. That ranking is the work queue.

The four reasons

Distinguishing them matters because the remedies differ completely.

Capacity. The next step is busy. Shows as waiting that rises with volume.

Availability. The next step is not staffed at that hour or that day. Shows as waiting concentrated at particular times, and it is the cheapest to fix.

Dependency. Something else must happen first. Shows as waiting that correlates with another case or an external event.

Batching. Work is deliberately accumulated. Shows as clustering at fixed intervals.

Test which by plotting waiting against volume, against hour of day, and against the calendar.

The invisible waits

Before the first recorded event. A request that sat in an inbox for three days appears nowhere.

Suspension, where a case is on hold. Only visible with lifecycle states.

Outside working hours, which no intervention removes and which inflates elapsed time.

Waiting on the customer, which is real delay and not the operation's to fix — and should be reported separately or every improvement target is unreachable.

Segmenting the wait

By resource or team, which shows where the queue forms.

By case attribute, which frequently reveals that one customer type waits far longer.

By whether the case later reworked, since cases that wait longest frequently also fail.

By day of week, which exposes availability patterns immediately.

The handover finding

Waiting concentrates at handovers between teams, consistently.

Each handover adds a queue, and the queue is usually larger than the work.

Count handovers per case and correlate with cycle time. The relationship is usually strong and it is the argument for reducing handovers rather than speeding up steps.

What to report

The ten transitions with the greatest total delay, with volume, median wait and the reason category.

The proportion of cycle time that is waiting, which is the headline and usually startling.

Waiting on the customer, separated out.

One table. It is more actionable than any map and it fits in an email.

Separating customer wait from internal wait

The distinction that makes a waiting target achievable.

Time waiting on the customer or a third party is real delay and not yours to remove.

Identify it from the activity that precedes it — a request sent, information awaited — or from a suspension state.

Report it separately, always.

Otherwise every waiting target includes time nobody can influence, which makes the target unreachable and the reporting demoralising.

It is also frequently a finding in itself: the chasing process, or its absence, is usually improvable even where the wait is not.

Testing the four reasons

Three plots distinguish them, and the remedies differ completely.

Waiting against case volume. A rising relationship indicates capacity.

Waiting against hour and day of week. Concentration indicates availability, which is the cheapest to fix.

Waiting against the calendar. Clustering at fixed intervals indicates batching.

What remains, correlating with neither, is usually a dependency: something else had to happen first.

Do this before proposing anything, because adding capacity to an availability problem is the most expensive wrong answer available.

Separating waiting from working

The distinction that makes duration analysis actionable, and it needs both timestamps.

With only one timestamp per event, you measure the gap between events — which is working plus waiting, undivided.

With start and end timestamps, you can split them, and the split is usually stark.

Where only one timestamp exists, say so and report the gap as elapsed time rather than as processing time.

Push for the second timestamp in the source system, which is frequently available and not extracted.

Report waiting as a proportion of elapsed time, which is the number that changes conversations.