How to read the AMD Log Report when answering-machine detection looks wrong

Agents complain that live people are getting cut off, or voicemails are slipping through to agents. Either way, the suspect is your answering-machine detection, and the AMD Log Report is where you check its work. It shows the results of the built-in answering-machine detection function on calls placed from your dialers, one row per call.

What AMD is doing

AMD (answering machine detection) listens to the first few seconds of a connected call and guesses whether it reached a human or a machine. VICIdial's built-in detection — sometimes called ViciAMD — analyses the early audio: a short greeting then silence looks human, a long unbroken stretch of speech looks like a machine. When the guess is "machine" the system can drop the call or fire a Voicemail drop instead of bothering an agent.

Reading the results

The report gives you the detection result for each call. Read it as a population, not one row at a time:

• A healthy mix of HUMAN and MACHINE results that roughly matches reality means detection is working.
• A flood of MACHINE results when you know people are answering points at an AMD false positive problem — detection is too aggressive and clipping live answers.
• MACHINE on calls that lasted long enough for a real conversation usually means the audio reaching the detector was bad, not that a machine answered.

Telling a real misfire from carrier noise

flowchart TD
  A[Open AMD Log Report] --> B{Too many MACHINE results?}
  B -->|No| C[Detection looks fine]
  B -->|Yes| D{Audio clean on those calls?}
  D -->|No| E[Fix audio / codec first]
  D -->|Yes| F[Detection too aggressive: tune AMD]
  E --> G[Re-run and re-check]

This is the step people skip. Detection is only as good as the audio it hears. If the Carrier is delivering clipped or delayed audio, the detector hears garbage and over-calls "machine." Before you loosen detection thresholds, confirm the audio on a sample of the misclassified calls is actually clean. Tuning detection on top of a bad audio path just hides the real fault.

Each detection result ties to a Lead and a call, so when you find a clear misfire you can trace that exact call elsewhere and confirm the timeline. The most useful thing you can do with a confirmed false positive is pull the call recording and listen: if you hear a real person being cut off mid-greeting, you know the detector is the problem and not the data.

When you do tune detection, change one setting at a time and re-run the report on a fresh batch. Loosening several thresholds at once tells you nothing about which one helped, and you can easily swing the other way into letting voicemails reach agents — which wastes talk time as surely as dropping live people wastes contacts. Read the report as a feedback loop: adjust, run a sample, re-check the HUMAN-to-MACHINE split, repeat until it matches what your agents actually hear.

Where to go next

If you suspect the audio path rather than the detector, the SIP Event Report can surface false answers that confuse detection, and the Dial Log Report shows how those calls actually resolved. The troubleshooting playbook helps you decide which to open first.

A VICIfast managed dialer ships with detection ready to tune and clean audio out of the box — live in under 40 seconds. See plans and pricing.