How to find the bottleneck in your operations

The bottleneck in your operations usually sits at a handoff: the moment one person finishes their part and the work waits for the next person to pick it up. To find it, follow one real piece of work from request to done. Write down every handoff, mark where the work waits and who holds it, and rank those waits by how often they happen. The step people complain about loudest is often not the one that costs the most. This article walks through each step and ends with a checklist you can run with your own team.

Why the process on the wall isn't the process people use

Most companies have a version of their process written down somewhere. It might be a diagram, an onboarding document, or a list someone made when the team was smaller. It describes how the work was meant to flow on the day it was written.

Then the work changed. A new product line came in, a person left, a tool got added. People adapted, because the work still had to get done. They started a side spreadsheet. They text the warehouse instead of updating the system. They learned that one person knows how to push a stuck order through, so everyone asks that person.

None of those adaptations is wrong. Most of them are smart. But they don't appear on any diagram, and they're where the time goes. If you look for the bottleneck in the documented process, you look in the wrong place. Start from the work instead.

Map one piece of work from request to done

Pick one type of work that repeats: an order, a quote, a service call, a new customer setup. Then pick one real, recent instance of it. Not the typical case and not the worst case. A real one, with a date on it.

Follow it from the moment the request arrived to the moment it was done from the customer's point of view: delivered, installed, or paid. Write one line for every handoff. Each line answers four questions:

• Who passed the work on?
• Who received it?
• How did it move: a system, an email, a phone call, a sheet of paper, a conversation at someone's desk?
• What did the next person need before they could start?

Ask the people who did the work, not only the person who manages them. Managers know the intended path. The people doing the work know the real one, including the side channels. If an order moved because someone sent a text, that text is a handoff. Write it down.

Keep it to one line per handoff. You aren't documenting every task inside a step. You're drawing the route the work took between people.

Mark each handoff where work waits, and who holds it

Every piece of work has two kinds of time in it: time someone spends working on it, and time it sits waiting. The bottleneck lives in the waiting.

Go back through your map and look at each handoff. Ask:

• What tells the next person the work is ready? Do they find out on their own, or does someone have to chase them?
• Does the work sit in an inbox, a queue, or a pile until someone checks?
• Does the next person have everything they need, or do they have to go back and ask?
• Does anything need an approval, and is the approver around when it arrives?

Wherever the answer points to waiting, mark that handoff. Then write down who holds the work while it waits. Use a name or a role.

This isn't about blame. The person holding a wait is often the busiest person in the building, and the wait exists because the handoff was never designed. But a wait without an owner is a wait nobody fixes, so name one.

Rank the waits by how often they happen, not by how loud the complaint is

You now have a list of waits. Resist the urge to fix the one everyone talks about.

Loud problems are memorable. A shipment that went to the wrong customer, a quote that sat for a week and lost the job: those get retold for months. Quiet waits are different. A job that waits a few hours on every single order doesn't make a good story, so nobody tells it. It adds up anyway.

For each wait on your list, answer three questions:

• How often does it happen? Every time, most times, sometimes, or rarely.
• How long does the work sit when it happens? A rough answer is fine: minutes, hours, overnight, days.
• What does it block? Does the next step stop entirely, or can other work continue around it?

Put the waits that happen every time and block the next step at the top. Those are your bottleneck candidates. The rare disaster still matters, but it usually needs a safeguard, not a redesign.

Hypothetical: order entry at a print shop

This example is invented. The company, the people, and the flow are fictional and describe no real business.

A small print shop takes orders by email. Here is the route one order takes, with three handoffs.

1. Customer to sales. The customer approves a quote by replying to an email. The sales rep re-enters the approved order into the job system. The wait: the rep checks email between calls, so approvals sit until the rep is back at a desk. Who holds it: the sales rep. How often: most orders.
2. Sales to production. The production lead pulls new jobs from the job system once each morning and builds the day's schedule. The wait: any order approved after the morning pull sits until the next day. Who holds it: the production lead. How often: every order approved after the pull.
3. Production to billing. When a job ships, production marks it done on a whiteboard. The bookkeeper creates the invoice when they see the board. The wait: the invoice waits until someone notices the board. Who holds it: the bookkeeper. How often: most orders, longer in busy weeks.

The owner complains most about late invoices, because that's where cash shows up late. It's the loud problem.

Ranked by frequency, the second handoff comes first. It hits every afternoon approval, and it pushes the delivery date out, which the customer feels. The first handoff comes next. Billing is real but ranks third.

Notice what the fix for the top wait might be: a second schedule pull after lunch. That's a change in routine, not new software. Sometimes the bottleneck needs a tool. Sometimes it needs a decision.

Checklist: find your bottleneck

Run this with the people who do the work, not only the people who manage it.

• Pick one type of work that repeats.
• Pick one real, recent instance of it, with a date.
• Follow it from request to done, as the customer defines done.
• Write one line per handoff: from whom, to whom, how, and what the next person needed.
• Include side channels: texts, calls, hallway conversations, side spreadsheets.
• Mark every handoff where the work waits.
• Name who holds the work at each wait.
• For each wait, record how often it happens, how long the work sits, and what it blocks.
• Rank the waits by frequency and what they block, not by how loud the complaint is.
• For the top wait, ask whether the fix is a tool or a decision.

When an outside view helps

You can run this checklist yourself, and you should. It still has limits. The people closest to a process often can't see the workaround they built, because to them it's how the job is done. Teams also disagree about where the work stalls, and a map drawn from memory settles that argument less well than one drawn from watching.

That's the work of a workflow audit: someone outside the process watches it happen, on site or remote, maps every handoff, and ranks the stalls. It ends with a plan you can act on, whether that plan calls for new software or a change your own team can make.

If one part of your operation keeps costing you patience and nobody can name why, send us a note about it. That's a good place to start the conversation.