A caller should never have to decode your org chart just to reach the right person. Yet plenty of phone menus still make people choose between internal department names, remember a long string of numbers, and listen to a seasonal message that expired months ago.
IVR prompts and phone menu voiceover are not merely recordings. They are the spoken surface of a routing system. The routing has to make sense first; then the audio needs a concise script, deliberate pronunciation, and an unambiguous handoff to whoever manages the phone platform. Vois fits the production portion of that work: it lets a team create, review, revise, and export the approved prompt set locally without claiming to deploy or operate the phone system.
Start with the caller's path, not the welcome line
An interactive voice response menu is a set of choices that moves a caller toward a job: checking an order, reporting an issue, paying an invoice, changing an appointment, or reaching a person. Make a simple call-flow map before you write any narration.
For each entry point, record four things:
| Prompt ID | Caller intent | Available action | Next destination |
|---|---|---|---|
main-001 |
Needs help with an order | Press 1 for order help | Order-support queue |
main-002 |
Wants an appointment | Press 2 for appointments | Scheduling menu |
main-003 |
Needs an operator | Press 0 for an operator | Reception or overflow queue |
afterhours-001 |
Calls outside staffed hours | Hear hours and an urgent route | After-hours route |
Use the words callers use, not the names inside the business. "Billing question" is usually clearer than a department acronym. If two choices lead to the same team, merge them. If one route has several unrelated tasks, split it before recording the prompt.
Ask the phone-system owner what the platform supports before finalizing the map: keypad input, spoken input, interruption while a prompt plays, repeat options, an operator route, and the fallback behavior after no selection. The W3C VoiceXML recommendation is a useful technical reference for voice interaction systems, but your installed platform defines the behavior you must test.
Write short phone menu prompts that callers can retain
The best IVR script has one job per sentence. Give the action before the option, use a concrete destination, and leave room for the caller to respond.
A main menu can follow this pattern:
Thank you for calling Northwind Supply. For order help, press 1. For appointments, press 2. For billing, press 3. To speak with an operator, press 0.
That is much easier to follow than a greeting that begins with a company story, a legal notice, and five detailed explanations. Save information such as holiday hours, a temporary outage, or a deadline for a separate prompt. It should be possible to replace that message without rebuilding the main menu.
A useful script pass asks:
- Does each option describe a caller goal rather than an internal team?
- Does each number appear once and match the configured route?
- Can someone understand the option without seeing a screen?
- Is there a clear recovery path for a wrong choice or no choice?
- Has a real person read the script aloud at phone-call pace?
Do not write punctuation as a substitute for a decision about pacing. Break long ideas into sentences. If a caller must remember a number, a date, or a reference code, say it in the way you would explain it aloud to one person.
Build a pronunciation record before generation
Phone prompts tend to contain the words that text-to-speech gets least context for: business names, product names, local place names, abbreviations, team initials, and a contact person's surname. Treat those words as a small editorial list, not a surprise found after deployment.
Create a pronunciation record with the written term, the approved spoken form, a plain-language note, and the person who confirmed it. For example, a brand may be written as VoiS but spoken as voyce, while an initialism may need to be read letter by letter. Put the approved spoken form in the script where it helps, then add it to Vois's pronunciation dictionary so the same term is handled consistently in later prompts.
Listen to names in the exact sentence where callers will hear them. A word can sound right in a test phrase and awkward after a menu number or before a postcode. Do not assume a special markup language will fix pronunciation later. The reviewable script is the source of truth.
Generate a set that sounds like one system
A phone menu should feel continuous even when its prompts were created on different days. Use one approved voice for a consistent menu family unless the call flow has a clear reason for a different speaker, such as a recorded executive message that has been separately approved.
Vois has 100+ voices for testing. Generate one representative main-menu line, one short error or fallback line, and one longer informational line before committing to a voice. Listen through a normal phone call if you can, not just speakers or studio headphones. The useful question is simple: are the words easy to understand when the delivery path is narrow and familiar?
Keep each prompt as its own project item or source script. Give it an ID that matches the prompt inventory, such as main-001-order-help or hold-2026-07-hours. That connection avoids a common failure mode: a perfectly named WAV file in one folder and a differently worded prompt in the phone system.
If your organization wants to clone a particular approved speaker, use a clear 10 to 15 second sample and obtain that person's permission first. For ordinary menus, a library voice is often easier to keep consistent across routine revisions.
Match new prompts to the existing phone experience
Level matching is less about making an audio meter look tidy and more about preventing a caller from reaching for the volume control when the menu changes. Gather a small reference set from the current phone system: a main greeting, a menu choice, a queue message, and an after-hours prompt.
Then use the same approved project and mastering approach across the new prompt set. Compare new and existing clips in their intended call flow. Listen for abrupt changes in apparent level, unusually sharp consonants, clipped endings, and a sudden shift in voice character. If one prompt is uncomfortable or hard to understand, revise the script or generation before asking the telephony team to install it.
Do not try to make every prompt identical by eye. A short error message and a longer information message naturally have different rhythm. What matters is that neither calls attention to itself as a separate recording.
Plan hold-message updates as replaceable segments
Hold messaging changes for reasons that have nothing to do with the main IVR: a holiday, a service disruption, a campaign, a temporary office closure, or a new support channel. Put each temporary message in its own script and give it both a start condition and a removal condition.
Your prompt inventory can be a plain table with these fields:
| Field | Why it matters |
|---|---|
| Prompt ID and route | Connects spoken words to the configured call flow |
| Approved script and version | Shows exactly what was reviewed |
| Owner and reviewer | Makes an update accountable |
| Start and review dates | Stops an expired message from lingering |
| Source export and delivery spec | Lets the next update begin from the right file |
| Live verification note | Records that someone tested the deployed route |
When the message changes, update the script, regenerate the individual clip, review it, and hand it to the phone-system owner. Do not bury the new text inside a full main-menu recording unless the main menu itself changed.
Hand off audio in the format the phone platform requests
There is no universal IVR export setting. One platform may accept a WAV file with a prescribed mono PCM configuration. Another may accept a tagged MP3, require an audio URL, impose a file-size limit, or convert the file after upload. For example, Microsoft documents a specific mono WAV configuration for one of its call-automation services, while the ITU-T G.711 recommendation appears in many telephony specifications. Neither is a substitute for the specification of the platform you actually operate.
Before delivery, ask the phone or contact-center administrator for:
- Accepted container and codec.
- Sample rate, bit depth, and channel layout.
- File-size limit and maximum prompt duration.
- File-naming rule and required metadata.
- Upload location, hosting requirement, and cache behavior.
- The test number or route where the prompt will be verified.
Vois can generate and export the source audio locally. Vois does not deploy prompts to phone systems. The administrator or separate integration process owns upload, route assignment, scheduling, and release verification. Treat the handoff like a small production release: include the approved script, prompt ID, version, source file, and the requested delivery file.
Human review belongs at the end of the line
The final review happens after the prompt is configured, not when the file lands in a folder. Dial the relevant number from a normal caller context and test every advertised route. Try an expected choice, an invalid choice, no input, a repeat request if the system offers one, and the operator or escalation path.
Have the business owner confirm the words and the telephony owner confirm the routing. If the menu serves more than one language, use reviewers who know the language and the customer-facing terminology for each version. Keep a copy of the approved script and the live test result with the prompt record.
Once that routine is in place, updating a phone menu stops being a scavenger hunt. It becomes a small, reviewable change with a caller-friendly result. Start by mapping one busy menu, use Vois to generate a reviewed prompt set, and let the phone-system team own the final deployment. Get started with Vois and keep recurring terms consistent with the pronunciation dictionary.
Sources
- W3C Voice Extensible Markup Language (VoiceXML) 2.1
- ITU-T Recommendation G.711
- Microsoft Learn: Customize voice prompts with Play action
The Vois Team