AI chatbot UX design: best practices for B2B products

In a B2B product, chatbot UX depends less on personality than on what the assistant may know, say and do. In our judgement, five practices carry most of the weight: answer from the customer's own data within the asking user's permissions, show sources a person can open, say plainly when it does not know, hand over to a person with the conversation attached, and act only within the user's permission. Tone, quick replies and a friendly greeting matter, but they cannot rescue an assistant that fails one of the five.

The difference from consumer chatbot advice is who relies on the answer. In workflow software, an answer becomes a decision, a record or a reply to someone else's customer. Accountability does not move to the software either: in Moffatt v. Air Canada, British Columbia's Civil Resolution Tribunal rejected the airline's position that it could not be held liable for information from its chatbot ("It makes no difference whether the information comes from a static page or a chatbot"), and found the airline liable for negligent misrepresentation. That was a small-claims consumer decision in one Canadian province, not a binding precedent, but our judgement is that it is the right assumption to design for: what your assistant tells a user is your product's statement.

The five practices at a glance

The sections below take each practice in turn, then the conversation details that still matter, then a test set for the cases that break B2B assistants.

First, decide whether it should be a chat window

A chat window is the right surface when people have open questions across a body of content and cannot know in advance where the answer lives: policies, documentation, account history, past tickets. It is the wrong surface when the task is short, stable and has a known sequence, because a form, a filter or a button is quicker to use and easier to check. It is also awkward when the answer belongs inside a specific record; there, the assistance should appear in the record, not in a side panel the user has to copy from.

A useful decision rule: if you can write down the steps of the task, design the steps and add AI where a step is hard. If you cannot, because the questions vary too much, a conversational surface earns its place.

The two can share an entry point without being merged. In the Tcules redesign of Eden AI's workflow builder, one search field served template search by default, Tab switched it into AI assistance, and a search with no results became an AI prompt. Search and AI assistance stayed two distinct modes of one field rather than being merged into one.

Whichever surface you choose, the first two of Microsoft Research's Guidelines for Human-AI Interaction (Amershi and colleagues, CHI 2019) apply at once: make clear what the system can do, and how well it can do it. In a chatbot, that means the starting state names what the assistant can answer about and what it cannot reach, rather than offering an empty box and a cursor.

Answer from the customer's data, within the asker's permissions

A B2B assistant is useful because it can read the customer's own material. That same reach is its main risk. Two people at one company should get different answers to the same question if they have access to different records.

Shipped products set the bar here. Microsoft's Copilot data, privacy and security documentation says Copilot surfaces only organisational data that the individual user has at least view permission for, and that grounding honours the user's identity-based access boundary. Slack's security page for its AI features says they use only data members have access to at the time of the request.

What this means for the interface:

• Say what was searched. "Searched: help centre, your team's projects, tickets from the last 12 months" tells the user whether a missing answer means "not there" or "not looked for".
• Keep the no-access answer quiet about what exists. Our judgement: "I couldn't find anything you have access to on that" is safer than "there is a document, but you can't open it", because a title alone can disclose something.
• Give administrators control of sources. An assistant can surface content that was over-shared before it arrived. Microsoft's documentation tells customers to use the permission models in their services so the right people have the right access; the product should let an administrator choose which sources the assistant may read.
• Check permissions when the answer is read, not only when it was written. Slack's "at the time of request" wording points at the risk: a saved or shared conversation can outlive a permission change. Re-check access before showing old answers or the sources behind them.

Customer data brings a second risk: instructions hidden inside it. OWASP's LLM01:2025 Prompt Injection describes indirect injection, where a model takes in instructions from external content such as files or websites. A support assistant that reads customer-uploaded documents is exposed by design, so treat retrieved text as material to quote, never as instructions to follow, and include a planted document in your test set.

Show sources a person can open and check

Citations let the user check the answer without leaving the work. Good citation design has four parts:

1. Cite at the claim, not at the end. A list of five links under a long answer does not tell anyone which sentence came from where.
2. Open the exact passage or record. A link to a 40-page policy is barely better than no link. Slack's citations point to the source message that informed the answer.
3. Show what the reader needs to judge the source: its title, owner or space, and when it was last updated. In workflow software, an out-of-date document can produce a confident wrong answer.
4. Separate "from your data" from "general knowledge". If the model adds anything not found in the customer's sources, label it.

A citation is not proof that the sentence beside it is supported. Liu, Zhang and Liang's audit of four generative search engines, Evaluating Verifiability in Generative Search Engines (Findings of EMNLP 2023), found that on average only 51.5% of generated sentences were fully supported by their citations, and only 74.5% of citations supported the sentence they were attached to. Those were public web search engines in 2023, not a B2B assistant working from a curated knowledge base, so the figures will not transfer directly. The lesson does: check on a sample of real questions whether each citation supports its claim, rather than counting answers that carry one.

Keep the citations with the answer afterwards. Microsoft records the citations used to ground each Copilot response in the user's activity history; for a B2B product, that history is what lets someone later work out why the assistant said what it said.

Say what it does not know, and what to do next

A B2B assistant meets three different kinds of not knowing, and each needs its own message:

How the doubt is worded matters. In a pre-registered experiment with 404 participants, Kim and colleagues (FAccT 2024) found that first-person uncertainty phrases such as "I'm not sure, but..." reduced how often people agreed with the system and improved their accuracy, which an exploratory analysis suggests came from reduced, though not eliminated, over-reliance on wrong answers. Uncertainty expressed from a general perspective, such as "It's not clear, but..." showed similar but weaker effects that were not statistically significant. The study used medical questions and a fictional search engine, so it is evidence about the mechanism, not about your product; the authors' own conclusion is that the exact wording matters and should be tested with users.

Two judgements of our own. We would not put a confidence percentage beside every answer: a figure such as "72%" gives a person nothing to do, and the number may not be calibrated. And a no-answer message that ends the conversation is a dead end; every version above should offer a next step.

Hand over to a person, with the conversation attached

Handover is where a chatbot can fail a person who did everything right. Design four things.

When it happens. Intercom's documentation for Fin's escalation guidance and rules lists default triggers: the customer clearly asks for a human, Fin detects strong frustration or anger, or the customer is stuck in a repetitive loop; teams can add their own rules on top. Add triggers from your domain as well. In B2B products, good candidates are topics where a wrong answer is costly: billing disputes, contract terms, security questions and changes to account access.

What the user is told. Who or which team is taking over, through which channel (here in the chat, by email, by a ticket), and roughly what to expect. Label who is speaking once a person joins, so nobody mistakes the assistant for a colleague or a colleague for the assistant. Article 50 of the EU AI Act requires providers to design AI systems that interact directly with people so that those people are told they are dealing with an AI system, unless that is obvious from the context; the obligation has applied since 2 August 2026, and the 2026 Digital Omnibus amendments did not postpone it (AI Act Service Desk timeline).

What the person receives. The whole conversation, the sources the assistant used and the account context, so the customer does not repeat themselves. Zendesk's documentation on AI agent tickets describes this: on escalation the conversation history is backfilled into the ticket, including the opening messages.

What happens when nobody is available. Both vendors document this state. Intercom notes that escalation offers are skipped when no human routing is configured, and Zendesk reports an "escalation failed" status for conversations with an unsuccessful escalation attempt. Design the honest version: say that nobody is online, offer the asynchronous route, and confirm what will happen to the request. Then measure failed handovers alongside answered questions; a high deflection rate can hide people who wanted a person and could not reach one.

Act only within the user's permission

Once a chatbot can update a record, send a message or change a setting, it has stopped being only a conversation. The rule for the conversation is simple: the assistant can only do what the asking user could do themselves, and the user sees the action, the affected records and the result.

The enforcement has to sit outside the model. OWASP's guidance on LLM06:2025 Excessive Agency recommends minimising the permissions of the tools the model can call, executing them in the user's own context, requiring human approval for high-impact actions, and having downstream systems enforce authorisation rather than trusting the model to decide what is allowed.

The interaction design for those actions is a subject of its own. Our articles on agentic UX design principles and human-in-the-loop UX patterns cover approval, stop, undo and partial completion.

Conversation details that still matter

These are topics the common chatbot guides cover. They still matter in B2B, in this form:

• A starting state built from the user's role. Suggested questions should reflect what this user can actually ask about, drawn from their sources, not generic examples.
• Clarify before guessing. The Human-AI Interaction guidelines advise scoping services when in doubt: ask a short clarifying question, or offer two or three interpretations, when a request is ambiguous and the answer would differ.
• Short answers first, quick replies where the choices are known. Our judgement: lead with the answer and keep it short, offer likely next steps as buttons or quick replies when the options are known, and keep one plain voice rather than a persona.
• Stop, edit and retry. Long answers need a stop control while they generate, and users need to edit their question and run it again without starting a new conversation.
• Memory the user can see. If the assistant carries context from earlier in the conversation, or across conversations, show it and let the user clear it.
• Keep the AI's words distinguishable when they enter the work. When an answer becomes content, mark it until a person adopts it. In the Tcules work for Omny AI, generated suggestions sat in their own panel and entered the listing only when a person clicked to add them, with purple marking AI-generated material and blue marking what a person added. The case study reports that users became more aware of how they used the AI suggestions and more forgiving of occasional inaccuracies; that is a qualitative observation, not a measured change.
• Feedback with a reason. A thumbs-down tells you little. Offer a few reasons (wrong, out of date, missing source, did not answer the question) so the reports can be acted on.
• Accessible progress and errors. "Searching your workspace", "Generating" and error messages are status messages under WCAG 2.2's success criterion 4.1.3 (level AA): assistive technology must be able to announce them without moving focus. W3C lists role="log" as a technique for sequential updates and warns that live regions can make an application too "chatty", so announce a finished answer once rather than every streamed fragment, and test with screen-reader users.

Test it with the cases that break B2B assistants

A test set of common questions checks whether good answers come back. The cases below test the five practices directly, which common questions will not reach. Build them into a test set before launch and run it again whenever the model, the prompt or the sources change.

Measure the results by what went wrong, not by volume: citation support on a sample, wrong answers reported, failed handovers, and conversations that ended without an answer or a next step.

Where this work sits

A chatbot that answers, cites and hands over well is one part of a wider decision about how much the product should let AI do. When your assistant is about to move from answering questions to taking actions, the Tcules AI copilot and agent UX work starts with how much authority the product should delegate and the controls each level needs.

For the review step that sits between an AI proposal and a committed change, see human-in-the-loop UX patterns. For examples of where shipped AI products place that check, see nine AI products that place the human check at the point of consequence.