Overview

SupportBot emerged from a strategic pivot toward AI-first support experiences. As the organization moved faster toward automation and augmentation, it became clear that existing support tooling needed to evolve beyond traditional workflows and static interfaces. SupportBot was designed to help support advocates work more efficiently while maintaining accuracy, empathy, and control.

The challenge was not simply adding AI to support, but designing an experience advocates could trust. Support work is high-stakes, and mistakes are costly. The goal was to build an AI-powered assistant that augmented human judgment, reduced cognitive load, and helped advocates move faster without sacrificing quality or care.

Approach

Early on, product direction leaned toward a simple chatbot-style experience, where advocates could “chat with the copilot” to ask questions and take actions using natural language. While intuitive on the surface, I was concerned this approach would struggle in practice.

My hypothesis was that advocates would be unlikely to adopt a purely conversational interface for two reasons. First, speed is their primary performance metric. Chat-based interactions are often slower than existing shortcuts, macros, and workflows, and advocates are understandably risk-averse when new tools might hurt their targets. Second, many advocates are based in South America and the Philippines, where English is not always a first language. Relying solely on free-form natural language queries would introduce friction and confidence barriers at exactly the moments where advocates need to move quickly and decisively.

This led to a broader framing of the problem. Instead of asking how advocates could talk to AI, I focused on how AI could better support advocates within their existing workflow. Building on prior research and jobs-to-be-done analysis, the approach expanded beyond reactive chat to include proactive patterns that surface what advocates need to know, say, and do, without requiring them to ask.

Solution

SupportBot was designed as an advocate-augmented system that combined reactive and proactive AI assistance. We built a strong conversational foundation for knowledge and context search, allowing advocates to ask questions when needed. But equally important, we layered proactive AI features on top of this foundation, designed to reduce effort rather than introduce new steps.

Ask Copilot

We began by designing a strong conversational foundation through Ask Copilot, a natural language interface for knowledge and context search.

Launched in August, advocates can ask questions in plain language and receive AI-generated answers grounded in real customer context, knowledgebase content and policy data.

Since launch we've been iterating on the copilot, rapidly launching new features:

- Copilot responses were not limited to text. They included modular components that surfaced key objects, such as customers, transactions, and issues, directly within the conversation flow.

- Suggestion pills as lightweight entry points to encourage adoption. These allowed advocates to engage with AI faster than typing a full query, while still retaining the flexibility of natural language when needed.

Know / Say / Do suggestions

To complement conversational search, I am currently exploring how we might introduce proactive AI modules as part of the copilot experience. Instead of waiting for advocates to ask the right question, might supportbot be able to surface high-confidence guidance directly in the workflow?

That's what I'm exploring right now.

My exploration is structured around three advocate needs to Know, what to Say, and what to Do, and providing AI guidance, or AI suggestions - across these 3 areas.

• Know - rather than hunting down the right knowledge article, knowledge snippets surface relevant guidance, policies and context.

• Say - suggested responses can help advocates know what to say next, all while reducing the need for advocates to hand craft every message, or use pre-written macros that sound robotic.

• Do - when confidence is high, suggested actions can help them understand what actions and steps they need to take to get to a resolution.

Proactive vs Reactive AI

Adding suggestions to the colipot requires designing for two distinct modes of interaction. In proactive mode, AI suggests when confidence is high. In reactive mode, advocates lead by asking questions or exploring further.

To demonstrate my idea here, i needed more than a figma prototype. After many different experiences with a variety of AI prototyping tools, I've used cursor to create a prototyping system that allows me to demonstrate and test proactive and reactive modes across different support scenarios.

As of now, I am presenting this work with cross function partners as part of 2026 planning. But my POV is this - Natural language is powerful, but it cannot be the only interaction pattern in a speed-critical environment.

Context, Conversation, Copilot

To support these interaction patterns, we designed a desktop layout organized into three clear columns. The Context column surfaced structured information about the case and customer. The Conversation column unified messaging and voice transcripts into a single, cross-channel view. The Copilot column provided a dedicated space for AI assistance, including suggestions, explanations, and conversational search.

This layout reduced cognitive load by separating concerns while keeping everything visible at once. It also acknowledged the limitations of natural language by giving AI its own space, rather than forcing all interaction through chat. Advocates could stay focused on the conversation, reference context when needed, and engage with AI support without losing their place or slowing down.

We explored whether a copilot could eventually perform all of an advocate’s jobs through conversation alone. Prototypes mapped how AI might support each stage of the support journey, and we audited other copilot initiatives across the business to ensure alignment.