<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Mark J Adams]]></title><description><![CDATA[Honest writing on customer service operations — strategy, design, and the messy bits in between. By someone who's run them, not just advised on them.]]></description><link>https://www.markjadams.co.uk</link><image><url>https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png</url><title>Mark J Adams</title><link>https://www.markjadams.co.uk</link></image><generator>Substack</generator><lastBuildDate>Wed, 01 Jul 2026 04:42:20 GMT</lastBuildDate><atom:link href="https://www.markjadams.co.uk/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Mark J Adams]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[markjadams@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[markjadams@substack.com]]></itunes:email><itunes:name><![CDATA[Mark J Adams]]></itunes:name></itunes:owner><itunes:author><![CDATA[Mark J Adams]]></itunes:author><googleplay:owner><![CDATA[markjadams@substack.com]]></googleplay:owner><googleplay:email><![CDATA[markjadams@substack.com]]></googleplay:email><googleplay:author><![CDATA[Mark J Adams]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[Customer surveys are still dead! ]]></title><description><![CDATA[Three years ago I wrote a post arguing customer surveys had had their day.]]></description><link>https://www.markjadams.co.uk/p/customer-surveys-are-still-dead</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/customer-surveys-are-still-dead</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Wed, 17 Jun 2026 06:57:55 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Three years ago I wrote a post arguing customer surveys had had their day. The argument then was that response rates were falling, customers were busy, and the data systems coming online would soon do a better job. I&#8217;d say the point is even stronger now. Surveys aren&#8217;t just past their useful life. There&#8217;s a risk they&#8217;re distorting how companies serve customers.</p><p>Three things have changed since 2023.</p><p>Firstly, response rates have got worse, not better. Customer survey response rates in 2025 sat at 20-30% on a good day, and email channels are now routinely in the teens. The UK&#8217;s Labour Force Survey (the data the ONS uses to produce official unemployment figures) has fallen sharply to around 13%. If government statistics with real consequences can&#8217;t get people to respond, your post-purchase NPS prompt is not winning.</p><p>Secondly, AI has flipped the economics. Real-time analysis of unstructured customer interactions, the thing your call and email transcripts and chat logs already contain, was aspirational in 2023. It&#8217;s a basic and standard capability in 2026. Companies that haven&#8217;t picked it up are choosing the harder route.</p><p>Finally, and this is the one that made me stop in my tracks and move my thinking from &#8220;surveys are tired&#8221; to &#8220;surveys are harmful&#8221;. The survey economy has started corrupting the operation itself. Two experiences over the past year highlight what I mean.</p><p>A courier company couldn&#8217;t deliver a parcel to me for three months. The advisor I spoke to couldn&#8217;t help, the business processes blocked them, and they couldn&#8217;t fix the underlying problem and the parcel was never delivered. The agent, while apologetic, still had to ask me for a top rating (it was part of the process).</p><p>An Amazon seller delivered the product on time. Inside the box was a card offering me an 80&#8364; gift card if I posted a 5* review and sent them a photo of it.</p><p>No one wins here. The customer gets a worse experience, because being asked to rate a service that failed you is insult added to injury. And the score is meaningless, because the operation generating it has every incentive to game it.</p><p>It is worth calling out one defence of surveys: they give you the customer&#8217;s words. They do, but only in response to your questions. Reviews and transcripts give you the customer&#8217;s words on their terms, when they actually had something to say, in the context of trying to get something done. That&#8217;s a stronger form of customer voice, not a weaker one.</p><p>So what should you do instead? Same answer as 2023, but easier now. Spend the energy on the data you already hold. Effort scores from interaction logs, sentiment from transcripts, abandonment patterns, repeat contact rates, complaint themes. The signals are there. Stop asking customers things you could find out yourself. And stop asking your own people to force superficial reviews.</p><p>If your operation doesn&#8217;t have this data structured yet, that&#8217;s where to start. You don&#8217;t need a big programme. You need three to five signals you can read every week. If you have the data but not the capability to make sense of it, you don&#8217;t need a data science team either. You need someone who can ask the right operational questions of the data you already have, and translate the answers into changes the business can act on.</p><p>That&#8217;s the kind of work I do. If you&#8217;re in either of those positions, <a href="mailto:mark@soothconsulting.xyz?subject=Substack: customer surveys">get in touch</a>.</p><p>Surveys made sense when getting customer data was hard. It isn&#8217;t hard anymore. Anyone still running a survey-led VoC programme in 2026 is choosing the more expensive, less timely and less accurate route.</p>]]></content:encoded></item><item><title><![CDATA[What the Ofcom data is really telling you about your operating model]]></title><description><![CDATA[Three patterns in the Q4 2025 complaints data that the headlines missed.]]></description><link>https://www.markjadams.co.uk/p/what-the-ofcom-data-is-really-telling</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/what-the-ofcom-data-is-really-telling</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Tue, 09 Jun 2026 07:52:46 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The Q4 2025 Ofcom complaints figures came out a few weeks ago and almost every outlet that picked them up ran the same story. Complaints up for the first time since 2023. Mostly driven by mobile mid-contract price rise announcements from O2 and others (mild regulator finger-wag). Cue pieces about the cost of living and consumer trust.</p><p>All fair and accurate. And the wrong story for a service leader.</p><p>The interesting thing about regulator complaints data is not the headline number. It&#8217;s the operational gap between providers selling broadly the same product, in the same market, under the same rules. That gap, the one between the best and the worst, is where the lessons actually live. And the lessons in this latest set of numbers are worth a closer look.</p><p>Three of them are worth your attention. This isn&#8217;t really a piece about telecoms. It&#8217;s about what the data exposes about the operating models inside any service business, and what to do about it if you find yourself running one.</p><div><hr></div><h2>Observation one: the gap that only operating model explains</h2><p>Vodafone took 11 broadband complaints per 100k customers in Q4 2025. Virgin Media took five. The industry average sat at seven. Same broadband technology, broadly comparable products, the same regulator looking over their shoulders.</p><p>That gap, more than double the complaint rate in the same market, has to be explained by something. Strategy doesn&#8217;t explain it. Pricing doesn&#8217;t. Brand doesn&#8217;t, at least not all of it.</p><p>I worked at Virgin Mobile in the UK when we ran on the T-Mobile network. The network was identical: the same masts; the same coverage; the same dropped calls. Every year, JD Power ranked Virgin higher than T-Mobile on network performance. The reason was the Virgin brand halo. Customers wanted to believe their service was better, and so they perceived it as better. Brand absolutely shifts perception, and to some extent it shifts whether people bother to escalate a complaint at all.</p><p>But there is a limit to what brand can do. Complaints to a regulator are not a satisfaction score. They are someone deciding that service was bad enough to actively put effort in to report it. Brand halo can soften the edges. It cannot turn a failed installation into a successful one, or stop a fault going unfixed for three weeks. The 11-versus-5 gap is too wide to be brand alone, and what&#8217;s left is operating model. The unglamorous work of doing the basics consistently well.</p><p>So the practical takeaway for any service leader reading this: stop benchmarking your service operation against the sector average. Benchmark against the best in your sector. That number is what&#8217;s actually possible in your market, because someone is already there.</p><div><hr></div><h2>Observation two: the unglamorous 52%</h2><p>As others have stated, over half of Vodafone&#8217;s broadband complaints, 52% to be exact, came from issues with the broadband service itself: faults, service performance, and provisioning. Not journey design. Not voice of customer programmes. Not omnichannel strategy. The boring middle of the operating model: does the kit work, does the install happen on the day it&#8217;s booked, does the fault get fixed inside SLA.</p><p>This is what businesses consistently under-invest in, not because service leaders don&#8217;t want to fix it, but because operational basics don&#8217;t compete well for board attention against shinier strategic initiatives. The slide on &#8220;AI-driven self-service&#8221; or &#8220;frictionless customer experience&#8221; lands better than &#8220;we need to improve our installation right-first-time rate from 78% to 85%.&#8221; So the operational basics get squeezed out of the investment plan, year after year, while the leadership team spends its energy on the bits that look strategic in a deck. </p><p>The Ofcom data is a useful. It says that for the most complained-about broadband provider in the country, more than half of the reason customers are escalating to a regulator is operational failure. Not a clever experience design problem. Not a digital transformation issue. Things not working the way they&#8217;re supposed to.</p><p>There is a number worth thinking about. In many service operations I&#8217;ve worked in, somewhere between 30% and 60% of contact volume is &#8220;failure demand,&#8221; contact that should never have happened because something broke. If that&#8217;s true in yours, then a substantial chunk of your operating cost is being spent cleaning up after preventable failures. That&#8217;s also where the genuine ROI of any improvement programme lives. Not in the headline-grabbing transformation, but in the unsexy work of fixing what&#8217;s already breaking.</p><p>Before you buy anything new, fix what&#8217;s already broken. The data shows you exactly where to look.</p><div><hr></div><h2>Observation three: the price rise that became a service event</h2><p>The mobile complaints spike came from mid-contract price rise announcements in Autumn 2025. Several providers told their existing customers they&#8217;d be paying more, mid-contract. The decision was made by commercial teams, signed off by leadership, and landed in service operations after the fact. The wave of inbound contact, the churn risk, the regulatory scrutiny: all of it was predictable from the moment those comms went out.</p><p>This pattern is everywhere, in every sector, not just telecoms. Pricing changes, product launches, system migrations, billing updates, marketing campaigns. Decisions get made in one part of the business, and the service operation finds out either at the same time as customers or shortly afterwards. By the time the volume hits, the staffing isn&#8217;t there, the advisors haven&#8217;t been briefed, the FAQ on the website is out of date, and the conversation has already turned into a complaint.</p><p>The instinctive response from senior service leaders is usually to get better at firefighting. Build a rapid response capability. Improve forecasting. Hire flex resource. All of that helps at the margins, but it treats the symptom, not the cause. The real fix is structural. Service has to be at the table when those commercial decisions are being made, not informed about them afterwards.</p><p>That sounds like a soft, political point. It isn&#8217;t. It&#8217;s an operating model question. Either the service function has the standing, the relationships and the data to push back on commercial decisions before they go live, or it doesn&#8217;t. If it doesn&#8217;t, you&#8217;ll keep being surprised by the same kind of event quarter after quarter, and the Ofcom data will keep telling the same story.</p><div><hr></div><p>Ofcom data isn&#8217;t really a league table. It&#8217;s a mirror. The thing it shows you most clearly isn&#8217;t where everyone else is. It&#8217;s what&#8217;s possible in your market, because someone in your market is already achieving it. Best in class isn&#8217;t an aspiration, it&#8217;s an existence proof.</p><p>Three questions worth carrying out of any data set like this:</p><ol><li><p>How does our complaint rate compare to the best in our sector, not the average?</p></li><li><p>What share of our contact volume is operational failure that should never have happened?</p></li><li><p>Are we involved when commercial decisions land in our operation, or finding out afterwards?</p></li></ol><p>If the answers are uncomfortable, that&#8217;s the point. Uncomfortable is useful. It tells you where the genuine improvement lives.</p><p>The temptation when reading data like this is to look for reassurance. Most providers are average. Most operations are flawed. The regulator is mainly worried about a few outliers. Resist it. Treat the data as a finger pointing at your own operating model. Then go and see what it&#8217;s actually pointing at.</p><p>Brand promises don&#8217;t close the gap. Operations do.</p>]]></content:encoded></item><item><title><![CDATA[Welcome and why I'm starting again, more deliberately]]></title><description><![CDATA[A short note about why I&#8217;ve changed how I show up and why this is the new home for my writing.]]></description><link>https://www.markjadams.co.uk/p/welcome-and-why-im-starting-again</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/welcome-and-why-im-starting-again</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Tue, 02 Jun 2026 08:00:09 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>A short note about why I&#8217;ve changed how I show up and why this is the new home for my writing.</p><p>I&#8217;ve been writing intermittently for years. Blog posts on the Sooth Consulting website, the occasional LinkedIn article, a guest piece here and there. The intermittent part is the problem. I&#8217;d write a piece, post it, watch it land, and then six weeks would pass before I wrote the next one. That&#8217;s not enough to build any kind of relationship with readers, and it&#8217;s not enough to genuinely sharpen my own thinking either.</p><p>So I&#8217;m starting again, more deliberately. One post a week, give or take. Customer service operations, the strategy and the messy realities, in plain language. No clickbait. No &#8220;10 secrets&#8221; listicles. No AI-generated filler. Just clear thinking from someone who&#8217;s been in the room and sometimes as an in-house director, sometimes as a consultant, increasingly both.</p><p>While I was at it, I simplified everything else.</p><p>The Sooth Consulting website is gone. The Sooth LinkedIn company page is gone. A diagnostic tool I&#8217;d built and that nobody had ever completed is gone. What remains is simpler:</p><ul><li><p>This Substack, where I&#8217;ll write</p></li><li><p>My LinkedIn profile, rewritten to reflect what I actually do</p></li><li><p>A personal domain (markjadams.co.uk) that points here</p></li></ul><p>The legal entity, Sooth Consulting Ltd, still exists, it&#8217;s just the company my work is invoiced through. But the brand people meet, follow, and hire is me.</p><p>The lesson, restated for myself as much as anyone: complication is rarely strategy. It&#8217;s usually accumulation. When you&#8217;re not sure whether something is earning its place, it usually isn&#8217;t.</p><p>A small irony I&#8217;ve been sitting with: I&#8217;ve spent twenty-plus years helping businesses simplify their customer service operations. My own setup was quietly the opposite. The decision to fix it has been overdue for at least a year. If you&#8217;ve ever recognised the same dynamic in your own business; the proliferation of tools, channels, processes, and brand artefacts that nobody quite remembers approving then that&#8217;s the conversation I want to have here.</p><p>The first proper piece is the <strong>5-Pillar Service Operations Health Check -</strong> a self-assessment for founders, COOs, and service leaders to work through honestly in twenty minutes. Free, ungated, and structured around the five things I most often see going wrong. It&#8217;s the natural starting point for what I&#8217;ll write here.</p><p>If you&#8217;d like to follow along, subscribing is free and I&#8217;m not going to spam you. Roughly one post a week. Sometimes a little more, sometimes a little less.</p><p>Onwards.</p>]]></content:encoded></item><item><title><![CDATA[The 5-Pillar Service Operations Health Check]]></title><description><![CDATA[A self-assessment for founders, COOs, and service leaders]]></description><link>https://www.markjadams.co.uk/p/the-5-pillar-service-operations-health</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/the-5-pillar-service-operations-health</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Tue, 02 Jun 2026 07:55:49 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<h3>A self-assessment for founders, COOs, and service leaders</h3><p>Most service operations don&#8217;t fail dramatically. They fail quietly through accumulated drift, postponed decisions, technology that no longer fits, and processes that were designed for a smaller business and never updated. By the time the failure shows up in customer complaints, attrition, or board reports, it&#8217;s usually been visible for months to anyone who knew where to look.</p><p>This is a self-assessment built around five pillars that, in my experience, account for almost every meaningful service operations problem I&#8217;ve seen. There&#8217;s no scoring tool, no email gate, and no booking calendar at the end. Read through it, sit with the questions honestly, and you&#8217;ll know within twenty minutes where your operation is genuinely strong, where it&#8217;s drifting, and where it&#8217;s quietly storing up trouble.</p><p>A simple way to use it: rate yourself on each statement from 1 (strongly disagree) to 5 (strongly agree). The number itself doesn&#8217;t matter but pay attention to the questions you&#8217;d rate 1 or 2. Those are the conversations worth having with your team this quarter.</p><h3>Pillar 1: Design</h3><p><em>How well your service operation has been designed, rather than accumulated.</em></p><p>Most service operations weren&#8217;t designed. They grew. A channel was added because a competitor had one. A self-service tool was bought because someone wanted to cut costs. A process was created to handle a specific problem and never retired. The result, in many businesses, is a tangle of channels and tools that nobody chose deliberately and nobody is willing to take ownership of simplifying.</p><p>Honest answers to these three questions tell you whether you have a designed operation or an accumulated one:</p><ol><li><p><strong>Our service channels are intentional, not just added over time.</strong></p></li><li><p><strong>We&#8217;ve balanced tech and people to create consistent, reliable customer journeys.</strong></p></li><li><p><strong>Our self-service is useful to our people and customers, and not just there to reduce costs.</strong></p></li></ol><p>The tell-tale sign of weak design isn&#8217;t usually customer complaints, it&#8217;s internal confusion. If your team can&#8217;t articulate why each channel exists, why each tool is in the stack, or what your self-service is <em>for</em>, the design has failed. The fix isn&#8217;t more tools. It&#8217;s pulling everything down to first principles and asking, channel by channel, &#8220;would we add this today if we didn&#8217;t already have it?&#8221;</p><h3>Pillar 2: Direction</h3><p><em>Whether your service operation knows where it&#8217;s going and why.</em></p><p>Service teams need direction in the same way any team does, but service direction is often weaker than it looks. There&#8217;s usually a strategy slide somewhere. There&#8217;s usually a set of KPIs. What&#8217;s often missing is the connective tissue, the link between what the business is trying to achieve and what the service team does on a Tuesday morning.</p><ol start="4"><li><p><strong>Our operating model is clearly defined and understood across teams.</strong></p></li><li><p><strong>We have clear priorities, and they&#8217;re reflected in how we work and make decisions.</strong></p></li><li><p><strong>Everyone understands how their role impacts the customer, not just frontline teams.</strong></p></li></ol><p>The third question is the one most businesses fail. Frontline teams almost always understand their impact on customers; it&#8217;s the function of their job. The disconnect tends to be in the supporting functions - marketing, product, billing, technology - whose decisions reach customers indirectly and whose teams often have no feedback loop telling them how those decisions land. If your billing team doesn&#8217;t know what kind of week the service team is having, your direction is fragmented even if your strategy is clear.</p><h3>Pillar 3: Enablement</h3><p><em>How well your team is set up to do good work.</em></p><p>A service team&#8217;s performance is determined by the conditions you create for them. Brilliant people will fail in poorly-designed systems. Average people will perform well in good ones. Most operational performance problems are enablement problems wearing different costumes.</p><ol start="7"><li><p><strong>Our team is supported with training, coaching, and feedback loops that drive performance.</strong></p></li><li><p><strong>Internal knowledge is actively managed so it&#8217;s accurate, accessible, shared, and actually used.</strong></p></li><li><p><strong>We don&#8217;t have bottlenecks, our systems and ways of working are resilient and scalable.</strong></p></li></ol><p>Knowledge management is the question worth lingering on. Almost every business I&#8217;ve worked with thinks their internal knowledge base is &#8220;fine.&#8221; Almost none of them are right. The test is simple: when an advisor needs an answer, where do they actually look? If the answer is &#8220;they ask the person sitting next to them,&#8221; your knowledge base isn&#8217;t doing its job, regardless of what&#8217;s in it. That&#8217;s not a content problem; it&#8217;s a usability problem dressed up as a content one.</p><h3>Pillar 4: Efficiency</h3><p><em>Whether your operation is getting better or just getting busier.</em></p><p>Growth tends to mask efficiency problems. When demand is rising, the workload is rising too, and it&#8217;s hard to tell whether the team is genuinely getting better or just running faster on the same treadmill. The efficiency pillar separates the two.</p><ol start="10"><li><p><strong>We improve processes continuously, not just when something breaks.</strong></p></li><li><p><strong>Change happens fast enough to stay ahead, not just keep up.</strong></p></li><li><p><strong>Our use of automation and AI is saving time and improving both service and team performance.</strong></p></li></ol><p>The third question now matters in ways it didn&#8217;t five years ago. Most businesses I speak to have invested in AI tools: chatbots; agent assistants; summarisation (automated notes); deflection. Most of them are honest enough to admit they&#8217;re not sure whether the investment is paying back. The mistake is usually treating AI as a deflection strategy rather than a performance one. AI used to push customers away from human contact tends to perform worse than AI used to make humans better at their jobs. If your AI strategy is mostly about reducing volume rather than improving quality, the results will eventually disappoint everyone.</p><h3>Pillar 5: Intelligence</h3><p><em>Whether you&#8217;re learning from what&#8217;s actually happening or running on instinct.</em></p><p>The best service operations I&#8217;ve worked with share one trait: they treat every customer interaction as a source of information about the business, not just an event to be resolved. The worst ones treat data as a reporting requirement.</p><ol start="13"><li><p><strong>We know what&#8217;s working and what&#8217;s broken and we have the skills and resources to fix things.</strong></p></li><li><p><strong>We regularly analyse root causes, not just symptoms.</strong></p></li><li><p><strong>We trust our data, and we always use it to inform decisions.</strong></p></li></ol><p>The most common failure mode here isn&#8217;t an absence of data. It&#8217;s an abundance of it that nobody trusts. Dashboards proliferate, definitions drift, the same metric means different things in different reports, and the team eventually stops using any of it because it&#8217;s all slightly wrong. If your weekly service review is a discussion about <em>whether the numbers are right</em> rather than <em>what the numbers tell us</em>, your intelligence pillar is weaker than you think and rebuilding the data foundation is almost always more valuable than buying another reporting tool.</p><h3>What to do with what you&#8217;ve found</h3><p>If you&#8217;ve worked through the fifteen questions honestly, you&#8217;ll have a sense of your strongest pillar and your weakest. The temptation will be to tackle the weakest one first. Resist it.</p><p>The pillar that matters most isn&#8217;t the lowest-scoring one, it&#8217;s the one most directly blocking what your business is trying to do over the next twelve months. A start-up scaling rapidly almost always needs to fix Design before anything else, because accumulated mess gets exponentially harder to untangle as it grows. A mid-market business going through transformation usually needs to fix Direction first, because nothing else holds without it. A business under cost pressure needs to fix Efficiency. A business losing customers it shouldn&#8217;t be losing needs to fix Intelligence.</p><p>The right next move depends on context. But the wrong move is almost always the same one: doing nothing because the picture feels too complicated.</p><p>If any of this felt uncomfortably familiar or if you&#8217;d like to talk through what your answers might mean for your business specifically - I&#8217;m easy to find. <a href="mailto:mark@soothconsulting.xyz">mark@soothconsulting.xyz</a>.</p>]]></content:encoded></item><item><title><![CDATA[Zero customer service]]></title><description><![CDATA[It&#8217;s a bold statement, and a great place to start a debate among service leaders, service teams, and customers alike.]]></description><link>https://www.markjadams.co.uk/p/zero-customer-service</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/zero-customer-service</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Sun, 15 Mar 2026 08:00:00 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>It&#8217;s a bold statement, and a great place to start a debate among service leaders, service teams, and customers alike. It brings out views from all perspectives. Let&#8217;s take a look at the subject, which actually isn&#8217;t a new concept.</p><p>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.</p><p>Today, that mindset is outdated. Yet many organisations still use metrics that have been around forever and leaders aren&#8217;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&#8217;re handed.</p><p>In their 2011 book <em>The Best Service is No Service</em>, 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.</p><p>Today, customers want seamless digital experiences and expect frictionless journeys. They don&#8217;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?</p><p>If only it were that simple. Recent research shows that for all the digital channels that exist, and the belief that &#8220;people don&#8217;t want to speak to people,&#8221; 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.</p><p>So it&#8217;s not really about zero customer service. It&#8217;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&#8217;s a sign that something earlier in the journey hasn&#8217;t worked.</p><p>The idea of zero customer service doesn&#8217;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.</p><p>But there&#8217;s a paradox worth acknowledging here. Service that&#8217;s invisible can also be service that&#8217;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&#8217;t part of their thinking. The very success of designing the operation away has taken away the moments where loyalty would have been built.</p><p>This is why scenario-based service matters. The goal isn&#8217;t to hide service, it&#8217;s to design products and journeys that don&#8217;t <em>need</em> service for the routine, while ensuring that the moments where service <em>does</em> 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&#8217;ll carry into the next switching decision.</p><p>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.</p><p>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.</p><p>If you&#8217;d like to talk through what this might look like in your business, I&#8217;m easy to find. <a href="mailto:mark@soothconsulting.xyz">mark@soothconsulting.xyz</a>.</p>]]></content:encoded></item><item><title><![CDATA[The dynamic operating model]]></title><description><![CDATA[Every business has an operating model, whether it&#8217;s consciously or unconsciously designed and deployed.]]></description><link>https://www.markjadams.co.uk/p/the-dynamic-operating-model</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/the-dynamic-operating-model</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Sat, 15 Nov 2025 08:00:00 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Every business has an operating model, whether it&#8217;s consciously or unconsciously designed and deployed. What&#8217;s your operating model and does it deliver for you and your customers?</p><p>Almost all the work I undertake involves engaging with a client&#8217;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&#8217;s operations and implementing a new OM.</p><p>Over the years I&#8217;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&#8217;s cost effective, builds teamwork (mostly), and focuses people on the things that are most important.</p><p>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.</p><p>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.</p><p>In my career I have definitely seen those pitfalls come to fruition. In a recent McKinsey &amp; Company study on operating models they found that &#8220;only 23% were highly successful&#8221; and &#8220;63% were somewhat successful.&#8221; That&#8217;s not great, particularly when you think about the effort and potential disruption the work may have brought about.</p><p>I believe an OM review and resultant changes can avoid all of those pitfalls if done correctly. It doesn&#8217;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 &#8216;just in time&#8217; basis.</p><p>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&#8217;ve described that, we design the approach to closing it.</p><p>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.</p><p>If any of this resonates and you&#8217;d like to talk it through, I&#8217;m easy to find. <a href="mailto:mark@soothconsulting.xyz">mark@soothconsulting.xyz</a>.</p>]]></content:encoded></item><item><title><![CDATA[Five mistakes I see businesses make when buying contact centre technology]]></title><description><![CDATA[Most contact centre tech projects under-deliver.]]></description><link>https://www.markjadams.co.uk/p/five-mistakes-i-see-businesses-make</link><guid isPermaLink="false">https://www.markjadams.co.uk/p/five-mistakes-i-see-businesses-make</guid><dc:creator><![CDATA[Mark J Adams]]></dc:creator><pubDate>Sat, 15 Jul 2023 07:00:00 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!yDdV!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F22f0e9c1-f331-4169-a05c-4ada9e730a67_512x512.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Most contact centre tech projects under-deliver. The reason is rarely the tech itself.</p><p>I&#8217;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&#8217;t pick. Sometimes as the consultant brought in eighteen months later to work out why the brilliant new platform isn&#8217;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.</p><p>These are the five mistakes I see most often, in roughly the order they happen.</p><h3>1. Buying without living in the current experience first</h3><p>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.</p><p>Five minutes of that is worth an hour of someone in head office telling you what they think is happening.</p><p>The reason this matters for tech decisions is simple: if you don&#8217;t know what&#8217;s actually broken in your current operation, you can&#8217;t know what to buy. You&#8217;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&#8217;t have while leaving the problem you did have firmly in place.</p><h3>2. Not being clear what problem you&#8217;re trying to solve</h3><p>Most tech buying decisions get framed too broadly. &#8220;We need a new contact centre platform.&#8221; &#8220;We need to consolidate our tech stack.&#8221; &#8220;We need to deploy AI.&#8221;</p><p>Those aren&#8217;t problems. They&#8217;re vague aspirations dressed up as briefs.</p><p>A real problem statement looks more like: &#8220;Our advisors are spending 25% of their handle time on after-call work, and our most experienced people are leaving partly because of that.&#8221; Or: &#8220;Our self-service deflects volume but increases complaints when it fails, because customers feel they&#8217;ve been pushed away rather than helped.&#8221; Or: &#8220;We&#8217;re growing 40% year on year and our current platform charges per-seat in a way that means we&#8217;re paying for capacity we don&#8217;t need.&#8221;</p><p>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&#8217;re not buying technology, you&#8217;re buying optimism.</p><p>The test I apply: if you can&#8217;t explain the problem in two sentences to someone outside your business, you&#8217;re not ready to talk to vendors yet.</p><h3>3. Buying for the operation you might be, not the one you are</h3><p>This is the most expensive mistake of the five, and it&#8217;s worth being precise about.</p><p>Buyers will always project some sense of their future operation into the buying decision. That&#8217;s reasonable; nobody wants to replace a platform every eighteen months. The problem isn&#8217;t planning ahead. The problem is buying <em>specific functionality</em> for an imagined future you can&#8217;t actually predict, and locking yourself into it today.</p><p>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.</p><p>The second is over-specifying within whatever you&#8217;ve chosen. Every modern platform comes with functionality you don&#8217;t currently need: workforce management modules, speech analytics, advanced reporting, automation suites, AI capabilities. The vendor&#8217;s commercial pitch is built around the idea that you&#8217;ll grow into it. Sometimes that&#8217;s true. More often, the unused functionality becomes a tax, you&#8217;re paying licence fees for capabilities sitting dormant, while your core use case underperforms because nobody&#8217;s optimising for it.</p><p>The discipline worth applying isn&#8217;t <em>don&#8217;t plan for the future</em>, it&#8217;s <em>buy for flexibility, not for predictions</em>. A platform that&#8217;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&#8217;re getting from over-buying. A platform sold to you on the basis of what you&#8217;ll need in 2029 is selling you a forecast nobody can make accurately, and charging you for it today.</p><p>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&#8217;re buying for &#8220;the future&#8221; with healthy suspicion.</p><h3>4. Underestimating the people change required</h3><p>A new platform isn&#8217;t just a tech project. It&#8217;s a change project that happens to involve technology.</p><p>Every contact centre tech decision I&#8217;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.</p><p>Every contact centre tech decision I&#8217;ve seen disappoint has skimped on at least one of those three. Usually two. Sometimes all three.</p><p>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.</p><p>The test I&#8217;d apply: if your business case doesn&#8217;t include the cost of training, process redesign, and leadership time over the first six to twelve months, your business case is wrong.</p><h3>5. Skipping the pilot &#8212; or running a pilot designed to succeed</h3><p>The most experienced buyers I&#8217;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&#8217;t fail.</p><p>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.</p><p>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&#8217;s a clear definition of what would constitute the pilot succeeding <em>and</em> what would constitute the pilot failing and a credible willingness to walk away if the latter happens.</p><p>The point of the pilot isn&#8217;t to confirm the decision you&#8217;ve already made. It&#8217;s to test it.</p><h3>A final reframe</h3><p>If I had to compress all five into one principle, it would be this: <strong>the technology decision is the easy bit. The hard bits are everything around it.</strong></p><p>Knowing what you&#8217;re buying for. Understanding the operation you&#8217;re buying into. Resisting the seductive promise of capability you don&#8217;t yet need. Resourcing the people change properly. Testing under real conditions before you commit.</p><p>Most contact centre tech projects don&#8217;t fail because the technology was wrong. They fail because the buyer didn&#8217;t do the work that surrounds the technology and no system, however good, compensates for that.</p><p>If you&#8217;re navigating one of these decisions and would like to talk through what you&#8217;re seeing, I&#8217;m easy to find. <a href="mailto:mark@soothconsulting.xyz">mark@soothconsulting.xyz</a>.</p>]]></content:encoded></item></channel></rss>