Stop Trying to Digitalize Everything

Let's say you did everything right. You gave your digital team real authority. They can decide what to build. They can say no to stakeholders. They're accountable for outcomes, not just delivery.

And then they fail anyway.

They had the authority. They just tried to do too much.

InsureCo had a digital team with real authority. Smart people, executive support, genuine decision-making power. Their mission: build a self-service portal that lets customers handle everything they currently call the contact center for.

Everything. That was the mistake.

The Completeness Trap

InsureCo's team started by mapping every call type to the contact center. Policy changes, claims filing, payment questions, coverage explanations, beneficiary updates, address changes, document requests, dispute resolution, cancellation requests - the list went on for pages.

Then they tried to build digital solutions for all of it.

Eighteen months later, the portal was a maze. Customers couldn't find anything. The flows were convoluted because they had to handle every edge case. The codebase was a nightmare because every rule from the legacy system had been replicated in the new one.

Call volume didn't drop. Customers tried the portal, got frustrated, and called anyway - now angrier because they'd wasted time first.

The team wasn't incompetent. They were thorough. And thoroughness killed them.

The Tyranny of Completeness

The trap: when you digitalize a process, there's enormous pressure to handle every scenario the old process handled.

The logic seems sound. "We can't launch until customers can do X" - where X is some edge case that affects 2% of users. "We need parity with the existing system" - even though the existing system is a mess of accumulated exceptions.

Before long, your clean digital journey becomes a digital version of your legacy chaos. You've automated the bureaucracy instead of eliminating it.

The result is a product that handles 100% of scenarios - and delights 0% of users. No one wants to be blamed for the case that wasn't covered. So teams pre-emptively cover every case, building complexity to avoid criticism.

The 80/20 Principle (Actually Applied)

You shouldn't digitalize everything.

Design your digital journeys for 80% of cases. The simple ones. The common paths. Make those flows beautiful, simple, and fast.

The other 20%? Handle them differently.

I know this sounds like heresy. "But we want a fully digital experience!" Sure. But a fully digital experience that's terrible is worse than a partially digital experience that's good.

I've seen this exact pattern play out multiple times. InsureCo eventually figured it out - most teams do, after the first launch humbles them. Their second attempt focused only on the five most common call types. No edge cases. No complex scenarios. Just the stuff 80% of customers needed, done really well.

Adoption tripled. Customer satisfaction scores jumped. And the contact center could now focus on the complex cases instead of answering the same simple questions repeatedly.

What About the 20%?

"But we can't just ignore 20% of our customers!"

You're not ignoring them. You're handling them differently.

Keep the old channel alive. Your contact center, your branch offices, your existing systems - they still work. Customers who don't fit the digital path can use them. This isn't a failure of your digital strategy. It's acknowledgment that not everything needs to be digital.

Create a human escalation path. For customers who start digital and hit a wall, make it easy to reach a person. "This is too complex for self-service - click here to connect with an agent." That's good design, not defeat.

Not every process can or should be digitalized. A complicated insurance claim with multiple parties and disputed liability? That needs humans. A life event that triggers complex policy changes? That's a phone call. And that's OK.

What matters is making it a deliberate choice, not a gap in your system. Force migration over time by incentivizing the holdouts to change - don't build for them.

A useful test: if you have to train your employees to do something in your systems, it will be a problem for digitalization. You're teaching your sales team how to push orders for a new product or navigate a complex portfolio. Now imagine asking customers to do the same thing. The processes that require internal training are the ones that will fail as self-service.

Forcing Migration (Without Building for Edge Cases)

Some customers will cling to old processes forever - unless you make that uncomfortable. Not impossible. Uncomfortable.

Price differentiation. Digital-first customers get better rates. Paper statements cost extra. Phone payments have a fee. Suddenly the edge cases have an incentive to become standard cases.

New features go digital-only. The loyalty program requires app enrollment. Certain promotions are only available online. If you want the good stuff, you come to us.

Sunset old services. Announce that paper forms are going away in 18 months. That the old portal will be decommissioned. Give people time, give them support, but draw a line.

Then there's the harsh option: reduce old channel quality. Longer hold times for the contact center. Fewer branch locations. Slower processing for paper forms. Don't make analog impossible - make it inconvenient enough that digital looks better.

A caveat: this only works when customers don't have easy alternatives. Utilities, government services, and healthcare monopolies can get away with making analog channels less convenient. If you're in a competitive market - retail banking, telecom, insurance - degrading service quality just drives customers to your competitors. In those markets, you migrate the 20% by making digital so obviously better that calling feels like a waste of their own time. The pull has to be stronger than the push.

The goal isn't to abandon customers. It's to shift behavior. Most of that 20% can become part of the 80% if they have a reason to.

Why This Is Politically Hard

The real challenge: every edge case has an internal champion.

The Head of Commercial Accounts will fight for features that serve her biggest customers, even if there are only 50 of them. The Compliance Officer will insist on handling regulatory edge cases, even if they're 0.1% of volume. The longtime employee will remember the one time, 15 years ago, when an exception process was critical.

Saying no to these people requires the same authority we talked about earlier. And it requires something more: the ability to articulate why doing less is actually doing more.

The most effective argument I've found isn't about what the edge case costs to build. It's about what everything else costs while you're building it.

When the Head of Commercial Accounts insists on supporting custom contract workflows for her 50 biggest customers, don't argue about whether those customers matter. They do. Instead, reframe the trade-off: "Building this delays launch by four months. That's four more months where 8,000 other customers are stuck calling the contact center for things they could do in 30 seconds. Are those 50 accounts worth that?"

Most stakeholders aren't unreasonable. They just haven't seen the cost of their request measured in everyone else's experience. Make the trade-off visible and specific, and the conversation changes.

Not everyone will be convinced. You build it anyway.

The Integration Tax

There's another reason teams try to digitalize everything: they don't want to maintain integrations with legacy systems.

If your new portal has to hand off certain cases to the old system, that's integration work. The two systems need to share data. Customer state needs to persist across channels. It's technically annoying.

So teams try to avoid it by building everything into the new system. This is a mistake. The integration tax is real, but it's cheaper than building and maintaining flows for every edge case forever.

It's a phase-out cost. You pay the integration tax now, knowing you'll sunset the legacy system eventually. Not a permanent architecture, just a transition state.

The 80% Standard

A simple principle for your digital team:

Design for the 80%. Build for the 80%. Launch with the 80%.

After launch, watch what actually happens. Some of that remaining 20% will adapt to the digital path. Some will reveal themselves as complex cases that need human handling. Some will turn out to be smaller than anyone thought.

Then decide: Is this worth building? Or is it worth handling differently?

The answer will often be "handle differently." That's focus, not failure.

Full Circle

A transformation fails when you rename your team to "Product" but don't change who makes decisions. Costume party.

A transformation fails when you give a team authority but measure them on delivery instead of outcomes. Startup aesthetics without startup accountability.

And a transformation fails when a team with real authority tries to digitalize everything instead of focusing on what matters. Thoroughness mistaken for strategy.

Real transformation means:

• Giving a team authority to make hard choices
• Backing them when those choices are unpopular
• Measuring them on customer outcomes, not feature checklists
• Accepting that not everything needs to be digital
• Having patience while they iterate toward something great

That's it. No innovation labs, no hackathons, no bean bags required.

Just the uncomfortable work of trusting people, letting them focus, and staying out of their way.