Field Guide
Designing a Support Chatbot
One language. Seventeen products. Fifty support surfaces. A research and service design story about creating the first conversational support framework across an enterprise portfolio.
What We Found
Customers do not judge conversations by speed alone. They judge whether expectations are clear.
“Fast only matters if everyone agrees what fast means.”
Design brief synthesis
The team was building its first support bot across a complex product portfolio. Seventeen products, three or more versions each, and more than fifty support surfaces were in scope. Support lived across email queues, ticket systems, phone support, and human live chat, but there was no automated first response and no shared definition of response time. The opportunity was not simply to automate conversations. It was to establish one response-time language that customers, support teams, designers, engineers, and product leaders could all use.
Why It Matters
Conversation design is expectation design.
A chatbot is not successful because it answers quickly. It is successful because people know what will happen next.
The response taxonomy created four shared tiers: instant, quick, live, and scheduled. Each tier set expectations for timing, ownership, escalation, and measurement.
Instead of every product inventing its own version of “fast,” the portfolio could design from one shared operating model.
The Original Question
How do we create one conversational system for an entire portfolio?
The work began before dialogue design.
We needed to understand the current human baseline, classify support intents, define where automation should help, and clarify when a human handoff was the better experience.
The research focused first on people and systems. The bot came later.
How We Got There
Research before automation.
The work unfolded across four phases: discover, synthesize, validate, and roll out.
We audited human chat and ticket logs, interviewed support leads, clustered intents, mapped them to response tiers, prototyped bot flows, tested the experience, and built a measurement plan for rollout.
Transcript logs. Intent clusters. Response tiers. Conversation flows. One system.
What I Learned
Technology changes quickly. Good conversations do not.
This project reinforced that people rarely remember exact response times. They remember whether a system respected their time, communicated clearly, and knew when to hand them to another human.
The most valuable deliverable was not a chatbot. It was a shared framework that allowed many teams to design conversations consistently while continuing to improve over time.
