Difference between revisions of "UseCases/Current/GenesysCloud/CE03"

From Genesys Documentation
Jump to: navigation, search
Line 1: Line 1:
 
{{SMART UseCase
 
{{SMART UseCase
 
|SMART_Benefits={{SMART Benefits
 
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Reduced Handle Time
+
|UCBenefitID=Improved Customer Experience
|UCBenefit=Customers who have not been kept on hold are less likely to spend time 'venting' in frustration, so reducing handle time.
+
|UCBenefit=Improve customer satisfaction by announcing wait time and offering callbacks when appropriate
 
}}{{SMART Benefits
 
}}{{SMART Benefits
 
|UCBenefitID=Reduced Interaction Abandonment
 
|UCBenefitID=Reduced Interaction Abandonment
|UCBenefit=Setting customer expectations about wait time with the offer of a callback reduces abandonment rates.
+
|UCBenefit=Provide clear wait times and callback options to decrease abandonment
 
}}{{SMART Benefits
 
}}{{SMART Benefits
 
|UCBenefitID=Reduced Volume of Interactions
 
|UCBenefitID=Reduced Volume of Interactions
|UCBenefit=Offering callback reduces the instance of follow-up and repeat calls by customers who have previously abandoned.
+
|UCBenefit=Decrease in inbound calls from individual callers repeatedly trying to initiate contact
 
}}{{SMART Benefits
 
}}{{SMART Benefits
|UCBenefitID=Improved Employee Occupancy
+
|UCBenefitID=Reduced Handle Time
|UCBenefit=Smoothing of inbound call volumes with offer of callback during busy times improves employee utilization.
+
|UCBenefit=Reduce overall handle time in addition to customer hold time and associated telephony costs
}}{{SMART Benefits
 
|UCBenefitID=Improved Customer Experience
 
|UCBenefit=Offering callback and providing wait time information during busy times rather than keeping customers on hold improves the customer experience.
 
 
}}
 
}}
|UCOverview=This use case enables companies to improve customer experience by providing wait time information and callback functionality. Dynamic treatment can be applied to transfers, playing different messages and providing different customer experiences based on the length of the wait. Businesses can specify wait time thresholds and, using reporting, monitor and quickly adjust the outcome if required.
+
|UCOverview=No one likes to wait on hold. If the system detects an excessive wait time for a caller in a queue, the system offers the caller the option to request a callback. This functional use case enables companies to improve customer experience by improving in-queue treatment ({{#mintydocs_link:topic=CE01}}) with configurable wait time announcements and callback offers. When companies enable callbacks within their Genesys environments, benefits can include:
|UCSummary=No one likes to wait on hold. When a customer is waiting to speak to an agent, and the expected wait time to reach an appropriate agent exceeds a specified configurable threshold, they are presented with the option to receive a callback, either as soon as possible or at a scheduled future time. Different treatment can be applied and a different message presented based on the length of the wait.
+
|UCSummary=When a customer is waiting to speak to an agent, and the expected wait time to reach an appropriate agent is above a specified threshold, they will be presented with the option to receive a callback - either as soon as possible or at a scheduled future time. Different treatment can be applied and a different message presented based on the length of the wait. The wait time thresholds can be specified by the business and quickly adjusted if required.
|PainPoints=*Long queue times lead to abandons and missed service levels​
+
|PainPoints=*Long queue times lead to abandons and missed service levels
*High staffing costs in order to have resources available for peak periods​
 
*Unable to obtain view of operational performance through reporting & analytics​
 
*Customer dissatisfaction with long waits and lack of options​
 
  
+
*High staffing costs in order to have resources available for peak periods
|DesiredState=* When caller requests agent assistance from IVR, the queue times are dynamically checked
+
*Unable to obtain view of operational performance through reporting & analytics
 +
*Customer dissatisfaction with long waits and lack of options
  
 +
<br />
 +
|DesiredState=*When caller requests agent assistance from IVR, the queue times are dynamically checked
 
*When queue exceeds threshold set by business, the caller is played a message relaying the current wait time and given callback option
 
*When queue exceeds threshold set by business, the caller is played a message relaying the current wait time and given callback option
 
*Caller can choose to accept or reject the callback option
 
*Caller can choose to accept or reject the callback option
 
*When accepted, the callback is registered in the queue
 
*When accepted, the callback is registered in the queue
 
*When the callback reaches the top of the queue, it is assigned to an available agent.
 
*When the callback reaches the top of the queue, it is assigned to an available agent.
 
<br />
 
 
|MaturityLevel=Consistent
 
|MaturityLevel=Consistent
|SellableItems=Genesys Callback, GVP, GVP HA (optional), ASR and TTS, Conversation Manager, Intelligent Automation Omnichannel Self-Service, Intelligent Automation Omnichannel Self-Service - HA (Optional)
+
|SellableItems=PureCloud 2 or greater
|CloudAssumptions=<em>No results</em>
+
|CloudAssumptionsAdditional_Sales=* This use case is available on Cloud
|CloudAssumptionsAdditional_Sales=Capabilities Assumption:​
+
|PremiseAssumptions=N/A
* BEC / Designer​Workspace Desktop / Web Edition​Pulse​
 
* Genesys Infomart & Interactive Insights
 
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:​
 
* Genesys Voice Portal​
 
* Workspace Desktop / Web Edition​Pulse​
 
* Genesys Infomart & Interactive Insights
 
 
|BusinessImageFlow={{SMART BusinessImageFlow
 
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The business flows describe the use case from the perspective of the customers and the system.
+
|BusinessImage=https://www.lucidchart.com/documents/edit/bbaf9a45-8ac4-4644-9ae9-049547b3caf9/0
 +
|BusinessFlowDescription=1.1 - A customer calls a service line of the company. As described in {{#mintydocs_link:topic=CE01}}<span>, PureCloud transfers the call to a queue.
 +
 
 +
1.2 - The customer waits for an agent with the requested skills. There are two configurable, messaging-related thresholds: Medium Wait Time and Long Wait Time. If the wait time is below these thresholds, the system transfers the call to the appropriate queue to wait for an agent with the requested skills.
 +
 
 +
1.3 - If the wait time is above these thresholds, the system plays the appropriate wait time announcement to the caller. The system may repeat the announcement, depending on the amount of time the call stays in the queue. The announcement is either a generic announcement, or the estimated wait time rounded in minutes.
 +
 
 +
1.4 - After the announcements, the system offers the option for a callback to the customer.
 +
 
 +
1.5 - If the customer does not accept the callback, the call continues to wait in the queue. If the customer accepts the callback, the system registers the callback.</span>
 +
}}{{SMART BusinessImageFlow
 +
|BusinessFlow='''Register Callback'''
 +
|BusinessImage=https://www.lucidchart.com/documents/edit/8b130009-8a45-42ad-9aae-3fb622b734a6/0
 +
|BusinessFlowDescription=2.1- PureCloud asks the customer to verify the phone number for the callback.
 +
 
 +
2.2 - If the phone number is correct, PureCloud registers the callback request in the same queue as the original conversation and ends the call. The callback replaces the original call and maintains the caller's position in the queue.
 +
 
 +
2.3 - If the phone number is not correct, PureCloud asks the customer to enter an alternate callback number.
  
'''Callback Offer'''
+
2.4 - The caller enters the callback number.
|BusinessImage=https://www.lucidchart.com/documents/edit/b4243842-acc0-4bbb-823d-b3ed88d47e8a/0
+
 
|BusinessFlowDescription=# A customer calls a service line of the company.
+
2.5 - PureCloud registers the callback request in the same queue as the original conversation and ends the call. The callback replaces the original call and maintains the caller's position in the queue.
# The customer requests to speak with an agent.
 
# The system verifies the estimated wait time (EWT) for an agent qualified to handle the request. If the wait time is below the specified threshold, the caller is immediately transferred to the corresponding queue to wait for an agent with the requested skill. Please note that the logic to route calls to agents is not within the scope of this use case. This use case relies on existing inbound voice functionality described in the prerequisites CE01 or CE02.
 
# When the Estimated Wait Time threshold is exceeded, a wait time announcement can be played to the caller. This can be a generic announcement or, ideally, a broader range estimate like "between 5 and 10 minutes" or "less than 10 minutes."
 
# After the announcements, the customer hears callback options.
 
# If the customer chooses an Immediate or Scheduled Callback, they are asked if the ANI on which they called in is the callback number. If the customer confirms, move to next step. If the customer does not confirm, they are prompted to enter the new callback number and are asked to confirm it. If the customer chooses an Immediate Callback, they are placed in the router's queue (see the Callback flow below). If the customer chooses a Scheduled Callback, they are asked when they want the callback (see the Register Scheduled Callback flow below).
 
# If the customer does not accept the callback offer, the call is transferred to the corresponding waiting queue.
 
# Optionally, you can play a recorded description of a callback.
 
 
}}{{SMART BusinessImageFlow
 
}}{{SMART BusinessImageFlow
 
|BusinessFlow='''Callback'''
 
|BusinessFlow='''Callback'''
|BusinessImage=https://www.lucidchart.com/documents/edit/8ff777ca-fa49-4bcc-91ff-0a2b406bef43/0
+
|BusinessImage=https://www.lucidchart.com/documents/edit/3cddc70b-a2c8-41ce-bd7e-06923008f7c2/0
|BusinessFlowDescription=# Consumers can request a scheduled or immediate callback:
+
|BusinessFlowDescription=3.1 - PureCloud assigns the callback interaction to an agent in the queue.
#: a. For a Scheduled Callback, at the requested time of the callback, the call is queued to be distributed to an agent with the right skill.
+
 
#: b. For an Immediate Callback, when the caller's turn in queue is reached, they are put in position number one.
+
3.2 - The agent receives the callback interaction, reviews the information, and manually calls the customer.
# Based on predicted agent availability for the callback, a call is initiated to the customer phone. Call progress detection is used to detect if a human has accepted the call.
+
 
# Up to three call attempts to reach the customer are performed. If the customer does not accept the request after the third attempt, then the callback is cancelled.
+
3.3 - If the customer answers the call, the agent and the customer are connected.
# If the customer accepts the call, an announcement informs the customer that this is the requested callback. A sample announcement text could be: "This is your requested callback from company XYZ. Please press 1 to confirm that you requested this callback and you will be connected to an agent."
 
# Customer confirms their desire to connect to the agent.
 
# Customer and agent are connected.
 
}}{{SMART BusinessImageFlow
 
|BusinessFlow='''Register Scheduled Callback'''
 
|BusinessImage=https://www.lucidchart.com/documents/edit/d3d10bc0-d843-4c0d-bdff-641e50d5e0c3/0
 
|BusinessFlowDescription=# The customer chooses a day and time for their callback from a selection of configured times.
 
# If the time slot is available, the system confirms it. If the time slot is not available, the system offers the next available time.
 
# The customer can accept the offered time slot. If the customer does not accept the next available time slot, they are asked to enter a day and time again. This loop can occur 5 times (5 is the default, and this is a configurable option).
 
# Once the customer accepts the time slot, Genesys registers the callback request and ends the call.
 
 
}}
 
}}
|BusinessLogic=These business rules drive the decisions made by the system.
+
|BusinessLogic=The business can configure the messages played and the wait time thresholds:
====Callback Offer====
+
* Automated In queue wait time threshold
The system verifies the estimated queue wait time for the type of request before transferring a call. The returned wait time is checked against the system configurable setting:  
+
* Wait time playback threshold(s)
* If the expected wait time is greater than or equal to this threshold, a message is played before offering callback to the customer. The message can be generic or provide a range of time (best practice) for the estimated wait.
+
* In queue waiting prompts could include callback option to customer
* Estimated Wait Time (EWT) uses one of 3 available options:
+
* Customer can opt in to leave a callback request
** URS analyzes callback processing speed and pending callbacks while ignoring agent availability.
+
* Number of times to offer callback option to customers
** URS analyzes callback processing speed and pending callbacks while accounting for the agents who have historically handled interactions of the Virtual Queue.
 
** Query EWT from Stat Server.
 
The business can configure the thresholds and messages played for various queues.
 
  
====Register Scheduled Callback====
+
====<span class="mw-headline" id="Callback_Priority">Callback Priority</span>====
Potential time slots for scheduled callback include these options:
+
A callback automatically inherits the priority set on the inbound ACD voice call it replaces.
* Business hours and special days for the callback service
+
====<span class="mw-headline" id="Callback_Position_in_Queue">Callback Position in Queue</span>====
* Callers can request to be scheduled in time slots of 15, 30, or 60 minutes.
+
A callback replaces the original voice conversation in the queue and therefore maintains the customer's position in queue.
* Maximum number of connection requests per time slot (the number will be the same for all slots).
+
===<span class="mw-headline" id="Routing_Logic">Routing Logic</span>===
 
+
====<span class="mw-headline" id="Routing_calls_to_agents">Routing calls to agents</span>====
====Callback====
+
This functionality defined in  {{#mintydocs_link:topic=CE01}}.
Configurable voice prompts for announcements / treatments for the callback:
+
====<span class="mw-headline" id="Routing_callback_requests_to_agents">Routing callback requests to agents</span>====
* Voice prompt in case the callback is answered by an automated answering machine
+
When a callback request reaches the top of the queue, PureCloud assigns it to the best-fit agent. That agent initiates the callback to the customer.
* Announcement once the customer is connected
+
|DistributionLogic=N/A
* Treatment while waiting for the agent to be connected
 
* Announcement in case no agent could be connected to the call after a certain timeout
 
* It is possible to assign a priority to callback requests. This is important in case this use case is used in combination with other inbound media types (such as inbound calls or e-mail). All callback requests will have the same priority.
 
These parameters are configurable for each type of request. The type of request is determined by the point in the IVR where transition from self-service to assisted service is required. It is defined by the Speech Application using this callback functionality.
 
|DistributionLogic=====Distributing transfer calls to agents====
 
This functionality is handled by one of the prerequisite use cases, which transfers the call to an existing queue for inbound voice routing.  
 
====Distributing callback requests to agents====
 
The minimum functionality for distributing a callback generated from the IVR to agents includes:
 
* Routing of callback requests to agent based on agent skills. The required skills for a callback request depend on the type of request and the language. The mapping between subject and skill is configurable.
 
* RONA (Redirect On No Answer).
 
* In combination with other use cases, blending with other media types is supported, including configuration of capacity rules.
 
* After configurable timeouts, the routing target can be expanded based on skill level. Upper and lower limits of skill levels can be configured by target.
 
 
|CustomerInterfaceRequirements=N/A
 
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=The minimum functionality for the agent’s callback interface includes:
+
|AgentDeskRequirements=The agent’s callback interface displays:
* Display of Type of Request, User ID, User First Name, User Last Name, User phone number, Language (as provided by the voice application).
+
* Type of request
* Disposition Codes to classify call and call outcome for reporting purposes.
+
* User ID (Optional)
This use case requiresexisting inbound voice functionality, so all agent desktop functionality available to handle inbound voice calls as part of this use case is also available for handling callbacks.
+
* User first name (Optional)
|RealTimeReporting=<meta charset="utf-8"><span>Callback-related reporting:</span><span></span><p class="mw_paragraph">Minimum functionality includes:
+
* User last name (Optional)
<ul><li>Information on entered and distributed callback requests for distribution. Callbacks entered counts those scheduled callbacks whose scheduled time has arrived and which have been entered into the queue for distribution to an agent. </li><li>The information is available per type of request</li></ul>
+
* User phone number  
|HistoricalReporting=Leverage standard out of the box Call Back reports in CX Insights.
+
* Language
 +
This use case is in addition to existing inbound voice functionality. Therefore, all agent desktop functionality for inbound voice calls is also available for callbacks. To change some of the information on the agent's callback interface, businesses can modify agent scripts.
 +
|RealTimeReporting=Due to the continuous evolution, the features available in PureCloud rapidly change. Please see the PureCloud Resource Center for latest features at [http://help.mypurecloud.com PureCloud Help]
  
Use<span></span>'''Callback Summary Report'''<span></span>for detailed information about callbacks that were processed by the contact center, allowing you to analyse callback performance based on nearly thirty metrics, including:
 
* Total number of accepted, declined, attempted, connected, cancelled, abandoned, and successful callbacks.
 
* Percentages of callbacks that were successful, unsuccessful, declined, or connected.
 
* Savings resulting from callbacks, including the total amount time and money saved and the average time and money saved per callback.
 
* The number of attempts made to complete callbacks, the time customers spent waiting for an agent, and time customers waited before abandoning a call.
 
  
 
+
'''Note:'''<span></span>Callbacks are a media type that users can select on the majority of views and reports.The following are examples of PureCloud Historical and Real-time views that provide relevant insights:
Use<span></span>'''Callback Detail Report'''<span></span>for<span>detailed information about callbacks that were processed by the contact center, allowing you to analyse callback performance based on nearly 30 metrics. Use this report to view a detailed picture of how Callback is used in your contact center, including information about the volume of callback calls, success rates, resulting savings, and customer wait times.</span>
+
* Queue
|GeneralAssumptions=====Preconditions====
+
** The Queue Activity view shows real-time queue information. Callbacks are a specific media type.
This use case contains only the functionality described above, which can be integrated with existing voice (self-service) applications.
+
** The Queue Performance Summary and Detail views allow a supervisor to see historical conversations based on media type, including callbacks. Supervisors can filter on skills, languages, DNIS, and so on.
|RequiresOr=CE01, CE02
+
** The real-time Queue Activity view and the historical Queue Performance view show outbound calls that agents place to customers.
|PremiseAssumptionsAdditional=* Implementation of this use case requires the following Genesys components:<br />
+
* Agent
** Outbound CPD: Genesys SIP & Media Server
+
** The Agent Performance view allows a supervisor to get historical metrics on the number of conversations each agent handles. Because callbacks are a separate media type, supervisors can see how many callbacks agents make and how long an average callback takes. Supervisors can filter on skills, languages, wrap-up codes, and so on.
** <span>Agent desktop:</span>Workspace Desktop
+
** The Agent Status Summary view provides insight on the availability of specific agents.
** <span>Real-time reporting:</span>Pulse
+
* Interactions
** <span>Historical reporting:</span>Genesys Infomart and Interactive Insights
+
** The Interactions view provides detailed information on both historical and real-time interactions.
** Other components:
+
** It allows supervisors to filter interactions based on metrics including agent names and wrap-up codes.
*** CIM Platform
+
** It allows supervisors to search for interactions by specific media types.
*** Orchestration Server (ORS)
+
* Reports
*** Genesys Mobile Services (GMS)
+
** PureCloud has a full library of canned reports available in PDF and XLSX formats.
*** Resource Manager<br />
+
** Supervisors can filter these reports by dates, users, queues, and so on.
** No integration with third-party systems
+
** Supervisors can download reports from the PureCloud user interface.
** Genesys Voice Platform is mandatory only for speech recognition (ASR) or text-to-speech (TTS) in the IVR.
+
** Supervisors can schedule reports to run and download in batch.
|CloudAssumptionsAdditional=Not applicable
+
|HistoricalReporting=Same as Real Time Reporting.
|DocVersion=v 1.1.4{{SMART HybridAssumptions}}
+
|GeneralAssumptions=No integration with third-party systems.
 +
|CustomerAssumptions=N/A
 +
|RequiresAll=CE01
 +
|SMART_PremiseAssumptions={{SMART PremiseAssumptions
 +
|Premise_Assumption=N/A
 +
}}
 +
|DocVersion=v 1.0.1
 
}}
 
}}

Revision as of 12:42, March 27, 2020

No resultsNo results

Use Case Overview

Story and Business Context

Info needed.

Use Case Benefits*

The following benefits are based on benchmark information captured from Genesys customers and may vary based on industry, lines of business or Genesys product line: Info needed.

*You can sort all use cases according to their stated benefits here: Sort by benefits

Summary

Info needed.


Use Case Definition

Info needed.

Business and Distribution Logic

Business Logic

Info needed.


Customer-facing Considerations

Interdependencies

All required, alternate, and optional use cases are listed here, as well as any exceptions.

All of the following required: At least one of the following required: Optional Exceptions
None None None None





Document Version

Needs info.