Genesys Cloud CX - Beta HQ

My company joined the beta for callback retries, but I am not receiving the second attempt. Has anyone else been able to successfully get this to work?

#CustomerCallbacks, #Callbacks, #CallbackFeature, 

------------------------------
Mark Whitchurch
Senior Engineer
IHG Hotels & Resorts
------------------------------

We have the retries working, in test, just by setting the queue parameters as the documentation suggests.  But after the 'Time between retries' has elapsed the callback won't be dispatched again until there is another change in state of the queue, i.e. an agent becomes Idle by either going on queue or completing a call.

But we have found that the system is including 'Available' agents in the calculation with the Pacing Modifier to determine how many callbacks to dispatch.  This seems to be contrary to the newly released Customer first callbacks overview article which states the calculation uses the number of 'on queue' agents.  We don't consider that 'Available' (logged in but not On-queue) should be counted as 'on queue'.

We would be interested in other customer's opinions on this.

My company joined the beta for callback retries, but I am not receiving the second attempt. Has anyone else been able to successfully get this to work?

#CustomerCallbacks, #Callbacks, #CallbackFeature, 

------------------------------
Mark Whitchurch
Senior Engineer
IHG Hotels & Resorts
------------------------------

The only documentation I've seen is to enable the 'Retry Attempt Controls' in the queue. I've tried setting the agent 'Available' and then 'On Queue', back and forth many times after the 2-minute timeframe, but I never receive the second callback. I had 'Answering Machine' set to 'Hangup' but then tried to route it to a flow that plays an announcement before disconnect. Was there something else needed? Can you share that documentation?

I currently only have one agent in the queue that I'm testing with, so it should immediately send the second callback. I also no longer see an interaction in the queue.

We have the retries working, in test, just by setting the queue parameters as the documentation suggests.  But after the 'Time between retries' has elapsed the callback won't be dispatched again until there is another change in state of the queue, i.e. an agent becomes Idle by either going on queue or completing a call.

But we have found that the system is including 'Available' agents in the calculation with the Pacing Modifier to determine how many callbacks to dispatch.  This seems to be contrary to the newly released Customer first callbacks overview article which states the calculation uses the number of 'on queue' agents.  We don't consider that 'Available' (logged in but not On-queue) should be counted as 'on queue'.

We would be interested in other customer's opinions on this.

My company joined the beta for callback retries, but I am not receiving the second attempt. Has anyone else been able to successfully get this to work?

#CustomerCallbacks, #Callbacks, #CallbackFeature, 

------------------------------
Mark Whitchurch
Senior Engineer
IHG Hotels & Resorts
------------------------------

It sounds like you have the queue set up like we have, i.e. the Retry Attempt Controls are set and Live Voice and Answering Machine are set to Transfer to a Flow.

The Callback should show in the Queue Activity window until it has reached the limit of retries. 

If you display the Wrap-up column in the Interactions view you should see ININ-OUTBOUND-NO-ANSWER or ININ-OUTBOUND-BUSY or ININ-OUTBOUND-DISCONNECT after the first callback attempt.  If you are not seeing those results, then GC may not be seeing the correct result for the first callback call and so isn't retrying.  If you see Wrap-up = ININ-OUTBOUND-TRANSFERRED-TO-FLOW, then GC considers the callback answered and won't retry, you have to then build retries into the flow by creating a new callback.

The only documentation I've seen is to enable the 'Retry Attempt Controls' in the queue. I've tried setting the agent 'Available' and then 'On Queue', back and forth many times after the 2-minute timeframe, but I never receive the second callback. I had 'Answering Machine' set to 'Hangup' but then tried to route it to a flow that plays an announcement before disconnect. Was there something else needed? Can you share that documentation?

I currently only have one agent in the queue that I'm testing with, so it should immediately send the second callback. I also no longer see an interaction in the queue.

We have the retries working, in test, just by setting the queue parameters as the documentation suggests.  But after the 'Time between retries' has elapsed the callback won't be dispatched again until there is another change in state of the queue, i.e. an agent becomes Idle by either going on queue or completing a call.

But we have found that the system is including 'Available' agents in the calculation with the Pacing Modifier to determine how many callbacks to dispatch.  This seems to be contrary to the newly released Customer first callbacks overview article which states the calculation uses the number of 'on queue' agents.  We don't consider that 'Available' (logged in but not On-queue) should be counted as 'on queue'.

We would be interested in other customer's opinions on this.

My company joined the beta for callback retries, but I am not receiving the second attempt. Has anyone else been able to successfully get this to work?

#CustomerCallbacks, #Callbacks, #CallbackFeature, 

------------------------------
Mark Whitchurch
Senior Engineer
IHG Hotels & Resorts
------------------------------

It sounds like you have the queue set up like we have, i.e. the Retry Attempt Controls are set and Live Voice and Answering Machine are set to Transfer to a Flow.

The Callback should show in the Queue Activity window until it has reached the limit of retries. 

If you display the Wrap-up column in the Interactions view you should see ININ-OUTBOUND-NO-ANSWER or ININ-OUTBOUND-BUSY or ININ-OUTBOUND-DISCONNECT after the first callback attempt.  If you are not seeing those results, then GC may not be seeing the correct result for the first callback call and so isn't retrying.  If you see Wrap-up = ININ-OUTBOUND-TRANSFERRED-TO-FLOW, then GC considers the callback answered and won't retry, you have to then build retries into the flow by creating a new callback.

The only documentation I've seen is to enable the 'Retry Attempt Controls' in the queue. I've tried setting the agent 'Available' and then 'On Queue', back and forth many times after the 2-minute timeframe, but I never receive the second callback. I had 'Answering Machine' set to 'Hangup' but then tried to route it to a flow that plays an announcement before disconnect. Was there something else needed? Can you share that documentation?

I currently only have one agent in the queue that I'm testing with, so it should immediately send the second callback. I also no longer see an interaction in the queue.

We have the retries working, in test, just by setting the queue parameters as the documentation suggests.  But after the 'Time between retries' has elapsed the callback won't be dispatched again until there is another change in state of the queue, i.e. an agent becomes Idle by either going on queue or completing a call.

But we have found that the system is including 'Available' agents in the calculation with the Pacing Modifier to determine how many callbacks to dispatch.  This seems to be contrary to the newly released Customer first callbacks overview article which states the calculation uses the number of 'on queue' agents.  We don't consider that 'Available' (logged in but not On-queue) should be counted as 'on queue'.

We would be interested in other customer's opinions on this.

My company joined the beta for callback retries, but I am not receiving the second attempt. Has anyone else been able to successfully get this to work?

#CustomerCallbacks, #Callbacks, #CallbackFeature, 

------------------------------
Mark Whitchurch
Senior Engineer
IHG Hotels & Resorts
------------------------------