A useful way through
- Choose a small authorised scope and the current information the bot may use. Name the content owner and the human support route. Do not assume that a system described as AI has access to accurate company facts or permission to make commitments.
- Create cases for a known answer, missing information, an ambiguous question and an out-of-scope request. Write the expected behaviour before testing. Include a correction or changed policy so the team can see whether an old answer remains in circulation.
- Run the cases with safe fictional data in an approved environment. Record the actual response, source reference if supplied and whether the user can reach the agreed human route. Do not enter personal, payment or account secrets to make the demonstration look realistic.
- Review failures with the responsible team and retest the changed version. Keep unsupported claims and invented promises as failures even when the wording sounds confident. Make the service’s automated nature and relevant limitations clear to users.
Read the map as text
THE WORKING DETAIL · KNOWN · Check the source · UNKNOWN · Say what is missing · AMBIGUOUS · Ask, do not guess · HUMAN · Working handover · An invented promise is a failed case.
- Known
- Unknown
- Ambiguous
- Escalation
Put it into practice
A fictional shop bot is asked for a delivery date that the approved source does not contain. The expected response is to acknowledge the missing information and offer the agreed contact route. Inventing “tomorrow” fails the case, even if the reply sounds friendly. A successful greeting does not establish reliable support.
Illustrative example, not a reported client project or test.
Your take-away checklist
Review a customer-help bot with known-answer and escalation cases
- □ Known: ____________________
- □ Unknown: ____________________
- □ Ambiguous: ____________________
- □ Escalation: ____________________
Before you act
This is a review method, not an implemented bot, security certification or permission to process customer data.
A worked record
Use the example to see the decisions, then download a blank record for your own task.
- Known
- Answer from current sourceVerify the actual fact
- Unknown
- State missing informationNo invented promise
- Ambiguous
- Ask a relevant questionDo not guess the order
- Escalation
- Reach agreed support routeTest the link or handover
A test record worth keeping
Use case, input, expected behaviour, actual response, source version, outcome and reviewer. Keep errors visible and distinguish a demonstration from a production test. Planned coverage is not evidence that the live service behaves the same way.
No need to impersonate a person
The earlier text made sweeping claims about bots behaving like humans and being more accurate. Those claims are not repeated. A useful support system can be clearly automated, narrow in scope and honest about what it does not know.
Sources & context
The earlier topic was published 2020-12-26 under the Maria Baldwin byline. The present procedure, examples and diagrams are new work by MichaelT editorial; they do not attribute a new test or professional assessment to the earlier author.