The Next AI Opportunity Is Between the Tasks

How to turn faster drafts and analysis into a shorter path from request to result.

Imagine a B2B service onboarding a new customer. An AI assistant reads the order form, gathers the setup information and prepares the onboarding package in three minutes. The customer gets access three days later.

The package waited for someone to confirm an exception. That person needed a detail from sales. Sales thought the implementation team already had it. By the time everyone had the same information, the next setup window had passed.

The assistant did its job. There is still plenty of useful work to do around it.

This is an illustrative scenario, but it points to a practical question for any team introducing AI: what happens to the work after the AI finishes?

Two clocks are running

One clock measures the time spent performing a task: reading a document, preparing a draft, checking a record. The other measures how long someone waits for the result they actually need.

AI can improve the first clock substantially. That matters. Less manual work can mean more capacity, less frustration and more time for difficult cases.

The second clock includes everything between the steps: queues, missing information, unclear ownership, scheduled reviews and work that comes back for correction. A faster task may barely change that journey if it still enters the same queue.

In our onboarding example, preparing the package is one milestone. The customer being able to use the service is the outcome. Both deserve attention, and they need different measurements.

Start by following a few requests from arrival to completion. Where was someone actively working? Where did the request wait? Where did it return to an earlier step?

This is the logic behind value stream mapping. DORA's guidance applies it to software delivery, including the waiting and handoffs that a task-level view can miss. The same questions give us a useful way to examine our onboarding scenario.

Improve what the next person receives

In the example, the next person received a completed package with an unresolved exception buried inside it. They had to reconstruct the situation before they could decide anything.

That is a useful place to improve the workflow.

Suppose the handoff looked like this:

The standard setup is ready. One requested integration needs a decision before we can confirm the launch plan.

The signed order includes the integration, but the implementation schedule has no time allocated for it. The relevant order section and current schedule are attached.

Decision needed from the delivery lead before the next setup window: allocate time for the integration before launch, or agree a later delivery date with the customer. The implementation lead will update the plan once this is resolved.

The recipient can see the issue, inspect the evidence and understand which decision is needed. There is still a judgment to make, but much less detective work before it.

For a recurring handoff, define what the next person needs to proceed: the requested decision, the supporting records, the unresolved point and who takes over afterward. Ask that person to help design it. They know which missing detail sends work back.

A useful output makes the next step easier to complete.

Put AI where the handoff breaks

Once the delay is visible, the automation opportunity becomes more specific.

If requests repeatedly arrive incomplete, an assistant could compare incoming information with a checklist and identify missing details before the next team picks them up. In our example, it could flag the difference between the signed order and the proposed setup plan early enough to resolve it before scheduling.

If people spend time hunting across systems, AI could assemble the relevant records into one view, with links back to the sources. Someone making a decision should be able to check where a statement came from and how current it is. Unverified assumptions should remain visible as assumptions.

If requests reach the wrong person, the workflow could use an agreed ownership map to suggest or route the next step. Cases with no clear owner should surface for resolution instead of being passed around.

These are useful, bounded jobs: find a missing input, expose a mismatch, gather evidence, make responsibility clear.

Some delays also need an operating change. A team may need a regular decision window, a simpler rule or more review capacity. AI can help prepare the work; the people responsible for the process still have to decide how it should run.

Make room for work to finish

A faster preparation stage can create more work for everyone downstream. If complete requests arrive faster than reviewers can handle them, the queue will grow.

DORA's March 2026 analysis of open-ended feedback from Google engineers describes a related tension in software development: faster creation can shift effort into verification and review. This is evidence from one engineering setting, but it gives teams a useful downstream effect to watch for.

Keep an eye on how much work remains unfinished and how long the oldest cases have remained open. The Kanban Guide treats unfinished work, its age, completion rate and cycle time as complementary measures of flow.

For the onboarding team, that means noticing when more prepared packages are accumulating without more customers becoming ready to use the service. The next improvement might be clearing missing inputs, reducing repeated review or giving the responsible person time to make decisions.

More reminders alone will not solve a shortage of review capacity.

A small experiment for next week

Choose one recurring workflow and inspect ten recent requests, including some that are still open. This is enough to start a conversation about recurring delays; a larger set of comparable cases will be needed to assess an improvement reliably.

For each request, record when it arrived, when each team could act, when they actually acted and what caused any return or pause. Include the people doing the work so the record captures the reason behind the timestamps.

Then choose one recurring delay and change the handoff around it. You could add an early completeness check, make an exception explicit or assign the next step to a clear owner.

Follow the next comparable cases. Did completed requests reach the outcome sooner? Are open requests getting older? Did the change reduce back-and-forth without increasing corrections or pushing more effort onto another team?

The customer in our example gains something when they can start using the service sooner. The team gains something when getting them there takes less chasing and reconstruction.

AI gives us more ways to improve both. The next opportunity may be in the few minutes of preparation that prevent a request from spending days between two teams.

A worked handoff: from a hidden exception to a decision

Consider a fictional request arriving on Monday morning. Sales has promised an integration, but the implementation plan covers only the standard setup. The assistant can assemble a polished package without resolving this mismatch. A completeness check that asks only whether every document is present would miss the problem too.

A more useful check compares two specific fields: what the signed order includes and what the delivery plan schedules. If they disagree, the request enters an exception state before a setup slot is confirmed. The assistant gathers the relevant records and describes the discrepancy. It does not invent an implementation estimate or silently remove the promised integration.

The delivery lead receives a decision request with three parts:

• Evidence: the order section containing the integration and the current delivery plan, each with a version or retrieval time.
• Decision: allocate implementation capacity before launch, or agree a later integration date with the customer. The lead may also reject both options and ask for a revised estimate.
• Completion condition: a recorded decision, an updated delivery plan and any required customer agreement. A message saying “please review” does not satisfy this condition.

The implementation owner acknowledges the decision and updates the plan. Only then can the request move to scheduling. If the order changes during review, the old recommendation must be checked against the new version before it is used.

This is still a human decision. The automation improves how early the conflict becomes visible and how much work the decision-maker must reconstruct. The sequence is illustrative, not a report of a client implementation.

Measure a shorter journey without hiding unfinished work

The worksheet separates arrival, ready to act, actual action and completion. These timestamps answer different questions. A request can be incomplete when it arrives; a reviewer cannot act until the missing input is available. Waiting after that point may indicate a queue, a decision window or unclear ownership.

Use one row per step, with a stable request ID. For example, a fictional row might record an exception ready for review at 09:10, reviewed at 14:40 and handed to implementation at 15:00. The review queue accounts for five hours and thirty minutes. That does not mean the reviewer spent that time working on the request. Record hands-on effort separately if you want to measure labour savings.

For a first comparison, keep the request type, business-hours convention and completion definition consistent. Show both the median completion time and a slower-case measure appropriate to the amount of data you have. With ten cases, a ranked list is often more informative than a confident-looking percentile.

Review three views together:

1. Completed requests: elapsed time from arrival to the customer outcome.
2. Open requests: current age, current owner and blocking reason.
3. Quality and effort: corrections, repeated reviews and time spent by each team.

A lower average among completed cases can coexist with a growing backlog of difficult requests. That is why open work stays visible. Similarly, a shorter queue is not a gain if a downstream team absorbs extra corrections.

Agree on a pilot stop condition before introducing automation. For example, pause automatic routing if it repeatedly chooses the wrong owner, exposes records to people who should not receive them, or marks an unresolved exception as ready. Keep a manual path and retain enough evidence to understand each decision.

Use the worksheet in a short team review

Start with one completed request and one still waiting. Ask the next recipient to fill in the decision they needed, rather than asking the sender what they believed they had delivered. That comparison often reveals why a technically complete package was not actionable.

Then choose one change, such as making an order-plan mismatch explicit. Name the person who can resolve it and decide where the resolution is recorded. Review the next comparable requests with that person. Keep the change only if the outcome improves without shifting hidden work elsewhere.