Genesys Cloud - Main

Hey guys, 

Quick question... 

When an agent transfers an email to another queue, the interaction is stripped of the priority and the priority is set as 0. This is causing issues as emails become 'stuck', trumped by other emails with the desired / correct priority. 

It doesn't seem that you can transfer emails to an inbound email flow - thus enabling the assigning of priority as the email is transferred to another email queue. 

We could always 'foward' the email interaction to the queue, ensuring the correct priority is assigned, but this then creates a new interaction and results in reporting stats being inaccurate (handling time for instance). 

Any suggestions / solutions appreciated. 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Hey guys, 

Quick question... 

When an agent transfers an email to another queue, the interaction is stripped of the priority and the priority is set as 0. This is causing issues as emails become 'stuck', trumped by other emails with the desired / correct priority. 

It doesn't seem that you can transfer emails to an inbound email flow - thus enabling the assigning of priority as the email is transferred to another email queue. 

We could always 'foward' the email interaction to the queue, ensuring the correct priority is assigned, but this then creates a new interaction and results in reporting stats being inaccurate (handling time for instance). 

Any suggestions / solutions appreciated. 

Nope. This isn't a solution. When the in queue ACD transfer sends the interaction back into the 'same' queue (with priority stamped) - it creates a little loop where the interaction keeps transferring itself back into the queue - this stops after about 10 cycles and leaves the interaction in the queue with the desired priority. However, these 'cycles' of the interaction repeatidly hitting the queue again are captured within the reporting 'stats' for the queue - reporting the 1 interaction as 11 (due to the loop routing of the interaction). 

Back to the original question - how do others deal with priority / skills stripping of email interactions when they are transferred from one queue to another? Surely there has to be a solution to this? 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Hey guys, 

Quick question... 

When an agent transfers an email to another queue, the interaction is stripped of the priority and the priority is set as 0. This is causing issues as emails become 'stuck', trumped by other emails with the desired / correct priority. 

It doesn't seem that you can transfer emails to an inbound email flow - thus enabling the assigning of priority as the email is transferred to another email queue. 

We could always 'foward' the email interaction to the queue, ensuring the correct priority is assigned, but this then creates a new interaction and results in reporting stats being inaccurate (handling time for instance). 

Any suggestions / solutions appreciated. 

Nope. This isn't a solution. When the in queue ACD transfer sends the interaction back into the 'same' queue (with priority stamped) - it creates a little loop where the interaction keeps transferring itself back into the queue - this stops after about 10 cycles and leaves the interaction in the queue with the desired priority. However, these 'cycles' of the interaction repeatidly hitting the queue again are captured within the reporting 'stats' for the queue - reporting the 1 interaction as 11 (due to the loop routing of the interaction). 

Back to the original question - how do others deal with priority / skills stripping of email interactions when they are transferred from one queue to another? Surely there has to be a solution to this? 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Hey guys, 

Quick question... 

When an agent transfers an email to another queue, the interaction is stripped of the priority and the priority is set as 0. This is causing issues as emails become 'stuck', trumped by other emails with the desired / correct priority. 

It doesn't seem that you can transfer emails to an inbound email flow - thus enabling the assigning of priority as the email is transferred to another email queue. 

We could always 'foward' the email interaction to the queue, ensuring the correct priority is assigned, but this then creates a new interaction and results in reporting stats being inaccurate (handling time for instance). 

Any suggestions / solutions appreciated. 

Hi Matthew,

You can save the priority in Participant Data, then in the Initial State of your In-Queue flow you get the value and set priority.

This will not show the correct priority in Queue Activity as it doesn't update the view when priority changes, but it will route based on the new priority.

Nope. This isn't a solution. When the in queue ACD transfer sends the interaction back into the 'same' queue (with priority stamped) - it creates a little loop where the interaction keeps transferring itself back into the queue - this stops after about 10 cycles and leaves the interaction in the queue with the desired priority. However, these 'cycles' of the interaction repeatidly hitting the queue again are captured within the reporting 'stats' for the queue - reporting the 1 interaction as 11 (due to the loop routing of the interaction). 

Back to the original question - how do others deal with priority / skills stripping of email interactions when they are transferred from one queue to another? Surely there has to be a solution to this? 

I think I may have found a workaround for this. I've done some testing and it appears to achieve the desired result...

By creating a very simple email 'in-queue' flow that contains only a 'Transfer to ACD' action, that is then assigned to the relevant queue, when an agent transfers the email interaction to the queue in question and the email is queued (99 times out of 100 within our environment the email will be queued) - the in queue action will execute, remapping the interaction to the queue in question but also 'stamping' the required priority upon the interaction (as defined within the in queue flow Transfer to ACD action). If that makes sense!

Hey guys, 

Quick question... 

When an agent transfers an email to another queue, the interaction is stripped of the priority and the priority is set as 0. This is causing issues as emails become 'stuck', trumped by other emails with the desired / correct priority. 

It doesn't seem that you can transfer emails to an inbound email flow - thus enabling the assigning of priority as the email is transferred to another email queue. 

We could always 'foward' the email interaction to the queue, ensuring the correct priority is assigned, but this then creates a new interaction and results in reporting stats being inaccurate (handling time for instance). 

Any suggestions / solutions appreciated.