Enter password to view case study
CASE STUDY
How i designed resolution system to increase one-touch resolution, providing more efficient customer experience through skilled-based routing.
THE PROBLEM
All dialogues and conversations enter the same queue - ready for any agent to pick them up.
We have specialist agents in certain business areas who work individual queues to support our customers - but they are blocked out to work on their specialist skill certain times of the day, with the majority of there time being on chat to support our customers.
More often, we are creating work that sits within a queue until there is a specialist available to pick it up, causing customer delays and frustrations.
We had already started to capture how often an agent isn't able to resolve a customer problem at FPOC, which was around 60% being handed from a general chatter to an specialist
MY ROLE
I owned the design of the resolution flow end to end: diagnosing why the existing Resolve/Snooze split wasn't telling us anything useful, proposing the reframe from a UI fix to a routing problem, and designing both the skill-based routing logic and the redesigned actions that expose it to agents. I worked closely with engineering to define the routing rules and with the data team to build the before/after measurement, since the old buttons already existed under different labels and gave us a genuine baseline rather than just a post-launch trend.
DESIGNING THE SOLUTION
One-touch resolution isn't a UI problem, it's a matching problem. An agent can only resolve in one touch if they're the right agent for the job. So the fix couldn't just be a better button; it had to be paired with skill-based routing that got the right person into the conversation before the resolution moment even arrived.
The redesigned actions, Resolve: One touch and Snooze: Connect to case, are the front-end expression of that back-end match. One touch became a legitimate, confident action once routing was doing its job upstream, and “Connect to case” replaced the vague Snooze with a deliberate, structured handoff for when the skill gap was real.
Early on, one option was to let agents opt into skilled dialogues manually: toggle themselves "online" for dialogue routing while still working through their task queue. We moved away from that. Giving agents that switch put the coverage decision in their hands, which reintroduced the same ambiguity the redesign was meant to remove. Instead, routing was built to prioritise on the system side: skilled dialogues go to the right agent in queue first, and only once that's satisfied does the agent's remaining capacity get filled with active tasks. The agent never has to decide whether they're "available" for a skilled conversation. If they're the right match and free, it's already routed to them.
After discovering the scope, we needed to introduce an interface that could be easily managed and maintained by managers. I designed a complete Agent Profile system where our skilled based routing would live. It enabled us to merge dialogues and task queues into one unified queue and include the LLM tags that route the dialogues to those that have those skills. You can enable SLA's before routing back to the main queue - which is handy if there are limited specialists online, plus change weights or priorities of task queues within the specific skill.
To make sure our CX team specialists had complete visibility of their queues, I designed a solution that showed a complete breakdown of customers waiting or queued tasks awaiting ot be picked up.
THE IMPACT
Because the old Resolve/Snooze buttons existed before the relaunch, just unlabeled as such, this gives a real pre/post baseline rather than only a post-launch trend.
Baseline (6 months pre-launch): 54.6% resolved without a case
Post-launch average (14 months): 74.0% resolved without a case, a lift of 35%
Peak: 77.7% in October 2025, once routing and resolution were both fully live
RETRO
Since October, the rate has drifted down to 69.3%. That's not the design regressing, it's the customer base outgrowing skilled-agent coverage: growth has outpaced hiring and training on the skill queues, so a larger share of conversations are correctly landing with generalists who don't have the match. The system is doing exactly what it should, routing them to a agent who can hand-over the case to a specialist who works that queue.
WHAT I’D DO DIFFERENTLY
Whilst most dialogues were covered via a pre-existing LLM tagging system, there were some dialogues that were slipping through the net. If we had more resources
and time we could have improved the LLM tagging so that it enables stronger routing for customers, that said when we implemented a new feature to have automated assistance with our customers, these dialogues were much easier to tag and has since increased the number of successful dialogues reaching a skilled agent.