- Newest
- Most votes
- Most comments
When an agent reject the task, the task is put back into the queue to be picked up by the next available agent (chosen by longest idle agent that is qualified base on Routing Profile).
There is no wait as we dont want to add more wait time for this task to be picked up. The problem you mentioned is common when that is the only agent available and the task will seems like an endless loop to keep going to the same agent. This is the same for any contacts.
So what exactly is the use case? What I have seen is agent would like to take other contacts in queue like voice or chat before tasks. If so, you can setup your Routing Profile so Task is shown as lower Priority than Voice and Chat. So Agent will pick up voice / chat contacts before Task. If priority is the same in RP for everything, longest contacts (regardless of channel) will be presented to agent.
If agent wants to stop contacts from coming, set your agent status to break or any non-productive status first while a contact is being presented to the agent to prevent contacts to come.
There wouldn't be an infinite loop unless the agent causes it. When an agent rejects the call they then have to close the contact. Until they close the contact they will not be set to available again.
Relevant content
- Accepted Answerasked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
Thank you for the response, very insightful
Is there any way that it's possible to delay when the task loops back to that single available agent in queue? I believe there is a "waitTimeInSecs" parameter that can be configured in .startTaskContact API, but I don't see what the default configuration is for that and whether it is that actual parameter that controls the wait-time for a task to re-appear within that queue.
On a side note, there is also a delay option in Routing profiles for each queues, is that delay option the same as "waitTimeInSecs" or does that delay refer to how long an agent has to accept or reject a task until it goes onto next agent or next priority?
I noticed also when clicking the Reject button for a task, there is an attribute called timesDeferred that gets incremented to 1. Is this also a built in property? I can't seem to find documentation regarding these attributes.
Both of the mentioned items are not for re-queue purposes. the time you specified in API you mentioned is only for creating a new task and how long you want to delay the creation. Use case would be a promised schedule callback reminder for the agent hours later.
The Delay in RoutingProfile (RP) is for routing purposes to determine how long an agent will delay in getting a contact from queue by contact queued time. So if the task already routed to an agent, it would have already met the delay requirement. What can be done here is if the agent transfer this task to ANOTHER queue that the agent's RP has a delay of a long time. But no matter how long it is, once the agent qualified to take the task, the same thing would happen if that is the only agent in queue.
So if you can tell me what is the use case and the scenario that this is happening, we can try to design a routing strategy that this does not happen. But not possible when there is a lonely agent handling all the contacts, that poor agent will most certainly get all of them. Reject is for the agent to take a break (with changing of agent status to not available) without impacting the Customer Experience too much.