Case Study · Zoom
Building proactive monitoring and AI escalation for Zoom Contact Center
Designed proactive monitoring and AI-driven escalation for Zoom Contact Center to help supervisors catch the right engagements sooner as the contact center scaled.
Product
Zoom Contact Center
My Role
Solo UX designer
Team
PM, Engineers
Timeline
6 months, 2025–2026
Platforms
Web
Overview
Zoom Contact Center (ZCC) is a customer service platform where agents handle customer interactions and supervisors oversee service quality through live coaching and monitoring.
I'd been working on the monitor feature domain across several iterations, extending monitoring to virtual agents, then rebuilding the permission architecture from hard-coded rules into a role-based configurable system. This project was the next layer of that work, with the goal of enabling supervisors to act on the right engagements earlier, reducing time to intervention as the contact center grew in scale and complexity. I led the design end-to-end, from research and problem framing through to implementation.
Outcomes
This work completed the supervisor monitoring experience, advanced the platform's AI capabilities. Expanded supervisor tooling in a way that aligned better with enterprise monitoring needs.
38 %
15 %
Findability
Usage and volume
Problem Framing
Finding the core scenario
I drove interviews with contacts at three large enterprise customers and collected feedback from internal account managers, then mapped the core supervision scenarios.
2 scenarios stood out as clear gaps:
Human agents
No proactive monitoring path
Supervisors had no structured way to follow a specific agent over time. When coaching new hires, they were scanning the full list manually and missing critical moments. One supervisor described using a separate platform just to join a new agent's call.
Virtual agents
Volume without signal
After VA monitor launch, virtual agent volume significantly exceeded human. The only filter was sentiment. One dimension, slow, and not enough to surface conversations that genuinely needed intervention.
How the industry handles it
I analysed how 3 major platforms handle high-priority work in high-volume queues, looking at both flow and information architecture.
At the flow level, I mapped how each platform triggers and handles priority work to synthesise a proactive monitoring flow, then identified gaps and opportunities to improve it.
At the IA level, the pattern was consistent: mature products give priority work a dedicated surface rather than a better filter. Escalations and monitored engagements needed their own entry points. For VA escalation specifically, no platform had a real answer.
Design Decisions
01. A layered escalation model for virtual agents
Constraint
Running all VA engagements through an LLM was the obvious starting point. At VA volumes, the token cost wasn't commercially viable.
Solution
I designed a three-layer model to pre-classify engagements before any AI involvement. Only ambiguous cases reach LLM review. Around 60% are resolved before that point. Parts of contributing factors are configurable with inline guidance, so admins can choose to tune the model to their business context.
02. Reducing cognitive load by restructuring IA
Problem
The page mixed escalation and operational tasks in one view, making each harder to focus on. With no filter priority distinction either, the table was left with under 50% of the screen, even less on smaller displays.
VA volume had grown significantly, but filtering VA out required enabling a collapsed status filter. The option was semantically hidden, and most supervisors never found it.
Design iterations
To reduce cognitive load and improve accessibility across both tasks, I split the view into two task-based tabs. Filters were reorganised by frequency — high-frequency ones surfaced as inline chips with clearer labels, low-frequency ones moved to a drawer.
Supervisors described finding what they needed immediately, with less scanning required to get there.
03. From permission complexity to a lighter, maintainable setup
Initial concept
My first direction was a dedicated monitored-agent list with configurable entry points. After validation, two problems emerged: the setup felt heavier than the task warranted, and pre-configuring entry points based on current permissions was fragile
Design iterations
To simplify setup and avoid duplicating existing list management, I moved setup into the existing Teams list and reframed it as a lightweight, in-context action instead of a separate flow.
I removed entry-point configuration from setup. Instead, I showed a permission-aware summary of available actions and left the actual choice to the moment an engagement starts, reducing setup complexity and keeping the workflow resilient when permissions changed.
04. A notification framework built around how supervisors actually work
Decisions
By analyzing urgency and importance of events, I treated the notification as a persistent top-right toast to keep the alert visible and actionable without being intrusive.
Consolidated multiple engagements into one path to the list, where supervisors could compare and decide what to monitor next.
I moved conflict handling into a follow-up confirmation step rather than deciding in the toast, which kept the pattern consistent and reduced hesitation.
Both proactive monitoring and escalation use the same pattern, with distinct icons and content.
Reflections
Lessons
AI works best at the edges of what rules cannot decide
Token cost forces you to be precise about where AI earns its place. That constraint turned out to be useful. It pushed me to draw a clearer boundary between what rules should own and what genuinely needs judgment, and made the design more honest about what AI is actually for.
What I would do differently
Making escalation configuration feel real
Admins can tune the model but can't feel what their changes do. I'd increase visibility in future release.
More efficient proactive monitoring
I'd add scenario-based recommendations like new hires and low-performers, and priority tiers so supervisors always know which engagement to focus on first.
Trade-off
The cost of designing for flexibility
Granular permissions were built for flexibility, but made it harder to define consistent behaviour for this workflow. That pushed me to think beyond the immediate problem: whether a design stays manageable as the system around it changes.