Determine outcome of 'transfer to group' during call flow using API?

[Zack_Schaffter]

Hey all, relatively new to genesys, hoping to gain some insight into a problem I'm trying to solve.

Summary: I'm looking for a way in which our backend system can determine the outcome of a 'Transfer to Group' action being triggered from an inbound call flow. The 'outcomes' being the customer either connects with an agent (success) or not (failure).

I've identified a few main flows:

• Connected (happy path) - Customer calls in, proceeds through IVR, is transferred to the group, agent successfully picks up
• Transfer failed - Customer calls in, proceeds through IVR, transfer fails (ex: no agents pickup)
• Pre-transfer abandon - Customer calls in, then abandons the IVR before the transfer begins
• In-transfer abandon - Customer calls in, the group transfer begins, then customer abandons before agent picks up

Ive also set up a trigger to emit the v2.detail.events.conversation.{id}.customer.end events to my backend (Im throwing these into a pubsub that a consumer service then picks up).

So ideally, our backend system would (1) catch the customer.end event, (2) use the conversation ID to retrieve the conversation details, and (3) use that data to determine the "result" of the inbound call that's already ended.

At first I thought this idea had legs, since the IVR is present as its own participant in the conversation object, and its flow property seemed to have an exitReason prop that differed on whether it succeeded or failed:

// Call connected
"flow": {
                "endingLanguage": "en-us",
                "entryReason": "tel:+15550123456",
                "entryType": "dnis",
                "exitReason": "TRANSFER", // I thought this meant it had succeeded, but I think it only means the transfer has started and hasn't failed yet
                "flowId": "XXXX-XX-XX-XXXX",
                "flowName": "My Awesome IVR ",
                "flowType": "INBOUNDCALL",
                "flowVersion": "15.0",
                "startingLanguage": "en-us",
                "transferTargetAddress": "XXX-XX-XX-XXXX",
                "transferTargetName": "Genesys Group #4",
                "transferType": "GROUP"
},

// Transfer failed
"flow": {
                "endingLanguage": "en-us",
                "entryReason": "tel:+15550123456",
                "entryType": "dnis",
                "exitReason": "DISCONNECT", 
                "flowId": "XXXX-XX-XX-XXXXX",
                "flowName": "My Awesome IVR",
                "flowType": "INBOUNDCALL",
                "flowVersion": "15.0",
                "startingLanguage": "en-us"
},

However in practice it seems like if the user disconnects during the transfer attempt, then the flow data looks the same as if the call was successful. Which means the exitReason of TRANSFER probably only means the transfer has begun and never failed (either because it succeeded, or the customer disconnected)

So, is there anything else within the conversation data I could use to glean whether an agent picked up the inbound call during the transfer to group attempt?

Thanks!

[Eos_Rios]

Transfer analytics are an area they give no damns about based on it having been a future consideration for years now.

From the perspective of an individual flow or queue once they've transferred a call it's no longer their problem so there is no tracking or verification of what happens to it next.

The only way to determine that is literally mining the segment order to determine what happened next for yourself and who and where it went and if it got there successfully and even then about half of it is guesswork.

[Zack_Schaffter]

Thanks for the reply Eos_Rios!

That's unfortunate to hear, but I appreciate the historical context & link to the proposal.

Also interesting about the segment mining approach you mentioned — to clarify are you saying we can loosely determine if an agent picked up by scanning each user participant's segment list for a particular action?

Or more broadly, does the segments list reflect actions taken by each participant? My tests do show that an agent who 'picks up' has a segment of type interact (examples below), but I'm not sure if that segment type might possibly appear for other type of "interactions".

(taking this with a grain of salt, mainly looking for any threads to follow)

Example 1 - User who picked up:

                {
                  "conference": false,
                  "segmentEnd": "2024-11-01T21:57:05.803Z",
                  "segmentStart": "2024-11-01T21:57:04.452Z",
                  "segmentType": "alert"
                },
                {
                  "conference": false,
                  "disconnectType": "client",
                  "segmentEnd": "2024-11-01T21:57:17.047Z",
                  "segmentStart": "2024-11-01T21:57:05.803Z",
                  "segmentType": "interact"
                }
              ]

Example 2 - User who did not pick up:

"segments": [
                {
                  "conference": false,
                  "disconnectType": "peer",
                  "segmentEnd": "2024-11-01T21:57:05.952Z",
                  "segmentStart": "2024-11-01T21:57:04.461Z",
                  "segmentType": "alert"
                }
              ]

[Eos_Rios]

A lot of it depends on the type of transfer and your system settings.

Transfers direct to another agent come out slightly different than transfers to a queue.
In both cases they can have more detail if the agent isn't on forced answer.

I generally start by finding my origins - the rep who has the transferred metric, and then looking for the immediate next queue if present and agent if present.

Conversations are a tree

• Conversation
• • Participants
• • • Sessions
• • • • Segments

With segments having their own distinct and potentially overlapping timelines broken out by the type of activity they encompass.

So yes, segments reflects the actions or states of a given participant they fall under and can be used to determine what happened at a given point in time or a sequence of events.

It's not necessarily easy to construct but it's mostly there.