A practical guide / Fonix.AI
Answering-machine detection: a practical implementation guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
Answering-machine detection is an uncertain classification
AI calling answering machine detection attempts to distinguish a person, mailbox, silence and ambiguous pickup. The outcome affects whether the agent speaks, leaves an approved message, waits or ends the attempt. A carrier-connected event does not prove that a person answered.
Evaluate Fonix.AI with the actual carrier path and approved outreach policy. Provider support and detection behaviour must be confirmed; this guide is a test protocol, not an accuracy claim or permission to leave sensitive voicemail.
Define the outcomes before configuring the policy
Include human, machine, silence and uncertain labels. The reference should come from reviewed call evidence, not the detector's own result. Keep short human greetings, business auto-attendants, long voicemail greetings and noisy pickup as separate conditions.
Choose the business response for uncertainty. Depending on the approved workflow, it may be a bounded wait, a neutral greeting or stopping the attempt. Do not automatically treat every uncertain pickup as a live customer or a permitted mailbox.
Worked example: a person sounds like a recorded greeting
A fictional receptionist answers with a long business greeting. The detector labels it as a machine and starts a voicemail message. This is a false-machine error with a visible customer cost. The reverse error can disclose details to a mailbox. Report both directions rather than one accuracy percentage.
| Reference class | Possible error | Impact to inspect |
|---|---|---|
| Human | Classified as machine | Wrong message or dropped contact |
| Machine | Classified as human | Unsupported disclosure/dialogue |
| Silence | Premature assumption | Wasted time or false outcome |
| Ambiguous | Forced certainty | Inappropriate next action |
Separate detection from message eligibility
Even a correct machine classification does not authorise a particular message. Use approved wording and content boundaries. Record whether a message was attempted and what delivery evidence exists; do not label the customer's task resolved because audio was played.
Keep retry policy tied to contact preferences and the business task. A changed account state or completed request should suppress older queued attempts. Deduplicate repeated provider callbacks so a single pickup does not create several follow-ups.
A reviewed greeting-set and consequence matrix
Create a reviewed set of synthetic or authorised human greetings, voicemail, silence and ambiguous cases. Define the downstream policy for each outcome. Keep sensitive account content out of test messages and control the called destinations.
| Pilot case | Required behaviour |
|---|---|
| A receptionist gives a long business greeting | Count a machine label as a false-machine error and inspect the resulting customer experience. |
| Voicemail is classified as a human | Check whether the next dialogue would disclose information outside the permitted message. |
| The detector returns uncertainty | Use the approved uncertainty path instead of forcing certainty to improve a headline metric. |
Use a confusion matrix with sample counts, both error directions and detection delay. Evaluate the business consequence of each error, including inappropriate messages. One aggregate accuracy figure can hide a costly tendency to misclassify people.
Does a machine label automatically permit leaving a message?
No. Message eligibility and content are separate business and provider-policy decisions. Apply the approved short-message or end-call route, and preserve uncertain outcomes rather than treating classification as permission to disclose private details.
Build a reviewed confusion matrix
Use authorised or synthetic test calls and include sample counts by greeting and channel condition. Inspect false-human and false-machine rates separately, plus uncertain rate and delay. Compare the downstream action with policy for every class.
Review pickup-detection behaviour with your permitted call outcomes. Twilio integration illustrates lifecycle separation; outage notifications shows why a delivered message differs from a resolved request.
Reference and scope
Twilio answering-machine detection documentation. This is a provider example of detection behaviour and uncertainty. The evaluation method here is provider-neutral; it does not claim that every Fonix route uses this detector. Reference reviewed 17 October 2026.