01 Overview
The call starts before the agent knows anything.
Agents at this internet service provider handle thousands of calls a week. Slow speeds, dropped connections, dead Wi-Fi, choppy video calls. By the time a customer reaches a person, they have usually rebooted the router twice and lost an hour.
To help them, agents had to work across four or five disconnected legacy systems: one for the account, one for installed devices, one for network and outage status, one for billing. Every call began with several minutes of tab-hopping before troubleshooting could start.
I designed a single console that brings customer, device, network and billing context onto one screen, and puts an AI-generated summary of the customer's last seven days at the top of it, so the agent walks into the call already knowing what is probably wrong.
02 Problem statement
Context lived in five places. The customer was in one.
Everything an agent needed to diagnose a connectivity issue existed somewhere in the company. None of it existed together. Agents assembled the picture by hand, on a live call, while a frustrated person waited. The assembly was inconsistent, so two agents could reach two different conclusions about the same fault.
Rather than describe that, it is easier to let you feel it.
03 Try the old way
Open five systems. The customer is waiting.
A customer has just called. Before you can troubleshoot anything, you need five facts, and every one of them lives in a different tool. Click each system to look one up. The clock starts on your first click.
Incoming #4471 / Tier 1, voice
"No internet since Tuesday. I've restarted the box twice."
"No internet since Tuesday. I've restarted the box twice."
00.0Customer on hold
What you still need
That took you 0 seconds. An agent did it on every call.
And that is only the gathering. Diagnosis had not started yet, the customer had heard nothing useful, and any agent who skipped a system risked troubleshooting a router during a known area outage.
Legacy, five systems
0.0s
Unified console
0.8s
5 facts remaining
04 Project goals
What we agreed success looked like.
G1
Cut handle time
Remove system-switching from the call entirely, not just make each system faster.
G2
Speed up diagnosis
Surface device, network and outage data automatically instead of asking agents to hunt for it.
G3
Lower cognitive load
Summarise recent customer activity so agents are not reconstructing a timeline mid-call.
G4
Build a foundation
Ship a component system the support organisation could extend to other agent tools.
05 UX process
Four weeks, run in parallel rather than in sequence.
A one-month timeline meant research and stakeholder alignment could not be separate phases. I ran agent interviews while the PM and I were already pressure-testing scope, so findings could change the roadmap while there was still time for them to matter.
Week 01, Discover
Stakeholder interviews, agent interviews across PST and MST, qualitative analysis, personas.
Week 02, Define
Empathy mapping, journey mapping, information architecture, low-fidelity wireframes.
Week 03, Design
High-fidelity screens, in-progress engineering reviews on component feasibility.
Week 04, Validate
Refinement, edge-case states with QA, developer handoff and build support.
06 Research methodology
Two tracks: the business, and the people on the phones.
Track A, stakeholder interviews
Sessions with the Product Manager and support operations leads.
- What success meant commercially: handle time and first-call resolution
- Which legacy systems were realistically replaceable inside the timeline
- Whether live network and outage data could feed a new interface at all
Track B, agent interviews
Real technical support agents, recruited across PST and MST time zones to catch regional differences in call volume and workflow habits.
- Screen-by-screen walkthroughs of a recent live call
- Where they felt slowed down, unsure, or forced to guess
- What they wished they knew the moment a call connected
07 Qualitative analysis
Four patterns came out of affinity mapping.
F1
System-switching was the single biggest time cost
Agents estimated four to five logins just to get oriented, before troubleshooting began. Everything downstream inherited that delay.
F2
Agents wanted context, not more data
Raw logs and device IDs were not useful mid-call. What agents needed was a fast read on what was likely wrong, so they could start somewhere sensible.
F3
Outage awareness was inconsistent
Some agents checked a separate outage map, others did not check at all. That led to full troubleshooting sessions on faults that were already known network problems.
F4
Confidence dropped under time pressure
Agents described feeling rushed to close calls, which sometimes meant skipping steps like reviewing full device history. The tooling was quietly encouraging shortcuts.
08 Personas
Two agents anchored every decision.
Primary persona
Alex Morgan
The troubleshooting support agent
Alex works the fast-moving front line: looking up customer profiles, checking service status, sending payment links or manual refunds, and escalating to Tier 2 when a case outgrows him. He is analytical and even-tempered under pressure, but the tooling does not move at his pace.
Goals
- Rapidly resolve billing, order and account issues in one pass
- Move fluidly between account overview and order history
- Give the customer a confident answer on the first call
Pain points
- Some modules are hidden or hard to locate mid-call
- No clear confirmation that a save or refund actually went through
- Terminology on screen does not always match what he says out loud
Needs
- On-screen confirmation immediately after actions like save or refund
- Navigation that does not force a detour to find related data
- Labels and terms that match the language used on live calls
Personality
Secondary persona
Nina D'Souza
The system sleuth
Nina is the person who gets pulled in when something feels off. Not customer-facing by default, she validates reports, reads through logs and customer records, and escalates deeper issues to engineering when a pattern emerges.
Goals
- Quickly understand what is wrong with an account or a flow
- Review and append internal notes and previous transactions
- Spot recurring patterns across otherwise disconnected cases
Pain points
- Difficulty piecing together a sequence of actions across systems
- No way to access supporting recordings, some user data missing
- No streamlined way to filter or add structured internal notes
Needs
- Full visibility into account history: orders, notes, contact changes
- A streamlined way to view, filter and add structured internal notes
- Quick links to related accounts, orders and devices
Personality
Supporting persona
Jordan Brooks
The multitasking billing agent
Jordan starts his day early, juggling two or three customer chats while handling billing calls. He is quick and efficient with keyboard shortcuts, and prides himself on resolving issues fast even when the systems around him lag.
Goals
- Send accurate payment information quickly and without errors
- Reduce billing-related frustration and customer churn
- Keep multiple concurrent chats moving without losing context
Pain points
- No easy way to confirm a customer received or clicked a payment link
- Promotions, autopay status and fees are scattered across screens
- Manual and autopay billing are not clearly differentiated on screen
Needs
- A clear way to confirm that payment links and emails were sent
- Easy-to-find breakdowns of promotions, autopay status and fees
- Clear visual differentiation between billing types
Personality
Supporting persona
Daniel Kim
The workflow executor
Daniel processes dozens of customer profiles a day: setting up registrations, changing plans, sending reset links, handling last-minute updates to an order. Speed matters, but accuracy is what he is measured on.
Goals
- Complete customer requests with zero errors
- Save time on repeat tasks without compromising accuracy
- Reassure customers by confirming their changes are complete
Pain points
- Little guidance when a customer's situation does not fit a standard order path
- No ability to clone or duplicate a similar past order
- Manual re-entry for requests that repeat with small variations
Needs
- Immediate confirmation that a password reset or email was sent
- Smart field validation and auto-fill to speed up routine workflows
- A way to preview all entered information before final submission
Personality
Supporting persona
Priya Singh
The customer care coordinator
Priya onboards new customers and manages profile updates end to end: service orders, contact information, password resets and welcome emails, promo and rate changes, all while keeping several open cases straight at once.
Goals
- Complete onboarding and profile updates accurately on the first pass
- Keep context when switching between the console and email
- Make every order form feel predictable, not like a guessing game
Pain points
- Switching between the console and her email client loses context
- Unclear whether every required field is complete before submitting
- Built-in templates do not always match her everyday outreach
Needs
- A live preview of the full order or email before it is sent
- Validation that flags missing or unclear fields before submission
- Quick-action templates and macros that match real day-to-day work
Personality
Alex and Nina anchored the core screens. Interviews with Jordan, Daniel and Priya, who use adjacent parts of the same console for billing, onboarding and account care, confirmed the same root problem: too many systems, not enough context, everywhere in the support organisation.
09 Empathy map
What it actually feels like to take the call.
Says
"I don't have time to check five places before I even start troubleshooting."
"I never know if there's an outage until I've already asked three questions."
Thinks
"There has to be a faster way to see what's going on with this account."
"I hope I'm not missing something sitting in a system I forgot to open."
Does
- Opens multiple systems per call
- Cross-references device and outage data by hand
- Keeps notes outside the system to hold onto context
Feels
- Rushed, and occasionally uncertain
- Responsible for a bad experience the tools created
- Relieved when a call closes, not confident it closed well
10 Journey map, current state
Where the ninety seconds went.
Design opportunity: collapse "identify customer" through "diagnose" into a single screen, with context generated automatically instead of assembled by hand.
11 Design strategy
Three principles I held everything against.
One screen, not five logins
Everything needed to start troubleshooting, account, device, network and billing, visible without switching context. Anything that required a second window had to justify itself.
Summarise before you ask an agent to dig
AI insights give the agent a starting hypothesis. They do not replace judgement, and they never hide the underlying record. Agents can always open the raw history behind the summary.
Make status visible at a glance
Outage state, device health and account flags are scannable in seconds. An agent should never discover a known outage on question four.
12 Information architecture
Five systems, redrawn as four zones.
Agent Console ├── Customer lookup ├── Customer overview <- default landing view │ ├── Account and billing snapshot │ ├── AI Insights 7-day summary, expandable to 90 │ ├── Device panel router and modem status, connection history │ ├── Map view customer and device location, live outage overlay │ └── Chat assistant AI search across account and device records ├── Case notes and history └── Escalation Tier 2 handoff
Consolidating five systems into these four zones was the core architectural decision. Everything an agent needs in the first sixty seconds of a call now lives above the fold on one screen.
13 Wireframes and high-fidelity design
From layout priority to the finished console.
Low-fidelity wireframes tested one question above all: tabs, or a single scrollable panel? Agents rejected tabs in review. They said tabs recreated the same switching problem the project was meant to remove. The scrollable overview won, with the map and outage overlay one click away rather than buried.
A note on these screens
Any on-screen branding has been blurred throughout this gallery. Click a screen to view it larger.
Customer lookup
An agent starts a call by looking a customer up with an account ID, name, unique identifier or phone number. A single customer can hold more than one account.
Customer overview
Once an agent is inside an account, everything sits on one screen: account status, recent activity and the AI-generated summary that used to take four extra logins to assemble.
Map and outage view
Customer and device locations plotted against live network status, so an agent can rule a known outage in or out before troubleshooting the router.
AI insights
Every action tied to a customer, timestamped, feeds the AI summary. This is what lets the assistant surface a hypothesis before the agent asks a single question.
Trouble tickets and dispatch
When an issue sits at the customer's device and needs a hands-on fix, the agent opens a trouble ticket directly from the account and the system assigns a technician.
Billing
Payment status, autopay and plan details in the same shell as everything else, so a billing question mid-call never means switching tools.
Device management
Installed hardware, connection health and which physical ports a customer's equipment is tied to, plus remote reboot and restart, and temporary device swaps for a faulty unit ahead of a technician visit.
Dashboard
A roll-up of the customer's products, active trouble tickets and accounts, the landing view for a returning case.
Chat assistant
Plain-language search across customer, device and account records, for the moments an agent knows what they need but not which panel it lives in.
14 Design decisions and engineering trade-offs
What I chose, and what I gave up to ship in four weeks.
- AI Insights defaults to 7 days
- Most calls only need recent context. Ninety days is available for escalations and repeat-issue investigations, but making it the default would have buried the signal under noise.
- The chat assistant sits beside the UI, not on top of it
- Rather than forcing agents to learn a new navigation model, the assistant was scoped as a fast lookup layer alongside the structured interface, for agents like Nina who jump between related records constantly.
- A map, not a table, for outages
- Agents think spatially about outages: "is this neighbourhood affected?" A map made the relationship between customer location and outage radius immediate, instead of asking agents to translate from a list.
- React over Angular
- Decided with engineering on team familiarity and component reuse across other internal tools. Not a design call, but it shaped how modular the component library needed to be.
- Near-real-time, not real-time, outage data
- True live network status was not feasible in the timeline, so I settled on a short refresh interval instead. I raised the trade-off with research participants to confirm it would not undermine trust in the tool.
- Summarisation, not diagnosis
- The AI widget summarises activity, it does not propose a root cause. That was an engineering feasibility call for this release, and it is the clearest opportunity for a second phase.
Collaboration: I worked with the PM through research and low-fidelity work to prioritise against the timeline, ran design reviews with engineers before high-fidelity was locked, and brought QA in during the final week to catch edge cases: no devices on file, outage feed unavailable, AI summary still loading. Early enough to design for them rather than patch them afterwards.
15 Final solution
The same five facts. One screen.
This is the shape of the console, rebuilt here as a working sketch. Everything an agent had to hunt for a moment ago now sits on one screen, including the time filter on AI Insights and the chat assistant.
Customer #4471
Fiber 500/500 · installed 14 Mar 2023
Account active
Paid in full
Area outage open
Devices2 on file
Router GX-820
Uptime 41h · firmware current
Modem, optical terminal
Signal degraded since 08:12
Downstream throughput, 24h
Chat assistantBeta
Ask me about this account, its devices, or recent network events.
Location and live outage overlay
Customer premises
Active outage, 412 accounts
01
AI Insights
Summarises the customer's activity across the last seven days: disconnects, speed drops, device restarts. The agent opens the call with a hypothesis instead of a blank screen. Filterable up to ninety days.
Default 7d, expandable 90d02
Chat assistant
An AI assistant for plain-language search across customer, device and account records. Built for the moments when an agent knows what they are looking for but not which panel it lives in.
Natural-language lookup03
Unified customer view
Account, billing, network and device information on a single screen. The four or five logins that used to open a call are gone.
5 systems to 1 screen04
Map and outage view
Customer and device locations plotted against live outage alerts, so an agent can rule a network fault in or out before troubleshooting the router.
Location and live alertsThis interactive sketch is a simplified rebuild for the case study. The actual production screens are in the high-fidelity gallery further up this page.
16 Agent feedback
Taking it back to the people who'd actually use it.
Once the console was in a usable state, I got on calls with real support agents, not a survey, an actual walkthrough, to see how the design held up against the way they really work.
The goal wasn't to confirm what I already believed. It was to find out where the design was still wrong, and it did.
Challenge
Every agent saw the console through their own domain
Agents aren't generalists. Some are assigned to billing, some to device support, some to account management, and each group had a different opinion about what the "important" part of the screen was. Getting everyone aligned on a single layout, rather than the layout that only served the person in the room, was the hardest part of this round.
Challenge
Billing agents pushed back the hardest
Billing agents specifically didn't want device or account information on their screen at all. Their first reaction was that it was clutter, extra sections that had nothing to do with their job. It took walking through actual calls with them to change that view.
What changed the argument
The reframe was simple once it was visible: a billing agent who could see a device status flag didn't need to transfer the customer to device support just to answer "is my router the problem?" What looked like clutter in a screenshot was, on a live call, the difference between resolving something in one conversation and bouncing the customer to another queue. That's the argument that got buy-in, not a design walkthrough, a side-by-side of a call handled with the old transfer-heavy flow against one where the agent had everything already in view.