AI Copilot for Customer Support Agents
Self-initiated Product · Enterprise SaaS · AI-assisted workflows
Context
Support agents in large enterprise environments handle hundreds of tickets a day. Each one means reading a long conversation history, searching a knowledge base, and writing a response from scratch. Average handle time sat above 9 minutes per ticket, a number that hits both cost and customer satisfaction directly.
But the real problem wasn't speed. It was that AI was already running in the background at companies like this, quietly analyzing conversations and flagging patterns, while agents had no visibility into it. They didn't know it existed, didn't know when to trust it, and had no way to check its reasoning. Better AI made agents more anxious, not less.
The challenge
Talking to how agents actually work (through workflow mapping and published research on agent tooling) surfaced three consistent pain points:
1. Context overload.
Agents re-read 20 to 40 messages per ticket just to get up to speed, even on handoffs they didn't start. Over 50+ tickets a shift, that adds up fast.
2. Blank-page fatigue
Writing every response from scratch, with no structure to lean on, pushed agents toward inconsistent tone and heavy template use.
3. AI distrust
Agents had seen AI suggestions before and didn't trust them; no confidence indicators, no explanations, no clear way to override. They ignored good suggestions along with bad ones, because there was no way to tell the difference.
That last point became the real design problem: not "can AI write a good response," but "how does an agent know when to trust it."
My Role
Self-initiated concept, designed end to end: research framing, interaction design, and the guardrail system that governs how AI suggestions behave under uncertainty. Built in Figma and Figma Make.
Principles, before any screens
Three rules shaped every decision that followed:
AI suggests, human decides.
Every output is a starting point. The agent has a one-click override and full visibility into the reasoning behind any suggestion.
Show confidence, not just output.
Every suggestion carries a confidence score, so agents calibrate trust from data, not instinct.
3. No hidden automation.
If the agent wouldn't know something happened, it doesn't happen. Fallback states are explicit, never silent.
Agent's workspace
The copilot sits beside the agent's existing tools, not on top of them. It surfaces a conversation summary, key ticket details, and ranked response suggestions, all visible only to the agent before anything reaches the customer. Nothing here is automatic; it's all reference the agent chooses to use or ignore.
Confidence, made visible
Each suggestion carries a confidence score. Early on, a plain number wasn't enough, agents ignored a "62% confident" label because it gave them nothing to act on. Adding a one-line reason changed that: "Low confidence because this issue appears unique, only 3 similar cases in history versus the usual 15+." Agents started using the flag instead of dismissing it.
When the AI isn't sure
This was the hardest screen to get right. Saying "just write it yourself" when confidence drops defeats the purpose of the tool. Instead, low confidence still surfaces what the AI did find, relevant knowledge base articles, sentiment context, and hands the decision to the agent explicitly, rather than failing without saying anything.
Editing, not accepting
Suggestions land in the composer as a draft, not a sent message. The agent edits, adds their own tone, and sends. An "edited by agent" tag keeps a quiet, visible record of what was AI-drafted versus human-refined, useful for the agent, and for anyone reviewing the interaction later.
Why the guardrails mattered more than the suggestions
The interesting design problem here was never "can the AI write a good response." It was what happens the moment the AI isn't sure. Every point where the system could be wrong got an explicit fallback state, never a silent one. One test governed almost every decision in the project: would the agent know this happened? If the answer was no, the design got reworked until it was yes.
That constraint shaped the product more than the AI capability itself did.
Hypothesized impact
This is a concept project, so the numbers are modeled estimates based on comparable AI-assisted support tooling, not measured production results.
20-30% Cut
An estimated 20–30% cut to average handle time, driven by automating context assembly rather than the response itself
15–25% faster
An estimated 15–25% faster response composition, by removing blank-page drafting as the default starting point
Always a human click
Every AI-drafted response requires a human click to send. There's no path for the system to message a customer on its own.
What I'd want to validate first
If this moved from concept to a real build:
How often agents use suggestions unedited
How often the low-confidence fallback gets used versus ignored
Whether the "why" behind a confidence score actually changes trust over time, not just whether handle time drops
Learnings
1. Fallback states build more trust than success states do.
Agents judged the system by how gracefully it handled being wrong, not by how good its best suggestions were.
2. The reasoning is the persuasion.
"Here's a response" got ignored. "Here's why this fits, confidence 78%, based on a resolved similar case" got adopted.
3. Control mattered more than speed.
Agents didn't adopt suggestions because they were fast. They adopted them once they felt in control of the outcome. The one-click override wasn't a nice-to-have, it was the feature the rest of the product depended on.
4. Every shortcut got tested against one question.
Any time I was tempted to remove a click or automate a step to make it faster, I asked whether the agent would still know it happened. If not, it got redesigned.