UseCases/Current/GenesysEngage-onpremises/CE03

Important

The PS material for this use case has not been finalized. Please contact your local CSD for effort estimates and scope details of this use case.

https://all.docs.genesys.com/images-supersite/a/ae/CE21_-_genesys_click_to_call_-_header_%282%29.png

Offer callback to queuing callers

What's the challenge?

When callers wait in long queues, customer frustration with your brand goes up right along with your abandonment rate. However, always keeping staff at peak performance level is costly and inefficient. You need a way to distribute calls during peak times to meet your service levels and keep callers happy.

What's the solution?

An alternative to waiting on hold can make the difference in a customer’s experience. After a threshold of time, give callers the wait time and the option of receiving a callback. Now you can deliver higher customer satisfaction without maintaining a peak-level staff.

Other offerings:

PureConnect

Use Case Overview

Story and Business Context

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.

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:

Use Case Benefits	Explanation
Improved Customer Experience	Offering callback and providing wait time information during busy times rather than keeping customers on hold improves the customer experience.
Improved Employee Utilization	Smoothing of inbound call volumes with offer of callback during busy times improves employee utilization.
Improved First Contact Resolution	Offering callback reduces the instance of follow-up and repeat calls by customers who have previously abandoned.
Reduced Handle Time	Customers who have not been kept on hold are less likely to spend time 'venting' in frustration, so reducing handle time.
Reduced Interaction Abandonment	Setting customer expectations about wait time with the offer of a callback reduces abandonment rates.

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

Summary

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.

Use Case Definition

Business Flow

(1) Callback Offer

The business flows describe the use case from the perspective of the customers and the system.

Business Flow Description

1. A customer calls a service line of the company.
2. The customer requests to speak with an agent.
3. 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.
4. 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."
5. After the announcements, the customer hears callback options.
6. 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).
7. If the customer does not accept the callback offer, the call is transferred to the corresponding waiting queue.
8. Optionally, you can play a recorded description of a callback.

Business Flow

(2) Callback

Business Flow Description

1. Consumers can request a scheduled or immediate callback:

   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.

2. 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.
3. 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.
4. 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."
5. Customer confirms their desire to connect to the agent.
6. Customer and agent are connected.

Business Flow

(3) Register Scheduled Callback

Business Flow Description

1. The customer chooses a day and time for their callback from a selection of configured times.
2. If the time slot is available, the system confirms it. If the time slot is not available, the system offers the next available time.
3. 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).
4. Once the customer accepts the time slot, Genesys registers the callback request and ends the call.

Business and Distribution Logic

Business Logic

These business rules drive the decisions made by the system.

Callback Offer

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:

• 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.
• Estimated Wait Time (EWT) uses one of 3 available options:
  • URS analyzes callback processing speed and pending callbacks while ignoring agent availability.
  • 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

Potential time slots for scheduled callback include these options:

• Business hours and special days for the callback service
• Callers can request to be scheduled in time slots of 15, 30, or 60 minutes.
• Maximum number of connection requests per time slot (the number will be the same for all slots).

Callback

Configurable voice prompts for announcements / treatments for the callback:

• Voice prompt in case the callback is answered by an automated answering machine
• Announcement once the customer is connected
• 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.

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.

User Interface & Reporting


Agent UI

Full inbound Voice Call handling features:

• Call controls
• Callback UI

Callback interface includes:

• Display of Type of Request, User ID, User First Name, User Last Name, User phone number, Language (as provided by the voice application).
• Disposition Codes to classify call and call outcome for reporting purposes.

Reporting

Real-time Reporting

Callback-related reporting

Minimum functionality includes:

• 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.
• The information is available per type of request.

Historical Reporting

Leverage standard out of the box Call Back reports in CX Insights.

UseCallback Summary Reportfor 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.

UseCallback Detail Reportfordetailed 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.

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	Inbound Genesys Call Routing (CE01) Genesys Personalized Routing (CE02)	None	None

General Assumptions

Preconditions

This use case contains only the functionality described above, which can be integrated with existing voice (self-service) applications.

Implementation of this use case requires the following Genesys components:

• Outbound CPD: Genesys SIP & Media Server
• Agent desktop:Workspace Desktop
• Real-time reporting:Pulse
• Historical reporting:Genesys Infomart and Interactive Insights
• Other components:
  • CIM Platform
  • Orchestration Server (ORS)
  • Genesys Mobile Services (GMS)
  • Resource Manager
    
• No integration with third-party systems
• Genesys Voice Platform is mandatory only for speech recognition (ASR) or text-to-speech (TTS) in the IVR.

Document Version

• Version v 1.1.5 last updated January 25, 2019