What is a process bottleneck?
You know the pattern: everything moves fine until it hits one particular step, and then it doesn't matter how fast everyone else is, the whole thing waits. An order sits untouched over the weekend because only one person knows how to process it. Approvals pile up because they all need one specific signature, and that person is in back-to-back meetings.
That single point, the one everything else is waiting on, is a bottleneck: the step that limits how fast everything after it can move, regardless of how efficient the rest of the process is. In small and medium businesses, a handful of patterns show up repeatedly:
- Approval queues: work sits waiting for a signature or sign-off from one person, especially if that person is also doing the majority of client-facing or revenue-generating work themselves.
- Single-person dependency: a step that only one person knows how to do, or is allowed to do, becomes a bottleneck the moment that person is unavailable.
- Manual re-entry: data typed once into a form, then retyped into a CRM, then retyped again into accounting software. Every retype is a delay and an error risk.
- External waiting: steps that depend on a third party (a client, a supplier, a bank) responding, with no fallback plan for when they don't.
How to find bottlenecks in a business process
Once you have a workflow map, finding bottlenecks is mostly a matter of asking the right diagnostic questions against it:
- Where does work sit and wait? Look for any step where the item (an invoice, an application, an order) is untouched for more than a few hours with nobody actively working on it.
- Where does the same information get typed more than once? Trace a single piece of data (a customer's name, an order total) and count how many systems it gets manually entered into.
- Which step depends on one specific person being available? If the process stalls whenever that person is in a meeting, on leave, or simply busy, that's a structural bottleneck, not bad luck.
- What generates the most "where is this at?" follow-up messages? Steps that regularly need a status-check email or a Slack ping are usually the ones with the least visibility, and least visibility often means least efficiency.
- What step, if it doubled in volume tomorrow, would break first? This identifies the true limiting factor, even if it isn't the slowest step on an average day.
A useful habit: pick three recent, real examples that moved through the process and time how long each one actually took at every step. The gap between "the step itself takes ten minutes" and "the step actually took three days" is almost always sitting at a bottleneck. If you want the formal version of this idea, queueing theory's Little's Law says that at a steady pace of work, the more items waiting in a queue, the longer each one takes to get through. The gap between hands-on work time and total elapsed time is what Lean practitioners call flow efficiency, and at a bottleneck it's usually very low.
Why do business processes get slower as a company grows?
A process that worked cleanly with five employees and fifty customers often starts breaking somewhere between twenty and a hundred, and the reason is structural, not a sign anything was done wrong:
- More handoffs appear. What one person did end-to-end gets split across specialised roles, and each split adds a handoff, and a chance for delay.
- Informal coordination stops working. "Just ask Sarah" is a fine system when there are eight people in one room. It fails once there are three offices and Sarah's on leave.
- Approval layers accumulate. Each time something goes wrong, the instinctive fix is often "add an approval step," which is reasonable in the moment, but the approvals rarely get removed once the immediate risk has passed, and they stack up over years.
- The process was never redesigned, only added to. Most growing businesses patch processes reactively rather than periodically redesigning them, so a process that's technically ten years old is really ten years of patches on an original design that assumed a much smaller team.
None of this means growth is the problem; it means a process that was never revisited is the problem, and revisiting it is exactly what process redesign is for.
Where administrative work quietly gets stuck
Some patterns are common enough to check for directly, even before doing a full mapping exercise:
- Unclear ownership: nobody is explicitly responsible for the next step, so it waits until someone notices and picks it up.
- Waiting for one approval, from one person, with no backup: especially common with owner-approval on anything financial.
- Data spread across systems with no single source of truth: the "correct" answer to a simple question (is this client paid up? is this order shipped?) requires checking two or three places.
- No visibility into status: if the only way to know where something is in the process is to ask a person directly, that process has an invisible bottleneck baked in, even on a good day.
How to identify unnecessary steps, duplicate work, and repetitive tasks
Once you're looking at a mapped process, a short checklist catches most of what's worth removing or automating:
- Same data, entered twice (or more). Any time information is manually copied from one system or document into another, that's duplicate work by definition.
- Steps that exist "because we've always done it that way." For each step, ask what would actually break if it were removed. If nobody has a concrete answer, it's a strong candidate to cut.
- Manual checks that could be a simple rule. "I always check if the order total is over $500 before approving" is a rule, not a judgment call; it doesn't need a human doing it by eye every time.
- Reports built by hand from data that already exists elsewhere. If a weekly report is someone manually copying numbers out of a system that already has them, that's pure re-entry with no decision-making value added.
- Repetitive, low-judgment tasks done at volume: anything done the same way, dozens or hundreds of times, with essentially no variation is a signal worth flagging, whether the eventual fix is simplifying the step or automating it.