VICIdial AMD Agent Route Options: Which Calls Reach Agents

Out of the box, answering machine detection (AMD (answering machine detection)) sends every call labeled HUMAN or NOTSURE to your agents and routes everything else elsewhere. That is a sensible default, but it is not always what you want. AMD Agent Route Options lets you rewrite those rules, status by status, so you decide precisely which detected calls reach a live agent (Agent). This post explains how the setting works and how to use it carefully.

What the default does

When AMD Agent Route Options is DISABLED, the built-in Asterisk engine applies its standard behavior: HUMAN and NOTSURE answers go to agents, and other results follow the machine path. For many campaigns that is fine. You only reach for this setting when the default routing sends you the wrong mix, for example too many uncertain calls landing on agents or machines slipping through.

How the override works

Enable the setting and it opens a settings container where you list status-response pairs, one per line, each as a status and a response separated by a comma. Each line tells the routing script how to treat a given detection status (Status (lead status)). A simple container might read:

• HUMAN,HUMAN
• NOTSURE,TOOLONG

The first line keeps confident human answers going to agents; the second reclassifies uncertain calls. To know which statuses your traffic actually produces, look at the AMD Log Report under Admin Utilities, which lists the detection statuses and responses logged on your system. Build your container from real data rather than guesses.

A handy safety feature is the PENDING option. Selecting it lets you open the Modify Settings Container page and edit the rules without making them live, so you can stage changes and review them before they affect calls.

Routing logic

flowchart TD
  A[Detected call] --> B{Agent Route Options}
  B -->|Disabled| C[HUMAN and NOTSURE to agents]
  B -->|Enabled| D[Read status response pairs]
  D --> E{Match status}
  E -->|HUMAN| F[Send to agent]
  E -->|NOTSURE| G[Apply chosen response]
  E -->|Other| H[Machine path]

Extra hangup switches

The same container holds a few special options. NOAUDIODATA-Hangup-ENABLED drops calls that arrive at the routing script with no audio data. FAX-Hangup-ENABLED and FAS-Hangup-ENABLED immediately end calls detected as fax or false answer, which keeps both off your agents. These belong with fax detection (Fax detection) tuning when you want a clean agent queue.

Because this setting works with the Asterisk engine, it assumes you are on an auto-dial method using a normal dial method (Dial method), not manual mode. If you switch to a third-party detection engine, the standard route options no longer apply in the same way, so this container is specifically a tool for the built-in AMD path.

A careful rollout

Treat any change here as something to test, not set and forget. Start by reading the log report to learn which statuses your real traffic produces and in what volume. Build a container that only changes the handling you actually need, leaving the rest at the default behavior. Stage it with PENDING, review it on the Modify Settings Container page, then make it live and watch your numbers for a shift.

The risk to watch for is sending live people to the machine path by mistake. If you reclassify a status too aggressively, you can quietly hang up on customers, which hurts both your conversion and your reputation. Move one rule at a time and compare your live-answer mix before and after each change so a routing tweak never hides real conversations.

For how detection fits the rest of your outbound setup, read our AMD and CPD complete guide, and to handle uncertain answers specifically see how to route NOTSURE calls.

A managed cluster gives you the settings containers, the log report, and the routing script already in place, so building route rules is a configuration task instead of a server project. See VICIfast pricing to start mapping your statuses today.