Why transformation stalls in Philippine banks and insurers

On-Off Group

October 2026

Transformation stalls in banks and insurers because the work stops between the strategy deck and the customer, and because nobody recorded a before number. Without a baseline for things like onboarding turnaround time, no one can prove a pilot worked, so the next round of funding goes elsewhere.

If you run digital, CX or operations at a Philippine bank or insurer, you have probably watched a project go quiet. This is about where that usually happens, and what to measure so you can answer your boss when they ask whether the pilot worked.

We have run workshops and projects for Philippine financial services since 2015. The same stall shows up in almost every room, and it is rarely the strategy that caused it.

Five places it stalls, and what to measure at each one.

The gap between the strategy deck and the customer

It usually goes like this: the plan gets approved, then it has to cross six teams before a customer sees anything. Legal, compliance, core systems, the vendor, marketing, branch operations. Each one is reasonable on its own. Together they add weeks.

In practice it is a status call where three people say they are waiting on someone who is not on the call. Nothing is broken and nothing moves.

The fix is to cut the time between a decision and a test with real customers. In a series of five-day design sprints on customer-facing web journeys for a large insurer, 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. The work stopped sitting in a queue between teams.

Before paying for a fix, find out which part of the business is holding things up. Score each area rather than guessing.

Nobody wrote down the before number

This is the most common reason a project cannot be defended. The team improves something real and has nothing to compare it against.

Ask what onboarding turnaround time was six months ago and you usually get a shrug, or a number someone half remembers from a PowerPoint. So when the boss asks whether the pilot worked, the honest answer is that it feels better.

Write the before number down first. It does not need to be perfect. Pick two or three the business already argues about: turnaround time on the onboarding flow, completion rate on the online application, how many submissions branch staff have to send back for rework. Measure them for a week. Keep the method boring so you can repeat it after.

On those insurer journeys, completion rates rose 80 per cent and the old drop-off points disappeared. We can only say that because someone had written down the completion rate before the work started.

AI gets added to a journey that already fails

There is pressure to show something with AI this quarter. So a chatbot or a document reader gets bolted to the front of a process that already loses people at step four.

You then get more customers reaching the broken step, faster, and branch staff fixing it by hand where the reporting never sees it.

Fix the journey first, then automate the part that works. If a step exists only because a system cannot talk to another system, no prompt will help it.

The cheap way to find out is to watch five real customers try the journey on video. Whatever makes them stop is your list, in order. If the biggest problem is a required field nobody can answer, that is a week of work and it has nothing to do with AI.

The strategy phase eats the budget

Six months of discovery, a fat set of slides, and nothing a customer can use. The money is gone and the customer experience is the same as it was on day one.

Size the gap before buying the fix. Two weeks of scoring, or two weeks of watching real users, tells you whether this is a big spend or two weeks of developer time. Sometimes the number turns out to be small, and we say so. We wrote about that choice here: instead of hiring a strategy consultant, size the gap in two weeks.

Then build a rough working version of the feature and put it in front of someone. A lot of the arguing in a scoping meeting stops once there is something on a screen to click.

Nobody used the training on Monday

People get sent to a session. The feedback score is good. Nothing changes in the work.

It stalls because nobody picked the first real task the training was for. Tie the session to work already in the queue, like summarising claim notes or drafting the first reply to a complaint, and people use it that week.

Check a couple of weeks later. Did anyone open the AI tool, and did it help? That tells you more than the feedback form.

The same applies to design and research skills. Our design thinking sessions put developers and product people in the same room as the business owners, and the work gets used. Some of the people in our 2015 Sun Life workshops are now senior across the industry.

What to do this week

Write down the before number for one customer journey, even if it is rough, and note how you measured it.
List the steps in that journey where branch staff fix things by hand, and work through that list first.
Take one stalled item and ask what it is waiting on, and who can release it. Put a name next to it.
Before any AI work starts, watch five real customers try the journey and keep the recordings.
Park anything a customer cannot try yet, and be honest with your boss about why.

Questions people ask

What baseline should we record before a pilot starts?
Pick two or three numbers the business already argues about, such as turnaround time on onboarding, completion rate on the online form, and how many applications branch staff have to rework. Write them down before anything changes.

Should we fix the customer journey before adding AI?
Yes. Putting AI on a journey that already fails means the failure happens faster and at larger volume, so fix the steps that drop customers first.

How long does it take to see where the work is stalling?
Two weeks is usually enough to score the operating model or watch real users attempt your journey. The point is to size the gap before anyone commissions the fix.

Why does training often make no difference on Monday?
Because people were sent, not chosen, and nobody named the first real task they would use it on. Tie training to work already in the queue, then check a fortnight later whether anyone used it.

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 diagnostics.