Why a New Platform Doesn't Fix Bad Communication

Every year, another wave of banks, insurers and utilities sign off on a new customer communications or CX platform. New logo, new dashboard, new promise: faster time to market, better personalisation, a single view of the customer.

Eighteen months later, the letters are still confusing. The claims correspondence still reads like it was drafted by a lawyer for another lawyer. The billing notice still buries the one thing the customer actually needs to know on page three.

The platform did what it was bought to do. It didn't fix the communication, because that was never really the platform's job.

The real issue

There's a quiet assumption behind a lot of technology business cases: that better infrastructure produces better output almost automatically. Give the business a modern customer communications engine, a new sending platform, an AI layer, and the quality of what customers receive will improve as a side effect.

It's an understandable assumption. It's also wrong, and expensive to be wrong about.

A platform is a delivery mechanism. It assembles, personalises and sends content faster, more reliably and at greater scale than what it replaced. What it doesn't decide is whether the content itself is any good: whether the letter explains the decision clearly, whether the tone fits the moment, whether the whole thing was built around the customer's situation or the business's internal process.

Those are content and communication design decisions. They sit upstream of the platform. If they were poor before the migration, the new platform just sends the same poor decisions out faster and to more channels at once.

What this looks like in practice

An insurer replatforms its customer communications system as part of a broader claims transformation. Templates are centralised, approvals are faster, the old legacy engine is retired. But the claim letters themselves were carried across largely unchanged, because nobody wanted to reopen "content" while the technical migration was already complex enough. Customers still get a dense, legalistic letter when their claim is declined, just from a shinier system.

A bank rolls out a new digital messaging platform to send real-time alerts instead of monthly statements. The technology works, but the logic for what triggers a message, and what it says, was inherited from the old batch system. Customers get more messages, not necessarily more useful ones, and complaints about "too many notifications" start appearing alongside the ones about unclear language.

A utility invests in a new billing engine specifically to reduce billing enquiries. It's faster and more accurate. The layout, the explanation of charges, the way usage is presented, wasn't part of the project scope. Enquiry volumes barely move, because customers weren't confused by the arithmetic. They were confused by the explanation.

In each case, the technology performed exactly as specified. The communication problem the business actually had was never on the project plan.

The maintenance bill that arrives later

There's a second cost that rarely makes it into the business case, and it isn't really about the quality of any individual letter either. It's not the migration cost. A project can come in on time and on budget, the old platform can be decommissioned cleanly, and the whole thing can be called a success. The expensive part is what happens afterwards, when the content that got migrated across was never designed properly in the first place. You can migrate the mess for less than expected and still pay for it for years.

Most modern customer communications platforms can handle content as reusable components: a standard disclosure clause, a signature block, a hardship statement, a piece of regulatory wording, a logo or letterhead treatment. Build these once and reference them wherever they're needed, and updating a piece of wording updates every document that uses it.

Whether that happens is a design decision, not a platform feature. Under project time pressure, a migration often becomes a lift-and-shift: hundreds of existing templates move across largely as they were, with the same clause copied into each one rather than pulled from a shared source. The result is a modern, capable platform sitting on top of exactly the same duplicated content structure the business had before, just wearing nicer software.

The bill for this arrives later, and keeps arriving. A regulatory update to a hardship disclosure, a changed phone number, a rebrand: instead of updating one component, someone has to locate and update every template that contains it, and hope they found them all. A missed instance isn't just untidy. It means two documents say two different things about the same clause, which is a compliance problem as much as a content one.

This part of a poorly scoped migration is genuinely invisible at go-live. It shows up two or three years in, in the size of the content team needed to keep several hundred near-identical templates consistent, in how long it takes to turn around a simple wording change, and in the audit finding that surfaces because nobody could confirm every instance of a clause had actually been updated.

Where AI fits, and where it doesn't

AI is now routinely bolted onto these platforms, usually as a drafting or personalisation layer. Used well, it genuinely helps: drafting variations faster, tailoring detail to context, catching inconsistencies across thousands of templates that no human reviewer would ever spot by eye.

Used on top of a poor content foundation, it does exactly what the platform migration does. It scales the existing problem. A confusing claim letter, run through an AI drafting tool, becomes confusing letters faster and in greater volume, often with more convincing confidence. Personalisation makes this worse, not better, because a confusing letter that feels written specifically for you is still a confusing letter.

The organisations getting genuine value from AI here have usually done the less glamorous work first: they know what good looks like for a claims letter or a hardship notice, and they're using AI to produce and maintain that standard at scale. The technology amplifies a decision that was already made well. It doesn't make the decision for them.

Why this matters commercially

The gap shows up in the numbers a business cares about, just not always where it's looked for. Complaint volumes don't fall the way the business case predicted. Contact centre calls about "what does this letter mean" continue at roughly the same rate, now handled by staff working with a system that was supposed to have solved this. Trust, particularly around decisions like claims declines or financial hardship, doesn't improve just because the decision arrived through a nicer channel.

Then there's the ongoing cost of running the thing. Every duplicated clause is a small piece of technical debt, and it compounds: the cost of any change goes up every time the same wording is pasted into another template instead of built as a shared component. Teams that should be redeployed to genuinely improve customer communication after a migration instead spend their time keeping several hundred versions of the same clause in sync.

None of this means the technology investment was wasted. It solved a different problem to the one the business actually needed solved, and the two get conflated often enough that it's worth saying out loud.

The advantage medium-sized organisations have here

Large enterprises tend to carry enormous sunk cost in their existing platforms and years of template sprawl, which makes "let's also fix the content architecture" a hard conversation to have mid-project. Medium-sized organisations usually have a smaller, more recent template library and fewer legacy exceptions, which makes it far more realistic to do the design work properly: define the reusable content blocks, agree what good looks like for each key customer moment, then choose or configure the platform to deliver it. It's a smaller decision to make, and it avoids paying for the same migration twice, once now and once again in a few years when the maintenance load becomes unsustainable.

The point isn't that technology doesn't matter. It's that it's the second decision, not the first. Get the communication right, and the right platform makes it scale. Get the platform right and assume the communication will follow, and you've usually just bought yourself a faster way of sending the same problem.