Ready-to-use test questions, permission and multi-agent checks, and quality and business outcome criteria.
A successful bot demonstration does not yet answer whether it can handle real enquiries. In a demo, the customer states the task clearly, every connection works and an employee is ready to receive the request. Acceptance testing checks both the normal conversation and situations where that sequence breaks down.
Below is a practical testing procedure for a company in Kazakhstan. It does not depend on any particular service’s promises: the criteria are defined by your bot’s task, information sources and staff workflows.
Agree exactly what you are approving
Describe the bot's responsibilities before testing. What information does it collect, what does it tell the customer, where does it send the result, and which actions does it perform independently? Separate preparing a request from actually submitting it. If a record is to be written to a working system, the confirmation to the customer must reflect the verified outcome of that write.
Name the company's acceptance owner and the person who will handle requests after launch. Agree on a test destination: a separate list, labelled records or another planned method. Use prepared test data that staff can distinguish from genuine requests. Do not send arbitrary test requests into the live queue without notifying its owner.
Create a record for each test
Write down the conditions for passing in advance. “The answer sounds fine” is too vague: it does not establish whether the selected product was retained or the manager received the corrected contact details. Fill in the same template for every scenario:
- Scenario name and the customer’s task.
- Initial state: a new conversation, a continuation, or a request already submitted.
- The sequence of customer messages and actions.
- An acceptable bot response and the data that must be preserved.
- The expected result for the employee or in the working system.
- Actual result and evidence: a record, message, or screenshot.
- Review status, the issue found and the person responsible for fixing it.
Save the cards alongside the agreed scenario version. After revisions, you can use them to repeat the checks and compare results.
Walk through one request from start to finish
Below is a completed training example for a hypothetical repair workshop. It is not a GIFS project test result. In the example, the bot collects diagnostic requests; the device model and problem description are required, while a photo is optional. An employee sets the price and visit date. Requests go into a separate test queue.
- Card T-01. Initial state: a new conversation, scenario version “Diagnostics v2,” and an empty test queue.
- Customer messages: “The А-10 device will not turn on” → “Correction: model А-12” → “I do not have a photo right now” → “Pass this to a technician.” These model names are fictitious.
- Expected record: one request; current model А-12; issue “does not turn on”; no photo attached; price and visit date not set. The original model must not remain in the current-model field.
- Expected response after the record is confirmed: “The diagnostic request has been passed to a member of staff. Model А-12, the device will not turn on. The cost and visit time have not yet been agreed.” If the record is not confirmed, this response is inappropriate.
- Employee check: open the test queue, find the request, verify the fields and save its identifier in card T-01. In this training scenario, pressing “Pass to the technician” again should leave only one request.
Example result entry: “Not accepted: the bot confirmed А-12, but А-10 was saved in the queue; evidence: screenshot of record T-01.” The fix must address transmission of the current value, not just the response text. After fixing it, repeat the entire conversation and attach the new record. Then separately test declining an optional photo and a case where the system did not confirm saving.
Test errors and repeated actions
Create separate cases for an unavailable connection, an interrupted conversation, and a repeated submission. If the bot creates records, define the expected behavior for a repeated click in advance—for example, showing the status of a request already submitted. Then check what actually appeared at the destination. The response text alone does not confirm that there are no extra records.
Review the case where a record exists but the customer received no confirmation. The employee should know how to check that request. Agree on an honest connection-error message, an available way to continue and the responsible person's actions. Run these checks in a prepared environment; there is no need to disable the company's live services for an experiment. Agree with the developer on how to reproduce the failure.
Test the boundaries of answers
Prepare questions that the agreed materials do not answer: an unknown price, a missing specification, or a request to confirm an unverified deadline. Ask them in several everyday phrasings. The expected result is the planned clarification, an explanation that information is unavailable, or a handoff to an employee. An invented condition cannot count as a successful answer simply because it sounds confident.
Include a request to change data already collected, a topic change, and an attempt to order something the company does not offer. If the bot uses AI, assess meaning and adherence to boundaries rather than an exact match for every phrase. One successful attempt shows the outcome of a particular conversation; it does not replace a set of test cases. The list of sources and permitted actions must be accessible to those accepting the work.
Test the handover to a person as a separate scenario
Test a direct request to speak to an employee at both the beginning and middle of a conversation. Make sure the request actually reaches the responsible person with the necessary details and that the customer understands what happens next. If that person is unavailable, use the agreed wording describing the actual handling process.
Ask an employee to continue one test conversation. Can they respond without collecting all the information again? Is it clear which details the customer provided and which the bot suggested? Also check what happens when a person ends the conversation: the bot's subsequent behavior must follow the agreed scenario and avoid contradictory messages. Acceptance depends on the whole chain working, including the team's actions.
Use a set of test questions with expected outcomes
Below is an acceptance template, not test results for a particular bot. Insert your own service and approved materials. For each check, specify the user role, authorised source and expected action in advance.
- Routine question: “What materials are needed for a quote?” Expected: the complete list from the current instructions, with no added conditions.
- Alternative wording: “What do you need from me for a quote?” Expected: the same meaning, even if the answer is worded differently.
- Missing condition: “How much does it cost?” Expected: clarify the required option or hand off to an employee; do not insert an arbitrary price.
- The source has no answer: “Will you definitely finish by Friday?” Expected: no promise and a clear next step to reach the responsible person.
- Two documents contradict each other. Expected: apply the source-selection rule agreed in advance; if no such rule exists, refer the question to the information owner.
- The customer corrected the request halfway through the dialogue. Expected: both the response and the employee’s final card reflect the latest clarification.
- The user requests information from a restricted section. Expected: the system neither retrieves nor discloses content unavailable to that role.
- The service is unavailable or the outcome of an action is unknown. Expected: an honest request status and a manual fallback; a “done” message without a confirmed result is unacceptable.
If Russian and Kazakh have been agreed, repeat significant cases in both languages. Check that terms, numbers and the next step remain intact; identical sentence length is not a quality criterion. Also save new real-world wording that caused errors and add it to subsequent tests.
If there are several agents, test the boundaries between them
For the chain “customer agent → internal agent → employee,” create one test task and follow it through to the end. Splitting roles alone does not confirm that the system restricts access or passes context correctly.
- The internal agent receives only the information needed for this task, rather than the entire conversation archive.
- The customer response contains no internal comments, confidential terms or data from another enquiry.
- Handover preserves the request identifier and latest clarification; a retry does not create a new independent task without reason.
- A responsible person is assigned to an unconfirmed action. If one participant is unavailable, the task does not disappear or enter a loop.
Access permissions are checked in the connected systems, not just through prohibitions in the model’s instructions. The principle of least privilege and separate confirmation for consequential actions is described in OWASP’s recommendations on excessive agent autonomy. This is a basis for review, not a security certification for the finished solution.
Measure response quality and process impact separately
In the acceptance log, separate correct answers, correct actions and employee time. For each group of test cases, calculate the acceptance rate: the number of cases that passed divided by the number tested in that group. Record both numbers, source versions and the review date; a single overall percentage can hide an error in a rare but important action.
Record invented conditions, disclosure of restricted information, lost requests, and unverified completion separately. A large number of successful simple answers cannot compensate for them. Acceptable criteria for other errors are agreed before launch based on the task.
To assess business optimization, measure the path to an accepted result: processing, review, corrections, and manual handoffs. Add the actual costs of services and support. Comparing tasks of different complexity will not reveal the agent's own contribution. The process for choosing a workflow and pilot is covered in the AI implementation guide.
Record the launch decision
After corrections, repeat the affected checks and the complete journey of one enquiry. Separately note cases you could not reproduce and remaining limitations. Errors that lose enquiries, send incorrect data or give customers invented terms must be resolved before the relevant scenario goes live.
In the final document, record the accepted version, scenarios tested, source owner, person responsible for inquiries, and a way to report problems. Agree on which results the team will review after launch. Acceptance confirms the scope that was checked; subsequent scenario changes require testing the affected actions.
If you are still choosing a solution, start with a comparison of button-based bots and AI. On the page GIFS AI agents you can discuss the project: send the bot's purpose, the channel used, and a few test conversations without customer data.