Enter password to view case study
Customer support queues often route conversations to whichever agent is free, regardless of whether they have the right skills to resolve them.
Our legacy setup sent every conversation into the same queue, with specialist agents only picking up skilled work in narrow windows between general chat. This meant around 60% of conversations couldn't be resolved by the first agent and had to be handed to a specialist, creating delays for customers and making the existing Resolve/Snooze buttons tell us almost nothing about why resolution was failing.
ROLE
COMPANY
Timeline
SKILLS
The problem
All dialogues and conversations enter the same queue, ready for any agent to pick them up.
We had specialist agents in certain business areas who worked individual queues to support customers. However, they were blocked out to work on their specialist skill only at certain times of the day, with the majority of their time spent on chat supporting customers.
More often, we were creating work that sat within a queue until there was a specialist available to pick it up, causing customer delays and frustration.
We had already started to capture how often an agent wasn't able to resolve a customer problem at FPOC — around 60% were being handed from a general chatter to a specialist.
My role
I owned the design of the resolution flow end to end:
Diagnosing the existing resolution flow — understanding why the Resolve/Snooze split wasn't telling us anything useful.
Reframing the problem from a UI fix to a routing problem — designing the skill-based routing logic and the redesigned actions that exposed it to agents.
Defining how we would measure the impact — working with engineering on the routing rules and the data team on the before/after measurement. The existing buttons, under different labels, gave us a genuine baseline rather than just a post-launch trend.
Designing the solution
Reframe the problem
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.
Design the routing logic
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.
Make the system manageable
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 skills-based routing would live.
It enabled us to merge dialogues and task queues into one unified queue and include the LLM tags that route dialogues to agents with those skills.
Managers could also configure SLAs before routing back to the main queue, which was useful when there were limited specialists online, as well as change the weights and priorities of task queues within a specific skill.
Giving specialists visibility
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 and queued tasks awaiting pickup.
The impact
Because the old Resolve/Snooze buttons existed before the relaunch, just under different labels, we had a genuine 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 35% relative lift.
Peak — October 2025: 77.7% resolved without a case, once routing and resolution were both fully live.
Retro
Since October 2025, the rate has drifted down to 69.3%. That's not the design regressing — it's the customer base outgrowing skilled-agent coverage.
Customer growth has outpaced hiring and training on the skill queues.
A larger share of conversations are therefore correctly landing with generalists who don't have the required skill match.
The system is still doing what it was designed to do: routing the conversation to the right available agent, who can then hand the case over to a specialist working that queue.
What I'd do differently
Most dialogues were covered through a pre-existing LLM tagging system, but some dialogues were slipping through the net.
With more time and resources, I would have invested in improving the LLM tagging and classification, so that more conversations could be correctly identified and routed to the appropriate skilled agent from the outset.
Interestingly, when we later introduced automated assistance for customers, these previously difficult-to-tag dialogues became much easier to classify. This increased the number of successful dialogues reaching a skilled agent and showed that improving the upstream tagging could strengthen the routing system without changing the core routing model.