Skip to content
Operations

IVR menus

Keypad phone menus for Telnyx calls, with an offline simulator to check the routing first.

IVR menus are keypad phone trees made of menu, message, voicemail, transfer and hangup nodes, linked by keypad, no-match and timeout actions. A simulator walks a menu offline for any key presses and returns the path taken, and active menus answer Telnyx calls with TeXML, including the calls a campaign's IVR step places.

What you get
  • ·Five node kinds — menu, message, voicemail, transfer, hangup
  • ·Keypad, no-match and timeout actions, matched in a fixed order
  • ·Offline simulator returns the node-by-node path for any key presses
  • ·Live runtime on Telnyx TeXML; draft and paused menus refuse calls
  • ·Operator text and recording links XML-escaped in every response
  • ·Outbound menu calls as a campaign step, gated on DNC and quiet hours
IVR · “Main reception” · ACTIVE
welcomemenu node · “Press 1 for sales, 2 for support”
1salestransfer to +1-415-…
2support_voicemailplay prompt + record
no_matchre-prompt (×3)then fall back
Simulator trace · last run
welcome → digit “1” → sales (transfer) → end_call
The problem

Why phone menus break after they go live

A phone menu is routing logic nobody can read by looking at it. A key mapped to the wrong step, a menu with no fallback, or a transfer to a number the business no longer holds only shows up when a caller reaches it. Autocloz stores each menu as data — nodes, keypad actions and an entry point — so any sequence of key presses can be walked before a live call arrives.

  • A caller presses a key nobody mapped and the call simply ends
  • No one can say which recording plays at which step without ringing the line
5
node kinds
menu · message · voicemail · transfer · hangup
5
action types
dtmf_route · goto_node · play_audio · transfer_to_did · end_call
0
carrier-minutes burned
simulator is offline
How it works

The detail.

Simulate before a caller hears it

The simulator takes a list of key presses and walks the menu from its entry node, using the same matching order as the live runtime: an exact key first, then the no-match action, then the timeout action. It returns every node visited and the reason the walk stopped. It is a separate code path from the TeXML runtime, so it proves the routing, not audio playback, transfers or carrier behaviour.

Status filter prevents accidents

Only a menu that is active and not archived answers a live call. A draft or paused menu replies 'Service unavailable' and hangs up, and every carrier request re-reads the status, so pausing takes effect on the next call without rebuilding anything. Status is changed through the API today.

Action types that map to real behaviour

dtmf_route and goto_node move the call to another node. play_audio plays a recording from your workspace and hangs up. transfer_to_did dials a number held in the workspace's own inventory. end_call hangs up. An action can only move a call to a node in the same menu, and a recording or number from another workspace is never used.

Example scenarios

How a team would use this.

Inbound line · small B2B team

A reception menu for sales and support

An admin creates Main reception in Call → IVR, then through the API adds a menu node — press 1 for sales, 2 for support — with a transfer action on each key to a number in the workspace's inventory, a no-match action for any other key, and sets it as the entry node. Before activating it, the admin simulates 1, 2 and 9 separately and reads the action each press triggers.

Every key press is checked offline before the menu goes active
Outbound campaign · Telnyx call sender

A reminder call with a keypad choice

An operations lead builds an active menu where 1 plays a recorded message and 2 transfers to an office number in the workspace's inventory, then adds a Call (IVR menu) step to a campaign. Before each dial the step checks the call DNC list, confirms the menu is active with an entry node, and defers during quiet hours. The key a lead pressed is not written back to the lead.

Leads answer to a menu, and a broken menu fails the step with a reason
FAQ

Specific to this feature.

Can I build the menu by dragging nodes in the app?

+

Not yet. The Call → IVR page creates, lists and archives menus. Nodes, keypad actions, the entry node and the active or paused status are set through the REST API, and the page notes that a drag-and-drop editor is still in development.

Does the simulator place a phone call?

+

No. You send a list of key presses and it walks the menu from its entry node, returning each node visited, the action chosen and why the walk stopped. It runs on draft menus, stops after 50 steps to catch loops, and does not play audio or dial transfers.

Which carriers can run a menu?

+

Telnyx only. The runtime answers in Telnyx TeXML, and a campaign IVR step refuses to dial from a FreJun or DIDLogic call sender and says why. A Telnyx sender also needs a TeXML Application ID in its credentials, and the step fails with that instruction when it is missing.

What happens when a caller presses the wrong key or nothing?

+

A menu waits a fixed five seconds. The node's no-match action is tried first and its timeout action second; with neither, the call ends. The IVR timeout and retry fields in the voice ops settings are stored but not yet applied to menus, and a voicemail node plays its message and hangs up rather than recording the caller.

Pairs well with