Latest revision as of 08:56, November 9, 2020

Callback Scenarios

Important

This content may not be the latest Genesys Engage cloud content. To find the latest content, go to Callback scenarios.

It does not matter how a callback originates, the voice interaction is always converted to a virtual call and added to the queue where it is monitored so the system can provide information – such as the Estimated Wait Time (EWT) for the queue – to future callers.

This page describes the callback scenarios that Genesys supports with Callback.

Immediate Callbacks

An Immediate callback is a callback that is set in motion when your customer (a "consumer") makes a request to be called back as soon as an agent who can provide assisted service becomes available. A consumer can request an Immediate callback in the following ways:

While the consumer is in-queue on an IVR:
- A consumer's call arrives and the caller is offered Immediate callback. If the caller accepts, he or she confirms the phone number for the callback.
Through an API call; in other words, the consumer makes the request from a mobile app or website:
- A consumer is using your company's or organization's mobile app or website and encounters a situation where he or she requires assisted service by voice. The consumer taps or clicks a button to request a callback, confirms or provides the number at which he or she would like to receive the call, and receives a confirmation message that the request was received.

No matter how the Immediate callback is requested, when an agent who satisfies the required skill expression is ready, then the consumer is called and the call is routed to the agent.

Because user/context data might be attached to the API request for a callback, key components of the consumer's app or web journey can be preserved for agent or reporting use.

Scheduled Callbacks

A Scheduled callback is a callback that is set in motion when your customer (a "consumer") makes a request to be called back in the future, at an approximate time that works for the consumer's schedule. A consumer can request a Scheduled callback in the following ways:

While in-queue on an IVR:
- A consumer's call arrives and the caller is offered the option to schedule a callback for some time in the future. If the caller accepts, he or she confirms the phone number for the callback and is prompted to input the time at which he or she would like to receive it. Using the caller's requested time, the system searches for the closest-matching available time to connect with an agent.
Through an API call (from a mobile app or website):
- A consumer is using your company's or organization's mobile app or website and encounters a situation where he or she requires assisted service by voice. The consumer taps or clicks a button to request a callback, confirms or provides the number at which he or she would like to receive the call, interacts with a date/time picker to search for availability, and receives a confirmation message that the request was received.

No matter how the Scheduled callback is requested, if an agent who has the required skill set is ready at the specified time, then the consumer is called and the call is routed to the agent.

Because user/context data might be attached to the API request for a callback, key components of the consumer's app or web journey can be preserved for agent or reporting use.

Click-To-Call-In (Immediate)

Important

To implement this scenario, you need to use the corresponding Call-In API to initiate the Click-To-Call-In request.

A Click-To-Call-In (Immediate) interaction is set in motion when your customer (a "consumer") taps a button in a mobile app that is designed to trigger a Call-In API request:

A consumer is using your company's or organization's mobile app and encounters a situation where he or she requires assisted service by voice. The consumer taps a button that you have provisioned in your app to connect consumers to your contact center.
The system responds with call-in details immediately. Using that information, the app triggers a call to your contact center. The system attempts to match the caller to existing information. For more information, see Provisioning the Click-To-Call-In (Immediate) Scenario.
If the attempt to match the caller to a Call-In request is successful and your Designer application is configured to route the call when a match is made, then the call is queued on hold like any other call to the contact center. If the consumer is placed in a queue where the EWT is above the configured threshold, then the consumer might be offered a callback option.

Because user/context data might be attached to the API request, key components of the consumer's app journey can be preserved for agent or reporting use.

Click-To-Call-In (Delayed)

Important

To implement this scenario, you need to use the corresponding Call-In API to initiate the Click-To-Call-In request.

A Click-To-Call-In (Delayed) interaction is set in motion when your customer (a "consumer") taps a button in a mobile app that is designed to trigger a Callback API request. The following description of what happens next is a brief summary. See How Click-To-Call-In (Delayed) Works for additional information. To provision the Click-To-Call-In scenario, see Provisioning the Click-to-Call-In Scenario.

A consumer is using your company's or organization's mobile app and encounters a situation where he or she requires assisted service by voice. The consumer taps a button to contact your center.
The mobile app sends a callback request, which includes Push parameters that the system uses to contact the consumer to provide information about the callback.
The call is queued in the Click-To-Call-In (Delayed) virtual queue.
When the consumer reaches the top of the queue, the system sends a Push Notification to the mobile app to notify the consumer that the callback is ready.
When the consumer accepts the callback, the system immediately replies with a Push Notification that provides a phone number to call and, if configured, a unique access code that the consumer will be asked to enter before the call is initiated.
When the consumer calls in and enters the access code, if required, the system attempts to match the caller to an existing callback request. When a match is made, the caller is queued and routed to the next available agent who satisfies the required skill expression.

Because user/context data might be attached to the API request, key components of the consumer's app journey can be preserved for agent or reporting use.

How Click-To-Call-In (Delayed) works

Your mobile app sends a Callback request when the consumer taps the button or link that you have provisioned for the Click-To-Call-In Delayed feature. The call is then queued in the Click-To-Call-In (Delayed) virtual queue. The Callback request includes Push parameters. To use Push Notifications with Callback, see Provisioning Push Notifications for information.

A Click-To-Call-In (Delayed) request is routed to an agent when the following criteria are met:

The Call-In request can be matched to an existing Callback request in the system.
Your Click-to-Call-In Match Designer application is configured to route the call.
An agent (with the correct skills if skills are configured) is ready to accept the call.

There are, however, a number of things that can happen during an active Click-To-Call-In (Delayed) session that might impact the session's flow. For example, the system might fail to match a Click-To-Call-In (Delayed) request on the first attempt. As long as the Click-To-Call-In and Callback requests remain valid and outstanding, though, the consumer can call and try again.

There are also Designer settings that can purge the callback from the system or remove the callback from its queue:

The Callback Purge Time (minutes) for the virtual queue is reached before the consumer responds to Push Notifications or before an agent is available to assist the caller. In this case, the callback is purged from the system.
The end of the business day, based on the configured Business Hours, occurs before the Callback Purge Time (minutes) is reached, before the consumer responds to Push Notifications, or before an agent is available to assist the caller. In this case, the callback is purged from the system.
The Push Callback Expiry Time (minutes) setting in Designer causes the callback session to terminate when that time interval expires. When this happens, the callback is removed from the queue, but not purged from the system until one of the previous two events occurs.

A Call-In API request that is associated with a Callback request that was purged or terminated will fail because no match can be made between the Call-In and Callback requests.

@@ Line 1: / Line 1: @@
 = Callback Scenarios =
+__NOINDEX__ {{Template:PEC_Migrated|
+Target=[https://all.docs.genesys.com/PEC-CAB/Current/Administrator/CallbackScenarios Callback scenarios]}}
 <!-- This page should eventually include:
 * ''In-Queue Callback: description of standard flow, end-to-end, with key logic of what Designer module does, link to Callback V2 module (text from CE03 use case might be helpful)''
@@ Line 9: / Line 15: @@
 It does not matter how a callback originates, the voice interaction is always converted to a virtual call and added to the queue where it is monitored so the system can provide information &ndash; such as the Estimated Wait Time (EWT) for the queue &ndash; to future callers.
-This page describes the callback scenarios that Genesys supports with the Callback application.
+This page describes the callback scenarios that Genesys supports with Callback.
 {{AnchorDiv|immediate}}
-===Immediate Callbacks===
+==Immediate Callbacks==
-An ''Immediate'' callback is a callback that is set in motion when your customer (a ''consumer'') makes a request to be called back as soon as an agent who can provide assisted service becomes available. A customer can request an Immediate callback in the following ways:
+An Immediate callback is a callback that is set in motion when your customer (a "consumer") makes a request to be called back as soon as an agent who can provide assisted service becomes available. A consumer can request an Immediate callback in the following ways:
-* While the customer is in-queue on an IVR:
+* While the consumer is in-queue on an IVR:
-** A customer's call arrives and the caller is offered Immediate callback. If the caller accepts, he or she confirms the phone number for the callback.
+** A consumer's call arrives and the caller is offered Immediate callback. If the caller accepts, he or she confirms the phone number for the callback.
-* Through an API call; in other words, the customer makes the request from a mobile app or website:
+* Through an API call; in other words, the consumer makes the request from a mobile app or website:
-** A customer is using your company's or organization's mobile app or website and encounters a situation where he or she requires assisted service by voice. The customer taps or clicks a button to request a callback, confirms or provides the number at which he or she would like to receive the call, and receives a confirmation message that the request was received.
+** A consumer is using your company's or organization's mobile app or website and encounters a situation where he or she requires assisted service by voice. The consumer taps or clicks a button to request a callback, confirms or provides the number at which he or she would like to receive the call, and receives a confirmation message that the request was received.
-** Because user/context data might be attached to the API request for a callback, key components of the customer's app or web journey can be preserved for agent or reporting use.
 <!-- * Using a Genesys Widget for Callback:
 ** Similar to integrating a company's or organization's Web site with our API directly, using the Genesys Callback Widget on a Web site allows for a reduced time to deployment and less impact on developer resources. -->
-No matter how the immediate callback is requested, when an agent who satisfies the required skill expression is ready, then the customer is called and the call is routed to the agent.
+No matter how the Immediate callback is requested, when an agent who satisfies the required skill expression is ready, then the consumer is called and the call is routed to the agent.
+Because user/context data might be attached to the API request for a callback, key components of the consumer's app or web journey can be preserved for agent or reporting use.
 {{AnchorDiv|scheduled}}
-===Scheduled Callbacks===
-A ''Scheduled'' callback is a callback that is set in motion when your customer (a consumer) makes a request to be called back in the future, at an approximate time that works for the customer's schedule. A customer can request a Scheduled callback in the following ways:
+==Scheduled Callbacks==
+A Scheduled callback is a callback that is set in motion when your customer (a "consumer") makes a request to be called back in the future, at an approximate time that works for the consumer's schedule. A consumer can request a Scheduled callback in the following ways:
 * While in-queue on an IVR:
-** A customer's call arrives and the caller is offered the option to schedule a callback for some time in the future. If the caller accepts, he or she confirms the phone number for the callback and is prompted to input the time at which he or she would like to receive it. Using the caller's requested time, the system searches for the closest-matching available time to connect with an agent.
+** A consumer's call arrives and the caller is offered the option to schedule a callback for some time in the future. If the caller accepts, he or she confirms the phone number for the callback and is prompted to input the time at which he or she would like to receive it. Using the caller's requested time, the system searches for the closest-matching available time to connect with an agent.
 * Through an API call (from a mobile app or website):
-** A customer is using your company's or organization's mobile app or website and encounters a situation where he or she requires assisted service by voice. The customer taps or clicks a button to request a callback, confirms or provides the number at which he or she would like to receive the call, interacts with a date/time picker to search for availability, and receives a confirmation message that the request was received.
+** A consumer is using your company's or organization's mobile app or website and encounters a situation where he or she requires assisted service by voice. The consumer taps or clicks a button to request a callback, confirms or provides the number at which he or she would like to receive the call, interacts with a date/time picker to search for availability, and receives a confirmation message that the request was received.
-** Because user/context data might be attached to the API request for a callback, key components of the customer's app or web journey can be preserved for agent or reporting use.
 <!-- * Through the Genesys Widget for Callback:
 ** Similar to integrating a company's or organization's Web site with our API directly, using the Genesys Callback Widget on a Web site allows for a reduced time to deployment and less impact on developer resources. -->
-No matter how the scheduled callback is requested, if an agent who has the required skill set is ready at the specified time, then the customer is called and the call is routed to the agent.
+No matter how the Scheduled callback is requested, if an agent who has the required skill set is ready at the specified time, then the consumer is called and the call is routed to the agent.
+Because user/context data might be attached to the API request for a callback, key components of the consumer's app or web journey can be preserved for agent or reporting use.
 {{AnchorDiv|click_to_call_in}}
-===Click-To-Call-In (Immediate)===
+==Click-To-Call-In (Immediate)==
+{{NoteFormat|To implement this scenario, you need to use the corresponding Call-In API to initiate the Click-To-Call-In request.}}
+A Click-To-Call-In (Immediate) interaction is set in motion when your customer (a "consumer") taps a button in a mobile app that is designed to trigger a Call-In API request:
+* A consumer is using your company's or organization's mobile app and encounters a situation where he or she requires assisted service by voice. The consumer taps a button that you have provisioned in your app to connect consumers to your contact center.
+<!--* The mobile app submits a request for Estimated Wait Time (EWT) for an agent with appropriate skills. Skills are determined based on the area of the mobile app in which the consumer tapped the button. -->
+* The system responds with call-in details immediately. Using that information, the app triggers a call to your contact center. The system attempts to match the caller to existing information. For more information, see [[ProvisionClickToCallIn#provision_immediate|Provisioning the Click-To-Call-In (Immediate) Scenario]].
+* If the attempt to match the caller to a Call-In request is successful and your Designer application is configured to route the call when a match is made, then the call is queued on hold like any other call to the contact center. If the consumer is placed in a queue where the EWT is above the configured threshold, then the consumer might be offered a callback option.
+Because user/context data might be attached to the API request, key components of the consumer's app journey can be preserved for agent or reporting use.
+{{AnchorDiv|click_to_call_in_delayed}}
+==Click-To-Call-In (Delayed)==
 {{NoteFormat|To implement this scenario, you need to use the corresponding Call-In API to initiate the Click-To-Call-In request.}}
-A Click-To-Call-In (Immediate) interaction is set in motion when your customer (a consumer) taps a button in a mobile app that is designed to trigger a Call-In API request:
+A Click-To-Call-In (Delayed) interaction is set in motion when your customer (a "consumer") taps a button in a mobile app that is designed to trigger a Callback API request. The following description of what happens next is a brief summary. See [[CallbackScenarios#ctci_delayed_hiw_summary|How Click-To-Call-In (Delayed) Works]] <!--and the [[CallbackScenarios#ctci_flow|figure]] below -->for additional information. To provision the Click-To-Call-In scenario, see [[ProvisionClickToCallIn|Provisioning the Click-to-Call-In Scenario]].
-* A customer is using your company's or organization's mobile app and encounters a situation where he or she requires assisted service by voice. The customer taps a button to contact your center.
+* A consumer is using your company's or organization's mobile app and encounters a situation where he or she requires assisted service by voice. The consumer taps a button to contact your center.
-<!--* The mobile app submits a request for Estimated Wait Time (EWT) for an agent with appropriate skills. Skills are determined based on the area of the mobile app in which the customer tapped the button. -->
+* The mobile app sends a callback request, which includes Push parameters that the system uses to contact the consumer to provide information about the callback.
-* The system responds with call-in details immediately. Using that information, the app triggers a call to your contact center. If the customer is placed in a queue where the EWT is above the threshold, then the customer might be offered a callback option. Otherwise, the call proceeds normally.
+* The call is queued in the Click-To-Call-In (Delayed) virtual queue.
-* Because user/context data might be attached to the API request, key components of the customer's app journey can be preserved for agent or reporting use.
+* When the consumer reaches the top of the queue, the system sends a Push Notification to the mobile app to notify the consumer that the callback is ready.
-When an agent who satisfies the required skill expression is ready, then the customer is routed to that agent.
+* When the consumer accepts the callback, the system immediately replies with a Push Notification that provides a phone number to call and, if configured, a unique access code that the consumer will be asked to enter before the call is initiated.
+* When the consumer calls in and enters the access code, if required, the system attempts to match the caller to an existing callback request. When a match is made, the caller is queued and routed to the next available agent who satisfies the required skill expression.
+Because user/context data might be attached to the API request, key components of the consumer's app journey can be preserved for agent or reporting use.
+{{AnchorDiv|ctci_delayed_hiw_summary}}
+===How Click-To-Call-In (Delayed) works===
+Your mobile app sends a Callback request when the consumer taps the button or link that you have provisioned for the Click-To-Call-In Delayed feature. The call is then queued in the Click-To-Call-In (Delayed) virtual queue. The Callback request includes Push parameters. To use Push Notifications with Callback, see [[CallbackPushNotification|Provisioning Push Notifications]] for information.
-<!-- <font color="#B24DE7">'''Corinne's Note:''' The following was original content for Click-to-Call-In.</font>
+A Click-To-Call-In (Delayed) request is routed to an agent when the following criteria are met:
+# The Call-In request can be matched to an existing Callback request in the system.
+# Your [[ProvisionClickToCallIn#ctci_delayed_match_app|Click-to-Call-In Match]] Designer application is configured to route the call.
+# An agent (with the correct skills if skills are configured) is ready to accept the call.
+There are, however, a number of things that can happen during an active Click-To-Call-In (Delayed) session that might impact the session's flow. For example, the system might fail to match a Click-To-Call-In (Delayed) request on the first attempt. As long as the Click-To-Call-In and Callback requests remain valid and outstanding, though, the consumer can call and try again.
-* Click-to-Call-In
+There are also Designer settings that can purge the callback from the system or remove the callback from its queue:
-** A customer initiates a Click-To-Call-In request using an app or a website to retrieve the inbound call instructions such as the number to dial and an optional pin.
+# The [[CallbackV2#callback_settings|'''Callback Purge Time (minutes)''']] for the virtual queue is reached before the consumer responds to Push Notifications or before an agent is available to assist the caller. In this case, the callback is purged from the system.
-** The system responds with a phone number and an optional verification code.
+# The end of the business day, based on the configured [[DesBusinessHours|Business Hours]], occurs before the '''Callback Purge Time (minutes)''' is reached, before the consumer responds to Push Notifications, or before an agent is available to assist the caller. In this case, the callback is purged from the system.
-** The customer calls in and optionally enters the verification code on the call.
+# The [[ProvisionClickToCallIn#ctci_delayed_vq_config|'''Push Callback Expiry Time (minutes)''']] setting in Designer causes the callback session to terminate when that time interval expires. When this happens, the callback is removed from the queue, but not purged from the system until one of the previous two events occurs.
-**  After the customer is matched to the previously-initiated session, the call is routed to an agent.
-**: {{NoteFormat|To implement this scenario, you need to use the corresponding API to initiate the Click-To-Call-In request. }}
-<font color="#B24DE7">'''Corinne's Note:''' The following is from the [https://all.docs.genesys.com/UseCases/Current/PureEngage/CE21 CE21] use case.</font>
+A Call-In API request that is associated with a Callback request that was purged or terminated will fail because no match can be made between the Call-In and Callback requests.
-The application retrieves the expected wait time for an agent with skills corresponding to the page and determines whether the time is within the acceptable threshold:
-* If the wait time is above the configured threshold, the app informs the customer and offers to notify him via push notification once an agent becomes available. For customers who do not have push notifications enabled, it is recommended to offer them the ability to activate push notifications for improved service. This functionality is within the application logic and not provided by Genesys.
-** If the customer does not want to wait to be notified, the call to the contact center is established from his mobile device.
-** If the customer agrees to be notified, a push notification is sent to the customer when an agent becomes available. If the customer declines the push notification, the flow ends.
-* The mobile app retrieves the customer details, then establishes a call from the customer’s mobile device to the contact center.
-* The call is queued within the Genesys system according to the distribution logic described below and delivered to an agent with the skill corresponding to the requested subject:
-** If the agent accepts the call, the call is established, and the following information is displayed in the agent desktop: Subject based on DNIS, Customer ID, First Name, and Last Name (as available), plus a new tab for Mobile Details, including a map with the customer’s current location.
-** If the agent does not accept the call, the call is sent back to the queue and the agent is set to not ready (RONA – redirect on no answer).
--->
 [[Category:V:PSAAS:Public]]

Latest revision as of 08:56, November 9, 2020

Contents

Callback Scenarios

Immediate Callbacks

Scheduled Callbacks

Click-To-Call-In (Immediate)

Click-To-Call-In (Delayed)

How Click-To-Call-In (Delayed) works

Contact

Genesys

Customer Care

Legal