Process Optimisation: Shorten Lead Time, Not Touch Time

Process optimisation is usually sold as speed. In practice the useful version is about finding where a process waits, because in almost every administrative process the time spent working is a small fraction of the time elapsed.

This is a practical method for shortening lead time, the three measurements it depends on, and why the obvious fix — making the work faster — is usually the wrong one.

Touch time versus lead time

Two numbers describe any process. Touch time is how long the work actually takes when someone is doing it. Lead time is how long it takes from request to completion, including every wait.

In administrative processes the ratio between them is routinely brutal. A quotation that takes forty minutes of real work can take nine days to reach the customer. An onboarding that involves two hours of tasks can take three weeks. The work is not slow; the waiting is.

This has a direct consequence for where to spend money. Automating the work attacks touch time, which was never the constraint. Halving forty minutes of effort inside a nine-day lead time changes the customer experience by almost nothing, while costing a project. The waits are where the lead time lives, and waits are usually free to remove.

Where processes actually wait

In queues. Work sits because the next person is busy with other work. This is the largest single component in most administrative processes and it is invisible in every system that reports only handling time.
For approval. Often a genuine wait of days for something that takes a minute to decide.
For information — from a customer, a colleague, another department. Each round trip adds a full cycle of someone noticing, responding and someone else noticing the response.
For a batch. Anything that runs weekly means an average wait of half a week before it even starts.
In rework loops, where an item goes backwards because something was wrong or missing. These are the most expensive waits because they repeat earlier steps as well.

The pattern worth internalising: most of the lead time is created by handovers, not by tasks. Every handover introduces a queue, and every queue introduces waiting proportional to how busy the receiving person is.

Three measurements, in order

1. Count the handovers

Walk one real case end to end and count how many times it changes hands, including going back. Not the documented process — an actual case, ideally a recent one that went badly. Most people are surprised, because the documented version omits the informal steps that were added to fix problems nobody recorded.

2. Measure lead time distribution, not average

Averages hide the problem. If your average is four days, that is likely a mixture of many cases at one day and a long tail at fifteen. The tail is where customers form their opinion and where the cost sits, and the fix for the tail is usually completely different from anything that would move the average.

Report the median and the 90th percentile together. If they are far apart, you do not have a slow process — you have a process with a category of case it handles badly, and finding that category is the whole job.

3. Separate touch time from wait time

Estimate, per step, how long the work takes and how long the item waits before that step starts. You do not need precision; the ratio is usually so lopsided that a rough estimate points at the right target. If waiting is 90% of lead time, no amount of making the work faster will matter.

What actually shortens lead time

Remove a handover. The single most effective change available, and it usually costs nothing but a decision about authority. If a step exists only so that someone is informed, replace it with a notification rather than a queue.
Raise approval thresholds. Approvals below a value where the approver has never once said no are ceremonial. Calculate the cost of the delay and compare it with the value being controlled — the comparison is often embarrassing.
Make batches smaller and more frequent. A run that happens daily instead of weekly removes an average of three days of waiting, and usually requires no new software at all.
Collect information once, completely. Most rework loops start with an incomplete request. A better intake form is a boring change that removes an entire category of round trip.
Set a work-in-progress limit. Counter-intuitively, starting fewer things finishes them faster, because queues shrink. Teams almost always resist this and are almost always convinced by the numbers afterwards.

Where automation belongs — and where it does not

Automation is genuinely valuable in specific positions in a process, and misapplied elsewhere:

Good: the high-volume, rule-clear step that creates a queue behind it. Removing that bottleneck moves the whole line.
Good: the information-gathering round trip, where automatic validation at intake prevents the rework loop entirely.
Poor: the step that already takes four minutes and is done twice a week. The saving is real and irrelevant.
Actively harmful: automating a step whose handover you could have removed. You have now made a queue permanent by building infrastructure around it.

A rule that has held up well: simplify first, then automate what survives. Automating a process you have not simplified locks in the complexity, because the code becomes the documentation of decisions nobody remembers making.

Little's Law, and why starting less finishes more

There is one piece of arithmetic worth knowing, because it explains the most counter-intuitive advice in operations. Little's Law states that average lead time equals work in progress divided by throughput.

Read practically: if forty cases are open and your team completes ten a week, average lead time is four weeks — regardless of how hard anyone works. To shorten it you either complete more per week, or you have fewer open at once. Most teams try only the first, which is the harder of the two.

This is why limiting work in progress shortens lead time without anyone working faster. It also explains why adding cases to a busy team makes everything slower rather than the new case merely joining the back of the queue — each additional open item lengthens the average for all of them.

It has an uncomfortable corollary for how work is assigned. A team told to "pick up whatever comes in" will accumulate work in progress until lead time is intolerable, then triage under pressure. A team with an explicit limit refuses work earlier and visibly, which feels worse and performs better.

Making the queue visible is half the fix

Most administrative queues are invisible: items sit in inboxes, in someone's head, or in a system that reports only what has been completed. You cannot manage a wait you cannot see, and a surprising amount of improvement comes from simply making the waiting visible without changing anything else.

Put every open item on one board with its age, not just its status. Age is the number that provokes action; status is the number that reassures.
Flag anything older than your 90th percentile automatically. That is the tail, and the tail is the customer experience.
Show queues between steps, not just totals. A total tells you the process is slow; a queue tells you where.

A note on what "doorlooptijd" means here

This article is about the lead time of a business process — quote to order, request to fulfilment, invoice to payment. That is a different question from how long an implementation project takes, which we cover separately in our guide to <a href="/nl/hoe-lang-duurt-ai-implementatie/">AI implementation timelines</a>. The methods do not transfer: project duration is about scope and dependencies, process lead time is about queues and handovers.

How we approach it

Our €2,500 audit walks one real case end to end, counts the handovers, and splits touch time from wait time — which regularly concludes that the process needs simplifying rather than automating, and says so. Where automation is the right answer, a €20,000 proof of concept runs four to six weeks against a measured baseline, and production starts from €50,000.

Frequently asked questions

What is the difference between lead time and touch time?

Touch time is how long the work takes while someone is doing it. Lead time is the total elapsed time from request to completion, including every queue and wait. In administrative processes the two are often an order of magnitude apart.

A task with forty minutes of touch time can easily have a nine-day lead time.
Automation usually attacks touch time, which is rarely the constraint.
If waiting is 90% of your lead time, making the work faster changes almost nothing for the customer.

How do you shorten lead time without new software?

Attack the waits rather than the work. Most of the available gain costs a decision rather than a budget.

Remove a handover — every handover creates a queue, and queues are where the time goes.
Raise approval thresholds that exist below a value where anyone has ever declined.
Run batches daily instead of weekly; that alone removes an average of three days.
Improve the intake form so incomplete requests stop generating rework loops.
Limit work in progress. Starting fewer things finishes them faster.

Should we map the process before optimising it?

Walk one real case rather than building a full map. A complete process map is a large piece of work that tends to describe the documented process, not the one that runs.

Pick a recent case that went badly — it exposes the informal steps added to handle problems nobody recorded.
Count handovers and note where the item waited. That is usually enough to find the constraint.
Full mapping earns its cost when several processes share a bottleneck, or when a regulator requires the documentation.

When is automation the wrong answer to a slow process?

When the delay is caused by waiting rather than working, which is the usual case. Automating a step whose handover you could have removed makes the queue permanent by building infrastructure around it.

Simplify first, then automate what survives — otherwise the code becomes documentation of decisions nobody remembers.
A step taking four minutes twice a week is not worth automating regardless of how easy it is.
If the median and the 90th percentile are far apart, you have a problem category, not a slow process. Find the category first.

Process Optimisation: Shortening Lead Time, Not Touch Time