Chatbot best practices

These recommendations come from how Buni.ai chatbots match messages, send replies and hand over to people. Each one links to the page with the details.

Start the conversation wellCopy Anchor Link

• Say what the bot can do. The Trigger's Introduction Message is the first thing a new user sees. Name the two or three things the bot handles, so people ask for those.
• Keep it short. A long welcome on WhatsApp or Telegram is read as a wall of text. Put detail in replies to specific questions.

Design intents that match reliablyCopy Anchor Link

• One request per intent. "Track my order" and "Cancel my order" are two intents, even if they share an API.
• Write at least 10 varied sample utterances per intent, in the words your users actually use: short and long, formal and casual, with common misspellings.
• Never reuse an utterance across intents. Overlaps make matching unpredictable, and validation flags them.
• Use parameters instead of near-duplicate intents. One OrderPizza intent with a pizzaSize parameter beats three intents for small, medium and large.
• Give every required parameter a clear prompt, one that says what format you expect: "What's your order number? It starts with ORD."
• Name output variables for what they hold, such as order rather than result1, so {{state.order.pizzaSize}} reads clearly later.

See Building chatbot flows.

Plan for messages the bot does not understandCopy Anchor Link

• Always add a fallback intent (an Intent whose only sample utterance is Fallback). Without it, people get a generic English apology.
• Make the fallback useful. Tell people what the bot can help with, offer buttons for the most common requests, or offer a person.
• Read what people actually asked. The project's Activity tab lists unrecognised messages and what to fix first. Turn them into sample utterances or new intents.

Use buttons wellCopy Anchor Link

• Set a Target Intent on every button that should continue the conversation, rather than relying on the tapped text being recognised.
• Keep button text to 20 characters or fewer and use at most three buttons per message. WhatsApp, Messenger and Instagram drop extra buttons and cut longer titles.
• Make the button value meaningful, such as large, so a downstream Router can branch on it.

Collect information with formsCopy Anchor Link

To ask for more than one or two details in a row, use a Form node instead of chaining intents. A form validates each answer, lets people go back or cancel, and stops a reply like "Kigali" from being mistaken for a new request.

Only ask for what you need, and mark sensitive fields so they are masked in the review step.

Handle failuresCopy Anchor Link

• Give every API and Data Store step a failure path. Tell the person something went wrong and what to do next, rather than going silent. See Error handling.
• Check for empty results. A lookup that finds no record is not an error, but it still needs its own reply.

Hand over to people cleanlyCopy Anchor Link

• Offer a person explicitly, through an intent such as TalkToPerson with utterances like "agent", "human" and "speak to someone".
• Write a Transfer Message that sets expectations, and use the agent's name: "{{agent.name}} from our team will reply here shortly."
• Keep the Fallback Message honest. It is sent when nobody can be assigned; tell people how else to reach you. Keep the Wait Reminder short, since it repeats.
• Set business hours so people who write when your team is closed are told when you are back.
• Pass the context in the Agent Note, such as the order number the bot already collected.

See Live chat handoff.

Respect channel rulesCopy Anchor Link

• WhatsApp: outside the 24-hour window after a customer's last message, WhatsApp only delivers approved templates. Use a WhatsApp template reply element for messages you send later, such as reminders. See WhatsApp templates.
• Test on the real channel after publishing. The simulator shows the web rendering of each message.

Ship changes safelyCopy Anchor Link

• Test every path in the simulator before publishing: each intent, each button, missing parameters, the fallback and failure paths.
• Publish after every change you want live. Saving updates only the development version that the simulator uses.
• Add release notes when you publish so your team can tell versions apart in Version history.

See Testing and publishing.

RelatedCopy Anchor Link