Resources / Acceptance testing

Build a repeatable set of public-information test questions

Create a stable baseline for checking office answers after changes.

01

The operational decision

Create a stable baseline for checking office answers after changes. Testing needs an expected result before the call begins. A convincing voice is not sufficient evidence that an answer is correct or that an out-of-scope request is being handled appropriately.

02

Prepare the workflow

Choose questions covering hours, entrance, public services and contact routes; write the expected factual answer beside each question.

03

Example wording for approval

“For this fictional test, ask where the visitor entrance is and which public hours apply on Tuesday. The expected answer comes from the approved office sheet.”

04

Worked example

Create a fictional set containing Tuesday hours, holiday hours, parking entrance, public phone number and an unlisted facility question. Beside each, write the exact facts that must appear and the claims that must not. After changing the greeting, rerun all five: a conversational improvement should not break address accuracy. Include the unlisted question because refusing to invent information is part of the baseline. Store test outcomes by fact and script version rather than giving the entire batch one informal thumbs-up.

05

Handoff record

Record these task-specific fields: test identifier, public fact, expected answer, reviewer.

06

Acceptance check

Run the same questions after a script update. Any changed fact needs an explanation; a more fluent answer is not enough to mark the test passed.

Front-desk time calculator ↗

Try Ava with your business’s public information ↗

Related guides

Your workflow, first

Let’s map your first week.

Bring the calls you want covered. We’ll agree the script, handoff and limits.

Start a pilot