Genesys IVR Personalization (CE09) for Genesys Cloud

From Genesys Documentation
Jump to: navigation, search
This topic is part of the manual Genesys Cloud CX Use Cases for version Current of Genesys Use Cases.
Increase self-service by personalizing your IVR

What's the challenge?

When your customers call in to service themselves, they want to get off the phone as soon as possible. Giving customers options that confuse more than help slows the process, causes frustration and leads to more agent interactions.

What's the solution?

Deliver a great experience and increase self service adoption by helping customers navigate the IVR quickly. Genesys IVR Personalization tailors messages, menus and treatments based on who the customer is and why they are calling, also taking capacity into account.

Use Case Overview

Story and Business Context

IVRs have historically been designed to maximize the containment of callers to reduce staffing costs associated with increased call volume, often without a careful assessment of customer experience. This has led to deep and complex IVR menu trees that frustrate customers, create an undesirable customer experience, and result in high opt-out rates. IVR personalization addresses the following:

  • Simplify the menu structure (both depth and within a single menu)
  • Present meaningful options to the caller
  • Increase containment and use of the IVR through ease of use and relevance of options
  • Increase customer satisfaction through simpler, more relevant navigation and completion of tasks IVR personalization is proven to increase self-service rates and improve customer experience.

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 Containment Rate Help customers service themselves quickly and easily so they don’t want to speak to an agent.
Improved Customer Experience Improve customer experience by reducing IVR handle time, which in turn improves Net Promoter Score (NPS). Increase self-service by presenting customers with proactive messaging based on context.
Improved First Contact Resolution Improve first contact resolution by using dynamic menus to more accurately offer the right self-service or route to the right agent.
Reduced Handle Time The time required to address a customer inquiry or request is optimized.
Reduced Interaction Abandonment Reduce number of callers abandoning while in queue by enabling easier to use IVR.
*You can sort all use cases according to their stated benefits here: Sort by benefits

Summary

Customers presented with personalized menus and messages are more likely to self-serve. This functional use case lists several types of personalization as follows:

  • Proactively play a status or balance before presenting any options. For example, “Your next order is due to be delivered on Thursday.”
  • Proactively offer most likely call reason. For example, “Are you calling about the loan application you have in progress?”
  • Personalize menu options, have multiple variants of the same menu which are personalized got different contexts. For example, play a menu that contains mortgage optionsonly if they have a mortgage, or present a menu with a promotion option only if they are eligible.
  • Data table driven personalization can be used in conjunction with dynamic prompting to provide the ability to change the prompts based on language or customer context, such as age. These types of personalization can lead to an increase in self-service rates. They can also improve customer experience by shortening the time spent on the IVR or bypassing self-service based on the context of the customer’s call. The context to drive this personalization can be retrieved from native or from third-party data sources. Personalized IVR can also update customer context so that this information is available across other channels.


Use Case Definition

Business Flow

Business Flow Description

  1. A customer calls a service line that belongs to the company and progresses through the routing strategy. The routing strategy is not in the scope of this use case.
  2. An IVR application answers the call. The full IVR application is not within the scope of this use case. However, but the functionality in this use case can be used as a model to enhance the IVR application with personalization options.
  3. If the customer must be identified and authenticated (verified), the identification and verification (ID&V) interaction uses one or more identifiers (for example, customer ID or account number). Customer identification may be verified by a PIN, if necessary. This functionality is offered byGenesys Customer Authentication (CE07)use case, which this scenario leverages. The identification and verification functionality itself is not within the scope of this use case.
  4. Using the customer identifier (for example, ANI), Genesys can retrieve customer context information from a third-party system (optional).
  5. The decision to provide personalized treatment comes from submitting context to business rules natively, using third-party systems or using internal data. Personalized treatments include:
    • Play a personalized message to the customer.If the customer has all required information, they may hang up at this point. For example, the system identifies that the caller is in a region with a power outage and plays an announcement to convey the status.
    • Proactively play a status or balance before presenting any options to the customer. For example, “Your next order is due to be delivered on Thursday.”
    • Proactively offer the most likely call reason. For example, “Are you calling about the loan application that you have in progress?”
    • Offer menu variations that are personalized for different contexts. For example, only play the main menu variant, which includes mortgage option if they have a mortgage or present a promotion option if they are eligible.
    • Send the customer to:
      • A queue with updated context.
      • A self-service application (not in scope).
      • A generic menu if the caller does not fit any of the configured personalization options. In this case, the caller continues to the standard main menu of the IVR application. Since this use case is about personalization, the development of this main menu is out of scope.

Business and Distribution Logic

Business Logic

The personalized treatments use built-in variables or external variables. See the following table for an example list of variables. Personalized treatments are confirmed during design.

Built-in Variables

Name Description
Call.Ani The caller’s origin phone number for the active call (Automatic Number Identification).
Call.CalledAddress The called address that caused the caller to enter this flow. For a new inbound call, this value is the same as Call.CalledAddressOriginal, but changes for a flow entered by a transfer, for example.
Call.CalledAddressOriginal The called address received when the call first entered the system. Typically this address is the phone number that the caller dialed to reach the system. For a specified call, this value never changes.
Call.Language The IETF language tag lowercase string value set on the current interaction.
Call.RemoteName Remote name for the active call.
Call.UUIData Reflects the user-to-user call information (UUI) set on the call.
FindSystemPrompt If it finds an exact match, FindSystemPrompt Performs a search for an Architect system prompt by the specified prompt name and returns the Prompt value.
FindUserPrompt If it finds an exact match, FindUserPrompt Performs a search for an Architect user prompt by the specified prompt name and returns the Prompt value.
Flow.IsTest Indicates whether the flow is running in debug mode.
Flow.StartDateTimeUTC The UTC DateTime when the flow started execution.


External Variables
In addition to the built-in variables described in the table, more customer variables can be used in the rules. These variables can be:

  • Retrieved from a third-party system by a data action call to a web service.
  • Set by the IVR application that applies this use case. This logic can be based on caller input, for example.

Business Rules

Apply the Business rules to the variables using expression evaluation in a Switch action. The outcome of the business rule determines which personalized treatment applies. Business rules consist of logical calculations that are built as an expression. Examples include:

  • Variable customer segment is equal to VIP.
  • Current Date is equal to 24.12.2020.
  • Can combine Multiple logical conditions within one business rule. This combination means that the treatment is applied only if all conditions are met. Another option is to apply the treatment when any of the conditions are met. Examples for business rules:
    • If Customer Segment = VIP and Outstanding Support Request = true, then route directly to VIP support queue
    • If Customer Segment = Platinum or Customer Segment = Gold, then play preferred customer announcement

Multiple Rules

Can add Multiple rules to the business logic for personalized routing so that many different personalized treatments can be handled within the same call flow.

Distribution Logic

There is no applicable content for this section.

User Interface & Reporting


Agent UI

No applicable content for this section.

Reporting

Real-time Reporting

The Genesys solution provides reports to determine:

  1. Self-Service success.
  2. How customers entered and exited the IVR
  3. How long customers spent in the IVR.

NOTE: This solution is not available until later in Q1.

Historical Reporting

The Genesys solution provides reports to determine:

  1. Self-Service success.
  2. How customers entered and exited the IVR.
  3. How long customers spent in the IVR.

N.B. This will not be available until later in Q1.

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

Inbound

None

Self-Service and Automation

None


General Assumptions

  • External variables require customer integration into a third-party system. We assume that this data can be accessed using a web service.



Related Documentation

Document Version

  • Version V 1.0.0 last updated February 16, 2021

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