Bottleneck Analysis for SMBs: Where Processes Get Stuck

A company spends weeks optimizing a process step and gets disappointing results. This is one of the most common patterns in consulting practice. The measure itself was sound. It simply targeted the wrong place.

The problem is rarely a lack of effort. It is a lack of clarity about where the real bottleneck sits. Finding it is not trivial. Bottlenecks often appear where you least expect them.

Why optimization so often targets the wrong place

When teams are asked what is not working in their workflow, they typically name what they experience themselves. The quoting tool is clunky. Response times from the other department are too slow. The template is outdated. All of this may be true, and still none of it is the actual bottleneck.

Eliyahu Goldratt described this precisely with his Theory of Constraints in the 1980s: every system has exactly one limiting factor at any given time. Only by addressing that factor does overall performance improve. Everything else is noise. Sometimes expensive noise.

For mid-market companies without an operations team, this sounds abstract. In practice it is surprisingly straightforward to apply if you know where to look.

What is a bottleneck, and what is it not?

Bottleneck vs. symptom

A bottleneck is where work accumulates. Not where errors happen. Not where the most complaints come from. But where incoming volume consistently exceeds processing capacity.

A classic example: a service provider has long response times. Management suspects the problem is in the front office, with too little capacity at reception. In reality, the bottleneck sits at a technical sign-off handled by a single specialist responsible for three teams. The front office captures requests quickly, then parks them. The bottleneck is deeper in the system.

Symptoms often appear elsewhere. That is why the first step of any bottleneck analysis is always to observe where work accumulates, not where the noise is loudest.

Finding the real bottleneck in three steps

Step 1: Map the workflow

Before analyzing, you need to understand the flow. This does not require detailed process documentation. A whiteboard session with the people involved is usually enough. The goal is to make every step of a typical transaction visible: who does what, when, based on what information?

Map the actual process, not the intended one. What really happens, not what the manual says. These two often differ significantly. Bottlenecks tend to hide in the gaps between how the process is described and how it works.

Step 2: Make the stacking visible

Once the flow is mapped, the analysis begins: where do cases accumulate? Where do waiting times appear? Where does backlog grow when volume increases slightly? The following questions help:

• Where are the longest waiting times between two process steps?
• Which step has the most unfinished cases at the end of a working day?
• Where does a specific person regularly become a constraint through approvals, sign-offs or follow-up questions?
• Which step slips first when someone is out sick?

These questions can often be answered without data analysis, through direct observation or structured conversations with the team. Two to three hours are usually enough in small organizations to build a clear picture.

Step 3: Ask the team directly

Sometimes the simplest method is the fastest: in an open round with the people involved, ask what they think slows the workflow down the most. Avoid 'What would you improve?' That leads to wish lists. Instead: 'If you could fix one problem tomorrow, what would make the biggest difference?'

Teams often know where the bottleneck sits. They see it every day. What is missing is a structured setting to discuss and assess that perception.

Common bottleneck sources in Austrian SMBs

Certain patterns appear repeatedly in our project work:

• Single-person approval loops: quotes, invoices, or orders that can only be signed off by one person and pile up there.
• Information gaps between departments: a step cannot start because a required piece of information is missing, and coordination happens by email.
• Scattered data: decisions that could in theory be made instantly take hours because data lives in multiple systems.
• Historically grown exception processes: special-case rules introduced for one client or situation that became standard procedure five years later.
• Unclear ownership at handover points: nobody feels responsible, a case sits between two departments and loops through email inboxes.

What comes after the analysis

Once the bottleneck is identified, the temptation is to 'solve' it immediately. In many cases, the right next move is to relieve the bottleneck first. Redesign can wait.

That means: examine what feeds into the bottleneck and what follows it. Can you reduce inflow? Can you create parallel capacity? Can you make the bottleneck faster without rebuilding the entire process?

Only once those options are exhausted does the deeper question make sense: does the step need to be redesigned? Can it be automated, delegated, or merged?

At a tax advisory firm, the bottleneck was manual data entry from client PDF documents into the internal system. The firm first standardized how clients submitted documents, before introducing automation. Transfer time dropped by half. Only in a second phase was a partial automation step introduced.

Conclusion

Bottleneck analysis sounds like a major undertaking. In practice it is surprisingly fast if you know what you are looking for. Two hours of structured observation and team conversations are usually enough to identify the primary constraint in a mid-market business.

What follows depends on the specifics. But without the analysis first, every optimization measure is a guess. And guesses are more expensive than necessary.

Frequently Asked Questions