Choose an AI chatbot through 3 demonstrations: it answers from the right sources, respects the intended data access and takes an unresolved question to a usable next step. Fluent wording is not enough. A business needs to know where an answer came from, what the system can see and who owns the conversation when automation cannot help.
Compare Microsoft Copilot Studio and Botpress against the receiving system your support team actually uses. Their official documentation describes different handoff arrangements. Neither is ranked universally best here, and no private agent was deployed for this article.
| Buyer requirement | Copilot Studio | Botpress | Evidence needed before choosing |
|---|---|---|---|
| Connected support destination | Configured engagement hub can receive an alert and conversation history | New workspaces use Botpress Desk for Human Handoff | Show the actual receiving workspace and responsible operator |
| Existing support workflow | A simple escalation message or contact URL is distinct from connected live transfer | Existing workspaces can continue the legacy HITL integration, documented as requiring Plus or higher | Identify which configuration the proposal actually includes |
| Agent ownership of unresolved work | Connected live agent can continue the conversation | Legacy HITL tickets can be assigned to workspace members | Demonstrate assignment and context with a fictional enquiry |
| Implementation dependency | Engagement-hub integration is required for the documented connected transfer | New Desk setup and legacy HITL setup are different routes | Confirm workspace type, current plan entitlements and setup scope |
Botpress’s handoff guide explicitly separates new workspaces from the legacy instructions beneath its notice. The documented legacy HITL feature requires a Botpress Plus plan or higher. That condition applies to the legacy instructions here; it is not evidence of Desk’s current plan requirements. Its legacy ticket controls are useful comparison evidence, but they should not be promised as the current Desk interface. Choose from demonstrated requirements rather than treating both products as interchangeable.
What should the chatbot know, and what must remain outside its reach?
Start with a bounded customer task. A bot answering published service questions needs a different source set from an agent accessing customer-specific order information. Write the distinction before selecting a model or uploading files. If the task is unclear, a demonstration can appear successful while avoiding the data boundary your actual operation needs.
Microsoft’s knowledge-source overview describes grounding responses in sources such as public websites, uploaded documents, SharePoint, Dataverse and external systems. These are different access arrangements. A public FAQ can be read by anyone; a private document collection may require the user’s identity and the relevant permissions. Do not treat “connected knowledge” as a single security setting.
The documentation identifies authentication differences between source types, including Microsoft Entra ID for relevant internal sources. Ask the demonstrator to use the intended user role. A correct answer obtained with an administrator account does not prove that an ordinary customer or employee should be able to receive it.
Name the authoritative source for each answer category. A service description, a returns policy and an order record may have different custodians and update processes. If they disagree, decide which one should govern the response. Uploading contradictory documents does not resolve the disagreement; it can merely make the bot express it more confidently.
Keep public information separate from private case details. If the question requires personal or account-specific data, define the identification and permission checks before allowing retrieval. Do not ask a customer to paste passwords, payment credentials or unnecessary identity documents into a general chat merely to make the agent appear helpful.
Test uncertainty deliberately. Ask a question whose answer is absent from the approved sources and inspect what happens. The desired response should acknowledge the limit and provide the agreed next step rather than fabricate a policy or commitment. This is an acceptance requirement, not an assertion that selecting a knowledge source automatically prevents unsupported answers.
Use this original evaluation card to make the evidence concrete.
| Test question | Evidence to request | Failure to retain |
|---|---|---|
| Published service question | Relevant current source and supported answer | Confident answer without a matching basis |
| Ambiguous customer request | Clarifying response tied to the task | Unsupported assumption about the customer |
| Question outside the sources | Accurate limit and next step | Invented policy or capability |
| Private-record request | Intended authentication and access result | Information shown to the wrong role |
| Conflicting documents | Named source authority and correction route | Arbitrary answer that hides the conflict |
| Escalation request | Actual destination and retained context | A handoff message with no receiving owner |
How do you prove escalation and operational ownership?
Do not accept a sentence saying “I will connect you” as evidence of handoff. Microsoft’s live-agent documentation describes a connected engagement hub receiving an alert and allowing a live agent to review history and continue the conversation. That involves a configured receiving system and a person able to respond, not just a friendly line of text.
The same guide explains that an escalation topic can instead provide a simple message, support URL or contact instructions without linking to an engagement hub. Keep that distinction explicit in a proposal. A contact instruction may be an appropriate next step, but it should not be marketed as a live transfer if nobody receives the conversation.
Demonstrate the actual route with a fictional enquiry. Ask for help, observe the destination and inspect the context available to the receiving person. Record who owns the next response and what happens when that route is unavailable. Do not invent a response-time promise to conceal an unstaffed queue.
Check which context is passed. Microsoft describes sharing conversation history and relevant variables in its configured handoff arrangement. Your business should decide what is necessary for the receiving person and what should be excluded. A complete transcript can include more information than the next task requires; minimise the data instead of forwarding it indiscriminately.
Ask about actions separately from answers. A bot that explains how to request a booking is not necessarily authorised to create one. Any action should have a clear scope, confirmation rule and recoverable record appropriate to the task. Do not grant broad access to operational systems merely because a demonstration of FAQ answers went well.
Finish with an ownership plan covering source updates, access administration, escalation and incident correction. The system should make unresolved work visible so staff can act. Do not infer performance improvement from a sample conversation.
For related digital requirements, see Spout’s web development and WhatsApp Business pages. Get started with the customer question, approved source types and escalation route you need to evaluate. Keep private conversation records, customer data and access tokens outside the initial enquiry.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary sources.