We took initial customer response time at Q4 from 17 hours to 2 hours, and we did it with a sequence, not a single fix. Resourcing, AI automation, process improvement and training each did part of the work, and none of them would have been enough on its own. This is what the three years looked like end to end, and what I’d tell the next person to take the job.
I started as Director, Client Support at Q4 in December 2020, leading 69 front-end technical support developers across Tiers 1 to 3 in North America, Europe and Latin America, including Mexico and Brazil. I left in June 2023. In between, initial response time went from 17 hours to 2. Time to first response improved by 92% and time to resolution by 72%, through skill-based routing, omnichannel case distribution and automatic prioritisation and categorisation, and the team got structure, training, scorecards and customer feedback it hadn’t had before. I’ve written the sequence up piece by piece, and here is the whole picture.
What did the plan look like when it was finished?
It began in a hard place. After searching for a job when live entertainment had stopped, I arrived at a company whose customers worked to the calendar of public-company earnings, and I spent my first weeks learning what that meant. The first big realisation was that quarterly spikes are a calendar, which made them plannable. I turned that into a three-to-five-year plan with six pillars in an order that mattered.
Structure and location came first: clear levels of support and a nearshore team in Mexico working to the same standards as everyone else. Next came channels and routing, so that a request reached the right person through whichever channel the customer chose. Then AI triage, which went live on February 3, 2022 and saved $200K in the first year. Alongside those, a Voice of Customer programme built on CSAT and NPS, and dedicated training and QA teams with employee scorecards.
Which changes mattered most?
The numbers moved because of a chain, and the order is the whole story. Defining the levels and the skills made routing by skill possible. Cleaning up the categories made automation possible, and also fixed reporting and VOC, because they all draw on the same data. Training and QA made sure the people at the end of the routing were good at the work. Scorecards showed each person where they stood. And automation removed the manual sorting that had put a delay at the front of every request.
If I had to pick two, I’d choose the data cleanup and the structure. Neither is exciting and neither makes a conference talk. But each one made the next change cheaper and more reliable, and the changes that looked like the big wins, such as the AI model, only worked because those two were done first. The case study says it plainly: the model took weeks, and the data cleanup that made it possible took months.
The other change I’d name is cultural. A team with a visible path, certification levels like the ones I built earlier, and honest feedback treats the work differently. Conversations shift from “what are you going to do about my ticket?” to “what do I need for the next level?” That change isn’t on any dashboard, but it’s the one customers notice first.
What would I do differently?
Start the data work earlier, and start the retraining of the AI models sooner. The case study records that we had a large volume of correct predictions to learn from in year one, and a structured retraining schedule from about month three would have lifted accuracy faster. Treat any model as something you maintain, not something you launch.
I’d also give more attention to the human side of automation from the beginning. The classification work of six people’s worth of effort went to software, and redeploying that capacity took more leadership time than the technology. Plan the destination for those people before the launch date, not after, as I described in the AI triage post.
And I’d keep the customer’s voice closer to the centre earlier. The Voice of Customer programme, with its CSAT and NPS measures and its tagging discipline, was the part of the plan that gave the others their direction. Where we had it, we made better decisions. Where we didn’t yet, we were guessing.
What would I tell the next person in the role?
Four things. Learn the customer’s calendar before you change anything, because in a business like this the calendar explains most of the behaviour you’ll see. Do the foundations in order, and resist the exciting item first. Make the structure visible to the team, so they can see where they’re going. And measure the thing the customer feels, which for us was how long it took to hear back, and keep it at the top of the page.
Be honest about what takes time. A three-to-five-year plan is long on purpose. Some of what I’ve described took most of a year to bed in, and several pieces were still improving as I left. If someone tells you a support operation can be rebuilt in a quarter, ask what they plan to skip.
Look after the people in the middle of it. Distributed teams, a nearshore location, a new tool and a new structure are a lot to absorb. The ones who did best were the ones who understood why each change was happening and had a say in how it worked. I tried to explain the reasoning every time, and I’d do that earlier and more often.
How does it connect to what came before?
Almost every piece had a predecessor. The tiered levels came from AudienceView, and the scorecard from Tyco. The VOC tagging came from the same discipline I used there, and the insource-versus-outsource thinking behind the nearshore decision came from the cost model I’d built at Tyco. The follow-the-sun idea, from the global operations work, shaped how I thought about covering a customer’s day. None of it was invented from scratch. It was carried, adapted and checked against a new industry.
That’s the part of the career I’d most want a younger version of myself to hear. You don’t build a support operation once. You build the same few ideas, structure, training, measurement and honest communication, again in each place, a little better each time. The industry changes. The ideas travel.
How did the customers feel about it?
The best evidence was in the conversations. Customers who used to ask whether anyone had seen their request began to talk about the work itself. Escalations about waiting became rarer, and the ones that remained tended to be about genuinely hard problems, which is where a senior person’s time belongs. I’d be wary of claiming more than that. The data says response and resolution times improved. What customers felt is harder to measure, and the CSAT and NPS programme was how we tried to hear it.
It’s also worth noticing what didn’t change. The calendar of public-company earnings didn’t move, and peaks stayed peaks. What changed was how the team met them. A team that knows its levels, has a clean queue and trusts its tools handles a rush with far less drama than one that’s improvising. The peaks weren’t smaller. We were readier.
What happens to a plan when you leave?
It survives if it’s written down, shared and built into how people work. I tried to make each piece independent of me: the level definitions are documented, the training is owned by a team, the scorecards run on a schedule and the routing rules live in the system. A plan that depends on its author stops when the author leaves. One that’s part of the operation carries on, and the next director can improve it instead of reinventing it.
Handing over is a kind of leadership too. Introduce the people who know where everything is, explain the reasoning behind decisions and be honest about what’s unfinished. I’d rather leave a list of open problems than an impression that everything is solved. The next person will find them anyway, and it’s kinder to say so up front.
When I think about those three years, I think about the team. Sixty-nine people, in different countries, working on a hard technical job under deadlines that don’t move. They did the work. The structure, the tools and the plan were there to let them do it well, and they did.
Seventeen hours to two wasn’t one big idea. It was the same small ones, done in the right order and kept up for three years.
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.
