Genesys Cloud - Developer Community!

 View Only

Sign Up

Back to discussions
Expand all | Collapse all

Detecting "customer did not answer" on callbacks when carrier voicemail picks up

  • 1.  Detecting "customer did not answer" on callbacks when carrier voicemail picks up

    Posted 6 hours ago

    Hi all,

    We're building automatic retry logic for outbound sales callbacks (created via POST /api/v2/conversations/callbacks) and need to reliably detect when the customer did not actually answer. We've hit a wall and would appreciate input before redesigning.

    Setup: Agent-first ACD callback, voice, mobile numbers in Colombia.

    Test performed: We placed a callback to our own mobile and deliberately did not answer. It rang ~33 seconds, the carrier voicemail picked up, the agent heard the greeting and hung up ~13 seconds later.

    Observed on v2.analytics.conversation.{id}.metrics:

    

    

    18:34:09.176  nOffered
    

    18:34:16.835  tAnswered
    

    18:34:17.154  tAcd
    

    18:34:17.461  nOutbound, tTalk
    

    18:34:19.744  tContacting, tFirstDial
    

    18:34:53.150  nConnected, tDialing, tFirstConnect   <-- carrier voicemail answered
    

    18:35:00.212  tConnected, tTalk, tActiveCallback
    

    18:35:06.296  tAcw, tHandle, tTalkComplete, tActiveCallbackComplete

    tCallbackNotReached was never emitted. Genesys recorded this callback as successful.

    What we have ruled out:

    • tCallbackNotReached - appears to fire only when nothing answers at all. Since virtually every mobile here has carrier voicemail enabled by default, this covers almost none of our real "no answer" cases.
    • tFirstConnect and participant connectedTime - populated identically whether a human or a voicemail answers.
    • WebSocket v2.routing.queues.{id}.conversations.callbacks - same limitation; the customer participant reaches connected either way.
    • EventBridge analytics detail events - we checked the published schemas for .outbound, .customer.start, .customer.end, .acd.start and .acd.end; none carry dispositionAnalyzer / dispositionName.

    We understand agent-first callbacks don't run call analysis, so the information may simply not exist. Our questions:

    1. Is there any supported way to obtain answering machine detection on an callback?
    2. With customer-first callbacks, is the AMD result exposed anywhere beyond routing to an Architect flow - a field on the conversation/participant, or an analytics dimension indicating machine vs. live voice? Or is a flow outcome the only way to surface it?
    3. In customer-first, does tCallbackNotReached fire when carrier voicemail answers, or is that also counted as delivered?
    4. In customer-first, does each automatic retry reuse the same conversationId or create a new one?
    5. Has anyone solved this without moving to Outbound Dialer campaigns?

    Wrap-up codes are our current fallback, but we'd rather not depend on agent input.

    Thanks!


    #PlatformAPI

    ------------------------------
    Omar Sinisterra
    NA
    ------------------------------


  • 2.  RE: Detecting "customer did not answer" on callbacks when carrier voicemail picks up

    Posted 5 hours ago
    Hi,
     
    Based on the documentation, I believe the main limitation is that agent-first callbacks do not perform Call Analysis (AMD). Without AMD, Genesys has no supported mechanism to distinguish between a live answer and a carrier voicemail. Both scenarios simply result in a successful SIP connection, which is why tCallbackNotReached is not emitted once the voicemail answers.
     
    From the Call Analysis documentation:
     
    Call Analysis is used to classify the outcome of an outbound call (live voice, answering machine, SIT tone, fax, etc.).
     
    https://help.mypurecloud.com/glossary/call-analysis/
     
    Because your scenario uses callbacks rather than an Outbound Dialer campaign, the AMD result is not available.
     
    One possible approach that came to mind (although I haven't validated it yet) would be to inspect the SIP signaling instead of relying on Analytics events.
     
    For example:
     
    Trigger a Workflow from v2.detail.events.conversation.{id}.customer.end.
    Retrieve the conversationId.
    Call the Telephony SIP Traces API:
     
    This would not provide AMD, and I would not expect it to identify voicemail directly, since both a human answer and carrier voicemail typically produce a SIP 200 OK.
     
    However, depending on the carrier, it may be worth comparing SIP traces from:
     
    a call answered by a person, and
    a call forwarded to carrier voicemail,
     
    to see whether any forwarding-related SIP headers (such as Diversion, History-Info, Reason, or other carrier-specific headers) are present.
     
    If the carrier exposes this information consistently, it could potentially be used as a custom heuristic for callback retries. Of course, this would be carrier-dependent and not equivalent to Genesys AMD.
     
    Given that this is a callback scenario rather than an Outbound Dialer campaign, I think that's probably the only technical avenue worth exploring beyond wrap-up codes.


    ------------------------------
    Raphael Poliesi
    ------------------------------



Related Content