Operational bottlenecks in a service business: where work waits

Picture a 14-person advisory firm on a Monday morning. A client file has been open for three weeks. Nobody dropped it. Nobody can say why it has not moved. The owner asks the question every owner asks: "Why do jobs take as long as they do?"

The answer is almost always the same. An operational bottleneck is the point in your business where work waits longest, and in a service business that point is rarely a machine. It is a person, a decision, a client or a tool. You can find yours without time-tracking software, using the jobs already open in your business.

The firm in this article is a composite, not a client. The numbers are illustrative.

What an operational bottleneck is in a service business

The Lean Enterprise Institute describes the Theory of Constraints as a set of tools for improving results by managing the constraints that stop an organisation reaching its goals. The idea is old and simple: output is set by the slowest step, not the average one.

In manufacturing that step is a machine. In a service business it is usually a handoff or an approval. Work does not queue at a machine. It queues at a partner's review pile, a client's inbox, or a decision that has no owner.

Researchers writing in MIT Sloan Management Review separate two kinds of bottleneck. A task bottleneck is work stalled because it depends on other work that has not finished. A resource bottleneck is a shortage of the people, time or tools needed to do the work. The difference matters because more resources fix the second kind but do not necessarily fix the first.

There is also simple arithmetic that makes the cost visible. Little's Law says that, in a stable system, the average number of jobs in progress equals the rate they finish multiplied by the average time each one spends in the system.

If you have 30 jobs open and finish 6 a week, the average job spends about five weeks in the business. That is illustrative arithmetic, not a benchmark. It shows why a long queue at one step stretches every job, even when the work at every other step is quick.

The six places work waits

In many small service businesses, a stalled job is waiting for one of six things. The categories are useful because they point at different fixes.

The handoff between sales and delivery is one common place for the "person" and "decision" rows to show up. If that is where your jobs wait, how to automate project handoffs covers the build side.

Find your bottleneck from the jobs you already have

You do not need a tracker. You need about 30 minutes, a sheet of paper or a spreadsheet, and the jobs already open in your practice management system, shared inbox or task board.

Pass 1: your ten oldest open jobs.

1. List the ten oldest open jobs, by the date they started.
2. Next to each, write one word for what it is waiting on right now: client, person, decision, tool, redo, or nobody. If it is a person, note their role.
3. Write the date anyone last touched it.
4. Count by category. The category with the most jobs, or the longest gap since last touch, is where to look first.

Pass 2: ten recently finished jobs. Pass 1 has a bias. The oldest jobs are the slow ones, so they overstate how common slow cases are.

To check, take ten jobs finished recently and, from dates already in your email, project tool or invoice history, note when each moved from one stage to the next. If the same handoff is the long gap in both passes, you have a real candidate. If the two passes disagree, the oldest ten were oddities.

If it helps, keep a one-line note for a fortnight whenever a job gets stuck: the job, what it is waiting on, the date. Treat it as a prompt for where to look, not as a measurement.

What the pattern tells you, and what it does not

Ten jobs is a sample, not proof. Read the result as a pointer.

The exercise tells you where work waits. It does not tell you why. The same queue can come from a missing system, too little capacity, an unclear authority, or a scope problem. Do not draw a verdict from one pass. Draw a shortlist of places to look.

There is no magic cut-off for "too many". If six of ten jobs wait on the same step, that is worth a conversation. If the passes disagree, it may not be.

A worked example: the review queue

Back to the advisory firm. Its ten oldest open jobs looked like this:

• Six waiting on one partner's review
• Two waiting on client documents
• One waiting on a scope decision
• One with nobody: an exception no one had picked up

The partner reviews in a single block on Fridays. The second pass showed recently finished jobs spent a few days at the review step and only hours at every other step.

The firm's first instinct was a tool for tracking reviews. The pattern said otherwise. The queue was one person's calendar. That is a task bottleneck of the kind MIT Sloan Management Review describes, and more tooling elsewhere would not have shortened it.

The fix was not software. It was a second reviewer for routine jobs, a daily 30-minute review window instead of one weekly block, and a short rule for which jobs needed partner review at all. The scope-decision job and the nobody job went onto a separate short list for the owner.

When it is not a systems bottleneck

Plenty of bottlenecks have nothing to do with systems. Check these before building anything.

• Capacity. If most waits are on a person and that person is genuinely full of delivery work, you have a resource bottleneck. Hiring, delegating or saying no is the answer. A workflow build moves nothing.
• Scope and pricing. If jobs wait on a decision about scope or price, or keep coming back as rework because the brief changed, the cause is how the work is sold and scoped. Tighten the scope document and the change process.
• Hiring before diagnosing. A new hire placed into a bottlenecked step inherits the queue. Name the queue first.
• Clients. If most waits are the client, look at what you ask for and when before looking at your own systems.
• One person's judgement. If the queue is one person who has to decide, the fix may be written rules for what they decide, or someone else sharing the decision. The pattern is a prompt for a conversation about the role and the process together, not a verdict on the person.

When not to build anything yet

The scope-decision job in the example is the clearest case. If nobody is authorised to decide, or the rule changes every quarter, automating the step encodes one person's current guess.

Settle who decides and by what rule. Run it by hand for a few cycles and see whether it still queues. If it does, then it is worth building. When not to automate a business process covers the wider set of reasons to wait.

Name the queue, then decide

The useful question is not who is slow. It is where work waits and what it is waiting for. Name the queue first. Sometimes the answer is a system. Sometimes it is a hire, a price or a decision. You will know which before anyone builds anything.

If you want to test whether a particular workflow is ready for automation once you know where it queues, the workflow automation fit check is a quick way to do it.