Fix the journey or add the AI: how to decide which comes first

On-Off Group

October 2026

Fix the journey first when the drop-off is caused by steps, handoffs and waiting. Add the AI first when the steps are sound and the delay sits in one task a person repeats. Either way, take a before number for turnaround time before anything changes.

You have one pot of money this quarter and two things pulling at it. One is the customer journey work you have already mapped. The other is an AI feature management has asked about by name.

This is for heads of digital who have to choose, and who will be asked later whether it worked. It gives you a way to decide whether to fix the journey or add the AI first, and what to measure so the answer is not a shrug.

Short version: where the delay sits decides. If the delay comes from extra steps, handoffs and waiting, fix the customer journey. Where the steps are already sound and one repeated task is slow, put the AI on that task.

What the choice looks like in the room

The onboarding flow has a drop-off nobody can explain. Branch staff have a workaround they have been using for a year. Meanwhile there is a request in your inbox for an AI assistant, and a vendor who can demo one next week.

So the meeting turns into a preference argument. Someone says customers first. Someone says we need a win on AI. Nobody has a number for how long the flow takes today, so both sides are just guessing.

The way out is boring. Before either project, sit and watch five real customers use the current journey, and time one week of real cases end to end. That gives you two things: where people stall, and how long it takes today. Both answers point at the work, and one of them is the before number you will need later.

Fix the journey first when the delay is in the steps

If the stall happens between people, fix the journey. A form that asks for a document the customer does not have to hand. An approval that waits for someone in another department. A rejection with no reason on it, so the customer starts again from the top.

None of that gets better with an assistant bolted on. It just fails faster, and for more customers. We wrote about that pattern in Fix the customer journey before you put AI on it.

The upside of doing this first is that it moves real numbers. On customer-facing web journeys with a large insurer, we ran a series of five-day design sprints. Journeys that had previously taken six months or more were designed and tested with customers in two weeks, and live in four. Twenty-six weeks down to four. Completion rates on the new journeys rose 80 per cent, measured by the client, and the old drop-off points stopped appearing.

Add the AI first when one task is the bottleneck

Sometimes the flow is fine and one job inside it is slow. A person reading the same kind of document forty times a day. Someone writing the same reply with three details swapped. A team summarising case notes before they can act on them.

That is a good place to start with AI, because the task has a clear start and end. You can time it now, change one thing, and time it again. You are not redesigning anything customers touch.

Start with a rough working version in front of the person who does the job, not a business case. Watching them use it will tell you more than a costed proposal, and it usually kills or confirms the idea quickly. That argument is set out in Build a rough working version of an AI feature instead of writing the business case first.

One warning. Buying licences for everyone is not the same as adding AI to a task. Licences get handed out, barely used, and forgotten. Pick the one task, prove it, then widen.

Whichever you pick, take the before number

Most of the teams we sit with have no baseline. They have a project that ran for six months and a slide pack at the end of it. When the boss asks whether turnaround time improved, the honest answer is that nobody knows, because nobody wrote down what it was before.

You need two numbers and nothing clever. Turnaround time on the flow you are changing, measured end to end from the customer's side. Completion rate on the same flow. A week of real cases is enough.

Small numbers are fine. A drop of a few days in turnaround time is a sentence your boss can repeat. A projected saving with no measurement behind it is not. If the number barely moves, you have learnt something cheap, and you can say so before someone spends a year on it.

If the gap you are trying to size is customer behaviour rather than time, One-off customer research or monthly insight: which suits you covers when a single round of watching users is enough and when you want it running every month.

Do not run both at once

The tempting move is to fund both, to keep everyone happy. Then the number moves and nobody can say which change did it. Worse, if it does not move, both teams blame the other one.

Sequence them. Fix the journey, measure, let it settle for a few weeks, then put the AI on the task that is still slow. The second project is cheaper by then, because the steps around it have settled, and branch staff already believe something can improve.

One more thing. Your before number from the first project becomes the before number for the second, and you end up with a run of measurements instead of two unrelated stories.

What to do this week

Write down, in one line, what the delay actually is: steps and handoffs, or one repeated task.
Time one week of real cases end to end, and note the completion rate on the same flow.
Watch five real customers use the current journey on video, without helping them.
Pick one of the two directions for this quarter and put a date on when you will measure again.
Tell your boss the before number now, in writing, so the after number means something.

Questions people ask

How do I know the journey is the problem and not the AI gap?
Watch five real customers try the flow on video. If they stall at a step, a handoff or a wait for approval, that is a journey problem and AI will only make the same failure arrive faster.

What before number should I take?
Turnaround time end to end, plus completion rate on the flow you are changing. A week of real cases is enough to stand on when your boss asks whether it worked.

Can we do both at once?
You can, but then nobody can say which change moved the number. Sequence them a few weeks apart and keep measuring the same two things.

How fast can a journey fix actually ship?
On customer-facing web journeys with a large insurer, journeys that used to take six months or more were designed and tested with customers in two weeks and live in four.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with ai adoption.