Genesys Cloud - Main

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Not out of the question, Jan.  As we explore implementing this - we can see what optionality we can introduce.  

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Sounds to me like there needs to be several options. (Turn it off, Turn it on only if Agent is Online and On Queue, Turn it on if Agent is Online regardless of Queue Status Turn on always and so on. There may even be opportunity to link to WFM and consider scheduled agent activity - Turn on if agent is due on queue within the next X minutes....)

Given the asynchronous nature of some of these interactions,  can see that you won't find a "one size fits all" solution and whatever you do, someone will say "but in THIS instance...."

Not out of the question, Jan.  As we explore implementing this - we can see what optionality we can introduce.  

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

Is this "feature" properly described anywhere 'cos I haven't found it.

How long will it wait for that LAST Agent?

Adding a dummy Agent to the mix means we have to tell people to ignore Dummy when they look at their views etc. 

Poor design decision which may be why there's little documentation?

Sounds to me like there needs to be several options. (Turn it off, Turn it on only if Agent is Online and On Queue, Turn it on if Agent is Online regardless of Queue Status Turn on always and so on. There may even be opportunity to link to WFM and consider scheduled agent activity - Turn on if agent is due on queue within the next X minutes....)

Given the asynchronous nature of some of these interactions,  can see that you won't find a "one size fits all" solution and whatever you do, someone will say "but in THIS instance...."

Not out of the question, Jan.  As we explore implementing this - we can see what optionality we can introduce.  

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

This isn't a proper feature, just a workaround brainchild of some frustrated administrators :).

The length of time it tries the dummy agent is down to how you configure the queue routing. I have configured it to route to preferred agents and try them for the shortest possible time (2 seconds), then timeout to my main routing method which is Bullseye. This means there will essentially be a 2 second delay built into the call routing as it tries the dummy agent for 2 seconds before progressing with your actual routing strategy.

You are correct that the dummy agent shows up on views, however, we haven't had any reports of this being frustrating or an issue to either team leaders or users.

And lastly,  I'm afraid that this thread is the only documentation you'll find on this 'feature'. Good luck :D

Is this "feature" properly described anywhere 'cos I haven't found it.

How long will it wait for that LAST Agent?

Adding a dummy Agent to the mix means we have to tell people to ignore Dummy when they look at their views etc. 

Poor design decision which may be why there's little documentation?

Sounds to me like there needs to be several options. (Turn it off, Turn it on only if Agent is Online and On Queue, Turn it on if Agent is Online regardless of Queue Status Turn on always and so on. There may even be opportunity to link to WFM and consider scheduled agent activity - Turn on if agent is due on queue within the next X minutes....)

Given the asynchronous nature of some of these interactions,  can see that you won't find a "one size fits all" solution and whatever you do, someone will say "but in THIS instance...."

Not out of the question, Jan.  As we explore implementing this - we can see what optionality we can introduce.  

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

I have it working with a Dummy Argent thanks to here.

When I asked "How long will it wait for that LAST Agent?" I was hoping someone from Genesys would explain how the in-built feature works - how long it waits for the last Agent before moving.<o:p></o:p>

This isn't a proper feature, just a workaround brainchild of some frustrated administrators :).

The length of time it tries the dummy agent is down to how you configure the queue routing. I have configured it to route to preferred agents and try them for the shortest possible time (2 seconds), then timeout to my main routing method which is Bullseye. This means there will essentially be a 2 second delay built into the call routing as it tries the dummy agent for 2 seconds before progressing with your actual routing strategy.

You are correct that the dummy agent shows up on views, however, we haven't had any reports of this being frustrating or an issue to either team leaders or users.

And lastly,  I'm afraid that this thread is the only documentation you'll find on this 'feature'. Good luck :D

Is this "feature" properly described anywhere 'cos I haven't found it.

How long will it wait for that LAST Agent?

Adding a dummy Agent to the mix means we have to tell people to ignore Dummy when they look at their views etc. 

Poor design decision which may be why there's little documentation?

Sounds to me like there needs to be several options. (Turn it off, Turn it on only if Agent is Online and On Queue, Turn it on if Agent is Online regardless of Queue Status Turn on always and so on. There may even be opportunity to link to WFM and consider scheduled agent activity - Turn on if agent is due on queue within the next X minutes....)

Given the asynchronous nature of some of these interactions,  can see that you won't find a "one size fits all" solution and whatever you do, someone will say "but in THIS instance...."

Not out of the question, Jan.  As we explore implementing this - we can see what optionality we can introduce.  

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?

It won't wait for Last Agent, it will try another agent if the Last Agent isn't available, or if the they don't answer when available.

I have it working with a Dummy Argent thanks to here.

When I asked "How long will it wait for that LAST Agent?" I was hoping someone from Genesys would explain how the in-built feature works - how long it waits for the last Agent before moving.<o:p></o:p>

This isn't a proper feature, just a workaround brainchild of some frustrated administrators :).

The length of time it tries the dummy agent is down to how you configure the queue routing. I have configured it to route to preferred agents and try them for the shortest possible time (2 seconds), then timeout to my main routing method which is Bullseye. This means there will essentially be a 2 second delay built into the call routing as it tries the dummy agent for 2 seconds before progressing with your actual routing strategy.

You are correct that the dummy agent shows up on views, however, we haven't had any reports of this being frustrating or an issue to either team leaders or users.

And lastly,  I'm afraid that this thread is the only documentation you'll find on this 'feature'. Good luck :D

Is this "feature" properly described anywhere 'cos I haven't found it.

How long will it wait for that LAST Agent?

Adding a dummy Agent to the mix means we have to tell people to ignore Dummy when they look at their views etc. 

Poor design decision which may be why there's little documentation?

Sounds to me like there needs to be several options. (Turn it off, Turn it on only if Agent is Online and On Queue, Turn it on if Agent is Online regardless of Queue Status Turn on always and so on. There may even be opportunity to link to WFM and consider scheduled agent activity - Turn on if agent is due on queue within the next X minutes....)

Given the asynchronous nature of some of these interactions,  can see that you won't find a "one size fits all" solution and whatever you do, someone will say "but in THIS instance...."

Not out of the question, Jan.  As we explore implementing this - we can see what optionality we can introduce.  

Hi,

Personally I would much rather see an option for Last Agent Routing to require the agent to be on-queue in the target queue, than turning the feature off.
If the agent isn't in the queue they should no longer be considered for Last Agent routing.

Now we have to build this logic with Preferred routing.

All - please note that we do have an idea on the backlog to 'turn off' Last Agent Routing by default.  I don't have an ETA but I know this is something that would bring some relief so I'm hopeful we can get to it some time this year.

Feel free to vote on and follow this idea:  https://genesyscloud.aha.io/ideas/ideas/INB-I-1307

Thanks Jan, that's worked. It's always the simple things :D

For anyone wanting to use this functionality its worthwhile noting that the routing doesn't immediately move on to the standard routing when it sees the preferred agent is not online, it will wait the full specified preferred agent routing duration as set in the queue first. This means there will be some delay to every interaction using this routing method (the shortest preferred agent routing duration is 2 seconds, but you may be using preferred agent routing for other purposes and have a longer duration set). In most cases a 2 second delay shouldn't matter but worthwhile noting.

Thanks for your help all.

Have you added the dummy user to the queue?

From another thread it seems you need to do that for it to work.

Thanks Lawrence.

I have just copied the logic to the web message flow and I'm having the same results. Please see attached screenshots of the transfer to queue action (the agent score pair is hard coded straight into the action), the workspace report and the queue configuration.

Note that on the Workspace report it says that preferred agents were requested and it has correctly listed the name of the agent ("Default Preferred Agent"), however, when looking at the analytics API (see below customer participant code) it shows that it has requested and used "last" routing the second time I messaged in. When looking at the ACD participant code on the API, you can see the agent score pair is listed.

I also have debug logging set up in the flow and can track that it is following the correct path to the transfer to queue action.

Hey Russell, 

Thanks! Let's see if we can nut this down - 

To test, have you tried doing the same on a normal web message interaction and see if it repeats itself by using the last agent routing still? If this is the case, there might be an error in the flow setup when creating the agent score pair, though I expect not as it would be hard coded - but just going down the list of cases. It also sounds like you've got the queues set up correctly too, which is exactly what I have set up in my orgs for these scenarios, though I have the second step as standard routing after. If you wanted to share a screenshot of your flow where you make the agent score pair I can take a look. And even throw this into a test queue of my own to try and replicate. 

Hello Lawrence,

First of all, thanks for the great idea, I always like seeing ingenuity like this :)

I am trying to achieve the same intent and have just set up routing for our WhatsApp's to a 'default preferred agent' which is has never logged in as you have described. However, when I have tested this and looked at the analytics API it seems that it is still using "last" routing, even though the agent score pair is listed there as well. It just doesn't seem to try routing to that preferred agent.

I have checked the queue is set up on preferred agent routing then spills out to bullseye routing.

Do you know if there has been a change where Genesys native behaviour will default to "last" routing if it sees the preferred agent is not online?

Any other thoughts? 

Many thanks for your help.

Hey Petter, 

You can create a user (that is never used or logged in so wouldn't take a license) and then set up preferred agent routing to always go to that userID. Then as it will never be able to see that user online, it will default to your next type of routing and drop the last agent part. 

Is it possible to disable the default last agent routing? 

When an agent has answered a message via the configurated facebook messenger there is a threading timeline of 72 hour. This also means that the agent gets the interaction back even thou the agent is not active on the queue any more if there is a new message in the interaction within the 72 hours. 

The interaction will now be routed to the previous agent if the agent is on-queue (queue membership is not taken into consideration). 

I would like to keep the threading timeline of 72 hours but disable the last agent part of the routing if that is possible?