ViciDial returns AMDSTATUS NOTSURE — what should the dialplan do with it?

This is a decision guide, not an explainer. If you want the background on why the gray zone exists and why it skews human, read AMDSTATUS NOTSURE: the gray zone that drops your best leads first, and keep the amd.conf cheat sheet open for the thresholds. What follows assumes you already know what NOTSURE means and want to decide what to do about it on Monday.

Step one: instrument before you decide

Most operators pick a NOTSURE branch without knowing how many calls it affects. That is backwards, and it is the reason the choice usually gets made once and never revisited. Before touching routing, log both the verdict and the reason for it. app_amd sets two channel variables, and the second one is the one nobody reads.

; Log the verdict and the reason for it before branching on either.
exten => _X.,n,AMD()
exten => _X.,n,NoOp(AMDSTATUS=${AMDSTATUS} AMDCAUSE=${AMDCAUSE})
exten => _X.,n,Set(CDR(userfield)=${AMDSTATUS}/${AMDCAUSE})
exten => _X.,n,GotoIf($["${AMDSTATUS}" = "MACHINE"]?machine,1)
exten => _X.,n,GotoIf($["${AMDSTATUS}" = "NOTSURE"]?notsure,1)
exten => _X.,n,Goto(human,1)

AMDCAUSE records which threshold produced the verdict. A NOTSURE mix dominated by the analysis-window ceiling means your total_analysis_time is doing the deciding; a mix dominated by greeting-length causes means greeting and maximum_number_of_words are. Those point at different fixes, and neither of them is a routing change.

Let that run for a full week of normal dialing, then count. This is your own database, not a benchmark from anyone else:

-- Run against your own ViciDial database, not ours.
-- Requires CDR(userfield) to be populated as shown above.
SELECT SUBSTRING_INDEX(userfield, '/', 1) AS amdstatus,
       COUNT(*)                          AS calls,
       ROUND(100 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct
  FROM cdr
 WHERE calldate >= CURDATE() - INTERVAL 7 DAY
   AND userfield <> ''
 GROUP BY 1
 ORDER BY calls DESC;

We deliberately do not publish a reference NOTSURE percentage here, including our own. AMDY’s detection pipeline does not emit an undecided class at all, so we have no measured NOTSURE rate to quote, and a stock-Asterisk figure from someone else’s traffic would be meaningless for yours: NOTSURE share is a function of your thresholds, your lists and your carrier audio quality. The measured distribution we can publish is in how often answering machine detection is wrong.

The four branches, and what each one costs

Why the machine branch looks better than it is

Treating NOTSURE as a machine improves every number you report. The FTC Telemarketing Sales Rule caps abandoned calls at 3% of answered calls, and a person hung up on after a NOTSURE verdict never enters that denominator as an abandonment — they were never queued for an agent, so nothing counted. Your abandonment rate drops. Your agent occupancy rises. Your contact rate falls, and the only place that shows up is a slow decline in dials-per-sale that gets blamed on the list. The arithmetic is worked through in the 3% rule.

How the ViciDial layer changes the answer

The dialplan is not the only place this gets decided. Two ViciDial campaign settings sit on top of the AMD verdict and can quietly override your intent.

• amd_send_message controls what happens to a call classified as a machine — typically playing a recorded message or hanging up. If your dialplan sends NOTSURE down the machine path, this setting is what actually executes, and a message-leaving configuration means you are leaving voicemails for live people.
• drop_call_seconds caps how long a connected call waits for an agent before ViciDial drops it. Routing NOTSURE to agents raises queue pressure, so a branch that looks safe in the dialplan can push calls past this ceiling and turn them into counted abandonments.

Those two settings are why the agent branch and the machine branch are not symmetric. The agent branch converts undecided calls into abandonment-rate risk, which is visible and regulated. The machine branch converts them into lost contacts, which is invisible and unregulated. Operators optimise for the visible one. Full definitions for both settings are in the AMD glossary and the parameter walkthrough is in ViciDial AMD variables.

What not to do: tune total_analysis_time down to make NOTSURE go away

This is the most common reaction and it moves in the wrong direction. Every call that reaches the total_analysis_time ceiling without crossing a threshold is returned as NOTSURE by definition. Shortening the window converts calls that would have resolved late into undecided ones. Shortening it to protect agent time is a legitimate trade, but you are buying speed with a larger gray zone, not shrinking the gray zone.

The same applies in the other direction. Loosening greeting or initial_silence to shrink NOTSURE pushes those borderline calls into confident HUMAN and MACHINE verdicts that are now more often wrong. The undecided calls do not disappear; they get a label they did not earn. That trade-off is the whole subject of the narrow middle.

The decision, in order

• Log AMDSTATUS and AMDCAUSE to CDR(userfield). Wait a week.
• Measure your NOTSURE share and its AMDCAUSE mix.
• Hand-label 50 NOTSURE recordings. This is the only step that tells you whether the bucket is human-heavy on your traffic. The procedure is in how to test your AMD accuracy.
• Pick the branch that fits your agent headroom and your abandonment margin, and write down why, so the next person does not inherit an unexplained default.
• Re-measure after any amd.conf change, because every threshold move redistributes the buckets.

If the labelled sample comes back human-heavy and you have no agent headroom, you are out of dialplan options — the branch you need does not exist, because the information needed to make the call was never in the timing signal. That is the point at which the fix is a classifier that decides from the answer audio itself rather than from silence durations, which is what AMDY does and what sound, not words explains.

FAQ

What should a ViciDial dialplan do with AMDSTATUS NOTSURE?

There are four workable branches: route NOTSURE to a live agent, treat it as a machine and hang up or leave a message, send it to a short pre-agent audio prompt that forces the caller to speak again, or queue it for a scheduled callback instead of deciding now. Which one is correct depends on your NOTSURE share, your agent headroom and your abandonment margin, so measure those three before you pick.

Is it safe to just treat NOTSURE as MACHINE?

It is safe for your reported metrics and unsafe for your contact rate. A live person hung up on after a NOTSURE verdict never enters the abandoned-call denominator, so this branch improves the number the FTC 3% cap is measured against while reducing the number of people you actually reached. If you choose it, choose it knowingly and measure the NOTSURE bucket by hand rather than assuming it is mostly machines.

How do I find out what my NOTSURE rate actually is?

Write AMDSTATUS and AMDCAUSE into CDR(userfield) in your dialplan immediately after the AMD() call, let it run for a full week of normal dialing, then group your CDR rows by the AMDSTATUS portion. Nobody else’s NOTSURE rate transfers to your traffic, because the figure is a function of your amd.conf thresholds, your lists and your carrier audio quality.

Does lowering total_analysis_time reduce NOTSURE?

It does the opposite. Every call that reaches the total_analysis_time ceiling without a threshold being crossed is returned as NOTSURE by definition, so shortening the window converts calls that would have resolved late into undecided ones. Shortening it is a reasonable way to protect agent time, but the NOTSURE share is the price, and you should expect it to rise.