For decades, companies treated customer service as a cost centre: built around call queues, scripted responses, and rigid escalation paths. The dominant model assumed that problems were inevitable and the goal was to resolve them efficiently. Success was measured in average handle time, closure rates, deflection performance, and of course the cost to serve.

Today, that mindset is outdated. Yet many organisations still use metrics that have been around forever — leaders aren’t sure where those metrics originated, and the metrics themselves provide diminishing insight. Consumers, meanwhile, are more informed and clearer on their expectations, rather than passively accepting whatever service experience they’re handed.

In their 2011 book The Best Service is No Service, Bill Price and David Jaffe offered a game-changing approach, showing how organisations were using the wrong metrics to measure customer service. Customer service, they argued, is only needed when something has already gone wrong — and eliminating the need for service is the best way to satisfy customers. While 2011 feels like a long time ago, they were onto something. And what they said still stands.

Today, customers want seamless digital experiences and expect frictionless journeys. They don’t want better apologies; they want fewer reasons to make contact. In a world where everyone seems busy all the time, and organisations are focused on reducing or deflecting contact, the idea that the best customer service is no customer service continues to gather momentum. A win-win, surely?

If only it were that simple. Recent research shows that for all the digital channels that exist, and the belief that “people don’t want to speak to people,” being able to call an organisation still ranks high in importance for consumers. This can be to talk through a complex situation in detail, to get reassurance, or simply to hear it from a human. In these instances, service is a necessity for the customer and adds genuine value.

So it’s not really about zero customer service. It’s about scenario-based service. There are some moments — driven by customer demand, organisational benefit, or both — where service is the best option, and other moments where it’s a sign that something earlier in the journey hasn’t worked.

The idea of zero customer service doesn’t mean ignoring customers. It means designing products, policies, and processes so intuitive and reliable that support is rarely needed. Clear onboarding. Proactive communication. Transparent pricing. Self-serve tools that eliminate confusion before it becomes a ticket. By shifting focus from reactive support to preventive design, companies reduce costs, increase loyalty, and build trust. When nothing goes wrong, service becomes invisible.

But there’s a paradox worth acknowledging here. Service that’s invisible can also be service that’s unvalued. If a customer has never had a reason to interact with you — never had a problem solved, never had a question answered, never had a person on the other end of a call show up well — they may also have no felt sense of why they should stay. At the next renewal, the next switching opportunity, the next conversation with a friend asking for recommendations, your service simply isn’t part of their thinking. The very success of designing the operation away has taken away the moments where loyalty would have been built.

This is why scenario-based service matters. The goal isn’t to hide service — it’s to design products and journeys that don’t need service for the routine, while ensuring that the moments where service does show up are moments that visibly add value. A car insurance customer who never has a claim experiences nothing of your service operation across years of cover; the moment a claim does happen, the experience either reinforces every reason to renew or undermines them. Energy customers go years without contacting their supplier; one misbilled bill or one query about a tariff change is the entire emotional impression they’ll carry into the next switching decision.

When nothing goes wrong, service should be invisible. When something does go wrong — or when a customer reaches for service deliberately — that moment should be unmistakably good.

The art of great service design, as with many things, is getting the right balance. Removing unnecessary effort for both customer and advisor. Not feeling the need to offer every channel all the time. Demonstrating real value in the moments when you do directly interact with your customers.

If you’d like to talk through what this might look like in your business, I’m easy to find. mark@soothconsulting.xyz.

Almost all the work I undertake involves engaging with a client’s operating model (OM). This can include designing a new OM from the ground up for a pre-launch company or a start-up in its early growth stages, evaluating and updating an existing OM, or entirely reimagining a company’s operations and implementing a new OM.

Over the years I’ve seen the whole range. From very detailed Target Operating Model documentation running into tens of pages (TL;DR), to the other end of the scale — businesses that have organically developed and people just got stuff done. Unsurprisingly the second approach is mostly seen in start-ups where everyone needs to muck in on whatever the priority is. It’s cost effective, builds teamwork (mostly), and focuses people on the things that are most important.

The thing is, as a business grows, that approach can turn into chaos, confusion and cost through mistakes, lack of clarity and lack of coordination.

When I talk to clients about operating models there can be concerns that an OM might slow down quick changes that are needed, or that the result could be too rigid for their business, or that it means lots of new roles and therefore cost.

In my career I have definitely seen those pitfalls come to fruition. In a recent McKinsey & Company study on operating models they found that “only 23% were highly successful” and “63% were somewhat successful.” That’s not great, particularly when you think about the effort and potential disruption the work may have brought about.

I believe an OM review and resultant changes can avoid all of those pitfalls if done correctly. It doesn’t need to be overly engineered, cost a lot of money, or take so long that opportunities are missed. Done right, it can be freeing, build engagement, and be deployed on a ‘just in time’ basis.

My approach is to quickly come to know a business through both qualitative and quantitative work. I review data, look at the goals of the business, and talk to people inside it — the approach is the same whether there are 10, 100, or 1,000 people in the business. Understanding the now and the future objectives means I can identify and describe the gap. Once we’ve described that, we design the approach to closing it.

I build modular operating models that can be deployed over time as the business needs them — supporting growth, working more effectively, reducing cost to serve, all of these, or something else.

If any of this resonates and you’d like to talk it through, I’m easy to find. mark@soothconsulting.xyz.

I’ve spent the last twenty-plus years on every side of these decisions. Sometimes as the buyer choosing a system. Sometimes as the leader inheriting one I didn’t pick. Sometimes as the consultant brought in eighteen months later to work out why the brilliant new platform isn’t delivering what was promised. The patterns are remarkably consistent. The tech is rarely the villain. The decisions made before, during and after the purchase are almost always where the value gets quietly lost.

These are the five mistakes I see most often, in roughly the order they happen.

1. Buying without living in the current experience first

Every contact centre tech engagement I take on starts the same way: I sit with advisors while they do their actual job. I watch which systems they reach for and which they avoid. I use the tools as a customer would — picking up the phone, opening the chat, navigating the IVR, completing the journey. I look at where the friction lives and where the workarounds have built up.

Five minutes of that is worth an hour of someone in head office telling you what they think is happening.

The reason this matters for tech decisions is simple: if you don’t know what’s actually broken in your current operation, you can’t know what to buy. You’ll buy what the vendor demonstrates well, or what the loudest internal stakeholder is asking for, or what looks impressive on a feature comparison spreadsheet. None of those are the same as buying what your team and your customers actually need. The result is a system that solves a problem you didn’t have while leaving the problem you did have firmly in place.

2. Not being clear what problem you’re trying to solve

Most tech buying decisions get framed too broadly. “We need a new contact centre platform.” “We need to consolidate our tech stack.” “We need to deploy AI.”

Those aren’t problems. They’re vague aspirations dressed up as briefs.

A real problem statement looks more like: “Our advisors are spending 25% of their handle time on after-call work, and our most experienced people are leaving partly because of that.” Or: “Our self-service deflects volume but increases complaints when it fails, because customers feel they’ve been pushed away rather than helped.” Or: “We’re growing 40% year on year and our current platform charges per-seat in a way that means we’re paying for capacity we don’t need.”

Each of those statements points to a different solution. The first might be a summarisation tool. The second might be redesigning the self-service journey, not buying more of it. The third might be a renegotiation rather than a replacement. Without that level of specificity, you’re not buying technology — you’re buying optimism.

The test I apply: if you can’t explain the problem in two sentences to someone outside your business, you’re not ready to talk to vendors yet.

3. Buying for the operation you might be, not the one you are

This is the most expensive mistake of the five — and it’s worth being precise about.

Buyers will always project some sense of their future operation into the buying decision. That’s reasonable; nobody wants to replace a platform every eighteen months. The problem isn’t planning ahead. The problem is buying specific functionality for an imagined future you can’t actually predict, and locking yourself into it today.

It manifests in two ways. The first is the platform decision: all-in-one suite versus best-of-breed components. The all-in-one is seductive — one supplier, one contract, one data model, the promise of seamless integration across every channel and function you might ever need. The best-of-breed approach is more rigorous — you accept some integration complexity in exchange for genuinely strong tools in each area. Neither is universally right. What makes the decision wrong is choosing based on the operation you imagine running in three years rather than the one you actually run today.

The second is over-specifying within whatever you’ve chosen. Every modern platform comes with functionality you don’t currently need: workforce management modules, speech analytics, advanced reporting, automation suites, AI capabilities. The vendor’s commercial pitch is built around the idea that you’ll grow into it. Sometimes that’s true. More often, the unused functionality becomes a tax — you’re paying licence fees for capabilities sitting dormant, while your core use case underperforms because nobody’s optimising for it.

The discipline worth applying isn’t don’t plan for the future — it’s buy for flexibility, not for predictions. A platform that’s modular, that scales sensibly, that lets you add and remove components as your needs actually emerge, gives you the genuine optionality buyers think they’re getting from over-buying. A platform sold to you on the basis of what you’ll need in 2029 is selling you a forecast nobody can make accurately, and charging you for it today.

Buy what you can credibly use, well, in the near term. Make sure what you buy can grow with you. Treat any specific feature you’re buying for “the future” with healthy suspicion.

4. Underestimating the people change required

A new platform isn’t just a tech project. It’s a change project that happens to involve technology.

Every contact centre tech decision I’ve seen succeed has had three things alongside the platform itself: a properly resourced training plan, redesigned processes that actually use the new capabilities (rather than replicating the old ones on the new system), and a leadership team prepared to back the team through the inevitable performance dip in the first few months.

Every contact centre tech decision I’ve seen disappoint has skimped on at least one of those three. Usually two. Sometimes all three.

The reason this gets underestimated is structural. The business case for the technology is built around the cost of the technology — licences, implementation, integration. The people change is a different budget line, often owned by a different team, sometimes not budgeted at all. The result is that organisations spend hundreds of thousands on the platform and nothing on the change required to use it well. The platform then under-delivers, and the post-mortem typically blames the vendor rather than the buyer.

The test I’d apply: if your business case doesn’t include the cost of training, process redesign, and leadership time over the first six to twelve months, your business case is wrong.

5. Skipping the pilot — or running a pilot designed to succeed

The most experienced buyers I’ve worked with insist on a pilot before any major contact centre tech purchase. The least experienced ones either skip it entirely, or run a pilot so carefully designed that it can’t fail.

A pilot designed to succeed looks like this: a small, motivated team using the new platform on hand-picked easy cases, with the vendor providing white-glove support, in a tightly controlled environment. The pilot delivers exactly what the demo promised. The decision is made. Twelve months later the production rollout struggles, and nobody can quite explain why.

A real pilot looks different. It runs against actual operational conditions — real customer mix, real volumes, real edge cases, real handoffs between systems. The vendor is involved but not over-involved. The team is representative rather than hand-picked. There’s a clear definition of what would constitute the pilot succeeding and what would constitute the pilot failing — and a credible willingness to walk away if the latter happens.

The point of the pilot isn’t to confirm the decision you’ve already made. It’s to test it.

A final reframe

If I had to compress all five into one principle, it would be this: the technology decision is the easy bit. The hard bits are everything around it.

Knowing what you’re buying for. Understanding the operation you’re buying into. Resisting the seductive promise of capability you don’t yet need. Resourcing the people change properly. Testing under real conditions before you commit.

Most contact centre tech projects don’t fail because the technology was wrong. They fail because the buyer didn’t do the work that surrounds the technology — and no system, however good, compensates for that.

If you’re navigating one of these decisions and would like to talk through what you’re seeing, I’m easy to find. mark@soothconsulting.xyz.