Your Best AI Opportunity May Be Between Two Screens

Look between the tools people use before deciding where AI belongs. That is where a handoff can expose work your feature plan has missed.

In a typical workflow, someone reads a message and checks the details in another system. Then they copy those details across. The screens look simple. I want to understand the work connecting them.

Where should you look for AI opportunities in a workflow?

It depends on what makes the work difficult. Varied documents that need interpretation are candidates for AI assistance. Known information moving between systems may need an integration. Waiting for a decision may need a clear owner. Start by following the work across the handoff and asking what the recipient needs.

A screen can work well while the person receiving its output still struggles. I check what the next person needs before choosing a feature. Their part of the task counts too.

What happens between the screens?

Here is a hypothetical service booking. A customer sends a request. The operator checks availability against the message. Then they copy the details into a scheduling tool. Someone else confirms the arrangements.

You can see the request and the booking on screen. In between, the operator has to understand what the customer means. They also have to decide whether they have enough information.

I ask the operator to walk through a recent case. Where did each detail come from? What happened when something was missing? Then I ask the next person what they check before confirming.

That walkthrough helps separate copying from interpretation. Sometimes the repeated question is about who can make a decision. Giving someone that responsibility changes the options we should consider.

I keep those explanations open until the walkthrough and available records support one. Picking a tool comes after that.

Why does the whole journey matter?

McKinsey's 2016 journey research reported an association in insurance and TV. A one-point improvement in journey satisfaction corresponded to at least three percentage points more revenue growth.

Satisfaction used a ten-point scale. The article omits the sample size and detailed model, which limits what we can infer. These are correlations about journey performance, rather than measured returns from drawing maps.

For our booking, I start with the customer's goal and follow it through. Responding faster sounds useful. But if confirmation still waits on the same missing detail, the customer is still waiting.

Use the customer's goal to set the boundary. Then inspect the internal work that makes the goal possible.

When do you need a service blueprint?

As of October 2026, NN/g's service blueprint guidance connects customer touchpoints with visible and backstage service components.

A blueprint is useful when the customer problem depends on work they cannot see. For our booking example, that includes checking availability and assigning someone to confirm it.

I record what arrives at each step and what the next person needs. I put the evidence beside that account, along with who can change the step.

A missing field and an unavailable decision maker can both delay a booking. Seeing the cause helps us decide what software should do.

How do you choose between AI and a simpler fix?

Once I understand the cause, I compare possible fixes. Here is a decision aid for the hypothetical booking, rather than a table of research findings:

What the handoff requires	First option to investigate	Possible role for AI
Copy an existing booking reference	Direct transfer between systems	Usually little benefit
Read varied customer messages	Better intake instructions	Propose structured details
Wait for confirmation	Named owner and visible queue	Limited unless prioritisation needs interpretation
Calculate a known total	Calculation rules	Explain the inputs if needed

The Google People + AI Guidebook recommends mapping current workflows and checking whether AI adds unique value. That supports asking these questions before selecting technology.

For message reading, I compare a clearer form with AI-assisted intake. I include requests the form handles poorly. Otherwise, we are only testing the easiest part of the work.

AI earns its place if it makes varied information easier to use. The result must reach the operator's tool, with the original request available for checking.

How do you test a handoff before building it?

I start with a bounded comparison:

1. Choose a specific handoff and define what counts as an accepted result.
2. Collect permitted examples, including incomplete requests and unusual cases.
3. Try the current method and the proposed change on comparable work.
4. Record total effort and corrections, then ask the recipient whether the result is usable.

I include difficult requests from the start. A clean demonstration can make the task look easier than it is. Record what the trial covered and where we still need evidence.

I also check how AI handles missing information. Does it leave a gap or suggest a detail? A plausible suggestion can take longer to verify than an empty field.

Put correction into the prototype too. The operator needs to change a suggestion and continue working. Test that interaction alongside the generated output.

Who owns the result across the handoff?

I name an owner for the complete outcome. They need to see whether time saved by one person becomes extra checking for someone else.

If the operator finishes sooner but the confirmer spends longer checking, record both effects. If an integration removes copying but adds maintenance work, include that responsibility too.

The comparison should survive ordinary operation. Keep the manual route available while learning which cases the proposed change handles well. Set the acceptance standard the handoff must meet before expanding its use.

For the wider discovery sequence, start with Before the PRD. For the financial comparison, see Cheap AI Outputs Can Be Expensive Workflows.

We connect the chosen outcome to Requirements and Iterative development through the process. You can see the available offers or book a call with a workflow you want to improve.

I judge the change by whether the work reaches a usable result. Follow it all the way through.

What else should you know about workflow handoffs?

Does copying between tools mean we need AI?

First check whether the information already exists in a usable format. An integration or shared record may transfer it more predictably.

What is the difference between a journey map and a service blueprint?

A journey map follows someone's experience. A service blueprint connects that experience to the visible work and internal processes that deliver it.

Where should I look for AI opportunities?

Look where useful work depends on interpreting varied information. Check whether the output meets the recipient's needs and how much effort verification requires.

How should we measure a handoff improvement?

Measure from the original trigger to an accepted result. Count the effort added for the next person, including correction. Record waiting time separately.