IVR Script Examples You Can Copy, and Where They Break

An IVR script is the recorded language a caller hears when they reach an automated phone menu: the greeting, the options, the hold messages, and the closed or after-hours message.

For what callers can complete without an agent, see self service IVR.

If you are rewriting the menu itself, the IVR best practices list covers the 15 rules callers actually notice.

Below are ten scripts covering the situations that account for most menu traffic, written to be copied and edited, plus two places where the language is set by your jurisdiction rather than by us. After them is the more useful part, which is where each one fails and what the failure costs you.

Every example uses square brackets for the details you replace.

TL;DR

• Keep the main menu to four options or fewer, and put the most-used option first.
• State the option before the key: "for billing, press 2", not "press 2 for billing".
• Give the hours and the website in the closed message, and say when someone will call back.
• Never promise a hold time you cannot keep, and never claim a call is important to you.
• Write the reprompt. Two attempts on a no-input, then a person, never a third loop.
• Menus break on anything the caller cannot map to an option, which is most of the calls that matter.
• A conversational agent removes the mapping problem entirely, because the caller just says what they need.

Main menu greeting

The workhorse. Short, four options, most common first.

• "Thank you for calling [company]. To help us direct your call, please choose from the following options."
• "For [most common reason], press 1."
• "For [second reason], press 2."
• "For [third reason], press 3."
• "To speak with someone, press 0, or stay on the line."

Three rules are doing the work here. The option comes before the key press, because callers cannot hold a number in mind while waiting to hear what it does. There are four choices, because recall collapses beyond that. And there is a stated route to a person, which raises satisfaction without collapsing menu usage as much as teams fear.

Business hours and location

The single most requested piece of information in most menus, and the cheapest to answer before the menu.

• "Thank you for calling [company]. Our hours are [days] from [time] to [time], and we are located at [address]."
• "To continue, please choose from the following options."

Putting hours and address in front of the menu rather than behind an option removes a whole class of call. If a meaningful share of your callers only ever want this, they should never have to press anything.

After-hours and closed message

This is the message that loses business, so it is worth more attention than it usually gets.

• "Thank you for calling [company]. Our office is currently closed. Our hours are [days] from [time] to [time]."
• "You can [book an appointment / check your order / find answers] any time at [website]."
• "If this is urgent, [specific instruction: press 1 for the on-call line / call [number]]."
• "Otherwise, please leave your name, number and a short message, and we will call you back [specific commitment, for example: before noon on the next business day]."

Two details separate this from the usual version. The callback commitment is specific rather than "as soon as possible", which is not a commitment. And the urgent path is a real path, because the caller with an emergency will not leave a voicemail and wait.

Hold and queue messages

Say something true, then say something useful.

• "All of our team are currently helping other callers. You are number [position] in the queue."
• "If you would prefer not to wait, press 1 and we will call you back without losing your place."
• "You can also [self-service action] at [website]."

Queue position and a callback offer both measurably help. What does not help is telling people their call is important while making them wait, which is the line callers most often quote back to support teams as the moment they got annoyed.

Estimated wait times are useful only if they are accurate. An underestimate that expires produces more complaints than saying nothing at all.

Call recording and consent notice

Where required, it goes first, before anything else is collected.

Placement is the part that matters, and it is the part that stays the same everywhere. The notice plays before any substantive conversation and before any information is collected, not after the caller has started explaining the problem.

The wording itself, and whether notice alone is enough or every party has to consent, is set by the jurisdictions you take calls in. Some require all-party consent rather than notice, and the position moves. If you take calls nationally, the practical build is to the strictest standard that applies to you rather than branching by area code, since area code does not tell you where the caller is.

This article does not supply that wording. Get the notice, its placement and the current position for your states from your own counsel rather than copying a template.

Appointment and callback confirmation

For outbound reminder calls and confirmations.

• "This is a reminder from [company] about your appointment on [day] at [time]."
• "To confirm, press 1. To reschedule, press 2. To hear this again, press 9."

Keep it to two real options. Reminder calls with five options get hung up on, because the recipient did not choose to be on this call and their patience budget is small.

Language selection

Goes before the greeting, and each option is spoken in its own language. A caller who does not speak the menu language cannot find the option that offers their own.

• "For English, press 1."
• "Para espanol, oprima dos."
• "[Additional language, spoken in that language], press [n]."

Two or three languages at most. Past that, route by the number dialled or by the account record instead of asking.

No input and no match

The reprompt is the script most teams never write, and it is the one that decides whether a confused caller reaches a person or a dial tone.

First attempt, after silence or an unrecognised key:

• "Sorry, I did not catch that. [Shortest form of the options: For billing, press 2. For orders, press 3.]"

Second attempt:

• "I still did not get a response. Let me put you through to someone who can help."
• "[Transfer to the default queue. Do not repeat the menu a third time.]"

Two attempts, then a person. A menu that loops is the single behaviour callers describe as being trapped, and it produces abandonment that your routing data will record as a completed call.

Voicemail greeting

For a direct line or a queue that overflows to message.

• "You have reached [name or team] at [company]. I am not available to take your call right now."
• "Please leave your name, your number, and a short message, and I will call you back [specific commitment, for example: before noon on the next business day]."
• "If you need someone sooner, [specific instruction: call [number] / press 0 to return to the main menu]."

The commitment is the part worth arguing about internally. If the team cannot hold it, change the commitment rather than the script.

Holiday and emergency closure

Two different messages that teams often write as one.

Planned holiday closure:

• "Thank you for calling [company]. We are closed for [holiday] and will reopen on [day] at [time]."
• "You can [self-service action] any time at [website]."
• "If this is urgent, [specific instruction: press 1 for the on-call line / call [number]]."

Unplanned or emergency closure:

• "Thank you for calling [company]. Our [location] office is closed today because of [reason]."
• "[What is still running: online ordering is unaffected / claims can still be filed at [website]]."
• "If this is an emergency, [specific instruction]."
• "We are posting updates at [website] and expect to reopen [time frame, or: we will confirm here tomorrow morning]."

The unplanned version needs the "what still works" line. Callers are trying to find out whether their own thing is affected, not whether your office is open.

Transfer announcement

Short, and it earns its place by saving the caller from repeating themselves.

Cold transfer:

• "I am putting you through to [team] now. Please hold."

Warm transfer, where the receiving person gets context:

• "I am putting you through to [team] now. I am passing on [specific context, for example: your order number and the delivery date], so you will not need to repeat it."

Say what you are passing on. A caller who hears it named will not start over, which is where most of the handle-time saving in a warm transfer actually comes from.

AI agent disclosure

If an AI agent answers the call or places it, say so in the first line, before anything is collected.

Two details carry across every version of this. The disclosure goes first, not after the caller has explained their problem. And the route to a person is stated in the same breath, because a caller who has just been told they are talking to a machine is deciding right then whether to stay on the line.

What the line needs to carry is the agent's name, that it is automated, who it is calling on behalf of, and the scope of what it can actually help with. The wording sits across federal and state rules on AI-generated voice, and those are moving, so this article does not supply the line. Get it from your own counsel before the agent takes or places a call.

Where these scripts break

Every script above works when the caller's need matches an option. The problems start when it does not, which is more often than menu analytics suggest.

Failure	What actually happens
The need has no option	The caller presses whatever seems closest, reaches the wrong team, and gets transferred. Your data records a successful routing
The caller has two issues	A menu can only route one. The second issue becomes a second call
Recall fails	By option four the caller has forgotten option one, so they press 0 or press at random
Nesting	Sub-menus multiply the recall problem. Depth past two levels is where abandonment climbs
Emotion	An upset or urgent caller will not navigate a menu. They press 0 repeatedly or hang up
Accessibility	Speech, hearing and dexterity differences all make key-press navigation harder, and older phone systems handle them badly

The expensive pattern in that table is the first one, because it is invisible. A caller who presses 2 and reaches the wrong department is recorded as routed, and the cost appears later as a transfer, a longer handle time, and a customer who explains their problem twice.

The structural point: a menu asks the caller to translate their problem into your org chart. Most callers cannot, because they do not know how your company is arranged, and the ones with unusual problems are the least able to.

How to test an IVR script before it goes live

Read it aloud, then break it deliberately.

1. Time the main menu. Past about 25 seconds, callers stop listening.
2. Count the options. More than four means the menu is doing the routing your routing rules should do.
3. Call it with a problem that is not on the list, and see where you end up.
4. Call it as an angry customer, and see how long it takes to reach a person.
5. Call it after hours, and check whether the message tells you anything actionable.
6. Check what happens when nobody presses anything. Silence should route to the default queue on the second attempt, using the reprompt script above, not repeat forever.
7. Pull the data on option usage. If one option takes most of the traffic, it should be first or it should not be a menu at all.

The alternative to writing better menus

Removing the menu.

A traditional interactive voice response system, the automated phone menu that routes callers by key press, exists because a computer could handle key presses long before it could handle speech. That constraint is gone, and the scripts above are all workarounds for it: option-before-key, four items maximum, no nesting. They are rules for compensating for a limitation.

Retell is a Customer Experience AI Platform for Autonomous Customer Relations, and the practical difference is that the caller says what they need in their own words instead of mapping it to a number.

This is a pillar 2 argument: conversation handling beyond just the voice. A menu runs every caller down the same fixed path because that is all a key press can express. Unlike platforms that send every turn through the same general-purpose model, the vCX stack routes each step to the best model for performance, speed, and cost, so the handling can change as the call does.

The evidence for that is a benchmark rather than a demo. In Cekura's 414-call benchmark on a regulated Medicare workflow, Retell passed 22 of 23 scenarios on all three attempts, leading six platforms with 95.7% workflow accuracy and 95.7% strict end-to-end reliability. The scenarios were the ones a menu has no answer for: interrupted disclosures, consent refusal, changing intent, corrected information, prohibited advice, sensitive data, and failed-transfer recovery.

The agent answers routine requests from a knowledge base, books appointments on the call, and transfers to the right person with the context already gathered when the call needs a human.

That changes the failure modes in the table above rather than mitigating them. A caller with two issues raises both. A caller with an unusual problem describes it. An upset caller says they want a person and gets one.

It does not remove every constraint. You still need clear handoff rules, and you still need a route to a person that works first time, because an agent that cannot resolve something and will not transfer is the same trap as a menu with no zero option. You also still need the disclosure script above.

One narrower case where key-press menus still make sense: outbound confirmations, where the recipient is answering a single yes-or-no question. If you also need to call through other companies' menus, that is the reverse problem and it is handled separately.

Frequently asked questions

What is an IVR script?

The written language behind an automated phone menu: the greeting, the options, hold and queue messages, and the closed or after-hours message. It is recorded or synthesized and played to callers before or instead of reaching a person.

How many options should an IVR menu have?

Four or fewer at the top level, with the most-used option first. Beyond that, callers stop being able to hold the list in mind and start pressing at random or dialling zero.

Should you say the option or the number first?

The option first. "For billing, press 2" works because the caller knows whether to listen for the number. "Press 2 for billing" makes them hold a number in mind before knowing if they need it.

Should an IVR offer a route to a human?

Yes, and say so. Hiding the path to an agent raises menu completion in the data and lowers satisfaction, and callers who cannot find it press zero repeatedly or abandon, neither of which shows up as a routing failure.

What should an after-hours message say?

Your hours, one self-service action the caller can take right now, a real path for urgent cases, and a specific callback commitment with a time attached rather than "as soon as possible".

What happens if a caller presses nothing?

Reprompt once with the shortest form of the options, then route to a person on the second failure. A menu that repeats itself a third time reads to the caller as being trapped, and the abandonment it causes is recorded as a completed call.

Do I need to say a call is recorded?

Where recording is in use, yes, and placement matters as much as wording: the notice goes before any substantive conversation or data collection. Some states require all-party consent rather than notice, so confirm the current position for the states you take calls from with counsel.

Do I still need an IVR script with an AI voice agent?

You need the content, not the menu. The greeting, hours, escalation rules, disclosure and after-hours handling all still have to be decided and written down. What goes away is the requirement to compress them into numbered options.

Run the same test against an agent

Before you rewrite another menu, run the test in the section above against an agent instead. Put one on your main number for a week alongside the existing menu, call it with the problem that is not on the list, and compare where you end up. Point one at your main number.