What answering machine detection actually measures
Answering machine detection is a probability judgment made in the first few seconds of a connected call. It tries to decide whether a person answered or whether the call reached a recording, voicemail system, tone, or automated line.
The direct answer: AMD tells the dialer what probably answered the call so it can decide whether to connect a rep, leave a voicemail, skip the call, or take another action.
It does not know whether the person is a decision-maker. It doesn't detect buying intent. It can't tell you if the prospect is having a good day. The question is narrower:
Did a human answer, or should the call be handled without putting a rep into dead air?
That sounds simple until you listen to real calls.
A prospect may answer with a quiet "hello" after a long pause. A company receptionist may say, "Thank you for calling Acme, please hold," which sounds like a recording. A voicemail greeting may start with several seconds of silence. Some mobile carriers add an automated message before the person speaks. On a shared office line, a person might answer with the company name and nothing else.
AMD has to make a useful call from those imperfect signals. It can't wait around for certainty. If it waits too long, the rep hears dead air and the prospect hangs up. If it decides too quickly, it can throw away a live conversation.
So AMD isn't a permanent label attached to a phone number. It's a decision about the call happening right now.
Why AMD gets calls wrong
There are two failure modes, and teams usually focus on only one.
The obvious one is a false human decision. The dialer sends a rep into a voicemail greeting, an automated phone tree, or several seconds of silence. The rep waits, says "hello?" twice, then disconnects. Do that often enough and the calling session turns into interruption management.
The quieter failure is a false machine decision. A real person answers, but the detector classifies the opening as a recording. The rep never gets connected. The call may be logged as voicemail or no answer, so the team doesn't see the conversation that disappeared.
This is where teams get AMD wrong: they treat fewer awkward rep connections as proof that the setting improved. It may only mean the detector is filtering more aggressively. A cleaner dashboard can hide a worse calling experience.
There isn't one setting that works for every list. A call to a mobile number in the United States behaves differently from a call into a large company's phone tree. A list of owner-operated businesses produces different greetings from a list of enterprise switchboards. Even the same number can behave differently depending on the carrier and the person's voicemail setup.
AMD is weighing evidence, not reading a label.
The handoff matters more than the label
Detection only matters because it controls what happens next.
If the call looks like a machine, the dialer might leave a voicemail drop or skip the call. If it looks like a human, it should connect the rep quickly enough that the opening doesn't feel broken. If the call is ambiguous, the system needs a defined fallback instead of leaving the rep to guess.
The handoff is where many otherwise capable systems fall apart. One provider places the call. Another runs detection. A separate service connects the rep. The CRM records the disposition later. When those systems disagree about timing or status, the team gets strange outcomes: a voicemail drop on a live answer, a rep connected after the prospect has hung up, or a call marked "no answer" even though someone spoke.
A useful test is to follow one call from dial to disposition. For example, a 12-person sales team at a regional payroll company starts calling 4,000 small-business owners after a state tax filing change. The team wants voicemail handled automatically so reps can spend the session on live conversations. But if AMD classifies owners who answer with a short "yeah?" as machines, the campaign will quietly lose its best calls.
Look at the call recording or transcript, the detector result, the connection timestamp, and the final disposition together. If those records don't tell the same story, changing the AMD threshold is guesswork.
Workloom keeps numbers, dialing, machine detection, and post-call records in the same calling workflow. Reps can call from a browser, and the dialer can connect them only after a human answer is detected. Voicemail drop and automatic skip handle the calls that don't need a rep. The advantage isn't that the detector becomes certain. It's that the result leads directly to an action and stays attached to the call record.
How to tune it without guessing
Start with the cost of each mistake, not with a vendor's recommended setting.
Suppose a five-rep insurance brokerage makes 600 outbound calls each morning. Reps report that they hear voicemail greetings several times per hour. At the same time, the connect rate has dropped sharply after a recent AMD change. Tightening the detector again may remove the voicemail problem, but it could also filter out short human answers.
For a week, review a sample of calls that fall into the uncertain or disputed outcomes. Record whether the answer was:
- a live person
- a voicemail or recording
- an automated business line
- silence or a failed connection
Then compare that result with what the system logged and what the rep experienced. You don't need to inspect every call. A consistent sample from each campaign, market, and carrier is enough to show whether the problem is concentrated somewhere.
The question to answer is: which mistake is costing more right now?
If false human decisions are common, reps are paying for every bad handoff in time and attention. If false machine decisions are common, the loss is harder to spot because the rep never sees the opportunity. In an outbound team, I'd rather tolerate a small number of awkward machine connections than quietly discard a large number of live answers. That isn't universal, but live conversations are usually the scarce resource.
Also check the opening script. A rep who waits silently after connecting can make a real person sound like a failed call. A dialer that connects too late can create the same problem even with a reasonable detector. AMD tuning can't repair poor connection timing.
AMD sits inside the calling rules
A detector can make the right classification on a call that should never have been placed.
Do-not-call rules still need to block every dialing path. Local calling hours need to follow the prospect's time zone, not the rep's. Suppression lists, number quality, retries, and voicemail policy all affect the result. If a team measures AMD only by "human" versus "machine," it misses the rest of the path.
The next action doesn't always need to be a rep connection, either. A calling agent might confirm a meeting, ask for a missing detail, or handle a simple follow-up in the prospect's language. A voicemail drop may be better for one campaign, while a scheduled retry makes more sense for another.
That is the practical boundary of answering machine detection: it is a fast, probabilistic filter between a connected call and the next action. The setting matters, but the bigger issue is whether detection, connection timing, voicemail handling, compliance rules, and call records all agree about what happened.