Implementing Auto-Response Detection to Suppress Out-of-Office Loop Storms

How-To-Articles
1

Implementing Auto-Response Detection to Suppress Out-of-Office Loop Storms

What This Guide Covers

This guide details the architecture and configuration required to detect machine-generated responses (Out-of-Office, fax machines, voicemail greetings) and terminate calls immediately to prevent infinite loop storms. The end result is a robust routing flow that identifies non-human audio patterns within the first 3-5 seconds of a call, applies a specific disposition code, and hangs up without billing for the connection duration or consuming agent capacity.

Prerequisites, Roles & Licensing

  • Licensing Tier: Genesys Cloud CX 2 or higher (required for Speech Analytics and Call Control features). Basic CX 1 licenses do not include the Machine Detection capabilities.
  • Permissions:
    • Architect > Edit (to modify the routing flow).
    • Speech Analytics > Edit (to manage machine detection rules).
    • Telephony > Trunk > Edit (if configuring trunk-level settings, though flow-level is preferred for granularity).
  • External Dependencies:
    • A configured Speech Analytics engine with the Machine Detection model enabled.
    • Access to the Architect tool.

The Implementation Deep-Dive

1. Understanding the Loop Storm Threat Model

Before configuring the solution, you must understand why standard IVR timeouts fail. A loop storm occurs when an automated system (e.g., a carrier voicemail or an OOO auto-responder) answers a call, plays a greeting, and then either hangs up or waits for input. If your IVR logic is designed to retry on failure or timeout, it will redial the same number. The remote system answers again. The cycle repeats.

A single misconfigured retry logic can generate thousands of calls in minutes. This consumes:

  1. Trunk Capacity: Blocking legitimate inbound/outbound channels.
  2. Billing: You are charged for every second of the loop.
  3. Reputation: Carriers may flag your SIP trunk as spam or fraud due to high call volumes with low answer rates.

Standard “Call Failed” dispositions do not distinguish between a busy signal, a no-answer, and a machine answer. You need a mechanism that inspects the audio of the answered call to determine if a human is present. This is where Machine Detection (also known as Auto-Response Detection or ARD) becomes mandatory.

The Trap: Relying on Call Duration or Silence detection alone.
If you configure a flow to hang up after 3 seconds of silence, you will disconnect legitimate callers who are hesitant to speak or are in noisy environments. Conversely, if you wait for a “No Input” timeout, you allow the loop to persist for the duration of the timeout (often 10-30 seconds), multiplying the storm effect. You must inspect the content of the audio, not just the presence of audio.

2. Enabling Machine Detection in Speech Analytics

Machine detection is not a native feature of the Routing Flow engine; it is a feature of the Speech Analytics platform that feeds data back into the flow via Call Control.

  1. Navigate to Admin > Speech Analytics > Machine Detection.
  2. Ensure Machine Detection is enabled for the relevant language models.
  3. Configure the Confidence Threshold.
    • Default: 50% (Balanced).
    • Recommendation: Set to 60-70% for outbound campaigns to avoid false positives (hanging up on shy humans). For inbound, you can lower this to 40-50% because the risk of a loop is higher, and the cost of a false positive is lower (the caller can redial).
  4. Verify that Real-Time processing is enabled. Batch processing will not stop the storm; it only provides post-call analytics.

Architectural Reasoning:
Speech Analytics uses a lightweight machine learning model to analyze the first few seconds of audio. It looks for patterns indicative of machines: repetitive loops, lack of intonation, specific frequency signatures of fax tones, and pre-recorded greeting structures. This happens in parallel with the call, adding minimal latency (typically <200ms).

3. Configuring the Routing Flow for Machine Detection

The core of the solution lies in the Architect flow. You must use the Call Control block to trigger the detection and the Condition block to act on the result.

Step 3.1: The Outbound Call Block

When initiating an outbound call (or handling an inbound call that might connect to a machine), you must ensure the call is monitored for machine detection.

  1. Add an Outbound Call block (or Transfer Call for inbound).
  2. In the Settings tab of the block, locate the Speech Analytics section.
  3. Check the box for Enable Machine Detection.
    • If this box is unchecked, the Speech Analytics engine will not analyze the audio stream in real-time, and the MachineDetectionResult variable will remain null.

The Trap: Forgetting to enable Machine Detection on the specific Call Block.
Many architects enable Machine Detection globally in Speech Analytics but forget to toggle it on the individual Call Block in Architect. The global setting defines capability; the block setting defines execution. Without the block-level toggle, the flow proceeds as if no detection is occurring, and the loop storm continues unchecked.

Step 3.2: Handling the Result with Call Control

Immediately after the Call Block, you must add a Call Control block. This block does not initiate a call; it manages the state of the current call.

  1. Add a Call Control block.
  2. Set the Action to Get Machine Detection Result.
    • Note: In newer versions of Architect, this may be integrated into the Condition block directly, or you may use a Wait block with a condition on the MachineDetectionResult variable. The most robust method is using a Condition block that evaluates the MachineDetectionResult attribute.

Step 3.3: The Decision Logic

Create a Condition block to evaluate the machine detection status.

  1. Add a Condition block.
  2. Add a rule:
    • Attribute: MachineDetectionResult
    • Operator: Equals
    • Value: Machine (or ProbableMachine, depending on your threshold configuration).
  3. Create two branches:
    • True (Machine Detected): Route to the Hang Up block.
    • False (Human Detected / No Detection Yet): Route to the normal agent transfer or IVR menu.

Architectural Reasoning:
You must handle the Unknown or NoResult state. Machine detection is probabilistic. If the system has not yet reached a confidence threshold within the first 3-5 seconds, the result may be Unknown.

  • Do NOT hang up on Unknown. This will result in high abandonment rates for legitimate callers.
  • Do allow the call to proceed to the agent or IVR if the result is Unknown. The agent can then manually determine if it is a machine. If it is a machine, the agent can hang up and update the disposition.

4. Implementing Retry Logic with Suppression

The most critical part of suppressing loop storms is preventing the system from redialing a number that has been identified as a machine.

Step 4.1: Disposition Mapping

  1. Navigate to Admin > Routing > Dispositions.
  2. Create a new disposition code: Machine Detected.
  3. Set the Type to Outbound.
  4. Set the Outcome to Not Connected.
  5. Crucial Step: In the Disposition Settings, ensure that this disposition is mapped to Suppress Future Calls.
    • In Genesys Cloud, this is often handled by the Campaign settings or the Contact List suppression rules.
    • If using Predictive Outbound, the system automatically suppresses numbers with Machine Detected dispositions for a configurable period (default is often 30 days).

Step 4.2: Flow-Level Suppression (For Non-Predictive)

If you are using Progressive Outbound or Manual Dialing, the automatic suppression may not apply. You must implement logic in the flow.

  1. Before the Outbound Call block, add a Condition block.
  2. Check the Contact Attribute for the last disposition.
    • Use the LastDisposition variable or query the Contact History via an API Call (if using custom attributes).
  3. If the last disposition was Machine Detected and the time elapsed is less than your suppression window (e.g., 30 days), route to a Hang Up block with a disposition of Suppressed.

The Trap: Hardcoding suppression in the flow without checking the timestamp.
If you simply check If LastDisposition == Machine Detected, you will suppress the number forever. You must include a timestamp check.

// Example Architect Expression for Timestamp Check
now() - lastCallTimestamp() > 30 * 24 * 60 * 60 * 1000

This expression checks if more than 30 days (in milliseconds) have passed since the last call. If true, allow the call. If false, suppress it.

5. Advanced: Handling Inbound Loop Storms

Inbound loop storms are rarer but more dangerous because they originate from external sources (e.g., a competitor’s auto-dialer or a misconfigured carrier).

  1. Inbound Flow Entry: At the start of your inbound flow, add a Call Control block with Enable Machine Detection.
  2. Early Hang-Up: Add a Condition block immediately after.
    • If MachineDetectionResult is Machine, hang up.
  3. Throttling: To prevent carrier-side loops, implement Rate Limiting on the inbound trunk.
    • Navigate to Admin > Telephony > Trunks.
    • Set a Max Concurrent Calls limit.
    • Enable Call Admission Control (CAC) if available.

Architectural Reasoning:
Inbound machine detection is tricky because you do not control the caller. A false positive here means you hang up on a legitimate customer who happens to have a robotic voice or is calling from a noisy factory floor.

  • Recommendation: Use a higher confidence threshold (80%+) for inbound machine detection.
  • Alternative: Use Speech Analytics to tag the call as Machine for reporting, but do not hang up. Instead, route it to a Queue with a Maximum Wait Time of 0 seconds, effectively dropping it after it enters the queue, or route it to a Voicemail box that does not prompt for input.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Shy Human” False Positive

The Failure Condition:
Legitimate callers are being hung up on immediately after answering. The machine detection model classifies their hesitation or quiet voice as a machine.

The Root Cause:
The confidence threshold is set too low, or the machine detection model is not tuned for the specific demographic or accent of your callers.

The Solution:

  1. Increase the Confidence Threshold in Speech Analytics from 50% to 70-80%.
  2. Review the Speech Analytics Dashboard for false positive rates.
  3. Implement a Grace Period: Do not hang up immediately. Instead, play a brief prompt: “Please press any key to continue.” If no key is pressed within 2 seconds, then hang up. This adds a human-in-the-loop verification step.

Edge Case 2: The “Long Greeting” Voicemail

The Failure Condition:
Voicemail systems with long greetings (e.g., “Hi, you’ve reached John. I’m currently in a meeting. Please leave a message…”) are not detected as machines until after the greeting finishes. By then, the IVR has already transferred the call to an agent, wasting agent time.

The Root Cause:
Machine detection relies on initial audio patterns. Long, natural-sounding greetings can mimic human speech.

The Solution:

  1. Use Keyword Spotting in conjunction with Machine Detection.
    • Configure Speech Analytics to listen for keywords like “leave a message,” “beep,” or “voicemail.”
    • If these keywords are detected, trigger a hang-up.
  2. Set a Maximum Call Duration for machine detection. If the call exceeds 10 seconds without a human interaction (DTMF input or agent transfer), hang up.

Edge Case 3: The “Fax Tone” Interference

The Failure Condition:
Calls to fax machines are detected as machines, but the fax tone (CED tone) is not always present at the start of the call. The call connects, plays silence, and then sends a fax tone. The machine detection model misses it because it only analyzes the first 3 seconds.

The Root Cause:
Fax machines often send a “Caller ID” signal before the fax tone, or they wait for a carrier signal.

The Solution:

  1. Enable Fax Detection in Speech Analytics. This is a separate model from Machine Detection.
  2. Configure the flow to check for FaxDetected attribute.
  3. If FaxDetected is true, hang up immediately.

Official References