Jump to: navigation, search
(Update with the copy of version: draft)
Line 1: Line 1:
 
= Callback Scenarios =
 
= 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)''
 +
* ''Mobile/Web Callback''
 +
** ''Using the Callback APIs''
 +
** ''Genesys Widgets''
 +
* ''Click-To-Call-In'' -->
 +
 
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.
 
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}}
 
{{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 consumer 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 customer 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}}
 
{{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:
 
* 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):
 
* 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}}
 
{{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.}}
 
{{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 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 mobile app sends a callback request, which includes Push parameters that the system uses to contact the consumer to provide information about the callback.
−
* 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.
+
* The call is queued in the Click-To-Call-In (Delayed) virtual queue.
−
When an agent who satisfies the required skill expression is ready, then the customer is routed to that agent.
+
* 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.
 +
 
 +
{{AnchorDiv|ctci_delayed_hiw_summary}}
 +
 
 +
===How Click-To-Call-In (Delayed) works===
 +
If you use the Click-To-Call-In (Delayed) scenario with your mobile app, then you must provision [[CallbackPushNotification|Push Notifications]]. 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 Callback request includes the Push parameters. The call is then queued in the Click-To-Call-In (Delayed) virtual queue. The consumer will eventually talk to an agent or the process might terminate before the consumer and agent are connected.
 +
 
 +
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.
 +
# 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. The Click-To-Call-In and Callback requests remain valid and outstanding, though, so 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 [[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 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 [[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.
 +
 
 +
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.
 +
<!--
 +
{{AnchorDiv|ctci_flow}}
 +
 
 +
====High-Level Summary: Click-To-Call-In (Delayed) callback flow====
 +
The following figure shows the basic flow for a Click-To-Call-In (Delayed) session and includes the major events that trigger a Push Notification. For information about provisioning Push Notifications to work with Callback, including the complete list of supported Push Notifications, see [[CallbackPushNotification|Provisioning Push Notifications]].<br/>
  
 +
[[File:Callback_click-to-call-in-delayed-scenario_consumer_experience.png|center]]
  
 +
<nowiki>*</nowiki> For more information, see the description of the CALLBACK_UPCOMING Push Notification in [[CallbackPushNotification#callback_push_notifs|Callback Push Notifications]].<br/>
 +
<nowiki>**</nowiki> Both the '''Callback Purge Time (minutes)''' and your business hours for the queue are specified in the [[CallbackV2#callback_settings|CALLBACK_SETTINGS data table]] in Designer.<br/>
  
 +
-->
  
 
[[Category:V:PSAAS:Public]]
 
[[Category:V:PSAAS:Public]]

Revision as of 20:19, December 11, 2019

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

If you use the Click-To-Call-In (Delayed) scenario with your mobile app, then you must provision Push Notifications. 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 Callback request includes the Push parameters. The call is then queued in the Click-To-Call-In (Delayed) virtual queue. The consumer will eventually talk to an agent or the process might terminate before the consumer and agent are connected.

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

  1. The Call-In request can be matched to an existing Callback request in the system.
  2. 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. The Click-To-Call-In and Callback requests remain valid and outstanding, though, so 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:

  1. 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.
  2. 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.
  3. 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.

Comments or questions about this documentation? Contact us for support!