The VICIdial AMD Call Menu Setting: Sending Machines to a Menu

A hang-up is not always the right answer for a detected machine. Sometimes you want to drop the call into a small menu that can play a message, offer a callback option, or ask the lead to press a key. The AMD Call Menu setting is where you tell VICIdial which menu to use. Like its sibling fields, it only does anything once another setting routes calls toward a menu.

What this setting controls

AMD Call Menu specifies which call menu (Call menu) will be used when CPD AMD Action has CALLMENU selected. A call menu is the IVR-style building block in VICIdial that plays audio and reacts to keypresses or timeouts. This field simply binds your detection routing to one of those menus.

It applies when you run call progress detection (CPD (call progress detection)) and have picked CALLMENU as your routing action. At that point, instead of being dispositioned or sent to a single recorded prompt, a detected answering machine is handed to the menu you named here.

When detected calls reach the menu

Two settings can send a call to your chosen menu. CPD AMD Action set to CALLMENU sends confirmed machines there. CPD Unknown Action set to CALLMENU sends calls the engine could not classify there as well. If neither uses CALLMENU, the AMD Call Menu field is ignored.

flowchart TD
  A[Call answered] --> B[CPD classifies the call]
  B --> C{CPD AMD Action}
  C -->|DISPO| D[Set AA and hang up]
  C -->|MESSAGE| E[Play AM message]
  C -->|INGROUP| F[Route to inbound group]
  C -->|CALLMENU| G[Look up AMD Call Menu]
  G --> H[Enter call menu]
  H --> I[Play prompt and read keypress]

Why a menu instead of a plain message

A menu gives the call somewhere to branch. You might play a short statement and then offer a press-1 path for a human who picked up late, or route to different audio depending on the time of day. Compared with the MESSAGE action, which plays one fixed prompt, a menu adds logic. Compared with a plain DISPO hang-up, it keeps the contact alive a moment longer.

The cost is complexity. Every menu you point detection at needs its prompts recorded, its key options defined, and its timeout behavior set so a true answering machine does not loiter on the line forever. Build a timeout that hangs up cleanly after the audio finishes.

There is a real-world reason a menu can beat a flat message. Call progress detection (CPD (call progress detection)) is fast but never perfect, and a slice of the calls it flags as machines are actually people who answered a beat late or paused before speaking. A plain MESSAGE action plays at them and ends. A menu can play your statement and then offer a key for the live person to press, recovering a contact you would otherwise have thrown away. That second chance is the whole argument for routing to a menu instead of hanging up.

Keep the prompt short and the options obvious. Long menus are murder on the contacts who really are people, and they are pointless for the machines. One clear sentence followed by a single press-1 path is usually enough. Anything more and you risk losing the human you were trying to rescue while a recorded greeting talks over your audio.

Setup checklist

• Create or pick the call menu first, then select it in AMD Call Menu.
• Confirm CPD AMD Action is set to CALLMENU, or this field stays inactive.
• Give the menu a sensible timeout so detected machines disconnect on their own.
• Decide whether Unknown-result calls should also reach the menu via CPD Unknown Action.

Keep an eye on how routed calls land in your Disposition reports. A call that runs through a menu can finish with a different status than one ended by DISPO, so design your reporting around the menu's exit paths.

For the full detection and routing story, read our AMD and CPD complete guide, and for the queue-based alternative see the AMD Inbound Group setting.

If building menus and detection routing sounds like one task too many, VICIfast sets it up and maintains it for you. See VICIfast pricing to learn more.