Key takeaways
- Identify whether the blockage is information, authority, capacity, or software.
- Agree on ownership and a measurable completion milestone before building.
- Test a small process change and measure rework across the whole handoff.
Putting this workflow into practice? Explore Automation Systems Architecture for implementation scope, controls, and next steps.
Business problems often look like software problems because the missing information is visible on a screen. The underlying fault may be elsewhere: nobody owns the next decision, two departments use different definitions of completion, or an exception has no route back into the process. Buying another application before identifying that fault can add another handoff.
Start with one delayed decision
Choose a real transaction that disappointed a customer or consumed unnecessary time. Follow it from the first request to its final outcome. Ask each person what they received, what they needed, what they changed, and who they expected to act next. Record timestamps where available. Do not begin by drawing the process everyone wishes they followed.
For example, a quotation may wait because sales is missing a delivery estimate. Operations may believe sales is still confirming quantities. Both teams can be working diligently while the customer hears nothing. A new quotation tool will not resolve that disagreement unless the required inputs and response owner become explicit.
Distinguish four kinds of bottleneck
An information bottleneck means the necessary facts are missing or scattered. An authority bottleneck means nobody knows who may approve the next step. A capacity bottleneck means the right person has more work than they can complete. A system bottleneck means a reliable decision exists but the software cannot execute or communicate it efficiently.
These require different interventions. Better forms help incomplete requests. Delegated approval limits help routine decisions. Capacity planning helps overloaded teams. Integration helps repeated copying. Treating all four as automation opportunities leads to fast movement of work that is still fundamentally unresolved.
- Follow a delayed decision
- Identify the bottleneck type
- Agree an operating contract
- Test the smallest useful change
A visual map of this article’s approach. The detailed requirements and exceptions are explained in the surrounding sections.
Define the smallest useful operating contract
For the quotation example, write down the minimum specification: confirmed items, requested delivery date, responsible estimator, promised response window, and reasons an estimate may be blocked. Define what sales should tell the customer while an exception is open. Attach those rules to the record rather than relying on someone's memory.
The contract should include an ending. Is the work complete when the quotation is sent, when the customer acknowledges it, or when an order is accepted? Choose one measurable milestone for this workflow. Other milestones can belong to subsequent processes without making the initial step ambiguous.
Decide what deserves software
Test the operating contract manually on a small sample first. If the team still cannot agree on ownership, pause the build. If the rules are stable and the remaining friction is repeated data movement, automate that movement. If several teams need to see shared status, add a lightweight queue or dashboard before commissioning a large platform.
A useful decision record compares the proposed change with doing nothing. List implementation effort, continuing maintenance, permissions needed, and the expected reduction in delay or rework. Estimates should be labelled as estimates, then checked against actual results after a pilot.
Know when the intervention worked
Measure elapsed time to the chosen milestone, the proportion of requests returned for missing information, and the number of unresolved exceptions. Also speak to the people doing the work: fewer steps in one department may have created extra steps elsewhere. Review customer outcomes alongside internal efficiency.
The aim is not a perfectly drawn process. It is a business where the next action is understandable and recoverable. Share a delayed workflow through the contact form, or explore business automation services to discuss whether the answer is process design, integration, or custom software.
Worked example of a quotation that stops between teams
Imagine a fictional quotation for 200 components. Sales records the quantity, but operations cannot estimate dispatch until the required finish is confirmed. The customer sees a silent delay while each team believes the next decision belongs elsewhere.
Open the full-size illustration.
Original process example, not evidence of a client engagement or time saving.
The first fix is an agreed input: item specification, quantity and required date must travel with the request. Operations then supplies an estimate or a named reason it cannot. Sales remains responsible for the customer update. Try that rule manually before automating the messages.
Track the received time, the point when the specification became complete, the returned estimate and the sent quotation. Those timestamps separate time spent waiting for customer information from time spent waiting inside the business. If the estimator is overloaded after complete requests arrive, adding notifications will not create capacity. That finding supports a staffing or allocation decision rather than another integration.
Only after the rule works should the system check the required fields, route a complete request and make overdue decisions visible. Keep the original request attached when information is corrected so the team can explain both the delay and the next action.
Track these separately. Evidence for one does not automatically confirm the others; use the article’s review and ownership checks.
Frequently asked questions
How can I tell whether a bottleneck needs software?
Trace a delayed transaction and identify whether information, authority, capacity or system execution is missing. Test clear inputs and ownership manually before automating repeated data movement.
What should a small workflow pilot measure?
Measure time to the agreed completion milestone, requests returned for missing information and unresolved exceptions. Check that work removed from one team has not simply become extra work for another.
Further implementation guidance
For a formal reference when documenting decisions and handoffs, consult the OMG Business Process Model and Notation specification. Use a level of notation your operators can understand and maintain.
Related implementation guides
- Design an Approval Matrix for Business Automation
- What Event-Driven Automation Looks Like in a Founder-Led Business
Founder, The Night Marketer (Shopify Select Partner). The agency has served 450+ brands since 2015.
Automation Systems Architecture
For teams where leads, orders, operations, or reporting still depend on memory, WhatsApp nudges, and manual sheet updates.
