‎Answering Machine Detection Policy (AMD Policy)

Answering Machine Detection Policy (AMD Policy)

Updated

4 days ago

The Answering Machine Detection Policy allows admins and supervisors to fine-tune how the system identifies whether an answered call is picked up by a human or a voicemail. It aims to give non-engineering teams the ability to easily fine-tune and optimize the Answering Machine Detection (AMD) model in real time through a simple, self-service interface.

With a UI-based configuration tool, teams like Support, Product, Implementation, and Admin are able to directly test, adjust, and roll back AMD settings as needed, without waiting for Sprinklr Support.

This solution:

Speeds up time-to-value by letting teams make quick adjustments during live campaigns.
Increases flexibility with the ability to tune AMD behavior for different regions or carriers.
Improves accuracy.
Adds transparency and control through built-in audit logs and rollback options.

In short, this project makes AMD tuning faster, easier, and more responsive, helping teams deliver better performance and a smoother experience for customers.

Enablement Note: Access to this feature is controlled by permissions - Create, Edit, View, Delete, and Share.

Creating AMD Policy

Perform the following steps to create the AMD Policy.

Click the New Tab icon. Under the Sprinklr Service tab, click Voice Care within Listen.
The Voice Application screen is displayed.
Click AMD Policy on the left pane of the Voice Settings screen.
The AMD Policy screen is displayed.
Click + Create AMD Policy on the top right corner.
The AMD Policy screen is displayed.
Enter the Name.
Enter the Detection Timeout (ms).
Select the AMD Model from the drop down list.
Select the Voicemail Classification Method from the drop down menu.
Click Enable Early Media toggle if you want to enable audio singals early in the call.
Click Classify call as Voicemail in case of complete silence toggle if you want to classify a silence as a voicemail.
Click Enable Voicemail Drop.
Select Voicemail Drop IVR.
Click Save.

Refer to the following table for parameter decsription of the AMD Policy screen.

Parameter	Description
Name	Enter a name for the AMD Policy. This helps identify it easily when associating with campaigns.
Detection Timeout (ms	The maximum permissible time (in milliseconds) for AI to decide whether the call is answered by a human or a voicemail.
AMD Model	Choose which AI model should be used for Answering Machine Detection in this policy. The dropdown shows all active AMD models available in the system. If no model is selected, the default model will be selected from Voice Outbound Settings. If a model becomes inactive later, the policy will still work with it, but you won’t see that model in the dropdown when editing. You can either leave the field blank (to use the default) or pick another active model. It allows safe A/B testing of new models without impacting all campaigns at once. Reports will also show which model was used for each call, so you can compare performance easily.
Voicemail Classification Method	Defines how voicemail detection is performed. There are three modes available: AI-based only: Uses Sprinklr’s AI/ML model to identify voicemail based on voice patterns and call behavior. How it works: The system analyzes voice patterns, speech cadence, tone, and call behavior (e.g., silence duration, response timing). It uses trained machine learning models to classify the call outcome in real time. Advantages: Can detect voicemail even when SIP signaling is unavailable or unreliable. Useful in environments with inconsistent carrier signaling. SIP code-based only: This method relies on SIP (Session Initiation Protocol) response codes sent by the telecom carrier to identify whether a call was forwarded to voicemail. How it works: When a call is initiated, the carrier returns SIP response codes that indicate how the call was handled. Specific SIP codes, such as 181 (Call is Being Forwarded) can signal that the call is being redirected to voicemail. These codes are interpreted by the system to classify the call outcome as voicemail or human-answered. Advantages: Fast and efficient- no need to analyze audio. Highly reliable when carriers provide consistent and accurate SIP signaling. AI & SIP code-based: Combines both methods for more accurate detection. How it works: The system first checks SIP codes for voicemail indicators. If SIP data is inconclusive or unavailable, it falls back on AI-based voice pattern analysis. Results from both methods are cross-validated to improve detection accuracy. Advantages: Maximizes detection reliability across diverse carrier networks and call environments. Reduces false positives and negatives by leveraging complementary data sources.
Enable Voicemail Drop	Beep Detection Timeout (seconds): Set the time the system waits to detect the beep in the customer’s voicemail greeting. If the beep is not detected within this time, the selected message will play immediately. Voicemail Drop IVR: Select an existing pre-recorded voicemail message (IVR) from the dropdown. Or click Create New IVR to upload or record a new audio file inline without leaving the page. Provide a display name and save. The new IVR will appear in the dropdown and be auto-selected. Note: Voicemail Drop is supported only for Sprinklr Voice Connect and SignalWire.
Enable Early Media	It refers to the phase of a call before it is formally connected, during which the telecom provider may still transmit audio signals such as ringback tones, announcements, or voicemail greetings.
Classify call as Voicemail in case of complete silence	If the system detects complete silence during the call (no speech, tones, or background noise), it automatically classifies the call as voicemail.

Implementing AMD

Perform the following steps to implement the AMD policy in the Campaign creation.

Navigate to the Campaign creation screen. To edit or create a Campaign, refer To create a Campaign.
On the Campaign screen click the Enable Answering Machine Detection checkbox to select the AMD policy you have created in the above steps.
Click Save.

Applications of AMD Policy

Voicemail Drop Automation: Automatically triggers pre-recorded voicemail messages when a machine is detected, saving agent time.
Campaign Optimization: Helps fine-tune call strategies based on live detection patterns, improving contact rates and conversion.

Standardization of AMD

Answering Machine Detection (AMD) is used to determine whether an outbound call is answered by a live individual or a voicemail/answering system. Based on this identification, the system can decide the next step—such as connecting the call to an agent or triggering a voicemail flow.

To improve accuracy and call outcomes, AMD models are continuously updated and refined. In earlier implementations, however, adopting a new model required replacing the existing one across all campaigns at once. This made gradual rollouts difficult and increased the risk of widespread impact from any change.

To overcome these limitations, a standardized model selection approach has been introduced. This enhancement allows a default AMD model to be configured at the settings level, while still enabling specific campaigns to use dedicated models through AMD policies. As a result, teams can roll out updates in a controlled manner, conduct targeted testing, and minimize potential disruptions.

This standardization also addresses previous challenges such as limited flexibility in model deployment, difficulty in comparing model performance, and lack of visibility into which model was being used when no policy was applied. The settings-level default model now serves as a reliable fallback, ensuring consistency while giving teams greater control over model usage.

AMD Model Selection Logic

When a call requires Answering Machine Detection (AMD), the system chooses the model using a predefined priority order. This ensures predictable behavior while supporting flexible configurations.

Priority Order for Model Selection

Policy-Level Model (Top Priority):
If an AMD model is specified in the policy linked to the campaign, that model is always selected.
Default Model from Settings:
If no model is defined in the policy, the system looks for a default model configured in Voice Outbound settings.
System Default Model (Fallback):
If neither of the above is available, the system uses the backend’s default AMD model.

This approach ensures that policy-driven configurations override all others, while still maintaining a clear fallback path.

Enhancements in AMD Configuration and Standardization

To accommodate different use cases, AMD can be enabled in multiple ways:

Direct Campaign Enablement:
AMD can be turned on at the campaign level for quick and straightforward usage. This is suitable for scenarios that do not require detailed configuration.
Policy-Driven Enablement:
Teams can define AMD policies and assign them to campaigns for more structured and scalable control. This is ideal for maintaining consistency across multiple campaigns.

These options are backed by the standardized model selection framework, which helps ensure uniform behavior, better oversight, and easier management of AMD settings across the platform.

Default AMD Model Configuration

This setting lets users choose a default AMD model from a dropdown menu. Only models that are currently active are available for selection. The configuration is optional. If no model is chosen, the system will continue to use the existing backend default. Default models can differ across production environments, as AMD configurations may vary by region or deployment.

Reporting

To enable internal analysis and evaluation, reporting continues to log the AMD model used for each call.

In reports:

The exact model name is displayed when a model is selected via a policy or configuration.
“Default (System)” is shown when the backend default model is applied.

This approach allows product teams to assess and compare model performance while keeping implementation details hidden from customers.