A bottleneck is the one step in a workflow that limits how much the whole workflow can deliver. You find it by measuring where work waits, not where people are busiest: the step with the longest queue in front of it is almost always the constraint. Automate that step, or the work feeding it, and the whole process speeds up. Automate anything else and you mostly move the pile around. So the right first automation is not the most annoying task or the most impressive demo. It is the frequent, rule-based work that sits on or directly in front of the constraint.
This guide covers how to find the constraint in a real process, how to fix the process before writing any code, and a simple scoring method for deciding which processes to automate first. It is written for operations leads, founders and technical leads who have more automation ideas than capacity to build them.
What a bottleneck actually is
Any process with several steps runs at the pace of its slowest step. This is the central idea of the Theory of Constraints, introduced by Eliyahu Goldratt in his 1984 book The Goal. If approvals can handle 40 requests a day and everything else can handle 100, the process delivers 40 a day, no matter how fast the other steps become. Work piles up in front of the constraint, and everything downstream sits idle waiting for it.
Two consequences matter for automation. First, improving a step that is not the constraint does not increase output. It may make that step cheaper, which has some value, but the customer waits just as long. Second, once you relieve the constraint, a different step becomes the slowest one. Finding bottlenecks is therefore a repeated exercise, not a one-off project.
Symptoms that point to the constraint
You can often spot a constraint before measuring anything. Look for:
- Queues: an inbox, a ticket status or a shared folder where items sit for days before anyone touches them.
- One person everyone waits for: a finance manager who signs off every payment, or the one engineer who knows how the billing system works.
- Rework loops: items sent back because information was missing or wrong, then joining the back of the same queue.
- Expediting: people regularly asking for their item to be “bumped up”, which tells you the normal route is too slow.
- Batch peaks: work that arrives evenly but is processed in a weekly or month-end rush.
These symptoms suggest where to look. They do not prove where the constraint is, because the loudest complaint is not always the binding limit.
Measure the flow, not the effort
Pick one process that matters, such as order to invoice, new client onboarding or supplier payment, and trace real items through it. Most business systems already record timestamps: when a ticket was created, when an order was approved, when an invoice was posted. Export a few weeks of these and calculate, for each step, how long items spend being worked on (touch time) and how long they spend waiting (wait time).
In most administrative processes, wait time is far larger than touch time. A purchase approval that takes four minutes of someone’s attention can still take three days end to end. That gap is where the bottleneck shows itself. The step with the largest and most persistent wait in front of it is your candidate constraint.
Little’s Law gives a useful sanity check: the average number of items in progress equals the throughput multiplied by the average time each item spends in the process. If you have 200 open requests and complete 40 a day, the average request takes five days, and the only ways to shorten that are to raise throughput at the constraint or reduce the work in progress. Process mining tools can automate this analysis from event logs, but a spreadsheet and a careful export are enough to start.
Combine the numbers with an afternoon of watching the work being done. The data shows where items wait. The people doing the work can tell you why.
The common kinds of bottleneck
Constraints in office workflows tend to fall into a handful of types, and each calls for a different fix:
- Approval queues: work waits for a sign-off that is often a formality.
- Single-expert dependency: only one person can handle a category of work.
- Handoffs between systems: someone reads data from one system and keys it into another.
- Poor input quality: requests arrive incomplete, so time goes on chasing missing information.
- Coordination: nobody owns the item between steps, so it waits until someone notices.
Fix the process before you automate it
Goldratt’s sequence still works well: get the most out of the constraint first, then make everything else serve it, and only then add capacity. In plain terms, that means some changes cost nothing and should come before any software.
Remove approvals that add no information, or set thresholds so only high-value items need a sign-off. Make sure the constraint never waits for missing inputs by validating requests at the point of entry. Stop the constraint doing work someone else could do, such as the senior reviewer who also formats the report. Limit the work in progress so items finish rather than all moving forward slowly. Write down the rules the single expert applies, which is useful whether or not you automate.
Automating a broken process produces a faster broken process, often with the broken parts now harder to see. If the rules change every month or depend on knowledge only one person holds, the first fix is process design and documentation, not code.
Which processes to automate first: a scoring method
Once the process is sound, score each candidate on five factors, from one to five:
- Volume: how many times a week the work happens.
- Time per unit: how many minutes of human effort each item takes.
- Cost of errors: what a mistake costs in money, rework or customer trust.
- Rule stability: how clearly the work can be described and how rarely the rules change.
- Position relative to the constraint: whether the work sits on the bottleneck or directly feeds it.
Volume and time per unit give you the size of the prize. Rule stability tells you how hard it will be to build and maintain. Cost of errors tells you how much review you need, which affects both build effort and the hours actually saved. The fifth factor is the one most scoring sheets leave out, and it decides whether the automation changes the speed of the whole process or just one corner of it.
The best first candidates are usually boring: high volume, stable rules, clean inputs, sitting on the constraint. Poor first candidates include processes that run once a month, work that depends on judgement nobody has written down, and anything built on a system you plan to retire. For a fuller worked example of the arithmetic, see our guide on how to scale operations without hiring.
Match the fix to the type of bottleneck
Different constraints need different tools, and choosing the wrong one is a common reason automation projects disappoint.
Where the constraint is a handoff that involves rekeying documents and messages into a system, a document processing pipeline with validation and exception review is the usual answer. We cover that pattern in detail in automating manual data entry, so it is not repeated here.
Where the constraint is coordination, a workflow engine that tracks each item’s state, assigns an owner and sends reminders often removes days of waiting without any AI at all. Where it is an approval queue, the fix may be a threshold rule plus a pre-assembled summary so the approver can decide in seconds rather than minutes. Where it is a single expert’s judgement, language models can draft, classify and gather context so the expert reviews instead of starting from scratch, while the decision stays with them. Where the constraint is an old system that cannot be reached, our notes on integrating LLMs into legacy enterprise systems describe the integration patterns that avoid a replatforming project.
After the fix, the constraint moves
When you relieve a bottleneck, measure the process again. Throughput should rise until the next slowest step becomes the limit, and that step is now your next candidate. This is why it pays to build automation as reusable pieces, such as shared connectors, validation rules and review queues, rather than one-off scripts: the second and third fixes reuse much of the first. We describe that approach in how to build software systems that compound over time.
Keep the measurement running. A dashboard showing wait time per step, items in progress and throughput per week tells you whether the fix held and where the next one should go. If your systems cannot produce those numbers, that is itself worth addressing, and our AI readiness audit covers observability alongside data access and integrations.
Mistakes to avoid
Automating the step that is easiest to automate rather than the one that limits output. Measuring success by hours saved at one step instead of end-to-end time and throughput. Removing human review from decisions where errors are expensive, before there is evidence the automation is accurate. Building without an owner, so the automation decays when an input format or upstream system changes. And treating the exercise as finished when the first bottleneck is cleared.
Where D3X Solutions LABS comes in
D3X Solutions LABS is an AI engineering studio in Ireland that builds AI agents, automation and LLM integrations for businesses in the EU, UK and Ireland. When we look at a process, we start with the flow data and the people doing the work, identify the constraint, and separate the changes that need no software from the ones that do. We then score the automation candidates with you, build the one that moves end-to-end throughput, and put measurement in place so you can see whether it worked and where the constraint has moved.
The aim is a working system your team owns and understands, not a report. If you have a process where work keeps piling up and you are not sure where to begin, book a free 30-minute call and we will help you find the constraint.
Frequently Asked Questions
What is a bottleneck in a business process?
It is the step with the lowest capacity relative to the work arriving, so it limits the output of the whole process. Work queues up in front of it and steps after it wait. Improving any other step does not increase overall throughput until the bottleneck is addressed.
How do you find a workflow bottleneck?
Trace real items through the process using timestamps from your systems and calculate how long each step spends working versus waiting. The step with the largest, most persistent queue in front of it is usually the constraint. Confirm it by talking to the people who do the work.
Which business processes should you automate first?
Score candidates on volume, time per unit, cost of errors, rule stability and whether they sit on or feed the bottleneck. Start with frequent, rule-based work at the constraint. Avoid processes that change often, depend on undocumented judgement or run on systems you plan to replace.
Should you fix a process before automating it?
Yes. Remove approvals that add nothing, validate inputs at the point of entry and stop the constraint doing work others could do. Automating a poorly designed process makes it faster but not better, and can hide the problems that caused the delay.
What happens after you remove a bottleneck?
Throughput rises until another step becomes the slowest, which is your next constraint. Keep measuring wait time and throughput per step so you can see where the limit has moved and decide what to tackle next.
Want this working in your business?
D3X Solutions LABS builds AI agents and automation that pay back fast. Set up a free 30-minute call and we will map your first win together.
Get in touch
