AMDSTATUS NOTSURE: the gray zone that drops your best leads

Three outcomes, and the one nobody plans for

Stock Asterisk AMD — the app_amd application configured in amd.conf — ends every analyzed call by writing one of three values into the AMDSTATUS channel variable: HUMAN, MACHINE, or NOTSURE. Most dialplans are written around the first two. The third is the one that quietly costs you money.

NOTSURE is not an error and it is not a fourth category of call. It means the timing heuristic ran its full analysis window — listening for initial silence, greeting length, the silence after the greeting, word counts — and never crossed the thresholds that would let it confidently say “person” or “machine.” The audio sat in the middle. So app_amd does the honest thing and admits it doesn’t know, then hands the decision straight back to you.

That handoff is the whole story. Everything that happens to a NOTSURE call after that point is a routing choice your dialplan makes — not a detection the engine made.

The gray zone is where your hardest leads live

Here is the part most operators miss: NOTSURE is not a random sample of your traffic. It concentrates a very specific kind of call — the hard cases the timing model was never good at:

• Fast greetings — someone picks up and says “Hello?” before the model expects a person to speak.
• Silent pickups — a person answers, hears dead air, and waits instead of talking.
• Noisy or low-bitrate lines where the heuristic can’t cleanly measure word length or silence.
• Very short hellos — a single clipped word that’s too brief to clear the greeting threshold.

Now look at who actually answers that way. A clipped, fast, slightly impatient “Hello?” followed by a pause is how an engaged human answers a call they were expecting. Voicemail greetings, by contrast, are smooth and predictable — which is exactly why the heuristic classifies them well and rarely punts them into NOTSURE. So the gray zone skews toward real people. We unpack the fast-greeting failure in detail in why “Hello?” breaks default AMD.

That is the trap. The bucket your dialplan handles last, and most carelessly, is disproportionately full of the people you most wanted to reach.

The dilemma the heuristic puts on your desk

Because app_amd punts, your dialplan has to choose, and both choices lose something:

• Route NOTSURE to machine / hang up. You protect agent time, but you drop the real prospects hiding in the bucket — and, as above, that bucket is human-heavy.
• Route NOTSURE to a live agent. You stop dropping humans, but agents now burn seconds greeting voicemails before they realize no one’s there.

There is no good universal setting here, because the heuristic didn’t fail at one call — it declared a whole class of calls undecidable and made the decision your problem. Tightening amd.conf doesn’t dissolve the dilemma; it just moves calls between buckets. Loosen the thresholds and you push borderline calls into wrong HUMAN/MACHINE verdicts; tighten them and you swell NOTSURE. The middle has to go somewhere. For the full picture of what stock tuning can and can’t do, see the drawbacks of stock AMD and the amd.conf cheat sheet.

How operators usually resolve it — and what it costs

In practice, most floors default NOTSURE to machine. The logic is understandable: idle agents are visible and expensive, voicemails are annoying, and “when in doubt, hang up” keeps the dialer moving. The Vicidial layer makes this the path of least resistance — amd_send_message and drop_call_seconds are usually set to treat anything that isn’t a clean HUMAN as droppable.

That decision is invisible on every dashboard you own. Your drop rate looks fine. Your agents look busy. Nothing flags the cost — because a dropped human leaves no trace. You never see the person who picked up fast, got hung up on, and is now slightly more annoyed at your brand. They simply weren’t connected, and your reports record it as “machine handled.” The leads bleeding out are your best ones: the people who answered quickly precisely because they were expecting a call.

A back-of-envelope sense of scale

Keep this hypothetical. Imagine a floor running 10,000 connected dials a day where the NOTSURE bucket is a meaningful slice of traffic — not unusual once you tighten amd.conf to suppress machine misses. If a large share of that slice is human and you default the whole thing to machine, you are discarding live, interested prospects every single day, silently, with no line item to show for it. You don’t need exact figures to see the shape: the bucket is big enough to matter and human enough to hurt.

The fix: shrink the gray zone, don’t route around it

The reason NOTSURE exists is that a timing heuristic only has crude levers — how long someone was silent, how long they spoke, how many words it counted. Real answer audio is richer than that, and when it doesn’t fit the rules, the only honest output is “not sure.”

AMDY doesn’t accept the gray zone — it removes most of it. Instead of timing thresholds, AMDY is an AI/ML model that classifies the acoustic signature of the answer audio: the actual sound of how the call was picked up, not a word count and not a transcript. Audio streams to a WebSocket gateway and comes back as a calibrated, confidence-scored decision in under 200ms, at 99% accuracy. (Why sound beats words is the subject of this companion piece.)

The difference for your dialplan is fundamental. A heuristic punts a class of calls and makes you guess; a confidence-scored classifier returns an answer for the calls that used to be undecidable. The fast greeting, the silent pickup, the short hello — the exact cases that pile up in NOTSURE — get a clear human-or-machine verdict instead of a coin flip. The “not sure” pile, and the real people quietly dropped inside it, largely disappear. And because the score is calibrated, the rare genuinely ambiguous call comes with a confidence number you can route on deliberately, instead of a flat NOTSURE that tells you nothing.

AMDY installs natively on Vicidial, Asterisk, FreeSWITCH, and Issabel with one bash command in about five minutes, and it’s telco-agnostic — you keep your carrier. The full setup walkthrough lives in the Vicidial AMD guide.

The takeaway

NOTSURE isn’t a detection — it’s the engine declining to make one and handing you the bill. The bucket is human-heavy, the default routing throws those humans away, and no dashboard tells you it’s happening. You can keep tuning amd.conf to shuffle calls between buckets, or you can replace the punt with a real answer and stop dropping the people who picked up fastest.

FAQ

What does AMDSTATUS NOTSURE mean?

NOTSURE is one of three values Asterisk's app_amd can set in the AMDSTATUS channel variable, alongside HUMAN and MACHINE. It means the timing heuristic ran the full analysis window but could not clear the thresholds in amd.conf that would let it confidently call the answer a person or a machine. The call wasn't unclassifiable — the rules simply didn't reach a verdict, so app_amd hands the decision back to your dialplan.

Should I treat NOTSURE as human or machine?

There is no universally correct answer, which is the core problem. Treat NOTSURE as machine and you protect agent time but drop real people. Treat it as human and you keep those people but send some voicemails to live agents. Most operators default to treating NOTSURE as machine to keep the agent floor busy, but that quietly bleeds your best leads. The real fix is to stop guessing — shrink the gray zone with an acoustic classifier so far fewer calls land in NOTSURE at all.

Why are so many of my calls NOTSURE?

NOTSURE volume rises whenever real-world audio doesn’t fit the timing model: fast greetings with no pause, silent pickups, noisy or low-bitrate lines, very short hellos, and carrier audio that clips the first word. Tightening amd.conf to reduce machine misses tends to push more calls into NOTSURE; loosening it pushes calls into wrong HUMAN/MACHINE verdicts. The heuristic can move the problem around but cannot make it disappear.

Are NOTSURE calls usually real people?

A large share are. The cases that confuse a timing heuristic — someone answering quickly, saying a short “Hello?”, then going quiet — are exactly how engaged people answer a call they were expecting. So the NOTSURE bucket is skewed toward humans relative to the overall stream, which is precisely why defaulting it to machine is so costly.

How does AMDY handle the gray zone?

AMDY replaces the punt with a decision. Instead of timing thresholds, it runs an AI model over the acoustic signature of the answer audio and returns a calibrated, confidence-scored classification in under 200ms at 99% accuracy. Because it classifies the sound itself rather than waiting on silence and word-length rules, the calls that used to fall into NOTSURE — and the real humans hidden inside them — largely get a clear answer.