Design Outcomes Weekly reflections on the real-time work of supporting a design org.
One Chat, and It Grows

One Chat, and It Grows

Why this matters

Every SaaS product now has a support bot and a product assistant. Customers type feature questions into whichever chat they can see.

One Chat, and It Grows I changed my mind twice in one week on how many chats a product should show, the argument for explicit doors even with smart routing, and where we landed. Every SaaS product now has a support bot and a product assistant. Customers type feature questions into whichever chat they can see. When a support bot and a product assistant compete for the same customer, look for the surface that shouldn't be a chat at all. Explicit affordances teach; routing helps; ownership arguments wear UX costumes.

I changed my mind twice in one week on how many chats a product should show, the argument for explicit doors even with smart routing, and where we landed.

Twice this week I changed my mind on the same question, and it’s a question every software product is about to have. When a product has an AI assistant for using the features and a support bot for when something breaks, how many chats does the customer see?

Some context. Like most companies our size, our support team runs a third-party chat behind the ”?” bubble, and it does its job well for tickets. Our product teams have been building an assistant into the product itself: help with features, context from the record you’re in, and eventually skills specific to billing, notes, and scheduling. Both are conversational, both are AI, and clinicians have started typing feature questions into the support bot (“help me fill my calendar”) because it’s the chat they can see. The support bot can’t do that. But it’s where the natural entry point for AI ended up, by default, and an engineering partner called out the risk plainly: if product doesn’t own that first touch, the support vendor’s roadmap starts driving ours.

My position on Monday was one door with smart routing behind it. You type, and the model figures out whether you need a feature or a fix. The engineering case for this is strong, because no matter what someone types, the back end can be wired to be smart about it.

By Wednesday I’d moved to 2 entry points. Routing is great and we should build it anyway, but clinicians have to learn the difference between “help me do this” and “this is broken,” and a single blank box with magic behind it teaches them nothing. So, 2 explicit affordances in one place in the header: the assistant panel, and next to it the help entry that moves up out of the corner bubble. A designer on our billing side sketched the version I liked most, which kept the entire help menu intact and just relocated it, so that “ask a question” routes to the assistant and nothing the support team relies on disappears. It removed nothing, which is usually the sign of a move people will accept.

The second chat was never the problem, because the thing confusing customers was the help menu.

By Thursday I was back to one chat, and the framing that got me there came out of that same designer’s alignment session with the people building it. The second chat was never the problem, because the thing confusing customers was the help menu. One chat for every account, starting with what the support bot does today and gaining skills as the account grows into them. The ”?” moves into the header next to it and stops being a chat: phone support, guides, feedback, the things that were never conversational to begin with. Both of my earlier positions were trying to preserve 2 conversational surfaces because 2 teams owned them. The customer only ever wanted one place to type.

There’s a sequencing principle underneath this that I’d carry into any product. Design the experience you believe in first, then take it to the go-to-market conversation. What I don’t want is packaging decided first and design built backwards from a price list, because the customer will feel that seam every time they open the panel. My recommendation is that the container belongs to every customer and what’s inside it is where tiers can live. Whether that survives contact with the commercial conversation isn’t my call, and it’s the right artifact to walk in with.

Three things I’d take from the week, in the order I learned them. Explicit affordances as well as routing, never instead of it, because customers learn from what they can see. When 2 teams own 2 surfaces, the argument is about ownership wearing a UX costume, and the move is to find the surface that shouldn’t be a chat at all. And write the sequence down: who builds the first version, who hooks in after, and roughly when, so the 4 or 5 groups working the same pattern can stop spinning wheels. One of our product partners put it as creating the safe space for the thing to get built. That’s the job for the next 6 weeks, and it’s mostly a communications job.

Filed under TD The Decision — What we chose, and why.