FAQs: Callbacks

When a callback is initiated, Genesys Cloud creates a callback interaction for the agent assigned to handle it. This interaction represents the overall callback process and includes multiple sub-tasks, such as:

• The agent accepting the callback
• Initiating the outbound call to the customer
• The system dialing the number
• The call connecting
• The voice conversation between the agent and customer
• Any additional attempts made if a previous call was disconnected

After the agent accepts the callback, dials the customer, and the call connects, the voice call between the agent and the customer begins. Genesys Cloud tracks this voice call as a separate interaction. After the conversation ends, the agent transitions to After Call Work (ACW) to apply a wrap-up code.

• Participant-level ACW – By default, Genesys Cloud uses participant-level ACW. In this mode, when an agent assigns a wrap-up code to a callback, the wrap-up code applies to the agent who is the conversation participant. When the wrap-up code is applied at the participant level, the wrap-up code is tagged to at least two interactions: the first being the overall callback conversation that is assigned by Genesys Cloud and the subsequent ones being the actual voice call communication that happened between the agent and the customer. Because wrap-up codes are applied at the participant level, this configuration can sometimes affect callback performance metrics and analysis, depending on how reporting data is aggregated.
• Communication-level ACW – When communication-level ACW is enabled, the wrap-up code is applied only to the voice call interaction after the agent moves to ACW. If for some reason the agent does not accept the callback, Genesys Cloud automatically applies the wrap-up code at the participant level instead. For more information, see Enable communication level After Call Work and automatic callbacks.

Because calls and callbacks are both considered to be call interactions, we recommend that you do not configure utilization to allow these media types to interrupt each other. This configuration can cause longer than anticipated wait times for customers who choose a callback. By default, the system is set to not allow calls and callbacks to override each other.

When a caller schedules a callback within the call route, the callback holds the caller’s place in queue. If new calls can move ahead of callbacks, the system will not hold the callback customer’s position in queue. This situation can cause less than desirable behavior; for example, if the caller’s estimated wait time is 30 minutes and they take the callback option, but do not receive a return call for longer than 30 minutes.

Yes. The Callback utilization setting applies to all callbacks, including ACD-routed callbacks. The maximum number of concurrent callback interactions is the value set for Callback on the Contact Center > Utilization page. However, agents participating in campaigns will receive one preview per campaign, regardless of that setting.

Genesys Cloud checks for eligible callbacks or slots, in these scenarios:

• An agent goes on queue
• An agent completes a call and is not pending in off queue status
• A callback arrives in the customer first callback queue
• Genesys Cloud dispatches an eligible callback

For answering machines, the only available configuration is to transfer the customer first callback to an Architect inbound flow. Settings such as Post Connect Call Analysis, Answering Machine Detection, and Beep Detection are enabled by default.

Genesys Cloud uses the site the organization sets as default.

Yes, customer first callbacks are configured per queue. If you configure the scheduled callback queue as Customer First, then Genesys Cloud dials the callback customer before the interaction connects to an agent.

Yes, in Genesys Cloud, customer first callbacks support agent-owned callbacks. For more information, see Customer first callbacks overview.

If Genesys Cloud detects an answering machine, queue configuration options can transfer the callback to an Architect flow. For all other interaction progress outcomes, Genesys Cloud dispositions the interaction with the outcome code. Genesys Cloud does not support the ability to retry unsuccessful outcomes.

The customer first callback keeps its place in queue from the time of the callback booking and its placement into the queue. When the callback Position in Queue is 1, the callback is eligible to be dialed out and has the highest priority, unless custom priority overrides take place as part of Architect inbound flows.

To control the pace of dispatching callbacks, use the Pacing Modifier setting.

When you use this modifier, Genesys Cloud calculates a coefficient that is multiplied by the number of agents that are logged in to the queue to determine the number of callbacks initiated at one time. If you notice that your callbacks are not dispatching, you can either increase the pacing modifier under Admin > Queues > Callback, or you can increase the number of agents in the queue.

Administrators can configure Genesys Cloud to start callbacks automatically when agents do not start a callback within the specified period. Using this option, administrators can also end callbacks after the completion of ACW, at the expiry of the set duration. 

To enable this option, set the Enforce Communication Level After Call Work (ACW) at the organization level and then set the required options at the queue level. For more information on automatic callbacks that agents receive, see Place, transfer, and dismiss a callback. For more information on agent’s after call work view, see Complete after contact work (ACW). 

For email and messaging interactions, and inbound callbacks, when you use preferred agent routing, Genesys Cloud no longer attempts to route the interaction to the last agent who handled it.

Scheduled callbacks, however, is unaffected by preferred agent routing. For more information, see Advanced routing overview.

Genesys Cloud does not automatically cancel the callback.

Best practice recommends not setting agent utilization that allows callbacks to interrupt calls. This configuration may create a situation in which real-time calls are answered before a callback is placed, thereby preventing the position in queue from being held.

Consider these scenarios:

• If utilization is set to prevent calls from interrupting callbacks, and both calls and callbacks go through a single queue, the system attempts the callback before the caller reaches an agent. In that situation, the customer’s phone line may be busy and the callback will not succeed. This situation may result in the agent rescheduling another callback and then receiving the call from the customer, which leaves the rescheduled callback in the queue.
• If multiple queues exist, the customer could possibly reach an agent before the agent places the callback. If the customer reaches an agent and the callback is still in queue, the system continues to route the callback to an available agent.

The agent must manually reschedule the callback for another time. If a caller ID and a caller name are specified on a callback, the values are transferred if the callback is rescheduled. For more information, see Schedule callbacks during a voice interaction and Schedule a callback in a script.

Setting callable times for callbacks only applies to campaign-related callbacks. This feature is not available for in-queue callbacks.

You may decide to offer callbacks only during certain hours of the day. For example, between 9:00 AM and 2:00 PM. Configure this process in Architect by adding a Decision action before the Create Callback action. Configure the Decision action to check hours and then determine whether to offer a callback. For more information, see Create Callback data action.

To retry a callback, the agent must manually reschedule each attempt.