When the bottleneck is upstream of what you want to automate

An operations lead at a contact center told me about the step everyone wanted gone. When a customer called with a complicated issue, the agent had to write a summary and route the case to the right specialist team. It took a few minutes per call. Agents hated it. Managers watched the queue back up during it. The request that reached him was clear: use AI to write the summaries and pick the routing, and give us those minutes back.

It was a reasonable ask. The step was slow, it was repetitive, and a model could plausibly do it. He almost approved it. Then he did the thing that saved the project. He went and watched.

The slow step was waiting on a faster one

What he saw was that agents did not spend those minutes writing. They spent most of them looking. The summary was quick once they knew what to say. Getting to that point meant clicking through three systems to piece together the customer’s history, because no single screen showed it. The account record lived in one place, the recent tickets in another, the billing state in a third. The agent assembled the story by hand every time, and only then wrote it down.

Automating the summary would have saved the writing. The writing was not the bottleneck. The gathering was. An AI that wrote summaries faster would have sat there waiting for the agent to finish hunting, exactly like the agent did. The queue would not have moved.

This is the pattern, and it is easy to miss. The step people complain about is the visible one, the one with their hands on it. The real constraint is often a step before it, feeding it slowly. You can make the visible step instant and change nothing, because the work still arrives at the same rate from upstream.

A friend who runs a warehouse operation described the identical trap from the floor. His team wanted AI to optimize the packing station, the place with the visible pile-up. The pile-up was real. But the packers were idle half the time, waiting on picks from the shelves. Speeding up packing would have grown the idle time. The picking was the constraint. They fixed the picking route and the packing pile-up cleared on its own.

Find the constraint, then decide where AI fits

Once the contact-center lead saw the gathering problem, the project changed shape. The high-value move was not a summary writer. It was pulling the customer’s history into one view, so the agent stopped hunting. That might be an AI that assembles context. It might just be an integration that puts three screens on one. Either way, the summary step got faster as a side effect, because the agent now knew what to say the moment the call started.

The discipline here is to trace the work backward from the slow step and ask what it is waiting on. A few questions that surface it:

When someone is stuck at this step, what are they actually doing? Producing, or waiting and looking?
What has to be ready before this step can even start?
If this step were instant, what would the next constraint be?
Is the pain here caused here, or inherited from upstream?

If the honest answer is that the step is starved by something before it, automating the step is motion without progress. You fix the upstream feed first, and sometimes that removes the need for the downstream AI entirely.

How we approach it at Density Labs

Finding the true constraint is a core part of the AI Opportunity Assessment, our fixed two-week engagement at $2,500. Before we scope any model, we walk the actual flow of work and locate where it stalls, not where people feel it stalling. The two are frequently different steps. When we hand back a recommendation, it points at the constraint that will move the outcome, which is often not the step the client came in asking us to automate. That reframe is usually worth more than the code.

Automating the step people complain about feels like progress. Find what that step is waiting on first, because that is the thing you actually need to fix.