Article · Chatbot development

A useful chatbot needs better knowledge and a way to hand over.

Plan the source material, answer boundaries and human handoff before adding a chat bubble.

Start with questions your team already receives

Ask support or sales for recurring questions and the answers they actually use. Group them by intent: service information, account help, pricing, policy and requests that need a person. These groups define the first version more clearly than a long list of possible chatbot features.

For each answer, identify the source and the person who owns it. If two documents disagree, resolve the disagreement before indexing them. A chatbot should not become the place where the organisation discovers that its published policies conflict.

Define the boundary of a good answer

An assistant can explain a public service without being allowed to change an account. It can collect information for a quote without inventing a price. Write those boundaries as examples the team can review: what the assistant may answer, what it should ask next and when it must hand over.

Make uncertainty visible in the conversation. When there is no supported answer, a direct explanation and a route to a person is useful. An answer that sounds confident but cannot be traced to the business’s information creates more work for the team later.

Design the handoff as part of the service

A handoff needs a destination, an owner and enough context to prevent the customer from repeating everything. Capture the question, the relevant conversation and the preferred contact method. Tell the visitor whether they are entering a live queue or requesting a later response.

Avoid promising an immediate reply when there is no staffed channel behind the interface. After-hours behaviour should be designed as deliberately as the welcome message.

Test the uncomfortable questions

Include outdated information, ambiguous requests and questions outside the service. Test attempts to get another customer’s data or make the assistant ignore its limits. Test what happens when the knowledge source or the handoff integration is unavailable.

The evaluation set should represent everyday language, including incomplete questions. Review the answer and the action taken. A polite message is not a successful result if it routes a request to the wrong team.

Keep the knowledge in service

Assign an owner to review unanswered questions and update source material. Record when content changes and rerun the relevant checks. A chatbot is an ongoing information service: its usefulness depends on keeping the underlying knowledge and the human route current.

Start with a conversation

Bring us the problem.
Let’s define the next step.

Tell us what you want to build or improve. We’ll discuss scope, dependencies and where to start.