Redesigning a Contact Center That Served Two Million Customers - Iqram Ahmed - UX/UI Expert, Designer, Developer & Team Leader
← All Case Studies
Enterprise SaaS · Desktop

Redesigning a Contact Center That Served Two Million Customers

The agents knew exactly what was wrong. It took two years and a failing system for the business to ask them.

Type Enterprise SaaS · Desktop
Role UX Lead · Frontend Director
Platform Browser-based desktop application
Read 2 min
Project visual

Multiple companies were running their customer service operations on the same contact center platform — a browser-based application that hadn't meaningfully evolved in years. The interface was built around how the software worked, not how agents worked. During peak periods, agents navigated fourteen competing elements on the main screen to complete actions that should have taken seconds. Mistakes went up. Handle time went up. Customer satisfaction went down. What the business hadn't fully accounted for was how much the interface itself had become the bottleneck — and how that was affecting every customer on the other end of every call.

I spent time inside call centers before drawing anything. Watching agents work under live conditions tells you things that interviews don't — the workarounds they've built, the things they've stopped trying to do. After that time, and across two dozen conversations with agents and managers, three problems kept surfacing consistently enough that I stopped treating them as individual complaints. The instinct was to modernize the visual design. The actual problem was information architecture — too much visible at the wrong moments. The redesign began there, not with the UI.

We reduced the primary call screen to four actions — the ones an agent performs in the first ninety seconds of a call. The previous version gave equal weight to fourteen elements. Agents had built muscle memory around the chaos and stopped noticing the inefficiency. Agents who tested the simplified version said the same thing: they felt less anxious during calls.

We added a persistent call history view that managers hadn't requested. Agents needed to know why a customer was calling again, not just that they were. Without that context, every interaction started cold. We argued it was structural, not a nice-to-have. It shipped as a core feature.

We built a team presence indicator showing which agents were available, on a call, or on break. It came from a single interview observation repeated across a dozen sessions: agents were interrupting each other for information they could have found themselves. Minimal development effort, meaningful change in how teams coordinated.

We chose not to redesign the manager reporting dashboard in the first release. It had real problems, but fixing it properly would have delayed the agent-facing work by months. The agents were generating the support tickets hurting the business. We shipped, measured, and used the results to fund phase two.

35%

reduction in support ticket volume in the first quarter after launch

The most direct measure was the drop in support tickets generated by agents about the platform itself — down 35% in the first three months. New hire orientation improved noticeably, which training teams confirmed. The team presence indicator, added outside the original scope, became one of the most-used elements in the interface. The manager reporting dashboard — deliberately left for phase two — shipped six months later with the credibility of phase one behind it.

We validated the design with experienced agents. I'd go back and test earlier with newer hires — the learning curve turned out to be one of the strongest arguments for the redesign, and we had the data to make it. We just weren't looking for it.

Get in touch

If you are working on something
that needs this kind of thinking,
I would like to hear about it.