VICIdial NOTSURE Calls: What They Are and How to Route Them

Not every answered call gives answering machine detection (AMD (answering machine detection)) a clean verdict. When the engine cannot confidently call a human or a machine, it returns NOTSURE. By default those uncertain calls go straight to agents alongside confirmed humans. That default is safe, but it is not free, and you can change it. This post explains where NOTSURE comes from and how to route it yourself.

Why a call lands as NOTSURE

The Asterisk engine listens to the opening of a call and weighs things like greeting length and silence patterns. When the audio does not clearly match a human or a machine profile, the result is NOTSURE rather than a forced guess. Slow talkers, background noise, short greetings, and odd telecom lines all push calls into this bucket. It is the engine being honest about uncertainty, which is better than a confident wrong answer that becomes an AMD false positive (AMD false positive).

The default routing

By default, HUMAN and NOTSURE calls both go to agents. The logic is simple: if there might be a live person, do not risk hanging up on them. The cost is that some machines reach agents anyway, eating into talk time. Whether that trade is worth it depends on how many NOTSURE results your traffic produces, which you can see in the AMD Log Report under Admin Utilities.

Routing NOTSURE yourself

To take control, enable AMD Agent Route Options. That opens a settings container of status-response pairs, one per line, each a status and response separated by a comma. You keep the lines you want and rewrite the rest. For instance:

• HUMAN,HUMAN keeps confirmed humans flowing to agents.
• NOTSURE,TOOLONG reclassifies uncertain calls instead of sending them all to agents.

Use the PENDING option to stage your container on the Modify Settings Container page and review it before it goes live. That way you can adjust how NOTSURE is handled without disrupting calls mid-shift.

NOTSURE decision path

flowchart TD
  A[Call answered] --> B[AMD analysis]
  B --> C{Result}
  C -->|HUMAN| D[Send to agent]
  C -->|MACHINE| E[Machine path]
  C -->|NOTSURE| F{Route Options enabled}
  F -->|No| G[Default to agent]
  F -->|Yes| H[Apply your status pair]

Tuning before re-routing

Before you reroute NOTSURE calls, consider whether you can shrink the bucket. Tuning the detection parameters can move borderline calls into clear HUMAN or MACHINE results, which often beats reclassifying them after the fact. Keep an eye on your answer rate (Answer rate) and disposition (Disposition) mix as you adjust, so a routing change does not quietly hide live customers.

When sending NOTSURE to agents still makes sense

For many campaigns the default is the right call. If a live person on the line is worth far more than the cost of an agent occasionally getting a machine, you want to err on the side of routing uncertain calls to a human. Sales campaigns with high contact value usually keep NOTSURE going to agents and instead work on reducing the count through tuning.

The case for rerouting NOTSURE grows when agent time is scarce and the uncertain bucket is large. If a big share of your answers come back uncertain and most of those turn out to be machines, sending them all to agents wastes shift after shift. There, a NOTSURE rule that pushes those calls toward the message path or a hangup can lift agent productivity meaningfully.

Whatever you choose, base it on the log report rather than instinct. The numbers tell you how big the NOTSURE bucket is and what those calls really are, which is the only honest way to decide whether the default is costing you or protecting you.

For the broader detection picture, read our AMD and CPD complete guide, and for the full mechanics of the routing container see AMD Agent Route Options.

On a managed cluster the log report and settings containers are ready to use, so deciding what NOTSURE means for your campaign is pure configuration. See VICIfast pricing to get a system where the uncertain calls are yours to route.