Putting AI on a broken journey makes the failure faster

On-Off Group

September 2026

If the customer journey already fails people, adding AI just runs that failure faster and at bigger volume. Fix the journey first, then automate the part that works.

If you have been told to show something with AI in it this month, and you already know the onboarding flow loses people partway through, this is the order we would do it in.

AI on a broken journey does not fix the journey. It answers faster, replies in better English, and still sends the customer down the same path that loses them. The failure gets quicker and harder to see, because now it looks polished.

What follows is what we do instead: find the step where people give up, put a number on it before anything changes, then decide whether AI is the right thing to put there.

What this looks like on a normal working day

A customer starts an application on the phone. They get to the document upload, the photo of the ID fails twice, they stop. Nobody in the office sees that. What the office sees is a weekly report with a submitted count and a completed count, and nobody can say what happened between the two.

So the AI request arrives: put a chatbot on the page. The chatbot answers questions about the product. It cannot take a better photo of an ID. Months later the completed count has not moved and the only evidence anyone has is the number of chats the bot handled.

We see this pattern often in the rooms we work in. The team is not lazy and the idea is not stupid. The problem is that nobody has watched a real customer try the flow end to end recently, so the AI gets aimed at the part of the page that is easiest to change rather than the part that is losing people.

Watch five real people use the journey first

Before any build, sit and watch people use the thing you already have. Real customers, on their own phones, on video, doing the actual task. Five is enough to tell you where the flow fails. You do not need a big research plan to learn that the ID upload keeps rejecting photos taken indoors.

This is the cheapest week of work in the whole project, and it changes what you build. Teams walk in wanting to add AI to the front of the flow and walk out knowing the problem is in the middle of it, in a screen nobody mentioned in the plan.

It also gives you something your boss can watch. A short clip of a customer stuck on the upload screen settles the priority argument faster than slides, because there is nothing to debate. Branch staff are worth watching too. They know exactly which step they have to talk customers through every single time.

Get a before number, even a rough one

The reason so much of this work ends in a shrug is that there was never a number at the start. Someone asks "did it work?" and the honest answer is that nobody knows, because nobody measured the old flow.

Pick one number you can get this week and write it down. Completion rate from start to submitted. Turnaround time from application to decision, in days. Number of applications that come back for a missing document. It does not have to be perfect. It has to exist before you change anything, and it has to be the same measure afterwards.

Most of the teams we work with have no before number at all on the customer journeys they are trying to improve. That is not a small gap. It means every improvement claim is a matter of opinion, and it means a project that genuinely worked cannot prove it. If the number turns out small, say so. A small honest number survives a review. A big vague claim does not.

Fix the flow, then decide where AI goes

Once you know the failing step and you have a number on it, the AI decision gets easy. Sometimes the answer is AI: reading a document, drafting a reply, checking a form before a person has to. Often the answer is a form with fewer fields, or a clearer error message, or not asking for the same document twice.

A series of five day design sprints we ran with a large insurer on customer-facing web journeys is the clearest example we can point to. Journeys that had previously taken six months or more to get out were designed and tested with customers in two weeks, and live in four. That took time to market from 26 weeks to 4. Completion rates on the new journeys rose 80 percent and the old drop-off points went away.

That gain came from fixing the flow and testing it with customers, not from adding intelligence to a flow that was already losing people. Once the flow works, AI added on top makes a working flow faster rather than a failing one.

Show a working thing, not a plan for one

The trap after all this is a document. A roadmap, a business case, a phase one and phase two, and three months of review meetings before anyone builds.

Build a rough working version of an AI feature before you write the business case. Rough means it only handles the one step you identified, it has no login, and it looks unfinished. Then put it in front of someone who does that task for a living and watch them use it without help.

You will learn more from watching that than from the whole scoping exercise. Usually you learn that the feature needs to do less than planned, and that a thing you assumed was fine is the part people get stuck on. Then the business case is easier to write, because it describes something that already exists and has been tried with a real user.

A five day design sprint we ran with Meralco, and what came out of it, is written up at onoffgroup.com.

What to do this week

Pick one customer journey where people are dropping out: onboarding, claims, a renewal.
Record five real customers using it on their own phones, start to finish, no help from you.
Write down one before number today: completion rate, turnaround time in days, or returned applications.
Mark the single step where most people stop, and ask whether AI helps at that step or somewhere else.
Build a rough version of the fix and watch one person try it, before you write anything up.

Questions people ask

So where do we start instead?
Start with the journey itself. Find the step where customers drop off or turnaround time stretches, fix that, then look at where AI helps.

How do we know if the AI pilot worked?
Take a baseline first. Without a before number on things like turnaround time or completion, the answer to "did it work" is a shrug.

Where can we see more of this work?
Workshop scripts and the projects they came from are at onoffgroup.com.

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.