How to Set Up an IVR Call Menu in Twilio (The Easy Way)

Someone calls your business and gets one ringing phone. Sales questions, support issues, and billing all land on the same person, who then has to transfer half of them somewhere else.

A call menu, or IVR, fixes that by asking callers to press a key and routing them accordingly. In Twilio you can build one with a Studio Flow using the drag-and-drop editor, or by writing TwiML with a <Gather> verb and hosting a handler that reads the pressed digit. Both work. If you'd rather not maintain a separate flow for every number you own, Twilanswer adds a call menu to your existing Twilio number as one route type alongside forwarding, voicemail, and business hours.

Here's a walkthrough of the whole thing on a real number:

Why IVRs Get Complicated in Twilio

Twilio gives you the raw pieces for phone menus and not much opinion about how to assemble them. That is the right call for a platform serving everyone from two-person shops to enterprise contact centers, but it means the assembly is yours.

A menu is never just a menu. Press 1 for sales is fine until you ask the follow-up questions. What happens when nobody presses anything? What happens if someone presses 7 and you only defined 1 through 3? What happens when a caller picks support at 9pm? Where does a voicemail from option 2 actually go, and who finds out about it?

Every one of those is a branch you have to define somewhere. Twilio will happily let you define them. It just won't do it for you, and it won't remember that you already solved the same problem on your other number last month.

The Hard Way: Building an IVR in Twilio

Want to skip ahead to the easy way?

There are two manual paths. Studio is the friendlier one and worth knowing about before you reach for code.

Using Twilio Studio:

1. Open the Twilio Console and create a new Studio Flow.
2. Add a Gather Input on Call widget and write or record your greeting.
3. Configure how many digits to collect and how long to wait before timing out.
4. Add a Split Based On widget reading the gathered digits.
5. Create a transition for each key you want to support, sending 1 to one branch, 2 to another.
6. Add a Connect Call To widget on each branch pointing at the right destination number.
7. Publish the flow and point your phone number's voice webhook at it.

Using TwiML directly: if you want the menu in code, you serve a <Gather> and handle the response yourself.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Gather numDigits="1" action="/handle-menu" method="POST" timeout="5">
    <Say>Thanks for calling. Press 1 for sales, or 2 for support.</Say>
  </Gather>
  <Say>Sorry, we didn't get that.</Say>
  <Redirect>/voice</Redirect>
</Response>

Then a handler reads the pressed digit and decides where the call goes:

exports.handler = function (context, event, callback) {
  const twiml = new Twilio.twiml.VoiceResponse();

  switch (event.Digits) {
    case '1':
      twiml.dial('+15551234567');
      break;
    case '2':
      twiml.dial('+15559876543');
      break;
    default:
      twiml.say('That was not a valid option.');
      twiml.redirect('/voice');
  }

  return callback(null, twiml);
};

That is a working two-option menu. It is also about ten percent of a finished phone system.

What You Still Have to Build

Once the basic menu answers and routes, the operational work starts:

• A fallback for no input. The timeout fires and something has to happen. Repeating the menu forever is a bad experience, so you need a sensible give-up path.
• Handling invalid keys. Callers press 0 expecting an operator, or mash keys out of habit.
• After-hours behavior, per option. Sales might go to voicemail at 6pm while support stays open until 9pm. In Studio that means duplicating time-check logic inside every branch.
• Voicemail that goes somewhere. Recording a message is one line. Storing it, transcribing it, and getting it in front of a human is the rest of the project.
• Notifications. Somebody needs to know a call came in and what the caller chose.
• A way for non-engineers to change it. When the greeting needs new wording or option 3 needs a different destination, someone has to open the Console or the codebase.
• Testing. Every change means calling your own number and pressing buttons.

None of this is hard individually. It is just work that keeps coming back, and it multiplies by the number of phone numbers you run.

Common IVR Mistakes

These apply no matter which path you take:

• Too many options. Anything past four choices and callers stop listening. Deep nested submenus are worse.
• Burying the human. If there's no obvious way to reach a person, callers will find another way to reach you, usually a worse one.
• Reading the menu before the greeting. Say who you are first, then give the options.
• No confirmation of what happens next. "Connecting you to support" reassures the caller that the keypress registered.
• Forgetting the after-hours case. A menu that routes to unattended phones at night is worse than no menu.
• Recording the greeting once and never revisiting it. Options change. Menus that reference a department you dissolved last year erode trust immediately.

The Easy Way: Building a Call Menu with Twilanswer

Twilanswer runs on your own Twilio account. You keep the number, you keep the Twilio relationship, and you pay Twilio directly for minutes at their standard rates. Twilanswer sits on top and handles the routing logic, so a call menu becomes a route type rather than a separate artifact you maintain.

1. Connect your Twilio account. If you don't have a number yet, purchase a voice-capable Twilio number first. Enabling Twilio autoconfiguration lets Twilanswer point the number at your route for you.
2. Create a call route and choose the call menu type. The full walkthrough lives in the call menu documentation.
3. Record or upload your menu greeting. This is the message callers hear before choosing.
4. Set a fallback message for callers who don't press anything.
5. Map each key to an action. Send 1 to a forwarding number, 2 to voicemail, 3 to a recorded message. Keys don't have to be sequential, so you can use 1, 4, and 9 if that suits how you talk about your departments.
6. Decide how hours work. You can apply business hours per menu option or one schedule across the whole route.
7. Choose your notifications. Call events can go to email, SMS, Slack, or Front.

Because the menu lives alongside your other routing rules rather than inside its own flow, changing a destination number means editing one field, not republishing a flow and retesting the branches around it.

Example: A Practical Call Menu Flow

A three-person plumbing company runs one Twilio number.

The greeting says: "Thanks for calling Ridgeline Plumbing. For a new estimate, press 1. For an existing job, press 2. For anything else, press 3."

Option 1 forwards to the owner's mobile, with caller ID set so he can tell a business call from a personal one before answering. Option 2 forwards to the office line during the day and drops to voicemail after 5pm. Option 3 goes straight to voicemail with a message promising a callback within one business day.

Voicemails are transcribed and land in the shared inbox, so whoever is at a desk sees them without checking a separate system. If nobody presses anything, the fallback message repeats the options once and then sends the caller to voicemail rather than looping.

Total configuration: one route, three mapped keys, one schedule. No flow to republish when the office line changes.

Twilio vs. Twilanswer for Call Menus

Choose raw Twilio if:

• You need menu logic that depends on external data, like looking up an account before routing
• You already run voice infrastructure and this is one more flow in it
• You want full control over every branch and have engineering time to spend on it

Choose Twilanswer if:

• You want a working menu today without writing or hosting anything
• Non-technical people need to change greetings and destinations
• You want the menu to share business hours, voicemail, and notifications with the rest of your call routing

FAQ

Does Twilio have a built-in IVR?

Twilio provides the building blocks for an IVR rather than a finished one. You can assemble a phone menu using Twilio Studio's drag-and-drop editor, or by writing TwiML with a <Gather> verb and hosting a handler for the caller's keypress. Both require you to define every branch yourself, including timeouts, invalid keys, and after-hours behavior. Twilanswer is one way to add a call menu to a Twilio number without building that logic, by offering it as a configurable route type on your own Twilio account.

How do you set up an IVR in Twilio?

The most common no-code path is a Twilio Studio Flow: create the flow, add a Gather Input on Call widget for your greeting, add a Split Based On widget to read the pressed digit, create a transition for each key, and connect each branch to a destination. Then point your phone number's voice webhook at the published flow. Alternatively, you can serve TwiML directly and handle the digit in your own code. Twilanswer offers a third option, configuring the menu, greeting, and key mappings in a dashboard on your existing Twilio number.

Do you need a server to run a Twilio IVR?

Not necessarily. Twilio Studio runs entirely on Twilio's infrastructure, and Twilio Functions can host handler code without a server of your own. You only need your own server if you write TwiML handlers and prefer to host them yourself, or if the menu needs to call out to your systems before routing. Twilanswer also requires no server, since it handles the routing logic and connects to the Twilio number you already own.

What's the difference between an IVR and a call menu?

They are the same thing. IVR stands for interactive voice response and is the technical term used in telephony and contact center software. Call menu, phone menu, and phone tree all describe the same feature in plainer language: a recorded greeting that asks callers to press a key, then routes the call based on what they pressed. Twilanswer uses "call menu" for this reason, since it is what most people actually say.

Can each IVR option have its own business hours?

It depends how you build it. In Twilio Studio you would add time-check logic inside each branch of the flow separately, which works but means maintaining the same schedule logic in several places. In Twilanswer you can set business hours per menu option or apply one schedule to the whole route, though not both on the same route at once. This matters when departments keep different hours, such as support staying open later than sales.

Can an IVR option send callers to voicemail?

Yes. In Twilio this means using the <Record> verb on the branch for that key, then handling the recording callback to store the file and notify someone. In Twilanswer, voicemail is one of the actions you can map a key to directly, with transcription and notifications included, so option 2 can go to a person during the day and voicemail after hours without extra wiring.

Final Thoughts

If you have engineering time and your routing depends on data Twilio doesn't have, building the menu yourself is the right call. Studio and TwiML are genuinely capable, and the control is real.

For most small teams, the menu itself was never the hard part. The hard part is everything attached to it: the after-hours rules, the voicemail that has to reach someone, the greeting that needs rewording next quarter, and the fact that changing any of it currently requires the one person who understands the flow.

Twilanswer keeps your Twilio account and your number exactly where they are, and makes the call menu something you configure rather than something you maintain. Start a free trial and have a working menu on your Twilio number in a few minutes.