A customer waits three days for a pricing decision that should have taken three minutes. A delivery route sits with a manager until the afternoon. A support agent escalates a routine request because the approval rules are unclear.
In each case, the problem may not be a lack of effort. It may be a decision process designed around human availability, hierarchy and handoffs.
Paul Cheek, a senior lecturer at MIT Sloan and author of No One Works Here, argues that businesses should remove people from decision-making processes where machines can act faster and more effectively. His broader point is deliberately provocative: many organisations still carry structures designed to compensate for older limits in communication and knowledge management.
That argument is useful, but only if it is applied carefully. The practical opportunity is not to remove humans from every decision. It is to identify where human involvement creates organisational latency, then move routine decisions into a controlled system that can act consistently and quickly.
Structural debt is often visible in everyday workflows
Technical debt is the future cost created by shortcuts in software. Structural debt is a similar problem in the organisation itself: layers, approvals, departments and meetings that once solved a real coordination problem but now slow down routine work.
Consider a small business that sells customised equipment. Its discounting process might look like this:
- A salesperson proposes a price.
- A sales manager checks the margin.
- Finance confirms payment terms.
- Operations checks delivery capacity.
- The manager sends the answer back to the salesperson.
The process may be sensible for unusual or high-risk deals. But if most requests fall within known margin, customer and capacity rules, the human chain is acting as a slow rules engine.
An AI-supported workflow could instead evaluate the request against approved parameters:
- minimum gross margin;
- customer credit status;
- current inventory or capacity;
- delivery location and timing;
- discount limits by product and customer type.
If the request fits the rules, the system returns a price and records the decision. If it falls outside them, it routes the exception to the right person with the relevant context attached.
The important design change is not simply adding a chatbot to sales. It is changing the decision architecture. People stop reviewing every case and start handling the cases that genuinely require judgement.
Why this matters to leaders
The cost of latency is not limited to lost minutes. Slow decisions can reduce conversion, create inconsistent customer experiences and consume senior staff capacity. They also encourage employees to create workarounds: private spreadsheets, informal approvals and messages that bypass the official process.
Before automating, map the real workflow rather than the documented one. Record:
- where a request enters the organisation;
- who touches it and why;
- what information each person needs;
- which decisions are repetitive;
- how often exceptions occur;
- how long each handoff takes;
- what happens when nobody responds.
This exercise often reveals that the largest bottleneck is not the decision itself. It is waiting for context, permission or a person who is already overloaded.
The latency J-curve explains the messy middle
Cheek’s concept of a “latency J-curve” describes a transition that many organisations underestimate. An automated process may initially be slower than the old manual process because the business must define rules, clean data, test edge cases, train staff and create escalation paths.
A routing example makes the pattern clear.
A logistics company may want an AI system to assign delivery jobs based on location, vehicle capacity, promised delivery times and driver availability. At first, the new process creates extra work. Staff compare automated recommendations with existing plans, correct bad addresses, identify missing capacity data and document exceptions. For several weeks, the organisation may be running two systems at once.
That is the unreliable middle — not evidence that automation cannot work, but a phase that needs to be planned and measured.
A practical implementation has four stages.
1. Establish the baseline
Measure the current process before changing it. Useful measures include decision time, rework, escalation rate, error rate, margin impact and the percentage of cases requiring management intervention.
For customer support, the baseline might show that 65 percent of password, order-status and cancellation requests follow predictable rules, while the remaining cases involve refunds, complaints or unusual account circumstances.
2. Start with recommendations, not autonomy
Run the AI system in shadow mode. It produces a proposed decision, but a human still makes the final call. Compare the recommendation with the actual outcome and record why they differ.
This phase is especially useful for discovering unclear policies. If employees repeatedly override the system because a rule is missing, the issue may be governance rather than model quality.
3. Delegate low-risk decisions
Once performance is understood, allow the system to complete a narrow class of cases automatically. For example, it might approve support credits below a defined amount, route standard delivery requests or apply pre-approved pricing bands.
Every automated action should leave an audit trail showing the input, rule or model output, decision, confidence where relevant and escalation path.
4. Expand only when the controls work
Increase the range of automated decisions gradually. Review exceptions weekly at first, then at a frequency appropriate to the risk. The goal is not maximum automation. It is reliable delegation.
The temporary “reliability tax” includes duplicate checking, policy work, monitoring and employee training. Budgeting for that cost prevents leaders from abandoning a useful system because the first month was slower than expected.
What trust-based autonomy should look like in practice
Trust-based autonomy is not a system that acts without oversight. It is a system whose boundaries are clear enough that people do not need to inspect every routine action.
For a support team, that might mean:
- automatic answers for approved knowledge-base questions;
- automatic order-status updates from verified data;
- automatic credits within a defined limit;
- mandatory human review for legal threats, vulnerable customers, high-value refunds or unresolved complaints;
- immediate escalation when customer identity or account data is uncertain.
For a pricing team, it might mean automatic quotes within approved ranges, with human review for unusual combinations of volume, margin, contract terms or strategic accounts.
The workflow should specify not only what the AI may do, but also what it must never do. These constraints are operational requirements, not optional prompt instructions.
A useful control document includes:
- the decisions covered;
- the data sources the system may use;
- the authority limits;
- the conditions that trigger escalation;
- the person or team accountable for exceptions;
- the review schedule;
- the process for suspending automation.
Where the argument can fail
The case for removing human bottlenecks becomes dangerous when it is treated as a general rule that faster decisions are always better.
First, automation can accelerate a bad policy. If a pricing rule quietly disadvantages a customer segment, an AI system can apply that rule more consistently and at greater scale. Policy review must come before speed optimisation.
Second, a system cannot compensate for missing or unreliable data. Automating supply-chain routing with outdated inventory records will produce faster, more confident mistakes.
Third, some decisions require accountability, empathy or negotiation. A customer complaint, employee performance issue or safety incident should not be reduced to a classification problem simply because the process is inconvenient.
Fourth, removing people from routine decisions can weaken organisational understanding. Employees who never see exceptions may lose the judgement needed when the system fails. Teams therefore need regular review of escalated cases and clear opportunities to challenge automated outcomes.
Finally, efficiency can be measured too narrowly. A faster process that increases refunds, churn, compliance risk or employee turnover is not an operational improvement.
A practical starting point for an SMB
Choose one process where all of the following are true:
- the decision happens frequently;
- the inputs are reasonably consistent;
- the cost of a mistake is limited and reversible;
- the current process includes avoidable approval steps;
- a clear human escalation route already exists.
Document 50 to 100 recent cases if possible. Classify them as standard, ambiguous or exceptional. Estimate the time spent waiting, reviewing and correcting. Then design a narrow automated path for the standard cases and keep the others with experienced staff.
Set a review date before launch. At that point, compare speed with quality: not only how quickly decisions were made, but whether outcomes, customer experience and exception handling improved.
The central lesson from the structural-debt and latency-J-curve framing is straightforward: AI adoption is an operating-model change, not a software switch. Human involvement should be reduced where it adds delay without adding judgement, while remaining strong where context, accountability and care matter.
Businesses that plan for the awkward transition can turn routine decisions into dependable automated workflows. Businesses that skip the transition work may simply replace visible queues with faster, harder-to-diagnose errors.