How to get AI adoption past the pilot stage

On-Off Group

October 2026

To get AI adoption past the pilot, pick one real task a team does every week, set a before number for it, fix the customer journey underneath it, then measure the same number again after four to six weeks. Adoption grows task by task, not licence by licence.

If your AI pilot demoed well and then usage flattened, this is the order of steps that gets it moving again. The pilot group has gone back to their normal work. The licences are still being paid for.

The order below is the one that works after a pilot: pick one task, get a before number for it, check the customer journey around it, then widen it.

None of these steps needs extra spend beyond the licences you already pay for. Most of it your own team can do.

Work out what the pilot actually proved

A normal week after a pilot looks like this. The dashboard says most of the pilot group have accounts, and only a handful logged in last week, half of them your own people.

That is not failure. It usually means the pilot showed the tool runs, and said nothing about whether the work changed.

Write down the task the pilot covered, who did it, and what happened to that task when the pilot ended. If people went back to the old way, the tool was never part of anything the team gets checked on.

In workshops with bank and insurer teams, the same pattern comes up. The demo used a tidy sample case. The real queue has scanned documents, missing fields, and a branch staff member chasing a customer by phone. The pilot was never tested on that queue.

Pick one task that one team does every week

The instinct after a good pilot is to widen it. More licences, more teams, an announcement.

Widening it is the wrong move. Pick one task that one team does every week and that someone already complains about. Document checking in onboarding, say, or drafting the first reply to a complaint.

One task means you can watch it. You can sit with two people doing it and see where the AI helps and where they quietly switch back.

We wrote about the licence version of this problem here: Instead of buying AI licences for everyone, train one real task first.

The training room does not tell you whether it worked. The test is the first piece of real work after the room empties. Did anyone open the AI tool, and did it help? Attendance and a good feedback score tell you people showed up, but that's it.

Get a before number for that task

Most teams cannot answer "did it work" because nobody wrote down what it was like before. Then the boss asks, and all you have is a shrug and a demo video.

Pick one number for the task you chose. Turnaround time is usually the honest one. How long from the request landing to it being done, measured over two normal weeks, including the bad days.

Count it by hand if you have to. Twenty cases timed by one person is a real baseline. It beats a system report nobody trusts.

Write the number down somewhere your boss can see it, with the date and how you counted it. Then set the date you will count it again, four to six weeks out, the same way.

Small honest numbers survive scrutiny. "Eight days down to five on twenty cases" holds up in a meeting. "Significant efficiency gains" does not.

Check the journey underneath before you widen anything

If the task sits inside a customer journey that is already broken, the AI just gets you to the same bad result faster. The customer still drops off at the same step.

Before spreading the tool, walk the customer journey around that task end to end. Five real users on video is usually enough to show where it breaks. Look for the step where customers stall, which is often nowhere near the step the AI touches.

This is worth doing first: Fix the customer journey before you put AI on it.

A large insurer we worked with ran a series of five day design sprints on customer-facing web journeys. Journeys that used to take six months or more were designed, tested with customers in two weeks, and live in four. Completion rates on the new journeys rose 80 per cent and the old drop-off points disappeared. The speed came from testing with real customers in the first two weeks, before anything was built on top.

Build a rough version and watch someone use it

The gap between pilot and rollout is usually filled with scoping. More meetings, more requirements, a business case being drafted.

Build a rough working version instead and put it in front of two people who do the task. Something they can type into, not screenshots in a PowerPoint.

Most teams arrive with the idea written up in a PowerPoint, and once they start building, the slides turn out to be wrong. Building it shows what the slides left out, usually an input nobody had, or an approval step that makes the whole thing pointless.

Give the two people the real work, not a sample, and stay quiet while they use it. Note every place they stop. Fix those, then hand it to five more people.

Make someone own the number once the pilot ends

Usage drops off when the pilot owner moves to the next thing. The tool is still there, the new way of working is not, and months later nobody can say what changed.

So name one person in operations who owns the task and its turnaround time. Make it the turnaround time they own, not just the licence. Put that number in whatever they already review weekly. If it does not appear in a report someone reads, it will not be counted.

Do the same with the know-how, so more than one person can run the task with the tool. If only a vendor or one keen person can do it, it leaves with them: UX agency or in-house team: how to keep the skill after the project.

What to do this week

Write down the one task from the pilot that is still being done the new way, and who is doing it.
Time twenty real cases of that task by hand and record the date you counted.
Watch two people do the task with the tool and note every point where they switch back to the old way.
Book the re-count for four to six weeks out and put it in the same report your boss already reads.
Hold off on more licences until the second count is in.

Questions people ask

What if we never set a baseline before the pilot?
Set one now for the task you are about to change. Turnaround time on a single step, measured over two normal weeks, is enough to compare against later.

Should we buy licences for everyone after a successful pilot?
Not yet. Licences spread access, not habit. Train one real task with one team first, count how many people still do it that way six weeks later, then decide how far to spread it.

How long should we wait before judging whether adoption has stuck?
Four to six weeks after the training or pilot ends. That is long enough for the room to empty and normal work to resume, and short enough that people still remember what they were shown.

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.