
A customer-support chatbot should help people reach a useful answer or the right person. A fluent conversation is not enough if the answer is unsupported, a private record is exposed or the visitor cannot escape a loop.
Before choosing a model or a chat interface, define the service boundary. This guide describes a proposed planning and test process for a focused support assistant, not a guarantee that every enquiry can be automated.
Choose the questions the chatbot should answer
Review the questions your team actually receives. A first release might cover published service information, opening hours and the steps required to start a project. Keep account-specific changes, exceptions and decisions requiring judgement outside that initial scope.
Write a short boundary statement: what the assistant may explain, what it may retrieve and what must go to a person. Make that distinction visible to the visitor. Do not imply that the chatbot is a human member of the team.
Prepare a small, owned knowledge base
Start with current, approved material. Give each page or document an owner and a review date. Resolve conflicting versions before indexing them. An assistant cannot reliably reconcile an old offer with a new policy if nobody has defined which one is authoritative.
Retrieval-augmented generation can supply relevant passages to a model when answering a question. It does not make every generated answer correct. Link to supporting sources where useful, and provide an honest fallback when the available material does not support an answer.
Keep public information separate from private records
A public FAQ assistant and an authenticated account assistant are different products. If private information is in scope, enforce identity and authorisation on the server before retrieval or an action. Asking a visitor for a name or order number is not, by itself, sufficient authentication.
Microsoft’s Copilot Studio documentation illustrates that knowledge sources have different authentication requirements. For your implementation, explicitly test what an unauthenticated visitor and each permitted user can access. Do not assume that connecting a source automatically establishes the correct permissions.
Design the human handoff before launch
Offer a clear way to reach the team when an answer is missing, disputed or unsuitable. Explain the next step honestly. If the business does not provide live support at that time, offer an enquiry route rather than suggesting an agent is about to join.
- Pass a concise issue summary to the receiving team, with appropriate consent and access controls.
- Show which details are needed and why; avoid unnecessary personal information.
- Retain an alternative contact route if the chat service fails.
- Do not promise a response deadline unless the business can support it.
Test the difficult conversations
Create representative questions with expected answers or escalation outcomes. Include misspellings, follow-up questions, missing information and requests that are outside the assistant’s remit. Test malicious instructions embedded in supplied text as well as direct attempts to bypass the rules.
Review whether the assistant uses the right source, stays within its permissions and admits when evidence is missing. Check keyboard access, readable errors and the handoff journey on mobile. A proposed acceptance checklist should cover the complete service experience, not just whether the model produces a reply.
Monitor usefulness after release
Start with a limited pilot and a named owner. Track unresolved questions, unsupported answers and handoff failures, alongside response time and availability. Use the findings to improve source material and routing. Re-test when policies, integrations or model settings change.
Common questions
Should the chatbot answer every question?
No. A reliable boundary and a useful escalation route are more valuable than a confident answer without evidence.
Can one chatbot serve both public and private enquiries?
It can be designed that way, but access paths and permissions need explicit separation and testing. Begin with the smaller scope your team can operate responsibly.
Plan the support journey with the website
Explore WebInfratech’s web development services for the interface and integration work. Our guides to RAG and business knowledge and responsible AI launch checks cover complementary foundations. You can discuss a focused support requirement before committing to a wider rollout.
Further reading: Microsoft Learn: knowledge sources and authentication. Validate the current requirements for the platform and data sources you choose.

