CX Operations: Price your Cherries
I spent 11 years at Zendesk, 10 of those in Support Operations roles. I was brought in to make agents’ jobs easier and their lives better. For much of my last few years there, I made the case for a different approach to routing. I don’t think of agents as individuals with personal targets, but as a team solving a set of ever-evolving problems. I had spent two years advocating for an approach centred on a combined effort to solve a business problem: a common goal for teams that recognises it takes different skills and different types of knowledge to solve a shared pool of issues.
There were good reasons to adopt omni-channel routing (OCR). Leadership had performance targets to hit, and as a product company we wanted to use our own features. OCR promised to help with much of what a support organisation faces: productivity, cherry-picking, first reply time, resolution time. Our large enterprise setup wasn’t the typical use case, which made it a good test of the feature.
Cherry picking can be your friend as long as you make sure your cherries are priced properly.
Years earlier I had built a sorting system at Zendesk called Queue Score. The principle was simple: even a minor issue becomes a major annoyance if it sits long enough without acknowledgment. Queue Score weighted tickets dynamically based on a few signals, time since creation being the most important. It surfaced the most timely work to the top of the queue automatically, built entirely on Zendesk’s own platform. It reduced first reply time by 60% within four weeks of going live and ran in production for about a year. When Zendesk moved to messaging-first, Queue Score was retired, since it had been built for a ticket queue rather than live channels. Messaging is the future, and with the AI-first approach and a renewed interest in self-service, the decision made sense. The underlying principle, a team focussing on what is important rather than what is top priority, is one I’ve carried with me since.
When the decision was made to adopt omni-channel routing, a task force was created for rapid feature adoption, and I was brought in as an advisor. The goal of the pilot was fairly straightforward: implement omni-channel routing and measure impact. The new routing engine would bring tickets directly to the agent interface, with no time spent looking for easy tickets. While looking for easy tickets, though, people sometimes noticed patterns in new tickets: a service incident could be identified by a spike in tickets about the same subject. The pilot was scoped to a small number of support agents working on the same type of ticket. The roll-out roadmap was already in place, so the pilot’s job was to learn as much as possible along the way. My focus in Ops was making sure the customer experience held up.
The pilot ran for 8 weeks. Early on there were kinks to work out, with a number of exceptional workflows that didn’t quite fit the mould of our OCR configuration. Some agents worked a specific type of ticket whenever it came in, and some were “just better at those tickets”, so we adapted the routing around these workflows to keep the pilot moving. After 8 weeks, first reply time, total resolution time and customer satisfaction had barely moved. That taught me something: how you route the tickets isn’t the core of the problem; who you route the tickets to is what actually matters. When volume is your core consideration in handling support tickets, you’re already measuring the wrong thing. The gap is about to get worse. This is the first piece in a series about what should come after volume-based performance metrics.
