15 Chatbot Best Practices, In The Order You Need Them

Design and UX: rules 1 to 5

These are decisions about the container, not the intelligence. They cost nothing to get right at the start and are irritating to retrofit once the widget is on your site.

1. Say it is a bot in the bot's first message.

This is no longer only a courtesy question. California's bot law, in force since 1 July 2019, makes it unlawful to use a bot to mislead someone about its artificial identity in a commercial transaction, and provides a safe harbour for anyone who discloses clearly and conspicuously that it is a bot. From 2 August 2026 the EU AI Act's Article 50 requires that people interacting directly with an AI system are informed of that fact, unless it would be obvious to a reasonably observant person.

The practical version is one clause in the opening line: "Hi, I'm an AI assistant for Acme." Giving the bot a human first name and no disclosure is the pattern that gets companies into trouble, and it also poisons the escalation experience, because a customer who thought they were talking to Sarah feels tricked when Sarah turns out to be software.

2. Use the welcome message to set scope, not to say hello.

"How can I help you today?" is the least useful sentence in customer experience. It invites the entire universe of questions into a system that can answer a slice of them, and every question outside that slice becomes a failure the customer blames on you.

Replace it with a scope statement and three real starter questions: "I can answer questions about pricing, shipping, returns and account setup. For billing disputes I'll get you a person." A visitor now knows the boundary before they type. This single change reduces out-of-scope questions more reliably than any amount of prompt engineering, because it works on the human side of the conversation.

3. Write every answer for a phone screen.

StatCounter's measurement of worldwide page views put mobile at 51.51% in June 2026, ahead of desktop at 47.12%. A chat widget on a phone is a narrow column with a keyboard covering half of it, so an answer that reads well in your desktop preview can be four thumb-scrolls in reality.

Front-load the answer in the first sentence, cap replies at roughly three short paragraphs, avoid tables entirely, and put the detail behind a cited link rather than in the message. If the honest answer genuinely needs 400 words, give the 40-word version and link to the page with the rest.

4. Put an escalation route in every conversation and pass the transcript with it.

Two failures matter here. The first is a bot with no exit, which turns a two-minute question into an angry email. The second is an exit that dumps the customer into a fresh chat where they have to explain everything again, which is worse than no bot at all because it wasted their time first.

The rule is that the handover carries the full transcript into whatever your team actually reads, and that the customer can trigger it at any point rather than only after the bot has failed three times. matram.ai escalates into a shared team inbox with the conversation attached, which is the shape you want regardless of which vendor you pick.

5. Make the widget keyboard-operable and legible to a screen reader.

Chat widgets are one of the most consistently inaccessible components on the modern web, usually because they are built as a floating div that traps focus or never receives it. WCAG 2.2 success criterion 2.1.1, a Level A requirement, is that all functionality is operable through a keyboard interface. Criterion 4.1.3, Level AA, requires that status messages can be programmatically determined so assistive technology can present them without moving focus, which is exactly the case of a new bot reply arriving.

Test it in ten minutes: tab from the page into the launcher, open it, type a question, send it with the keyboard alone, and confirm a screen reader announces the reply. If any of those steps fails, that is a defect to raise with your vendor before launch, not after a complaint.

AI training and content: rules 6 to 9

This is where most of the quality lives. A well-trained bot on a mediocre widget beats a beautiful widget over a pile of unsorted PDFs, every time.

6. Curate the sources. Do not point it at everything you own.

The instinct on day one is to crawl the whole site and upload the entire shared drive, on the theory that more knowledge means better answers. It does the opposite. Retrieval works by finding the passages most similar to the question, and every outdated blog post, superseded policy PDF and half-finished internal draft is a candidate to be retrieved instead of the correct page.

Start with the ten to thirty documents that answer the questions you actually get. Add sources one at a time, and check what changed after each addition. If your platform lets you connect Notion, Google Drive, SharePoint or Confluence in one click, resist the click until you know which spaces inside those tools are current.

7. Restrict answers to your own content, and cite the page every time.

Two settings do most of the work of preventing hallucination. The first is a strict or grounded mode that stops the model answering from its general training when your content has nothing relevant. The second is a visible citation on every answer, linking the page it came from.

Citations are usually sold as a trust feature for the customer, and they are, but their real value is internal. A wrong answer with a citation is a content bug you can find and fix in twenty minutes. A wrong answer without one is an unfalsifiable complaint about "the AI", and there is nothing you can do with it. Ask any vendor to show you a cited answer in a demo before you sign anything.

8. Give the bot an explicit way to say it does not know.

A language model with nothing relevant retrieved will either decline or improvise, and which one it does is a configuration choice you make. Write the decline message yourself rather than accepting a default, and make it do work: acknowledge the gap, say what the bot can help with instead, and offer the human route in the same breath.

"I don't have that in my documentation. I can help with pricing, shipping or returns, or I can pass you to a person now" is a good outcome. It also produces a clean signal in your analytics, which is what rule 13 runs on.

9. Test with real historical tickets, not with questions your team wrote.

Marketing-written test questions are grammatical, correctly spelled, use your product names properly and ask one thing at a time. Real customer messages are none of those. They are lowercase, they contain two questions and a complaint, they use the old name for the product, and they assume context from a previous conversation.

Pull the last hundred inbound tickets or chat transcripts, paste them into the bot verbatim, and grade every response as correct, wrong or declined. That exercise takes an afternoon and tells you more than any vendor benchmark. It also hands you your content gap list before a customer finds it, and it produces the baseline that rule 14 needs.

When a chatbot is not the answer

Every rule above assumes you should be building this at all. Sometimes you shouldn't. Four situations, running from the obvious to the genuinely arguable, where the honest advice is to close the vendor tabs and go and do something else.

Your whole support volume is a handful of emails a week

If you can clear every inbound question yourself before lunch, a chatbot is a project with no problem attached to it. You would spend weeks curating sources, writing decline messages, running the QA pass and agreeing who watches the escalation inbox, and at the end of all that the bot would field the questions you were already handling fine. There is nothing here to take off your plate. Buy the time back some other way, and come back to this page when the queue starts to hurt.

You never get the same question twice

Chatbots pay off on repetition. If your inbox is genuinely bespoke, every message a different account with a different history and a different half-configured setup, there is no frequent question to answer and no page worth citing. Grounded answering needs something written down to be grounded in. When the answer lives in a colleague's head and changes per customer, you don't have a content problem that retrieval can fix. You have a staffing problem, and a bot in front of it only adds a step.

Being wrong once would be worse than never answering

Here it stops being obvious. Some questions carry an asymmetric downside: eligibility for a benefit, whether a clause applies to somebody's contract, anything medical, anything where a confident wrong answer sends a person off to act on it. Strict mode and a well-written decline message make a bot much safer than an ungrounded one. Much safer is not the same as safe enough for this. Ask what happens to the person who believes the bad answer, and if the honest reply is that they lose money or make a legal mistake, keep a human in the loop and let the bot do nothing but route them there faster.

Your content is stale and nobody owns fixing it

This is the genuinely borderline one, and it is the most common. Everything in the training rules depends on source material that is current, and on somebody being responsible for keeping it current. If your help centre has not been meaningfully edited in years and there is no name against it, a chatbot will do exactly what it is built to do: repeat the stale answer, fluently, at scale, to far more people than those pages ever reached on their own.

But the argument cuts both ways, which is why this one is arguable rather than settled. Running your real tickets through a bot is the fastest content audit most teams will ever do, and the list of declines it produces is a prioritised backlog you did not have before. So the question is not whether your content is good enough today. It is whether anyone will act on that list once the bot hands it over. If the answer is no, fix the ownership first. The bot will still be available afterwards.

The pre-launch QA pass

Rule 11 says run a scripted QA pass before the widget goes live. This is the script. Run every row yourself, on a real device, in a fresh session, and do not delegate it to the person who built the bot.

Any row that fails is a launch blocker, not a backlog item. The cost of fixing these before launch is an afternoon. The cost of fixing them after launch includes the conversations that went wrong in between.

Deployment: rules 10 to 12

The most common implementation mistake is scope, not technology. Teams try to launch every use case on every channel at once, and end up unable to tell which part is failing.

10. Launch one use case, on one channel, first.

Pick the single highest-volume question category you have, put the bot only on the pages where that question gets asked, and leave everything else alone for two weeks. Support-only on the help centre, or pre-sales-only on the pricing page. Not both.

The reason is diagnostic, not cautious. With one use case on one channel you can read every transcript in a sitting and know exactly what is broken. With five use cases across the website, Slack, Messenger and your helpdesk, a drop in quality has fifteen possible causes and you will guess wrong. Widen the surface only once the narrow one is boring.

11. Run a scripted QA pass before the widget goes live.

Nobody skips QA deliberately. They skip it because the bot answered five questions correctly in a demo and everyone felt good. The checklist above exists to convert that feeling into evidence, and to catch the two categories that demos never surface: what happens at the edge of the content, and what happens on a phone.

Have someone who did not build the bot run it. Builders unconsciously phrase questions the way the content is written, which is the same bias that makes marketing-written test queries useless.

12. Tell your support team before customers meet the bot.

Escalation only works if somebody is on the other end of it. Before launch, agree who watches the handover inbox, what the response expectation is during business hours, and what the bot should say outside them. A bot that promises a human at 11pm to a team that starts at 9am has created a broken promise, not a deflection.

This is also the moment to be straight with the team about what the bot is for. It is answering the repetitive questions so they can work the hard ones. Teams that find out about a chatbot by watching their queue change tend to become its least helpful critics.

Optimisation: rules 13 to 15

Everything above is a project. This part is a habit, and it is the only reason a chatbot gets better rather than slowly worse.

13. Read the failed and escalated transcripts every week.

Book thirty minutes on a recurring calendar slot. Filter your analytics to conversations where the bot declined, where the customer escalated, or where the customer left immediately after an answer. You are not reading these to judge the model. You are reading them to build a list of pages you have not written.

Almost every "the AI is not good enough" complaint resolves to a content gap once you look. Three people asked about your refund window for annual plans, and your refund page only covers monthly. That is one paragraph of work, and it fixes the bot and your public documentation at the same time. Daily or weekly summary emails are useful here mainly as a prompt to actually open the transcripts.

14. Build your own resolution baseline in week one and measure against that.

There is a widely circulated set of chatbot deflection benchmarks, and none of them survives a look for a primary source. Ignore all of them. Resolution rate is overwhelmingly a function of how completely your content covers what people ask, so the industry average tells you nothing about your situation.

Instead: in week one, count conversations, count how many ended without an escalation or a repeat contact, and write that ratio down. That is your baseline. Then track four things month over month, all against your own numbers rather than anyone else's. Resolution rate. Escalation rate. The count of distinct questions the bot declined. And contacts per hundred sessions on the pages where the widget is live. Movement in those four is the entire performance picture.

15. Re-crawl on a schedule and treat a stale answer as a content bug.

The failure mode of a mature chatbot is not hallucination. It is confidently reciting last quarter's pricing, because your pricing page changed and nobody re-imported it. This gets worse over time, silently, and it is the reason bots that launched well are distrusted a year later.

Set a re-crawl cadence that matches how fast your content moves, and add "update the bot's sources" to whatever checklist already exists for changing a policy or a price. Then, once a quarter, re-run the top twenty questions from your QA pass. Ten minutes, four times a year, catches the drift that transcript review does not, because customers rarely tell you an answer was out of date. They just act on it.

What getting this wrong actually costs

The subscription is the cheapest part of a bad chatbot, and it is the only part anyone budgets for. The costs that actually hurt are all second-order, and none of them turn up on an invoice.

The quarter, not the invoice

A bot that launches wide, over uncurated content, with nobody watching the transcripts, does not fail loudly. It fails in slow motion. Somebody builds it, everyone is pleased in the demo, and then it sits there being mildly wrong while the person who championed it moves on to the next thing. Months later a manager asks how it is going and nobody can say, because no baseline was written down in week one and nobody has opened a transcript since launch. The money is trivial. The quarter is not, and you do not get it back by switching vendors.

The credibility you spent getting it approved

Somebody argued for this internally. They told support it would take the repetitive questions off them, and they told finance it would pay for itself. Both of those are promises, and a bot that quietly misleads customers cashes them in against the person who made them. The second-order cost is that the next automation proposal starts from behind. Teams that have been burned once don't evaluate the next tool on its merits. They evaluate it on the last one.

That is the real reason the deployment rules insist on telling your support team before customers meet the bot. A team that was consulted reports a bad answer to you. A team that found out by watching its queue change reports it to everybody else.

The work you stopped doing to build it

Every hour spent curating sources and grading your last hundred real tickets is an hour not spent on whatever was second on the list. Fine when the bot works. When it doesn't, the loss isn't the hours, it is the second thing, which is very often the unglamorous documentation work that would have made the bot good in the first place. Teams get this backwards constantly. They buy a platform to avoid writing the missing pages, then discover that the platform's entire value depends on those pages existing.

The customer who never complains

Everything above is internal. This one isn't, and almost nobody measures it. Most people who get a wrong answer from a chatbot don't screenshot it and don't email you. They quietly decide you are not worth the effort and go elsewhere, and you find out through a churn number that has plenty of other plausible explanations. And the few who do complain loudly are doing you a favour, which is a strange sentence to have to write down.

So citations and the weekly transcript habit look like overhead right up until the moment they don't. A cited wrong answer is a bug report with an address on it. An uncited one is a customer you never hear from again.

Are you ready to launch?

A short gate to run before the widget goes on your production site. If anything in the right-hand column is true, the fix is cheaper today than it will be next week.

None of these gates are about the model. They are about scope, content and staffing, which is where implementations actually fail. If you want a starting library of scoped, on-brand messages, the chatbot script examples page has openers, decline messages and handover lines you can adapt.

An illustrative worked example

This is a hypothetical, written to show the arithmetic rather than to report a result. matram.ai publishes no case studies and no deflection figures, so every number below is either a published third-party price or a placeholder you replace with your own.

Imagine a 40-person B2B software company handling 900 inbound support contacts a month. They apply rule 10 and launch on the help centre only, for one category: account and billing questions, which is 300 of the 900. They apply rule 9 and grade the bot against their last hundred tickets in that category before launch. They apply rule 14 and record their week-one resolution ratio, whatever it turns out to be, as the baseline.

Now the economics, which is the part worth understanding before you pick a vendor. ContactBabel's 2026 US Contact Center Decision-Makers' Guide puts the average inbound call at $7.20, which it reports as 47% more than an email and 23% more than a web chat. That is the number on the cost side of the ledger, and it is the one you should replace with your own fully loaded cost per contact.

The pricing model matters more than the sticker price

On the platform side, the market splits into two shapes. Usage-priced tools charge per outcome or per conversation: Fin, the helpdesk formerly known as Intercom, lists $0.99 per resolution with a 50-outcome monthly minimum and one outcome billed per conversation, plus $9.99 per qualification. Salesforce Agentforce lists $2 per conversation, or $0.10 per agent action through Flex Credits at $500 per 100,000 credits. Flat-rate tools charge a subscription regardless of volume: matram.ai is $29, $69 or $199 a month with unlimited team seats.

At 300 conversations a month, those two shapes produce very different bills, and neither is universally better. Usage pricing is cheaper at low volume and aligns cost with value. Flat pricing is cheaper once volume is predictable and makes budgeting trivial. Work out where the crossover sits for your own numbers before you commit, because the answer flips as you grow. The chatbot ROI calculator does that arithmetic with your inputs.

What the company should watch after 90 days

• Resolution rate against their own week-one baseline, not against any published benchmark.
• The number of distinct questions the bot declined, which should fall as they write the missing pages.
• Escalation volume in the shared inbox, and whether escalated conversations resolve faster than they used to because the agent sees the transcript.
• Contacts per hundred help-centre sessions, which is the only metric that shows whether the bot changed the workload rather than just added a channel.

If those four move in the right direction, widen the scope to a second question category. If they do not, the answer is almost always in the transcripts from rule 13, and almost never in switching vendors.

Frequently asked questions

Sources

• EU AI Act, Regulation (EU) 2024/1689, Article 50 - Providers must ensure people interacting directly with an AI system are informed of that fact unless it is obvious; Chapter IV transparency obligations apply from 2 August 2026.
• California Business and Professions Code § 17941 (SB 1001) - It is unlawful to use a bot to mislead about its artificial identity in a commercial transaction; disclosure that is clear and conspicuous is a safe harbour. Operative 1 July 2019.
• W3C, Understanding WCAG 2.2 SC 2.1.1 Keyboard (Level A) - All functionality of the content must be operable through a keyboard interface, which covers opening and using a chat widget.
• W3C, Understanding WCAG 2.2 SC 4.1.3 Status Messages (Level AA) - Status messages must be programmatically determinable so assistive technology can present them without moving focus, which is the case of a new chatbot reply arriving.
• StatCounter Global Stats, Desktop vs Mobile vs Tablet, June 2026 - Mobile accounted for 51.51% of worldwide page views in June 2026, against 47.12% desktop and 1.36% tablet. Used to justify designing chat replies mobile-first.
• ContactBabel, 2026 US Contact Center Decision-Makers' Guide - Average cost of an inbound call of $7.20, reported as 47% more than an email and 23% more than a web chat.
• Fin pricing page (checked 20 July 2026) - $0.99 per resolution with a 50-outcome monthly minimum and one outcome billed per conversation, plus $9.99 per qualification. Fin is the company formerly known as Intercom.
• Salesforce Agentforce pricing - $2 per conversation, or $0.10 per agent action via Flex Credits priced at $500 per 100,000 credits.
• Gartner press release, 25 June 2025 - Gartner coined "agent washing" and estimated only around 130 of the thousands of vendors claiming agentic AI were genuine.