Chatbot Best Practices: Rules, Testing, and Human Handoffs

A chatbot builds or destroys trust with every conversation. The practices that determine which way that goes are not about the model or the platform: they are about what knowledge you give the chatbot, how you test it before it goes live, and what happens when it cannot handle a question. Tools like fenbs help keep the reusable instructions and the lessons from failed conversations in one place, so every session builds on what was learned rather than repeating the same mistakes.

These practices apply to any chatbot you build or manage: customer support, sales qualification, internal tools, or workflow automation. The specifics vary by use case; the principles do not.

Start with the questions, not the tool

The single most reliable predictor of whether a chatbot works is whether it was built around the actual questions people ask, rather than the questions someone assumed they would ask. Pull three to six months of support tickets, chat logs, or search queries before you write a single response. Cluster the questions into categories. Build the chatbot to handle the top categories well, and leave the rest for a human.

A chatbot that handles 15 question types accurately is more useful than one that attempts 50 and gets half of them wrong. Narrow scope and high accuracy is the starting point. Expand once the narrow version is reliable.

Write clear, scoped instructions

A chatbot's behavior is shaped by its instructions (sometimes called a system prompt). Vague instructions produce inconsistent behavior. Clear instructions define the task, the constraints, the tone, and the escalation path.

• State what the chatbot should and should not answer. "Only answer questions about our return policy" is clearer than "be helpful."
• Specify the tone and format. "Reply in two to three short sentences, in a direct and friendly tone" produces a more consistent result than no instruction on format.
• Name the escalation trigger explicitly: "If the customer expresses frustration or asks for a supervisor, hand off to a human immediately."
• Set a fallback for unrecognized questions. "If you do not know the answer, say so and offer to connect the customer with a person" is better than leaving the fallback undefined.

Choose sources carefully

A chatbot is only as accurate as the knowledge it draws on. If that knowledge is outdated, internally inconsistent, or written for a different audience, the chatbot will reflect those problems.

Decide on a source of truth for each category of questions and keep it current. For a product chatbot, that source might be the current help documentation. For a policy chatbot, it is the current policy document. When the source changes, update the chatbot. A chatbot quoting last year's policy creates a support problem, not a support solution.

Test against real and edge-case questions

Testing a chatbot against the questions you wrote it for is not enough. Test it against the questions you did not plan for: phrasing variations, abbreviations, misspellings, and questions that are adjacent to but not quite in scope.

1. Test with at least 20 questions per category, including five that are phrased differently from the examples you used in training.
2. Test the escalation trigger deliberately: phrase questions that should cause a handoff and confirm it happens.
3. Test the fallback: ask something completely outside the chatbot's scope and confirm it handles it gracefully.
4. Have someone who did not build the chatbot test it. They will naturally phrase questions differently from the builder.
5. Test in the actual channel. A chatbot that works in a browser widget may behave differently in a mobile app or messaging channel.

Design human handoffs carefully

The handoff from a chatbot to a person is a high-stakes moment. A customer who has already explained their problem to a bot and then has to explain it again to a person will be frustrated before the conversation starts. Good handoffs are fast, complete, and honest.

• Pass the full conversation to the person, not just the last message. The person needs the context before they say hello.
• Tell the customer a person is on the way and when to expect a response. "I'll connect you with someone now" is better than silence followed by a reply 20 minutes later.
• Trigger notifications to the right person or queue. A handoff that sits unread for hours is not a handoff.
• Set after-hours handling explicitly: a clear message about response time is better than a loop that implies someone is coming who is not.

Review failed conversations regularly

Aggregate metrics like resolution rate or deflection rate tell you the overall picture but not the specific problems. The most useful review is of the conversations that ended badly: a user who gave up after a wrong answer, a question that escalated when the bot should have handled it, or an escalation that did not trigger when it should have.

Each of those is a specific, fixable problem. Log it as a task, fix the instruction or the source, retest, and move on. A weekly review of 10 to 20 failed conversations takes less than an hour and keeps the chatbot improving rather than drifting.

How to do this with fenbs

1. Create a free account and add a project for the chatbot you are building or maintaining.
2. Add the current approved instructions and response templates as AI context notes or Skills and prompts.
3. After each review session, add improvement tasks to the kanban board: wrong answers to fix, escalation rules to adjust, edge cases to handle.
4. When something goes particularly wrong, add a lesson with what happened and what to do differently. Search existing lessons before adding a new one.
5. Connect a supported AI app over MCP from Integrations and ask it to read the project context before drafting improved instructions or responses.