A customer-service chatbot should handle a bounded set of requests and hand off the rest cleanly. It should not impersonate a fully capable human agent or trap customers in a loop when the problem needs judgement.
Whether it reduces cost or improves service is an outcome to measure. It is not a safe assumption.
Give the chatbot a job description
Start with the requests it may handle:
- answer from approved published information;
- retrieve an order status after identity checks;
- collect structured details for a human case;
- route a request to the correct team;
- draft a response for an agent to approve.
Then name exclusions. Refund disputes, vulnerability reports, safeguarding concerns, legal threats and decisions with significant financial or personal consequences may need immediate human handling.
The first release should solve a narrow problem well. “Answer anything about our company” is not a testable scope.
Build from controlled knowledge
Give every source an owner, status and review date. Separate approved customer-facing answers from internal notes and obsolete documents.
For retrieval-based answers, preserve source links and show them to reviewers. If sources conflict or no approved answer exists, the chatbot should say it cannot confirm and offer the correct next route.
Do not assume that a larger document dump makes the bot more knowledgeable. It can make stale and sensitive material easier to surface.
Treat identity and tools as separate risks
A public FAQ bot may not need to know who the user is. An order-status bot does.
Use the minimum identity and access needed for each action. Keep read actions separate from changes. Validate business rules on the server rather than trusting model instructions.
Microsoft warns that untrusted content such as support tickets can manipulate agents connected to sensitive actions. Its Copilot extensibility security guidance recommends trusted sources and careful human intervention for sensitive operations.
Make escalation part of the main design
Escalation is not an apology bolted on after launch.
Define triggers such as:
- user asks for a person;
- identity cannot be confirmed;
- low confidence or conflicting evidence;
- repeated failed intent detection;
- complaint, distress or safety language;
- tool failure;
- request outside scope.
Pass the transcript, verified identity state, collected facts and reason for escalation where privacy and policy permit. Do not make the customer repeat everything.
Always provide a non-chat route for people who cannot or do not want to use the bot.
Test before customers do
Create an evaluation set from real, de-identified contact reasons. Include:
- ordinary requests;
- typos, slang and incomplete details;
- two intents in one message;
- an angry customer;
- an instruction hidden in retrieved content;
- a request for unauthorised information;
- tool timeout and partial failure;
- explicit request for a human;
- an answer absent from approved knowledge.
Score factual support, action correctness, privacy, tone, escalation and recovery. A fluent answer with the wrong action is a failure.
NIST’s Generative AI Profile is a useful voluntary reference for managing risks across the AI lifecycle. It does not certify a chatbot.
Measure service outcomes
Track more than containment. A bot can keep people out of the human queue by frustrating them into leaving.
Useful measures include:
- verified resolution, not just conversation ended;
- repeat contact for the same problem;
- escalation success;
- time to human help;
- unsupported-answer rate from reviewed samples;
- incorrect or unauthorised actions;
- complaints and accessibility failures;
- operational cost including review and remediation.
Define the metric and sampling method before launch. Do not publish improvement claims without the baseline and result.
Operate it as a service
Assign business, knowledge, technical, privacy and security owners. Version prompts, tools and sources. Monitor failures, investigate incidents and provide a rollback or shutdown route.
Microsoft Copilot Studio includes analytics and governance features, but availability and detail vary by experience, licence and release status. Preview monitoring features are not a production guarantee. Check current Copilot Studio analytics documentation and tenant settings.
Proof boundary, checked 24 August 2026
A passed evaluation shows the configured chatbot met defined expectations on the tested cases. It does not prove that customers prefer it, that it will reduce staffing or that unseen inputs are safe.
Human customer-service work may change as routine tasks move into automation. Neither this design nor current evidence establishes a date when call-centre roles will disappear.
For practical AI-agent design with explicit human and failure boundaries, join the Microsoft Copilot Adopters Space.