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 most of the last few years there, I was pushing back against the company's adoption of omni-channel 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.
The pressure to adopt OCR came from both directions. Leadership wanted performance targets hit; product wanted us to adopt our own features. Omni-channel routing was framed as the solution to everything a support organisation might be facing: productivity, cherry-picking, first reply time, resolution time. The large enterprise use case wasn't considered a strong match, but we were still good candidates according to the product team.
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 migrated to messaging-first, Queue Score was retired. It was deemed unfit for what was considered an environment geared towards live channels. Messaging is the future, with the AI first approach and a renewed interest in self-service the decision made sense. The underlying principle of a team focussing on what is important rather than top priority, never got revisited.
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, no time to waste looking for easy tickets. While looking for easy tickets though sometimes people did notice patterns in new tickets, a service incident could be identified by a spike in tickets about the same subject. The eventual pilot was scaled down to a small number of support agents working on the same type of ticket. The roadmap for OCR roll-out was already set. In a product-led company, the push for feature adoption often carries a momentum that is hard to pivot. The goal was rapid adoption; our goal in Ops was the integrity of the customer experience.
The pilot ran for 8 weeks. Initially there was quite a lot of confusion and some kinks to work out for a lot of exceptional workflows that didn't quite fit the mould created by our OCR configuration. Some agents worked a specific type of ticket whenever it came in, some agents were "just better at those tickets" and so Omni-channel routing was built around these workflows to ensure we did not halt progress on the pilot. After 8 weeks the analysis of first reply time, total resolution time, and customer satisfaction barely moved. It turns out that how you route the tickets isn't the core of the problem, it's who you route the tickets to that actually matters. When volume is your core consideration when thinking about 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.
