Agree on the outcome before the demonstration
An impressive conversation in a presentation does not yet show how an assistant will behave with a real visitor. Acceptance testing needs a set of situations with a clear definition of a correct outcome. Start with several tasks: explaining service terms, finding the right section, clarifying a request or handing an enquiry over to a team member.
Document the boundaries for each task. If the assistant helps choose a plan, may it promise an individual discount? If it collects an enquiry, is it authorized to confirm a delivery date? The product owner decides these questions. The development team turns those agreements into testable scenarios. This record is more useful than a general requirement to “respond intelligently and in a friendly manner.” Preparing sources is covered separately in our article on AI assistant data; this article concerns testing a completed scenario.
Acceptance testing checks the meaning of an answer, its limits and the actual handover of an enquiry. Repeat the same test set after changes.
Build a set of test questions
We suggest a five-column table: question, context, expected meaning of the answer, prohibited action and test result. Include direct enquiries, conversational wording, typos, repeated questions and messages in which the person changes their mind. Reserve some scenarios for the final check so the demonstration is not limited to prepared examples.
A hypothetical example for a service company: “I need maintenance, but I don’t know which package is right.” The expected behavior is to clarify the required scope, show options and offer a conversation with a manager. Unacceptable behavior is to invent a plan that does not exist or state that a contract has already been concluded. This scenario does not need one exact reference text: the meaning and sequence of actions matter.
Add a request with missing information separately. If someone asks “how much does it cost?”, the assistant should first establish which product they mean, unless the context already makes that clear.
Assess accuracy and usefulness separately
An answer can be polite but incorrect. Another answer may contain the right facts without helping the person take the next step. It is therefore useful to record reliability, completeness, clarity and compliance with agreed authority separately in the test report. Do not reduce these properties to the reviewer’s overall impression.
The OWASP risk list for LLM applications separately addresses misinformation, sensitive information disclosure and excessive agency. This is a reason to test scenarios that cross permitted boundaries as well as ordinary questions.
Ask reviewers to record the exact phrase next to each issue and explain what is wrong with it. “I didn’t like the answer” is difficult to fix; “it states a deadline that is not in the terms” gives a clear task. Refer disputed cases to the product owner rather than deciding them solely by a team vote.
Test refusals and handover to a team member
The test set must contain questions the system should not answer confidently. Examples include requests to confirm non-standard terms, change someone else’s order or disclose another customer’s information. Define the expected result in advance as a refusal, a clarification or a handover to a person.
Check the complete handover journey. Does the user understand what is happening? Does the team member receive a useful description of the question? Is the selected product retained? Is there a clear contact method if an operator is unavailable? “I have passed this to a manager” is acceptable only after the enquiry has actually been created; a delivery error requires a different, honest status.
Use fictional data for acceptance testing. You do not need real customer conversations to test a refusal or the preservation of context.
Repeat scenarios after changes
Run the same scenario several times and at different points in a conversation. Record the configuration version and test date. After changing the model, instructions, sources or an integration, repeat the test set. Otherwise, fixing one answer may silently change another.
Classify issues by their consequences. A button-label error and an incorrect order confirmation require different launch decisions. Agree on the acceptance threshold in advance: which cases block publication, which can be allowed with a restricted feature, and which can be fixed separately. There is no universal percentage of “good answers” for every product.
Record the launch decision
Before opening access, check this short list:
- the main tasks have been tested using the agreed questions;
- disputed answers have been reviewed by the product owner;
- missing information leads to clarification or an honest limitation;
- prohibited actions are not verbally confirmed;
- handover to a team member has been tested through to receipt of the enquiry;
- someone is responsible for new issues and repeat testing.
The report preserves questions, actual answers, issues and the decision made. After launch, expand the set with anonymized situations that were not anticipated. It is useful to discuss the feature scope and acceptance criteria alongside the AI integration task. To review an assistant that is already running, first collect problematic conversations with personal and confidential information removed.
