Good service is not one thing. After nearly two decades leading support and CX operations across SaaS, fintech, and enterprise technology, I’ve stopped trying to define it in a sentence. What I’ve found instead is that the organizations delivering exceptional service consistently have figured out how to make speed, empathy, data, and team design work together — and that when any one of those four breaks down, the whole thing shows it.
This post is about what I’ve learned building those organizations from the inside.
Speed Is Table Stakes — But It’s Not What You Think It Is
When most people talk about fast customer service, they mean low average handle time or quick first responses. Those metrics matter, but they’re the wrong frame. What customers actually experience as “fast” is: did my problem get resolved without me having to come back?
At Q4 Inc., I led a team of 69 developers supporting public company IR websites. Our initial response time was averaging 17 hours in an environment where clients were managing time-sensitive earnings communications. That gap between expectation and delivery eroded trust, even when the eventual work was excellent.
By combining AI automation for triage, skill-based routing, and tighter escalation protocols, we brought response time down to 2 hours — a 92% improvement. CSAT scores followed. The quality of the work hadn’t changed. The customer’s experience of the operation had.
Speed matters most when it’s consistent. A team that resolves 80% of tickets in two hours and the remaining 20% in two days has a service problem, even if the average looks fine. First contact resolution is a better proxy for the customer’s actual experience than handle time, because it measures whether the interaction actually finished the job.
The Gap Between Technical Support and Management
One of the most persistent challenges in CX operations is the gap between managing a support team and leading one. Support agents are measured on throughput — tickets closed, handle time, queue position. Managers need to be thinking about quality, retention, capacity, and team development simultaneously.
Bridging that gap requires making the connection between individual performance and customer outcomes visible to everyone, not just to leadership. At AudienceView, I built employee scorecards that combined quantitative metrics — tickets closed, response times, FCR — with qualitative feedback pulled from customer surveys. The goal was to show agents exactly how their daily work showed up in customer experience data.
The effect wasn’t just performance improvement. It changed how the team thought about their work. When an agent can see that their repeat contact rate is higher than the team average, and can trace that back to a pattern in how they’re closing tickets, the coaching conversation is a very different one. Data doesn’t replace empathy in management — but it makes it much more precise.
Technology as Infrastructure, Not Strategy
Every support leader gets pressure to implement AI, automation, or self-service tooling. Some of it is well-placed pressure; some of it is executives who’ve read the wrong articles. The distinction that matters is whether you’re deploying technology to solve a defined operational problem, or deploying it to look like you’re doing something.
At Q4, we deployed chatbots to handle routine request intake and status updates, freeing developers to focus on work that actually required their expertise. That’s a clear operational case: reduce the volume of low-complexity contacts consuming high-complexity capacity. The result was a 72% improvement in resolution times on the contacts that remained.
At Tyco/Johnson Controls International, the lever was different — a unified knowledge base and self-service platform across a global support function. The logic was the same: customers who can answer their own questions quickly have a better experience than customers who wait for an agent, even a good one. That initiative drove a 40% efficiency improvement and reduced customer time-to-resolution by 20%.
Neither of those was a technology strategy. They were operational strategies that used technology as the execution vehicle. That distinction matters when you’re deciding what to buy, what to build, and what to skip.
ITIL Is Not a Bureaucracy. It’s a Shared Language.
I’ve seen ITIL implemented well and implemented badly. Badly looks like: a change advisory board that blocks everything, incident templates nobody fills out properly, and a problem management process that generates reports nobody reads. That’s what happens when you treat ITIL as a compliance exercise.
Done right, ITIL gives cross-functional teams a shared language for talking about service failures — what’s an incident versus a problem, what triggers a post-mortem, how changes get evaluated for risk. When your company is going through a period of chronic incidents, that shared language is what makes the difference between firefighting and actually fixing the root cause.
The Continual Service Improvement process is the piece I come back to most. The core idea — that improvement is iterative and that everyone on the team can contribute to it — is what separates teams that get better over time from teams that plateau. There’s no single fix for a service problem. There are hundreds of small improvements, and the organizations that understand that are the ones that still look good two years later.
Balancing Business Needs with Customer Expectations
The tension between what the business needs (efficiency, cost control, scalability) and what customers expect (speed, quality, consistency) is permanent. You don’t resolve it — you manage it. And the way you manage it is by making both sides of the equation visible to your team and to leadership.
Support is often positioned as a cost centre, and the pressure that comes with that framing can push teams toward optimizing for the wrong things — lower handle time at the expense of resolution quality, fewer agents at the expense of SLA performance. I’ve written about why that framing is a trap and how to make the case for support as a retention and revenue protection function.
The leaders who navigate this tension well are the ones who can hold both numbers in their head — the cost-per-ticket and the churn rate — and articulate the relationship between them to a CFO. That’s not just a communication skill. It’s how you earn the investment your team needs to do the job properly.
What Good Actually Looks Like
I’ll close with something concrete rather than abstract. The best support operations I’ve seen or built share a set of characteristics that don’t change much across industries or company sizes:
- Clear, documented quality standards — not a vibe, but a rubric that anyone on the team can apply consistently
- Regular calibration on those standards, so quality doesn’t drift agent by agent or team by team
- Escalation paths that work — customers who need to go up the chain can, and the people at the top of that chain are ready to handle it
- Data that connects individual performance to customer outcomes, so everyone understands what their work actually produces
- A culture where raising a problem is treated as a contribution, not a complaint
None of those are complicated. Most of them are hard to sustain under pressure. The ones that hold up are the ones where leadership has made them structural — part of how the team works, not a programme or an initiative that can be quietly deprioritized when things get busy.
That’s the mantra, in practice: build it into the structure, measure it honestly, and keep improving.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
