When people think about designing an AI assistant, they usually think about the technology: which model, which architecture, how the knowledge base is structured.
What they don't think about as much is the conversation itself — how it starts, how it flows, what happens when something goes wrong, and what it feels like to a user who's in the middle of a stressful ticket at 11am.
We spent a disproportionate amount of time on this when building our own support assistant. Here's what we learned.
Start with the user's state, not the assistant's capabilities
The first thing a user sees when they open the assistant should reflect where they are, not what the assistant can do.
We designed the opening state of the assistant to be context-aware: it reads the currently open ticket and orients itself around it, rather than presenting a blank canvas and waiting for instruction.
Instead of "here is a tool, what do you want to do?", the assistant says "here is what I see, here is what might be useful." That shift from tool to collaborator is entirely in the design of the first interaction.
Make the fast paths fast
In a support context, speed matters. An agent handling a high volume of tickets can't afford to spend thirty seconds prompting the assistant every time they need help.
We identified the four or five things our support agents needed most frequently and made these available as one-click options alongside the open conversation field. The agent can go from opening a ticket to having a draft reply in under ten seconds.
The fast paths are where 80% of the value is delivered, and they needed to feel effortless.
Design for the bad moments
An AI assistant in a support context will sometimes be used by someone dealing with a difficult customer or a stressful day. The assistant needs to be calm and clear when the user isn't.
This influenced everything from the visual design (minimal, no visual noise) to the language of the responses (direct and confident) to the error states (when something goes wrong, the assistant acknowledges it clearly and gives a clear next step).
What we'd do differently
If we were building it again, we'd invest more time in the first-run experience. We assumed the interface was intuitive enough not to need explanation. It mostly was — but "mostly" isn't the same as "confident from day one."
A short onboarding flow would have paid for itself in faster adoption. That's now something we build into every client project from the start.