From measuring to improving: finding and fixing your bottleneck

In the previous lesson you made work visible and measured the time of each step. Now you hold numbers that tell you where work is delayed. The next move is not to collect more numbers, but to use them. Measurement that never turns into a change in the path is just a nice-looking report. This lesson is about reading the bottleneck in your data, treating it in the right order, then confirming the treatment worked.

What a bottleneck is

A bottleneck is the step that sets the speed of the whole path. No matter how fast the other steps run, a request cannot finish before it passes through this one. The sign in your data is clear: a longer queue in front of it than anywhere else, and waiting time before it that dwarfs the working time inside it.

Here is a distinction you cannot skip. Working time is the span during which someone is actually handling the request. Waiting time is the span during which the request sits and nobody touches it. In most small organizations waiting is several times the working time — and that is good news: the shortest route to a faster path is cutting waiting, not asking people to work faster.

How to read the bottleneck from your table

Take one month of requests and compute just three columns per step:

Step	Avg working time	Avg waiting time	Waiting now
Intake	10 min	1 hour	2
Pricing	30 min	4 hours	3
Manager approval	5 min	2 days	11
Execution	3 hours	2 hours	4
Closing and invoicing	15 min	1 day	6

The table gives itself away. Approval is the shortest step in working time, the longest in waiting time, and it has the biggest queue. The problem is not that the manager approves slowly; it is that the request waits two days before it reaches their attention at all. Had you tried to speed up execution because it shows the longest working time, you would have tired the team without changing delivery time for the customer.

A concrete example

A small maintenance company took five days to close a service request. Measurement showed that two and a half of those days were spent waiting in front of manager approval, because approval only happened when the manager opened the folder in the evening. The constraint was not the number of technicians or spare parts — it was a single point everything passed through and sat waiting at.

Treat the bottleneck in order

When you find the bottleneck, do not jump straight to the last remedy. Try these options in this order, because the first is the cheapest and the last is the most expensive:

1. Eliminate: ask whether the step is needed at all. Many steps survive from an old problem that no longer exists. Removing a step removes its waiting time entirely.
2. Combine: if two steps are done by the same person and the request waits between them, make them one step.
3. Delegate: push authority down with a clear limit. For example, any request below a set amount is approved by the department lead, and only what exceeds it reaches the manager. That pulls most requests out of the queue.
4. Automate: once the process is simple and clear, automate it — an automatic notice to the step owner, a defined deadline, and an escalation when it is missed.

The order matters. Automating an unnecessary step only means you perform unnecessary work faster.

Checklist before changing any process

• Do I have a before measurement to compare the after against?
• What risk was this step put in place to prevent, and how do I cover that risk once I change it?
• Who owns the new step, by name rather than by department?
• Did I update the written process, or did I change reality and leave the document stale?
• Did I tell the people affected before applying the change?

Change one thing, then measure

Start with the biggest bottleneck alone, run the change long enough for a result to appear, then measure again with the same table. If you change three things at once and the time improves, you will not know which one helped — nor whether one of them is hurting while another masks it. And when the first bottleneck clears, you will find a new one has taken its place. That is not failure; it is the sign that the path got faster and the limit moved to a new point.