Genesys Callback (CE03) for Genesys Engage cloud

From Genesys Documentation
Jump to: navigation, search
This topic is part of the manual Genesys Engage cloud Use Cases for version Current of Genesys Use Cases.
Read this topic for other versions:
Offer callback to queuing callers
    GenesysEngage-onpremises

Use Case Overview

Story and Business Context

Customers get frustrated with long hold times when waiting to speak to an agent. This functional use case enables companies to improve the customer experience by empowering their customers to choose a callback when wait times are long. When an agent with the right capabilities is not available and the expected wait time is above a specific threshold, the customer will be presented with three options:

  1. Continue to wait in queue
  2. Request a callback as soon as an agent becomes available, keeping their position in queue
  3. Schedule a callback for a more convenient time

Use Case Benefits*

Use Case Benefits Explanation
Improved Employee Occupancy Improved agent and employee utilization due to better scheduling of agents to match calls (Genesys WFM solution required)
Improved Net Promoter Score Improved customer satisfaction by taking wait time into account in messaging and offer of callback
Reduced Handle Time Reduction of handle time due to reduction of customer frustration and "venting time"
Reduced Interaction Abandonment Reduction in abandonment rates due to immediate response to set caller expectations with callback
Reduced Volume of Interactions Decrease in inbound call volume due to reduced incoming follow-up and repeat call
*You can sort all use cases according to their stated benefits here: Sort by benefits

Summary

When a customer is waiting to speak to an agent and the estimated wait time to reach an appropriate agent is above a specified threshold - and is not within the blackout period (optional/configurable) - the customer will be presented with the option to receive a callback. The callback can either be as soon as possible (immediate) or scheduled at a future time. The wait time thresholds can be specified by the business and quickly adjusted if required.


Use Case Definition

Business Flow

The following diagrams shows the business flow of the use case:The following flow describes the use case from the perspective of the main actors, i.e. customer. The following diagrams shows the business flow of the use case:


Callback Request

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 expected wait time for the particular request. If the wait time is below the specified thresholds or within the optional blackout period, 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 will rely on existing inbound voice functionality.
  4. When the Estimated Wait Time threshold is reached outside the optional blackout period, a wait time announcement can be played to the caller.
  5. After the announcements, the options for callback will be announced to the customer.
  6. If the customer chooses either an Immediate or Scheduled Callback, they will be 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 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 (Go To "Callback" section next). If the customer chooses a Scheduled Callback, they are asked for when they want the callback. (Go To "Register Scheduled Callback" section next).
  7. If the customer does not accept the callback, the call is transferred to the corresponding waiting queue.
  8. Optionally, you can offer a description of a callback, which is a recorded message.

Business Flow

Register Scheduled Callback

Business Flow Description

  1. From a selection of configured days and times, the customer chooses the day, then the time, for their callback.
  2. If the time slot is available, the system will confirm it. If the time slot is not available, the system will offer 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 will 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 Flow

Callback

Business Flow Description

  1. The callback will either be scheduled for later or immediate
    • 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.
    • 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 is 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 is played to inform the customer that this is the callback he requested. 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."
    Other configurable options include:
    • Confirm that the right party has been reached and offer the ability to speak to an agent
    • Request more time to get the right party on the line
    • Reschedule the callback
    • Cancel the callback
  5. Depending on the configuration options that are offered, the customer can confirm the callback by pressing “1”. If he does not confirm the call is ended. No further callback attempt will be done.
  6. If the customer confirms the callback, he will be connected to the agent

Business and Distribution Logic

Business Logic

Callback Offering and Registration

This section describes the business rules which drive the decisions made by the voice application described above, i.e. how the business rules are configured. The voice application verifies the estimated queue wait time for the type of request before transferring a call. The returned wait time is checked against the user specified settings:

  • Automatic transfer threshold: If the expected wait time is less than this threshold or if the call is within the optional blackout period, the call will be automatically transferred to an inbound queue. The logic and business rules to distribute the call to an agent from this queue is not part of scope of this use case.
  • If the call is outside the optional blackout period and the expected wait time is greater than the threshold, the expected wait time is announced to the customer. If the business prefers not to announce an expected wait time, then a generic message can be played instead.
  • If the wait time is greater than both thresholds, then a generic message will be played before offering callback to the customer.

The business can configure both the messages played and the thresholds.

Callback

The following parameters are configurable for the callback logic:

  • Potential time slots for scheduled callback:
  • Business hours and special days for the callback service
  • Duration of the time slots for requesting a scheduled callback. Business hours are separated into time slots of 15, 30 or 60 minutes that users can request to be scheduled in.
  • Maximum number of connection requests per time slot (the number will be the same for all slots)
  • Voice prompts for announcements / treatments for the callback:
  • 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 time out
  • It is possible to assign a priority to callback requests. This is important in the case this use case is used in combination with other inbound media types (e.g. inbound calls or e-mail). All callback requests will have the same priority.

These parameters will be configurable per type of request. The type of request will be determined by the point in the IVR where transition from self-service to assisted service is required. It will be defined by the Speech Application using this callback functionality.


Distribution Logic

Distributing transfer calls to agents

This functionality is outside the scope of this use case. The solution will transfer the call to an existing queue for inbound voice routing and will leverage existing inbound voice routing functionality.

Distributing callback requests to agents

The following lists the minimum functionality for distributing a callback generated from the IVR to agents:

  • Routing of callback requests to agent is based on agents' 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-functionality.
  • If this use case is used in combination with other use cases for inbound interactions of a different media type: Blending with other media types is supported including configuration of capacity rules.


Use Case Requirements

Customer Interface Requirements

N/A

Agent Desktop Requirements

N/A

Reporting

Real-time Reporting

Voice Application related reporting

Available KPIs:

  • Number of calls going through the callback voice application
  • Number of calls having successfully finished the voice application

These KPIs will be available per type of request.

Callback related reporting

Minimum functionality:

  • 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 will be available per type of request

Historical Reporting

IVR related reporting

Available KPIs:

  • Number of calls going through the callback voice application
  • Number of calls having successfully finished the voice application

These KPIs will be available per type of request.

Callback related reporting

Leverage standard reporting for Voice in Interactive Insights for reporting calls generated via Genesys Mobile Engagement. Each subject and language are a different dimension

Minimum Functionality:

  • Number of entered and distributed callback requests
  • Number of callback attempts
  • Number of times a customer was connected (including instances where no agent has been connected)
  • Number of successful callbacks
  • Maximum and Average Wait Time of the customer to wait that an agent is connected
  • Maximum and Average Wait Time of the customer before abandon callback attempt

Assumptions

General Assumptions

Preconditions

This use case contains the functionality described above only, which can be integrated in existing Voice (Self-Service) applications. This additional Voice application functionality is not part of this use case.

Use Case Inter-dependencies

The use case contains the functionality to transfer the caller directly to an agent without callback. This functionality will consist in transferring the call to a route point / queue. The routing functionality for these calls are not part of the scope of this use case; instead, existing inbound voice routing capability will be leveraged. Similarly, existing (virtual) queues will be used to determine the expected wait time. The routing logic for these inbound voice calls needs to be implemented in Genesys.

This capability can be provided by the following use case:

  • CE01 - Genesys Call Routing

Customer Assumptions

N/A

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

    Inbound

      None None None

      Premise Assumptions

      N/A

      Cloud Assumptions

      • The Cloud Contact Center Callback is a per seat add-on (enabled/concurrent) to the Cloud Contact Center Inbound Voice Seat (base seat).
      • Implementation of this use case requires the following Genesys components
      • Genesys Voice Portal
      • Voice Application is authored by Designer
      • CPD will be based on Genesys SIP & Media Server
      • Workspace Desktop/Web Edition is used as agent desktop
      • Pulse is used for real-time reporting of callback functionality.
      • Genesys Infomart and GCXI will be used for historical reporting of callback functionality.
      • Genesys components needed for this use case (in addition to the components mentioned above):
      • Orchestration Server (ORS)
      • Genesys Engagement Services (GES)
      • Resource Manager
      • No integration with third party systems

      Related Documentation

      Document Version

      • v 1.1.2