Genesys Cloud - Main

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,

Seems that the original OP went silent after this post, and there seems to be a lot of interest in the solution.

I have attached 3 files, hopefully they will attach to this post and be able to be downloaded.

Update 480 and Get-Conversation should have the extension changed back to .json, and the 480 Capture to .i3WorkFlow, this will allow them the be imported to the actions, and workflow.

create a data table to capture the incidents, the datatable ID should be replaced in the Update 480 data action.

create a trigger on v2.detail.events.conversation.{id}.user.end and set it to the workflow above, filter by mediaType == VOICE and disconnectType == ENDPOINT to limit to the ICE timeouts of the agent/user only.

This mechanism can be used to log all of the incidents so that you can see the scale and spread of the issue. After which you can then determine the best course of action for the Set Post Flow to perform the offer to the Customer to reconnect or other appropriate action.

hope this helps, feel free to email me,

Hi,

Not sure how many people have suffered similar to the below, but thought I would share what I have done to improve the customer experience when a call drops due to agent side disconnection.

We have remote agents onshore and offshore which due to network issues outside of our control (poor home network etc) can result in callers being disconnected as the agent side of the call drops the call with a 480 Ice Idle Disconnection as an example.

Using a couple of data action's and 'post flow' call flow when a 480 iceidledisconnection is detected on the live call, the caller is prompted with a comfort message (apologising for the drop) and opportunity to return to the queue instead of being disconnected. Call returns to the original call flow/queue and to another available agent.  

Agents receiving these dropped calls are informed on the screen the caller had been previously disconnected to enable them to handle the caller with additional care.

Within the same flow I am also assigning a wrap code to make identifying when this happens easier. This also helps with reporting, for example during a period today 47 drops were detected and 42 callers of those 47 chose to be put back in the queue.

Happy to share the flows and data actions if anyone is interested.

Thanks,