Test the phone menu
before your customers do.
Write the test plan once. Attendant Assurance calls your menu or AI attendant, checks every path, and gives you a signed report, compared with the last version that worked.
Today, most menu changes are tested by whoever has a phone handy. Someone calls in, presses a few keys, and says it looks fine. Then the after-hours route breaks, or option 4 now says “returns” instead of “exchanges,” and nobody finds out until callers do.
Pricing available by quote.
The problems, in the buyer's words.
“We changed one prompt and broke the after-hours route. We found out on Monday.”
“The vendor says the new menu is done. How do we accept it?”
“Our AI receptionist went live. Can someone talk it into reading out its instructions?”
“Change management wants evidence the phone change was tested.”
How it works
Write the test plan once
A test suite holds the cases for one number. Each case is one call with one expected behavior.
Run it
On demand, on a schedule (for example every weekday before the phones open), or from your release process through the API. Cases with a time window wait for it, so after-hours routing is tested after hours.
Read the result
Each case passes, fails, or is degraded, and says exactly why, such as “menu options: missing 'returns' (4).” Every call has its recording and transcript.
Sign it off
A named person accepts the run by typing their name, with a note for any known failure. That run becomes the baseline.
Compare every run after
Every later run shows what is newly failing, what was fixed, and what the attendant now says differently.
Hand it over
Export the signed acceptance report, every call of the run, or the results as CSV. Evidence for change management, the client, or an auditor.
Four kinds of test case.
Answer
What answers, whether the greeting says the right words, and how fast.
Menu path
Listen, press keys, and check the menu offers exactly the options it should, such as “press 2 for billing.” Speaks to menus that understand speech, and enters test account numbers or PINs, stored encrypted.
Goal (AI)
Describe a destination in plain words and an AI finds its own way there, reporting the keys it used and when the route changed.
Conversation (AI)
An AI caller with a persona talks to an AI attendant about a goal, then grades each check you set, with a note.
You audit your team. Now audit your AI attendant.
An AI caller phones your attendant as The Rambler, The Injector, or The Human-or-AI Tester, then grades it against your checks. Does it stay on task? Refuse to read out its instructions? Admit it is automated when asked? Hand off to a person? Every grade comes with the recording and transcript.
Baseline
The Straight Shooter, The First-Timer
Clear and correct when nothing goes wrong.
Real Callers
The Rambler, The Interrupter, The Tangent, The Switchback, The Silent Caller, The Confused Caller
Staying on task through realistic friction.
The Gauntlet
The Injector, The Extractor, The Fabrication Baiter, The Off-Menu Prober, The Human-or-AI Tester, The Escalation Demander
Prompt injection, data fishing, false premises, out-of-scope questions, “are you a robot?”, and demands for a person.
Each call is graded against your checks, with the recording and transcript attached so a person can review any result.
Accepted. Then compared, every run after.
When a run looks right, sign it off with a typed name, recorded with the time and user. It becomes the baseline. Every later run tells you what is newly failing, what was fixed, and what the attendant now says differently.
Part of the release, not an afterthought.
Run a suite every weekday before the phones open, or start it from your release pipeline through the API. Results are emailed only when something fails or changes.
Connect tests to Jira.
With the Jira Cloud integration, a failing case opens a Jira issue with the reason, the test definition, and the call PDF attached. Link a run to a change ticket and it posts its results and sign-off to that ticket, so the evidence lives where the change is tracked.
Features
Test suites with four case types: one plan covers greetings, menu paths, destinations, and AI conversations
Strict menu-options check: a reworded, missing, or extra option fails the case
Signed acceptance and baseline: a named sign-off, and every later run compared with it
Comparison per check and per answer: “newly fails 'offered a time'” and “Saturday hours: 9–1 changed to 9–2”, not just pass and fail
Schedules, time windows, and API trigger: tests run themselves, at the right hours, from the release pipeline
Results emails: hear only when something fails or changes, or after every run
Encrypted test inputs: menus that ask for an account or PIN can be tested with test accounts, kept out of transcripts
Recordings, transcripts, and PDF and CSV exports
Monitor this: turn a passing case into a scheduled Monitor check (with Monitor)
Jira Cloud integration: a failing case opens a Jira issue with the reason, the test definition, and the call PDF attached
Why teams choose Attendant Assurance.
Against calling it and pressing some keys
The same plan every time, a named sign-off, and a comparison that shows what changed.
Against enterprise IVR-testing vendors
A test plan a phone admin writes in an afternoon, without a services engagement.
Against AI voice-agent testing tools
Those test from inside the builder's stack. Attendant Assurance calls the real phone number as a caller, with no access to the agent's code, prompts, or platform needed.
One vendor for testing and watching
A case that passes acceptance can become a Monitor check with one click.
Use cases
Menu rebuild
A suite covering every option, run before go-live, signed off, then run nightly.
Holiday and after-hours routing
Cases with time windows that only call during those hours.
Vendor acceptance
The integrator delivers the menu; the customer runs the suite and signs.
AI receptionist launch
Baseline and Gauntlet personas before launch, and again after every prompt or knowledge change.
Change management
The run linked to the change ticket, with the signed report attached.
Frequently asked questions
How is this different from Monitor?
Monitor watches lines around the clock and alerts when one breaks. Attendant Assurance tests a menu or AI attendant against a test plan when something changes, and produces a signed report. They share the same calling technology, and a case can become a Monitor check.
Do we need access to the phone system or the AI platform?
No. It calls the number like any caller. Nothing to install, and no integration with the phone system or the AI vendor.
Does the AI caller pretend to be a person?
Each case chooses. By default it says it is an automated test call if anyone asks; it can also say so up front, or play the caller to the end.
Who sees recordings and transcripts?
Admins see transcripts and what the attendant said word for word. Other roles see results and the actions each call took.
Can it run as part of our release process?
Yes. Start a suite through the API and poll for the result, or use the Jira Cloud integration: failing cases open issues with the call attached, and a run linked to a change ticket posts its results and sign-off there.
We already use Audit's AI attendant tests.
They keep running in Audit. Each one can be moved into a test suite with one button; its caller, goal, checklist, and settings carry over.
Can we test any attendant?
Your menu or AI attendant. Customers confirm they own or may test the number before a suite can call it.
How do we buy it?
Pricing is available by quote. Contact our team and we will scope a plan around your menus, attendants, and testing volume.