Applied Enterprise AI
Search & Ask Ctrl K

Public knowledge

Search & Ask

Find exact concepts and practices for AI-enabled value delivery.

Open the full Search page
On this page

Faster Delivery

The step got faster. The dashboard shows the improvement. The customer is waiting just as long as before, because most of their wait was never in that step.

Definition

Faster delivery is a shorter elapsed time from a customer's request to a usable result.

Elapsed time runs on the customer's clock. Task time, the time spent working on one step, is only part of elapsed time. The rest is spent waiting: in a queue, for a specialist, for a review, for the customer.

The customer can be internal, such as a team waiting for another team's feature.

The recognition pattern

  • Handling time per ticket is down. Time to resolution is about where it was.
  • The next stage backs up. Escalations wait longer, reviews stack up and merges wait their turn.
  • Scheduled hours fell, and the wait stayed the same.

How a faster step fails to shorten the wait

The step's share of the clock

At Alibaba, using the AI's suggestions cut new support agents' time to identify a customer's issue by about a third, compared with agents without the tool. But identifying the issue took under a tenth of a chat's duration, so their chats got only about 4% shorter. Both results come from a randomized experiment with about 5,900 agents (Ni et al., 2026, working paper).

The direct saving from a faster step is capped by its task time. If the task time is a tenth of the elapsed time and nothing else changes, making the step instant saves at most a tenth. A step whose working time is nearly all taken can save more, because quicker tasks there also shorten its queue (see below).

The next queue

Across more than 10,000 developers, teams merged 98% more pull requests in their heaviest AI-use quarters than in their lightest. But review time rose 91% on the same comparison. The researchers found no company-level improvement in delivery (Faros AI, 2025, data collected through the vendor's own tools).

Work that finishes sooner reaches the next stage sooner. If that stage is already full, or runs on a fixed schedule, the work waits there instead. Across 28.7 million build workflows, the median team's feature-branch workflow runs rose 15% year over year. But its main-branch workflow runs fell 7% (CircleCI, 2026, vendor data).

The step that sets the pace is the one where faster handling would get the customer a usable result sooner. Look for it first at the longest wait, but a long wait is not proof. Clearing a long queue gains nothing if the work then waits somewhere else, such as for a release on a fixed date.

A shorter wait or fewer scheduled hours

Take a step whose working time is nearly all taken, with a queue in front of it. AI makes each task there quicker.

The freed capacity can lower how full the step is: the share of its working time already taken. Waiting rises steeply as a step fills. So making it even a little less full shortens the wait a lot. Or the freed capacity can be taken as fewer scheduled hours. Then the step stays as full as before, and the wait stays as long.

When a staffing tool is set to a target for how full the step is, it cuts scheduled hours as tasks get shorter. That is the default until someone changes the target, and nobody sees the choice being made.

What it costs

When a faster step does not shorten delivery, the organization still pays for the acceleration. Its budget may even show a saving, but the customer feels no difference.

In development, Faros also found average pull-request size up 154%. CircleCI found that only 70.8% of main-branch workflow runs succeeded, the lowest share in over five years.

In service, a faster but less complete answer can bring the customer back. One contact becomes two.

Boundaries and distinctions

In one customer-support deployment, agents with AI handled about 14% more chats an hour (Brynjolfsson, Li and Raymond, 2025). The study does not report how long customers waited, so it cannot show faster delivery. More output is not faster delivery. The same freed capacity can buy either.

When a faster step brings a large cut in elapsed time. Either it is the step that sets the pace, or the next stage is changed to keep up. The top 5% of teams, whose main-branch workflow runs rose 26%, were the ones where, in CircleCI's words, "validation keeps pace with generation."

Some waits depend on the customer, not on your team. Waiting for a customer to reply is one. A faster step cannot touch that time. Measure it separately.

Example

In a constructed case, a support team uses AI to draft the answer to each ticket. Drafting used to take 20 minutes and now takes 8. But a ticket that needs a product specialist still waits about two days for one, so the customer's elapsed time barely moves. The specialist queue is the first place to look. If the specialist's answer resolves the ticket, that queue is also the step that sets the pace. The team could spend some of its freed time sending complete cases to the specialists, so each case takes a specialist less time.

In a second constructed case, a development team's AI writes the first version of a change in half the time it used to take. The change then waits for a reviewer, then for a merge, then for the release train, which leaves every two weeks. The release date does not move. Review, where the work now piles up, is the first place to look. But faster review helps only if it gets the change onto an earlier train. If it does, the team could move some of its freed time into review. If it does not, the train is what sets the pace.

Applied test

  1. Take ten recent tickets or changes.
  2. Record for each:
    • the elapsed time from request to result;
    • the active task time in the step that AI made faster;
    • the time spent waiting for the customer;
    • the longest of the other waits, and where it happened.
  3. Divide the active task time by the elapsed time. That share is the most the faster step can save directly. Express the improvement you need as a share of elapsed time too. If the step's share is smaller, the wait that needs to change is somewhere else. Start with that longest wait.
  4. Decide what the freed time is for, and who owns that choice, before the staffing tools decide for you.

If the choice is not yours, take the records to whoever owns it.

Sources and lineage

Faster Delivery is part of Applied Enterprise AI, a body of work developed by Curtis Hibbs and Joshua Barnes. Eliyahu Goldratt made the idea of the step that sets the pace famous as the constraint, in The Goal. The page also draws on queueing research. The Faros AI and CircleCI figures are vendor data.

Continue in the Knowledge Base

Curtis Hibbs and Joshua Barnes are co-creators of Applied Enterprise AI and Applied End-to-End Flow, and co-authors of the Applied End-to-End Flow book series. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.