Genesys Documentation - User contributions [en]

UseCases/Current/GenesysEngage-onpremises/CE01

2019-04-22T10:00:00Z

PLeprieult:

{{SMART UseCase
|ID=CE01
|Title=Connect a Voice Interaction to the Right Resource
|Offering=PureEngage
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Routing revenue-generating opportunities to the best skilled agents increases revenue.
}}{{SMART Benefits
|UCBenefitID=Reduced Handle Time
|UCBenefit=Routing voice calls to the agents best skilled to handle the customer's specific query reduces handle time.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Routing voice calls to the best-skilled agents improves employee utilization.
}}{{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Routing voice calls to agents with the skills appropriate to the customer's query improves the customer experience.
}}{{SMART Benefits
|UCBenefitID=Reduced Interaction Transfers
|UCBenefit=Routing voice calls to agents with the appropriate skill reduces the need for internal transfers.
}}
|UCOverview=This functional use case provides companies with capabilities to improve efficiency by routing voice interactions to the right agent through skills based routing. The routing application contains flexible business logic and configuration options required to easily deploy the solution and derive benefits.
|UCSummary=The caller initiates a voice call to the company (Optionally Skype for Business platform can be used). Opening hours, special day and emergency checks are performed and corresponding messages are played. Caller selects an option from a menu (prompt and collect) which maps to an agent skill expression. If no agents are available, target is expanded to include an additional agent skill or skill level before routing to an optional overflow number. Priority tuning may also be used to gradually increment priority level over time.
* To go live quickly (Time to market)
* To use best practice scenarios to enable fast realization of benefits

After the initial implementation the solution can be enhanced by additional functionality to further improve benefits of enhanced Genesys routing capabilities.
|PainPoints=* Poor customer experience scores due to excessive wait times, transfers, hold times, agents who do
not have needed expertise, and the need for repeat contacts
* High staffing costs to meet service levels; some sites may be overloaded while agents are idle in others

|DesiredState=* Preempt customers waiting in queue and reduce agent workload by offering self service options
* Optimize customer experience by giving them expected wait times, offering callback in queue, and quickly connecting them to a knowledgeable, efficient agent who has their full journey history
* Escalate priority over time as customer waits in queue
* Reach out proactively with information customers want and need to preempt calls
|BuyerPersonas=Chief Marketing Officer, Business Analyst, IT Administrator
|QualifyingQuestions=# How easy is it for your customers to get repetitive or easy issues fixed?
# How often do your customers have first contact resolution?
# How often is a transfer required, due to agents’ experience or knowledge?
# What service level issues are you experiencing?
|MaturityLevel=TEST
|SellableItems=CIM, CIM (HA), Interaction Workspace, Genesys Infomart, Genesys Infomart - HA (optional), Genesys Interactive Insights, SIP Interaction, SIP Interaction HA (optional), GVP, GVP HA (optional), SIP Business Continuity (Optional), ASR and TTS (Optional)
|CloudAssumptionsAdditional_Sales=This use case is available in the Cloud
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:This use case can be addressed utilizing SIP qualification and Parking OR can be delivered using GVP solution.
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following flow describes the use case from the perspective of the main actors, i.e. caller and contact center agent. The following diagrams shows the business flow of the use case:
|BusinessImage=https://www.lucidchart.com/documents/edit/ee59a752-1e08-4be8-8caa-e0fe31f5f353/0
|BusinessFlowDescription=# The caller initiates an inbound voice call to the contact center. Optionally Skype For Business Platform can be used.
# The system checks if the day is configured as a special day. In this case a special day announcement is played and the call will be disconnected.
# The system checks if the call is within the contact center's business hours. If not an out-of-office announcement is played and the call will be disconnected.
# The system checks if an emergency announcement is activated. In this case an emergency announcement is played and the call will be disconnected.
# An call steering message (DTMF menu) is played with various menu options (optional). See chapter “Parameters to define Call Steering” on more details on how the this can be configured.
# A greeting announcement is played.
# The caller chooses a menu option using DTMF tone entered on handset. If the caller does not choose an option or chooses a non-available option, the menu will be repeated up to 2 times. If the caller still does not choose a valid menu option the call will be handled with default routing parameters.
# The call is distributed to the best-fit agent for the chosen topic based on the agent's skill and skill level (see [https://docs.genesys.com/Documentation/UC/Public/PureEngage/CE01#dist Distribution logic ] for details).
# At the end of the call the agent sets a disposition code to record the call outcome for reporting purposes.
}}
|BusinessLogic=This chapter describes the business logic and business rules which drive the decisions made by the Genesys system within the business & routing flow above described in the chapters above, i.e. the parameters used by Genesys to drive routing decisions and how these are configured.

These parameters allow the user to configure a number of operational parameters related to routing logic, including the target skills for each menu option, priority tuning, timers and overflows.Some parameters are only available at DNIS / Route Point level. These are either needed only once at the beginning of the call flow (e.g. greeting message) or will be used across the whole call flow independent of subsequent DTMF menu choices of the customer. Other parameters are available at both the DNIS / Route Point level (to be used if no call steering has been activated) and at the level of the choice of a specific touch point. The following tables illustrate example parameters which may be configured through Genesys configuration tools.
===Parameters to configure Service Line Announcements===
The following parameters can be configured by service line:
{{{!}} class="wikitable"
{{!}}-
!{{!}}Name
!{{!}}Description
{{!}}-
{{!}}{{!}}Business hours
{{!}}{{!}}Sets the hours that you are open and accepting calls
{{!}}-
{{!}}{{!}}Special day
{{!}}{{!}}A list of exceptions to the regular open hours, for a holiday or other reason
{{!}}-
{{!}}{{!}}Emergency declared
{{!}}{{!}}Activates the emergency announcement (i.e. power outage, general closure)
{{!}}}

===Parameters to define the Call Steering / DTMF Menus===
The use case allows users to define Menu options externally through parameters, thereby simplifying the flow. Based on the menu options chosen, corresponding caller segmentation can be done by this context.

Up to 4 levels of DTMF menus can be configured with maximally 9 different sub-options for each choice in the previous level. The combination of choices of the customer within the DTMF menu will determine the service requested and the agent skill required to best satisfy this request. This possibility provides highest flexibility to adapt the use case to a specific company requirement, but it is generally not recommended to use all available levels and number of menu choices to not provide a bad customer experience via a complicated and lengthy DTMF menu.
===Distribution Parameters===
The following list of parameters define the behaviour of the distribution logic. These parameters can be configured per combination of possible DTMF choices in the Call Steering.
{{{!}} class="wikitable"
{{!}}-
!{{!}}Name
!{{!}}Description
{{!}}-
{{!}}{{!}}Primary Target
{{!}}{{!}}The skill and skill level expression to which the call will be routed. Alternatively, a DN or a specific Agent/Agent Group can be configured as routing target.
{{!}}-
{{!}}{{!}}Secondary Target
{{!}}{{!}}The skill and skill level expression to which the call will be routed in the first target expansion step. Alternatively, a DN or a specific Agent/Agent Group can be configured as routing target.
{{!}}-
{{!}}{{!}}Tertiary Target
{{!}}{{!}}The skill and skill level expression to which the call will be routed in the second target expansion step. Alternatively, a DN or a specific Agent/Agent Group can be configured as routing target.
{{!}}}
The skill expression to define the target is defined by a combination of skill(s) and skill levels. Best practice is to use the same skill(s) with decreased skill level in subsequent targets to gradually expand the pool of agents after each timeout, rather than using a different skill.Priority tuning is configured via the following parameters:
* Priority increment (the amount to increase the priority after the interval time)
* Priority interval (the time between priority increases)
* Priority limit (the maximum priority)
* Priority start (the starting priority)

===Reporting Parameters===
The following five business parameters represent reporting categories and are completely customizable to your business model. You can assign different combinations of these parameters to each of your Inbound and Distribution parameter groups, to distinguish them in reporting and enable you to identify the unique properties of the parameter group.
{{{!}} class="wikitable"
{{!}}-
!{{!}}Name
!{{!}}Description
{{!}}-
{{!}}{{!}}Department
{{!}}{{!}}Business organization used as a category for reporting
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}A business flow used as a category in reporting
{{!}}-
{{!}}{{!}}Intent Category
{{!}}{{!}}Business categories typically used as the top level of the call steering menu choices
{{!}}}

===Audio Resources===
The following audio resources are configurable by service line:
{{{!}} class="wikitable"
{{!}}-
!{{!}}Name
!{{!}}Example
{{!}}-
{{!}}{{!}}Business Hours
{{!}}{{!}}A message announcing office closure and inviting to call again at opening time
{{!}}-
{{!}}{{!}}Please Wait on Hold
{{!}}{{!}}A message inviting to wait
{{!}}-
{{!}}{{!}}Welcome
{{!}}{{!}}A Greeting message
{{!}}-
{{!}}{{!}}Emergency
{{!}}{{!}}An emergency message
{{!}}-
{{!}}{{!}}Special Day
{{!}}{{!}}A message announcing office closure due to special day (i.e. a bank holiday)
{{!}}-
{{!}}{{!}}Music waiting in queue
{{!}}{{!}}Music
{{!}}-
{{!}}{{!}}Main DTMF Menu Message
{{!}}{{!}}The main Call Steering menu accouncement
{{!}}-
{{!}}{{!}}Sub-DTMF Menu Messages (multiple messages)
{{!}}{{!}}The sub-menu messages for the Call Steering as required.
{{!}}}
|DistributionImageFlow={{SMART DistributionImageFlow
|DistributionImage=https://www.lucidchart.com/documents/edit/ba39e741-d78c-431f-80cd-458408bc26e7/0
|DistributionFlowDescription=# The system checks whether any agents corresponding to the target are logged in. If no agents are logged in, the flow will continue with step 8.
# If agents are logged in, the call is queued to the first target.
# The system checks whether any agents are available.
# If agents with the required target are available, the call will be distributed to the available agent who is longest idle.
# If no agent is available, music is played while the caller is in queue.
# The priority is increased according to priority tuning parameters.
# The system checks whether the target timeout has expired (if configured). If the timeout has not expired, the call continues to wait for an available agent.
# If the timeout has expired, then the system checks whether an additional target has been configured. If no additional target has been configured, the call continues to wait for an available agent.
# If the next target is still internal, Genesys will attempt to distribute to the expanded target. Up to a maximum of two iterations of target expansion can be configured. The flow continues at step 1.
# If the next target is configured to be an external number, the call will be forwarded to this number.
}}
|DistributionLogic='''General distribution functionality'''

The distribution logic will include the following functionality:
* The target will be configurable by (final) DTMF choice. Additional targets are optional.
* RONA-functionality: If an agent does not accept the voice interaction, the voice call will be automatically put back into the distribution flow after a time out. The agent will be set to not-ready.
* Blending with other media types will be possible. Priority settings for voice interactions will be configurable to enable proper priority ranges between different media types. Capacity rules will be configured for the agents / agent groups to define what interactions can be handled in parallel (if any).
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=* The agent can view the menu selection (service) and/or the DNIS when the call is presented
* Agents can transfer calls to other individual agents as out-of-the-box functionality.
* The agents can transfer calls to defined route points. The routing logic defined for these route points will be similar to the routing logic defined above. Only route points to transfer calls will be visible to the agent in his desktop.
* Configuration of not-ready reason codes (Admin Work, Lunch, Meeting, Pause, RONA and Training).
* Configuration of disposition codes for reporting of business outcome (Cross Sell, Need Follow-Up, Not Right Skill, Processed, Terminated, Transferred, Up Sell).

If Skype for Business Platform is used for Inbound call (option), the agent uses Workspace Desktop Edition integrated with Skype for Business endpoint.
|RealTimeReporting=<big>'''Premise'''</big>

'''Pulse''' is a Genesys Administrator Extension (GAX) plug-in application that offers personalized dashboards based on specific functional, geographical or organizational needs. Pulse dashboards present information using graphical “widgets” that can be viewed as graphs or tables, showing information about specific key performance indicators, such as service level, interactions handled, and the average handle time.

With Pulse you can:
* Monitor the current state and activity of Contact Center objects to help make decisions about staffing, scheduling and call routing strategies.
* Create widgets from predefined and user-defined templates for a fast and easy text or graphical presentation of selected or user-defined object statistics.
* Predefined Inbound templates
** Agent KPIs
** Agent Group Status
** Agent Login
** Queue KPIs

====Pulse Example Dashboards====
Genesys Pulse offers personalized dashboards based on specific functional, geographical or organizational needs. Each Genesys Pulse dashboard presents information by widgets that can be simply configured to be viewed as graphs or tables and show information about queues, outbound campaigns, agent groups or employees. By selecting specific Key Performance Indicators (KPIs), such as service level, the number of interactions handled and average handle time, you can quickly customize Pulse to match your needs and help you make better decisions faster.

The following is an example of a Pulse Dashboard:

[[File:CE1 - Pulse1.png|Example Pulse Dashboard]]
====Service Level Performance====
Monitor KPIs by segment, category, department and company (Queue KPIs, Queue Overflows):
* Intraday service level with cumulative metrics
* Current SLA
* Overflows and dissuasion

''Queue KPIs''

See below the Queue KPIs widget displaying for each segment (VQ related to customer business) its respective KPIs (Service Level, Calls Answered, Current Calls in queue, ASA, AHT, ..) in expanded views.

The first screenshot shows what can be displayed in the grid view. Specific thresholds can be configured based on customers' SLA.

[[File:CE1 - Pulse2.png|Queue KPIs]]

The second screenshot shows what can be displayed in the bar view to visualize the Service Level performance with a better granularity and identify a time range where service level could be degraded.

[[File:CE1 - Pulse13.png|Queue KPI - Bar View]]

The third screenshot shows what can be displayed in the bar view to visualize the Service Level performance as well as other main KPIs to measure the calls distribution performance.

[[File:CE1 - Pulse3.png|Queue KPIs - Service Level and other main KPIs]]

The fourth screenshot shows what can be displayed in the line view to visualize the trend of the Service Level within the current day.

[[File:CE1 - Pulse4.png|Line View]]
====Team and Employee Performance====
In order to manage the workload across different teams, it is important for Pulse supervisors to monitor their employee availability and behavior. The ability to view a representation of all the agents assigned to a group and their current states provides supervisors a quick look at available staff and an at-a-glance view of their current states, for example, agents on calls, on hold, waiting for calls, or not ready with reason.

''Agent Group Status''

This widget can be applied to Genesys Agent Groups only.

The first screenshot shows what can be displayed in the grid view. Pulse supervisors can visualize KPIs and current status of their workforce.

[[File:CE1 - Pulse5.png|Agent Group Status - Grid View]]

The second screenshot shows what can be displayed in the bar view. At a glance, Pulse supervisors can visualize the distribution of agent status per team.

[[File:CE1 - Pulse6.png|Agent Group Status - Bar View]]

The third screenshot shows what can be displayed in the line chart view. At a glance, Pulse supervisors can visualize and compare the trend of agents logged in per team.

[[File:CE1 - Pulse7.png|Agent Group Status - Line Chart View]]

''Agent KPIs''

This report can be applied to Genesys Agent and Agent Group.

The first screenshot shows what can be displayed in the grid view. Pulse supervisors can visualize agent KPIs and status of their workforce.

[[File:CE1 - Pulse8.png|Agent KPIs - Grid View]]

The second screenshot shows what can be displayed in the bar view. At a glance, Pulse supervisors can visualize agent status and activity. Supervisors can sorted out agents out of specific interests. In this case, the supervisor sorted agents out of calls answered.

[[File:CE1 - Pulse9.png|Agent KPIs - Bar View]]

The third screenshot shows what can be displayed in the line chart view. At a glance, Pulse supervisors can visualize the trend and compare the number of calls answered per agent.

[[File:CE1 - Pulse10.png|Agent KPIs - Line Chart View]]

''Agent Login''

This report can be applied to Genesys agents only. With this report, the supervisor can ensure the agents are logged in where they should be and managing the service for which they are responsible but also monitor the current agent status.

The first screenshot shows the reason why agents are not ready in a specific group.

[[File:CE1 - Pulse11.png|Agents Not Ready]]

The second screenshot shows the properties related to the call currently handled by agents. It includes 4 KVP which are the one associated to Service Type, Service Sub Type, Customer Segment and Business Result.

[[File:CE1 - Pulse12.png|Agent Login - Currently handled calls]]

NOTE: Occupancy metric is specific to media type, it does not give the overall Occupancy of the agent across media types. You also have to consider if the agent can handle concurrent interactions this can understate the agents true Occupancy.

<big>'''Cloud'''</big>

Real-time reporting is provided by Genesys Pulse and by Designer Analytics.

The following ready to use Pulse reports are available for this use case in Cloud:
* Agent Group Status—Displays the current number of agents in their various interaction handling states by group.
* Agent KPIs—Displays agent key performance indicators for agent groups and individual agents within those groups.
* Agent Login—Displays agents that are logged in, what type of work they have been assigned, and their current status.
* Queue KPIs—Displays call activity associated with the interaction queues.

Each Genesys Pulse report presents information within graphical widgets that you can configure to show graphs or tables that provide information about incoming voice call queues, agent groups, or individual agents. You can personalize Genesys Pulse reports based on functional, geographical or organizational considerations. To customize reports, you select specific key performance indicators (such as service level, the number of interactions handled, or average handle time).
|HistoricalReporting=<big>''Premise''</big>

Interactive Insights out-of-the-box reports will be used to:
* Measure the effectiveness and efficiency of the use case
* Dimension reporting metrics by the “Reporting Business Parameters”
* The not-ready time in agents reports will be split for not ready reason codes set as follows “Break”, “Lunch”
* Monitor calls dissuaded due to emergency or out of office conditions as follows: “OutOfHours", "IsSpecialDay", "Emergency", "NoMoreTargets", "RouteOverflow"
* Evaluate resource performance with a variety of reports for Agents and Detail facts
* Report on calls transferred to an external number separately
* Compare agent performance in handling interactions against the agent’s group, focusing on a few specific measures that demonstrate the possible mishandling of interactions—a high number of unaccepted interactions, excessive hold and after-call work (wrap) times, and shorter-than-usual engage (talk) duration with customers.

====Reporting Metrics====
NOTE: Almost all Interactive Insight reports and metrics are dimensioned by Media Type, Interaction Type and some form of date&time out of the box. Occupancy metric is specific to media type, it does not give the overall Occupancy of the agent across media types. You also have to consider if the agent can handle concurrent interactions as this can understate the agents true Occupancy.

There are 40+ reports available reports to confirm the benefits for this use case. The following shows key metrics as examples:

'''Agent KPIs''' enable the organization to measure and filter InfoMart data based on the interaction-related activities that are conducted by active agents.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
! style="width:15em"{{!}}Sample Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Activity
{{!}}{{!}}Examples for available KPIs:
* Abandoned Inviting
* Accepted
* Conference Initiated
* Consult Initiated
* Engage Time
* Handle Time
* Hold
* Invite
* Offered
* Rejected
* Wrap
{{!}}{{!}}

Agent interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the agent.
{{!}}-
{{!}}{{!}}Interaction
State & Reason
{{!}}{{!}}Examples for available KPIs:
* % Engage Time
* % Hold Time
* % Invite Time
* % Wrap In Time
* Accepted
* Consult Received Accepted
* Engage Time
* Not Accepted
* Not Ready In Time
* Offered
{{!}}{{!}}Agent interaction level data.

Measures are attributed to each reporting interval in which agents handle the interactions and durations are clipped at interval boundaries.
{{!}}-
{{!}}{{!}}Summarized
State & Reason
{{!}}{{!}}Examples for available KPIs:
* % Busy Time
* % Not Ready Reason Time
* % Occupancy
* % Ready Time
* % Wrap Time
* Active Time
* Not Ready
* Not Ready Reason Time
* Wrap
{{!}}{{!}}Agent summarized data for a session.

Measures are attributed to each reporting interval in which agents handle the calls, and durations are clipped at interval boundaries.
{{!}}}

'''Queue KPI''' enable the organization to measure and filter InfoMart data based on the queue(s) through which customer interactions pass or the Business Attributes associated with the interactions. Counts and duration
measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
! style="width:15em"{{!}}Queue KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Queue
{{!}}{{!}}Examples for available KPIs:
* Period
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Abandoned Waiting
* Abandoned Time
* Not Accepted
* Redirected
* Accepted Agent
* Accepted Agent in Threshold
* Accept Time Agent
* % Service Level
* Invite Time
* Engage Time
* Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}

Queue interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the queue.
{{!}}}

'''Business Attribute KPI''' enable the organization to measure and filter Info Mart data based on the business attributes that are associated with the customer interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the Contact Center.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
! style="width:15em"{{!}}Business Attributes KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Business Attributes
{{!}}{{!}}Examples for available KPIs:
* Period
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Entered Obj
* Abandoned Waiting
* Not Accepted
* Redirected
* Accepted
* Accepted in Threshold
* Accept Time Agent
* % Service Level
* Engage Time
* Handle Time
* Avg Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}

Business Attribute interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered by business attribute.
{{!}}}

'''Accepted Agent''' enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions pass in which agents accept or answer the interaction. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
! style="width:15em"{{!}}Accepted Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Accepted Agent
{{!}}{{!}}Available KPIs:
* Queue Name
* Mediaedia Type
* Customerustomer Segment
* Service Type
* Service Subtype
* Accepted Waiting 1..20 Thresholds
* % Accepted Waiting 1..20 Thresholds
{{!}}{{!}}

Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were accepted as well as the percentage of interactions that were accepted within a specific set of time ranges.
{{!}}}

'''Abandoned Waiting''' enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions abandoned while waiting to be answered. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
! style="width:15em"{{!}}Abandoned Waiting KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Abandoned Waiting
{{!}}{{!}}Available KPIs:
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Abandoned Waiting 1..20 Thresholds
* % Abandoned Waiting 1..20 Thresholds
{{!}}{{!}}

Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were abandoned as well as the percentage of interactions that were abandoned, while the interactions were queued at a specific queue for a specific set of time ranges. The time ranges are configured within the InfoMart Application options.
{{!}}}

'''Interaction Details''' enable the organization to track low-level interaction details.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
! style="width:15em"{{!}}Interaction Detail KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Handling Attempt
{{!}}{{!}}Available KPIs:
* Interaction ID
* Connection ID
* Media Type
* Customer ID
* Customer Segment
* Service Type
* Service Subtype
* Business Result
* Interaction Type
* Start Timestamp
* End Timestamp
* Routing Target
* Resource Role
* Role Reason
* Technical Result
* Result Reason
* Queue Time
* Route Point Time
* Total Duration
* Customer Talk Time
* Customer Hold Time
* Customer Wrap Time
* ....
{{!}}{{!}}

Handling Attempt detail interaction level data.

Handling Attempt details of interactions that are stored mostly in the INTERACTION_RESOURCE_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}Available KPIs:
* Agent/Queue
* Connection ID
* Media Type
* Customer ID
* Interaction ID
* Interaction Type
* Interaction Subtype
* Segment ID
* Source
* Target
* Technical Result Resource Role
* Technical Result Role Reason
* Technical Result
* Technical Result Reason
* Duration
{{!}}{{!}}

Flow detail interaction level data.

Interaction-flow details of interactions that are stored mostly in the INTERACTION_FACT, INTERACTION_RESOURCE_FACT, and MEDIATION_SEGMENT_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Transfer
{{!}}{{!}}Available KPIs:
* Interaction ID
* Media Type
* Source
* Source Service Type
* Source Service Subtype
* Source Customer Segment
* Source Last Queue
* Source Technical Result
* Source Customer Engage Time
* Source Customer Hold Time
* Source Customer Wrap Time
* Source Queue Time
* Target
* Target Service Type
* Target Service Subtype
* Target Customer Segment
* Target Last Queue
* Target Technical Result
* Target Customer Engage Time
* Target Customer Hold Time
* Target Customer Wrap Time
* Target Queue Time
* ....
{{!}}{{!}}

Transfer detail interaction level data.

Interaction details identifying the source and destination of transferred and conference interactions.
{{!}}}

<big>'''Cloud'''</big>

Due to the continuous evolution, the features available in Cloud rapidly change. Please reach out to your local Cloud Team for latest information.
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.1.3
}}
|GeneralAssumptions=SIP connectivity is offered as a standard solution for PureEngage Premise and Cloud.

Optionally Skype for business can be offered for PureEngage Premise only (not supported for PureEngage Cloud).
|SMART_PremiseAssumptions={{SMART PremiseAssumptions
|Premise_Assumption=Implementation based on SIP Server (SIP Voice Blueprint)
}}{{SMART PremiseAssumptions
|Premise_Assumption=Routing parameters are configured through GAX operational parameter groups, which are referenced in the underlying strategy / routing application
}}{{SMART PremiseAssumptions
|Premise_Assumption=Text To Speech and Speech Recognition are not included.
}}{{SMART PremiseAssumptions
|Premise_Assumption=No Genesys Voice Portal - all customer input is via DTMF prompt and collect
}}{{SMART PremiseAssumptions
|Premise_Assumption=Genesys Infomart and Interactive Insights will be used for historical reporting
}}{{SMART PremiseAssumptions
|Premise_Assumption=Workspace Desktop Edition will be used as agent desktop
}}{{SMART PremiseAssumptions
|Premise_Assumption=Pulse will be used for real-time reporting.
}}{{SMART PremiseAssumptions
|Premise_Assumption=No Integration with third party systems
}}
|PremiseAssumptionsAdditional='''For Skype for Business Connectivity (Option):'''
* Integration with Skype for Business based on Multimedia Connector (Skype for Business Blueprint) 
* The agent uses Workspace Desktop Edition integrated with Skype for Business endpoint.
* No integration with 3rd party recording. GIR is the only available recording option with Multimedia Connector for Skype for Business.
* GIA is not supported as a standard option.
* PS team should be consulted for Skype for Business Platform deployment.
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=Implementation of this use case will be based on the corresponding Pure-Engage cloud blueprint Architecture
}}{{SMART CloudAssumptions
|Cloud_Assumption=All routing options and configuration parameters are configured through Designer Data Tables. This will allow users simplicity in managing their interaction logic and to dynamically make changes
}}{{SMART CloudAssumptions
|Cloud_Assumption=Text-to Speech and Speech Recognition are not included
}}{{SMART CloudAssumptions
|Cloud_Assumption=All customer input is via DTMF prompts. Customers need to provide these recordings for prompts. Standard definition for these recordings will be provided
}}{{SMART CloudAssumptions
|Cloud_Assumption=Genesys Workstation Web Edition will be provided as Agent Desktop
}}{{SMART CloudAssumptions
|Cloud_Assumption=Pulse will be used for real-time reporting
}}{{SMART CloudAssumptions
|Cloud_Assumption=No integration with third party systems out-of-box
}}
|CloudAssumptionsAdditional=* '''Skype for Business Connectivity not supported'''
|SMART_Interdependencies_Requires={{SMART Interdependencies Requires
|Requires=CE02, CE04
}}{{SMART Interdependencies Requires
|Requires=EE01
|Conditions=Optional to enable Video Chat
}}
|SMART_Interdependencies_Incompatible={{SMART Interdependencies Incompatible
|Incompatible=SL02
}}
|UCBenefitID=Improved Agent Competency
|UCBenefit=This UC improves NPS by XYZ.
|Personas=Edith (VP Customer Experience), Bettina (VP Digital Engagement), Carl (Contact Center Director)
|Cloud=Yes
|Premise=Yes
|Benefits=* Increase revenue due to improved match of customer with best agent (Revenue)
* Enhance customer retention by matching caller with highly skilled agent (Revenue)
* Reduce transfers through skills-based routing (Efficiency)
* Reduce Average Handle Time by matching every caller with the best available agent (Efficiency)
* Improve NPS by optimally handling customer issue/inquiry (Experience)
* Reduce customer frustration by matching with knowledgeable agent (Experience)
|GenersalAssumptions=test
}}

UseCases/Current/GenesysEngage-onpremises/CE02

2019-04-22T10:00:00Z

PLeprieult:

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Routing calls to the same agent that the customer previously spoken to may increase the chances of completing a sale.
}}{{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Using customer context enables routing to agents who can handle the customer's specific query more quickly.
}}{{SMART Benefits
|UCBenefitID=Reduced Interaction Transfers
|UCBenefit=Routing calls to agents based on customer context reduces the need for internal transfers.
}}{{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Routing calls based on customer context reduces familiarisation time and improves customer experience.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Enabling agents to handle queries more quickly improves employee utilization.
}}
|UCOverview=This functional use case has been created to enable companies to use Advanced Genesys Routing capabilities to improve customer experience by routing voice interactions to the best fit agent based on the type of request and customer context. Detailed routing behaviour is driven by configuration parameters and rules, therefore providing a highly flexible framework to adapt to specific organization needs. The base logic is based on experience and best practices from previous implementations and therefore enables the organization to use best practice scenarios to enable fast realization of benefits.
|UCSummary=A customer call is qualified within the IVR. The customer is identified and authenticated (if needed) within the IVR menu (not part of this use case). The customer ID is used to retrieve context data on the customer from Genesys Context Services. Based on his choices within the IVR and on the context data, he is routed to the best agent able to serve his request and potentially additional services, e.g. to realize up-sell potential. All relevant context information is displayed to the agent to enable high-quality service delivery. The logic of this use case is business rules driven and therefore flexible to changing needs and business environments.
|PainPoints=* Cannot recognize repeat customers
* Unable to use context to enable a finer granularity in matching the customer to the best agent in the target agent group
* Calls with long handle times, with customers having to recap previous interactions
* Missed service levels within or across channels
* Increasing interaction abandonment and repeat contacts
|DesiredState=* Recognize customers in all touchpoints and channels, and match callers with the same agent with whom they previously spoke
* Carry context and orchestrate interactions between channels
* Offer self-service and call back options
* Inform customers of expected wait/process times
|SellableItems=CIM, CIM (HA), Interaction Workspace, Genesys Infomart, Genesys Infomart - HA (optional), Genesys Interactive Insights, SIP Interaction, SIP Interaction HA (optional), SIP Business Continuity (Optional), SIP Qualification & Parking, SIP Qualification and Parking HA (Optional), GVP, GVP HA (optional), ASR and TTS (Optional), Conversation Manager, Intelligent Automation Omnichannel Self-Service (Optional, Intelligent Automation Omnichannel Self-Service - HA (Optional)
|CloudAssumptions=This use case is not supported in Cloud.
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:
* Full set of capabilities are available.
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following flow describes the use case from the perspective of the main actors, i.e. the customer and the contact center agent. It provides a high-level view of the basic flow. The detailed description of the underlying call flow is described in Chapter “Distribution Logic”.
|BusinessImage=https://www.lucidchart.com/documents/edit/ce874ffd-90f0-4ccb-baa6-970732d1c52e/0
|BusinessFlowDescription=# The customer calls one of the numbers of the contact center.
# He is routed to an IVR application which is determining the service type and also performs an Identification and (optionally) Verification of the customer. This functionality is provided outside of the scope of this use case, it is assumed that the information on the requested service and customer identification is passed on to be used within this use case. The use case CE7 - Effective Identification and Validation in IVR can be used for this functionality. Alternatively, customer CLI is used for Identification.
# If the customer calls outside of out-of-office hours or if an emergency situation is in progress, an announcement is played. After this the caller may be reconnected or diverted to another number inside or outside of Genesys.
# Genesys retrieves context data on the customer based on the customer identification.#If the contact center is open the routing parameters for this particular call is set based on the type of request and the customer context. This will enable flexible and personalized call handling.
# The Expected Wait Time (EWT) for the customer is calculated and is announced to the customer (optional). If the EWT exceeds a specific threshold, an announcement is played and the caller is disconnected or routed to another number inside or outside of Genesys (optional).
# Additional announcements are played to the customer. These announcement are based on the customer context. Examples include: Quality announcements/Special promotions-offers for the customer/Announcements for potential self-service options
# If the customer has been calling recently for the same type of request, Genesys can route to the last agent (configurable based on type of request and customer context). In case this agent is not logged in or not available for this call within a specified time out, the call is routed to the requested skill
# The call is distributed to the best agent who:
#* Has the base skill(s) to handle the original request
#* Has the supplementary skill(s) determined by the customer context (optional). Examples include:Skills to upsell a defined product / service to the customer or specific empathy skills based on the customer segment or demographic
#* A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill and / or reducing the skill level on the base skill if the call cannot be distributed within specific timeouts.
# Once the call is distributed to an agent, the call context information is displayed to the agent. As an example, the agent is able to see any special offer or promotion for the customer, so he can start the relevant information. The agent handles the customer request and any potential up-/cross-sell opportunity.
# After the conversation with the customer, the agent records the outcome of the call for reporting purposes e.g. if he has acted on the presented lead
}}
|BusinessLogic=====Emergency Check====
Emergency mode activation is enabled at three levels: Global, Service (Type of Request) and Queue. The emergency mode is not only checked at the beginning of a call, but is constantly monitored during call queuing. If an emergency flag is set for a queued call, the corresponding emergency announcement is played, and the configured action applies to the call (disconnect or deflect to another number within or external to Genesys).

Furthermore, Genesys runs a parallel stream to continually check if agents are logged onto the platform. If no agents are detected, then an emergency mode is automatically activated.
====EWT Announcements====
Announcement of Expected Wait Time to customers is handled based on predefined recordings. It is a good practice to announce expected wait times approximately to not jeopardize customer expectation. Six thresholds are configured which can trigger different announcements. Default values are: 60, 120, 180, 300, 600 and 1200 seconds. The announcement text should match the threshold.
====Last Agent Routing====
The last agent(s) a customer spoke to is stored within Context Services (part of Universal Contact History) including the base skill which was required for the corresponding service. When a customer calls the contact center for the same service and Last Agent Routing is enabled, Genesys checks in Context Services for a recent contact, not older than a configurable threshold, handled by an agent with the required skill. The corresponding agent is used for Last Agent Routing.

In case of multiple matches, the most recent entry is used.
====Busy Treatment====
Messages and Music are played for queuing calls. It is possible to configure up to six messages with music treatment in between. The first two messages and associated music treatments are played once, the remaining 4 messages and music treatments are looped until the call is answered or abandoned.
====Skill Model====
=====Skill types=====
The skill model, used for distribution, is based on three logically different skill types which define attributes and knowledge of the agents:

=====Basic skill=====
This skill is required to handle a specific type of request or service. One basic skill is required for each call for the distribution of calls to agents.
=====Language skill=====
This skill type determines the language in which a call shall be answered. The requested language is provided via the IVR. If no language is provided, a default language is used. One language skill is required for the distribution of calls to agents.
=====Supplementary skill=====
Genesys Routing utilizes supplementary skills for enhanced routing logic and personalization. Supplementary skills are defined by customer specific context data.

The following provides an example:
* A customer calls the service hotline for "Account Transactions."
* He successfully identifies and authenticates within the IVR. The corresponding data are passed to Genesys.
* The caller's profile within Context Services indicates that the caller is eligible for a Platinum Credit Card up-sell.
* In this case, the call should ideally be routed to an agent with the base skill "Account_Handling" and the supplementary skill "Up-Sell" to ensure that he can handle both the original request and successfully convert the up-sell opportunity for this customer.

=====Skill level=====
Each agent has one or more skills associated to their profile and a skill level associated to each base skill, referred to in this document as proficiencies. The skill level is used to define primary, secondary and tertiary targets within the routing logic described in section "Targeting". The targets are defined as follows:
* Primary target = Agents with base skill level > N & language skill > 0
* Secondary target = Agents with base skill level > M & language skill > 0
* Tertiary target = Agents with base skill level > P & language skill > 0

N, M, and P are configurable based on request type and customer context.
====Priority Model====
Different priorities are set for calls according to business value of the type of request. If priorities are set and an agent becomes available, Genesys distributes the call with the highest priority matching the agent's skills. This is specifically relevant if the agent can receive interactions for different types of request. The priority of a call is increased over time to make sure that low-priority calls are still distributed to an agent after a potential longer waiting time (priority tuning). Priority tuning is configured via the following parameters:
* Priority start (the starting priority)
* Priority increment (the amount to increase the priority after the interval time)
* Priority interval (the time between priority increases)
* Priority limit (the maximum priority)

These values are configurable by type of request and by customer context.

In addition, a priority mark-up is configured for customers who have previously completed IDV or ID within the IVR to account for their additional time within the IVR compared to customers who did directly drop out into the queue. The priority mark-up for customers who attempted / complete IDV and ID is relative to the amount of time it takes to complete the IDV and ID verification application within the IVR.

Transferred calls and RONA calls can also get a higher priority assigned.
====Transfer====
The agents can transfer calls to defined internal agent groups or business lines (route points). The routing logic defined for these route points is similar to the routing logic defined above (without initial announcements). Only transfer route points are visible to the agent in WDE.
====Additional functionality====

* RONA-functionality: If an agent does not accept the call, the call is automatically put back into the distribution flow after a time out. The agent is set to not-ready.
* This use case can be combined with other non-voice use cases. Blending is possible. The configuration of priority values need to be synchronized with priority settings for other media types to allow an ordering of interaction within the universal queue corresponding to business requirements. Capacity rules will be configured for the agents / agent groups to define what interactions is handled in parallel (if any).

====Context Service Data====
Customer Context is stored within Genesys Context Service as part of the Universal Customer History Server. The data is provided by the organization. A regular update process has to be set up. Instructions to map the organization's specific data with the data stored in Genesys need to be determined. The following data scheme provides flexibility to map specific organizational data with data to be used within Genesys. The data is used for routing rules or for display of the agent desktop. Context data related to a list is only used if the time and date of the call is within the List Stop and List Start data. The following table shows the available data and how these are used:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Attribute'''
{{!}}{{!}}'''Definition'''
{{!}}{{!}}'''Agent Desktop'''
{{!}}{{!}}'''Routing Rules'''
{{!}}-
{{!}}{{!}}Customer ID
{{!}}{{!}}Unique identifier of the customer
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Name
{{!}}{{!}}Customer Name
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Segment
{{!}}{{!}}Customer Segment
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 1
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 2
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 3
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 4
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 5
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Display Data 1
{{!}}{{!}}Custom Attribute to be displayed at agent desktop
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Display Data 2
{{!}}{{!}}Custom Attribute to be displayed at agent desktop
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}List Name
{{!}}{{!}}This data is used to indicate that the customer is on a specific list / campaign
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Type
{{!}}{{!}}Type of the list or campaign
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Start
{{!}}{{!}}When actions for a list / campaign starts
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Stop
{{!}}{{!}}When actions for a list / campaign stops
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List pop message
{{!}}{{!}}Message to be displayed to agent
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}List actioned
{{!}}{{!}}Indicates if the list / campaign has been already actioned. If the list / campaign has been actions, no list data is displayed to an agent.
{{!}}{{!}}

{{!}}{{!}}X
{{!}}}

====Parameters available per type of request / service====
The following lists the business parameters which are configurable by service. These are configured by Genesys Administrator Extension. Please note that the list is not exhaustive as additional parameters for technical settings might be required. It also does not reflect the technical realization and naming conventions to be used. Also some of the parameters are combined for ease of readability. The list is intended for business readers to give an overview of the flexibility in the configuration of the routing logic:

{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Service Name
{{!}}{{!}}Name of the service.
{{!}}-
{{!}}{{!}}Enable Rules
{{!}}{{!}}Flag to indicate if rules are used for the service. If rules are not enabled for the service, the default parameter settings within GAX are used.
{{!}}-
{{!}}{{!}}Service Emergency Flag
{{!}}{{!}}Flag to set emergency status for the service.
{{!}}-
{{!}}{{!}}Open hours
{{!}}{{!}}Sets the opening hours of the service.
{{!}}-
{{!}}{{!}}Special Day
{{!}}{{!}}A list of exceptions to the regular open hours, for a holiday or other reason.
{{!}}-
{{!}}{{!}}After Hour Message
{{!}}{{!}}Message to be played if the call is out of business hours.
{{!}}-
{{!}}{{!}}Special Day Message
{{!}}{{!}}Message to be played if the call is on a special day.
{{!}}-
{{!}}{{!}}Emergency Message
{{!}}{{!}}Message to be played in emergency situations.
{{!}}-
{{!}}{{!}}EWT flag
{{!}}{{!}}Flag to determine if EWT shall be announced to a customer.
{{!}}-
{{!}}{{!}}EWT Thresholds
{{!}}{{!}}6 Thresholds to activate different EWT announcements (see chapter "EWT Announcements").
{{!}}-
{{!}}{{!}}EWT Announcements
{{!}}{{!}}6 pre-recorded EWT announcements corresponding to the 6 thresholds above.
{{!}}-
{{!}}{{!}}EWT Breach Threshold
{{!}}{{!}}Threshold to determine if a call is queued (see chapter "Expected Wait Time Checkâ€).
{{!}}-
{{!}}{{!}}IDV Type
{{!}}{{!}}Level of ID&V required for the type of request. Values are "None", "ID" or "ID&V". This value is displayed to the agent.
{{!}}-
{{!}}{{!}}Quality Message
{{!}}{{!}}The quality message to be announced to the customer (see chapter "Main Flow").
{{!}}}

====Parameters available per customer context and type of request / service====
The following lists the business parameters which are configurable by service and customer context. Default values for these parameters are configured by Genesys Administrator Extension per service. These base parameters are overwritten by parameters defined by rules using additionally the customer context. These rules are configured in Genesys Rules Engine. Please note that the list is not exhaustive as additional parameters for technical settings might be required. It also does not reflect the technical realization and naming conventions to be used. The list is intended to give business users an overview of the flexibility in the configuration of the routing logic:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Special Message 1&2
{{!}}{{!}}The special messages to be played after the quality message (See chapter “Main Flow”).
{{!}}-
{{!}}{{!}}Last Agent Routing enabled?
{{!}}{{!}}Flag to indicate if Last Agent Routing is enabled for the Service
{{!}}-
{{!}}{{!}}Last Agent Routing Time Out
{{!}}{{!}}Time out used to wait for the last agent.
{{!}}-
{{!}}{{!}}Basic skill
{{!}}{{!}}Basic skill required for this call
{{!}}-
{{!}}{{!}}Supplementary skill
{{!}}{{!}}Supplementary skill for this call.
{{!}}-
{{!}}{{!}}Supplementary skill timeout
{{!}}{{!}}Timeout to wait for an agent with the supplementary skill.
{{!}}-
{{!}}{{!}}Skill Level Targets 1-3
{{!}}{{!}}Skill level thresholds to define the primary, secondary and tertiary target. The skill level defined provides the minimum skill level for the corresponding target.
{{!}}-
{{!}}{{!}}Timeout 1,2
{{!}}{{!}}Timeouts to wait for the primary and secondary target.
{{!}}-
{{!}}{{!}}In Queue Messages and Music
{{!}}{{!}}Parameters to define the in busy treatments as described in chapter Busy Treatment.
{{!}}}

====Reporting Parameters====
The following five business parameters represent reporting categories and are completely customizable to your business model. You can assign different combinations of these parameters to each of your Inbound and Distribution parameter groups, to distinguish them in reporting and enable you to identify the unique properties of the parameter group.
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Department
{{!}}{{!}}Business organization used as a category for reporting
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}A business flow used as a category in reporting
{{!}}-
{{!}}{{!}}Product
{{!}}{{!}}A product or product group used in reporting
{{!}}-
{{!}}{{!}}Service
{{!}}{{!}}Business categories typically used as the top level of the call steering menu choices
{{!}}}
|DistributionImageFlow={{SMART DistributionImageFlow
|DistributionFlowIntro=====Main Distribution Flow====
|DistributionImage=https://www.lucidchart.com/documents/edit/e5947052-7250-42e7-9121-a49817f763e3/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}The customer calls one of the numbers of the contact center.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}The IVR determines the type of request (or service) and the customer ID (out of scope for this use case).
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}Genesys performs a check if the customer calls within the business hours for his requested service. The call may be: Within business hours/ After hours/ On special days (e.g. public holidays). In the last two cases, a corresponding announcement is played. The caller is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Genesys performs a check if an Emergency Condition is activated for the call. In this case, a corresponding announcement is played and the call is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}The expected wait time is calculated. If the expected wait time is beyond a configured threshold, a corresponding announcement is played and the call is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}A quality message is played to satisfy compliance requirements.
{{!}}-
{{!}}{{!}}7
{{!}}{{!}}Up to two special messages are played which depend on the type of request and the customer context.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Expected Wait Time Check====
|DistributionImage=https://www.lucidchart.com/documents/edit/8a81a389-dc26-4c83-b079-e469e9403104/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}Genesys calculates the Expected Waiting Time for the call.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}If the EWT is beyond a configurable threshold, the flow returns to the main flow to determine further processing.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}The Expected Wait Time is announced to the customer based on predefined intervals and pre-recorded announcements.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Targeting====
|DistributionImage=https://www.lucidchart.com/documents/edit/1d07ada0-6a1c-41ff-9784-5e7fdbbad52e/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}Genesys determines if Last Agent Routing is activated for the call (configurable by type of request and context data, such as customer segment).
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}If Last Agent Routing is activated, Genesys verifies if the customer has spoken to an agent for the current type of request within a configurable time period. In case of a matching entry, Genesys attempts to distribute to this agent. After a configurable timeout the call continues with the distribution to the skill.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}Genesys calculates the Expected Wait Time (EWT) for the call based on a distribution to the primary target group of all agents being able to handle the service (without any supplementary skill). If the EWT is above a configurable threshold, the routing logic immediately continues with the secondary target group.
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Genesys checks if a supplementary skill is required based on the customer context data.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}In this case, Genesys queues the call for all agents within the primary target group who also have the supplementary skill. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the full primary target group.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}Genesys targets all agents within the primary target group. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the secondary target group.
{{!}}-
{{!}}{{!}}7
{{!}}{{!}}Genesys targets all agents within the secondary target group. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the tertiary target group.
{{!}}-
{{!}}{{!}}8
{{!}}{{!}}Genesys targets all agents within the tertiary target group until an agent becomes available.
{{!}}-
{{!}}{{!}}9
{{!}}{{!}}When an agent becomes available, Genesys distributes the call to this agent.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Conversation====
|DistributionImage=https://www.lucidchart.com/documents/edit/36f7333a-d340-4b4a-8737-7d9aad8e87ee/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}When the call is distributed to the agent, all relevant information on the call and the customer context is displayed at the agent workspace.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}The agent handles the customer request.
{{!}}{{!}}.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}The customer may not have identified and verified upfront, but his request may require identification and potentially verification. In this case, the agent can handle this manually via a third party system (outside of the scope of this use case).
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Once the customer is identified (and verified), the agent can update the customer Id and Verification status in Genesys. The customer context is retrieved from Genesys and displayed to the agent.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}After the conversation, the agent can set the call outcome including the information whether he acted on a specific lead (if part of the customer’s context data). This information is used for reporting purposes.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}Additionally, the information is updated in Context Services to avoid that the customer is presented with the same lead when he calls again.
{{!}}}
}}
|DistributionLogic=====Call Qualification & Customer Identification (outside of scope of this use case)====
As a prerequisite for this use case call qualification and customer identification is handled by an IVR application upfront of the start of this use cases. This IVR application is outside the scope of this use case.Use case CE7 - Effective Identification & Validation in IVR can be used for this functionality.

The assumption is that Genesys receives the following information from the IVR:
* Type of Request / Service (either via DTMF, natural language recognition or IVR intelligence).
* Caller language
* Caller identification
** Information on the status of the identification:
*** Anonymous
*** Identification provided
*** Identification and Verification (ID&V) provided
** Customer ID
*** the customer ID might be any ID as used by the organization which identifies the customer
*** Alternatively the CLI is used for customer identification, however this is less reliable

This input is used to determine the parameters for the specific customer call.

'''Remark on naming convention in this document:'''

"Type of request/service" is the mapping of a customer call to his need by using an IVR prequalification like DTMF menu. Therefore it may be more granular than a published service number for the contact center, or a department within the contact center (e.g. Sales, Billing). The latter is sometimes also referred as service within some organizations. However, in this document, "service" is used interchangeably with "type of request" and referring to the more granular definition.
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=====Context Data====
When a call is distributed to an agent the following data is displayed:
* Context Services Data as defined in chapter “Context Service Data”
* Customer language
* Time in IVR and in Queue
* ID & V Status
* ID or ID & V required for service?
* Indicator if a special promotional message has been played

====Call Outcome / Disposition Code====
If a lead is presented to the agent, he can classify the outcome within the agent desktop. This outcome includes the information whether the lead has been actioned. The data if a lead has been actioned is stored in Context Services to enable rules that it is not presented to an agent again.

Additionally, the call outcome is used for reporting purposes.

Up to 10 different call outcomes / disposition codes are configured.
====ID&V====
The agent is able to handle manual Identification and (optionally) Verification if required for the specific customer request. The ID&V is handled in an application outside of Genesys. However, it is possible for the agent to update the ID&V status of the call. In this case, the call data is updated and if the customer has not been identified before, the customer-related data from context services is retrieved and displayed to the agent. See also section “Conversation”.
====General Requirements====

* Agents can transfer calls to other individual agents as out-of-the-box functionality.
* Transfer: See chapter “Transfer”
* Configuration of not-ready reason codes (e.g Admin Work, Lunch, Meeting, Pause, RONA).
|RealTimeReporting=''Pulse''' is a Genesys Administrator Extension (GAX) plug-in application that offers personalized dashboards based on specific functional, geographical or organizational needs. Pulse dashboards present information using graphical “widgets” that can be viewed as graphs or tables, showing information about specific key performance indicators, such as service level, interactions handled, and the average handle time.

With Pulse you can:
* Monitor the current state and activity of Contact Center objects to help make decisions about staffing, scheduling and call routing strategies.
* Create widgets from predefined and user-defined templates for a fast and easy text or graphical presentation of selected or user-defined object statistics.
* Predefined Inbound templates
** Agent KPIs
** Agent Group Status
** Agent Login
** Queue KPIs
|HistoricalReporting=Interactive Insights out-of-the-box reports will be used to:
* Assess the day-to-day operations of the contact center resources for the routing and handling of interactions.
* Measure the effectiveness of the Engagement Rules and efficiency of the use case with the Customer Perspective Report and the Interaction Volume Customer Segment Report.
* Dimension the out-of-the-box aggregate based GI2 reports with Routing Parameters including the Engagement Rules and the Disposition codes.
* With Disposition codes calculate the conversion success rate
* Evaluate resource performance with a variety of reports for Agents and Detail facts
There are 40+ reports available, potential reports to confirm the benefits for this use case are being met are as follows.'''Agent KPIs'''enable the organization to measure and filter InfoMart data based on the interaction-related activities that are conducted by active agents.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Sample Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Activity
{{!}}{{!}}Examples for available KPIs:
* Abandoned Inviting
* Accepted
* Conference Initiated
* Consult Initiated
* Engage Time
* Handle Time
* Hold
* Invite
* Offered
* Rejected
* Wrap
{{!}}{{!}}Agent interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the agent.
{{!}}-
{{!}}{{!}}InteractionState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Engage Time
* % Hold Time
* % Invite Time
* % Wrap In Time
* Accepted
* Consult Received Accepted
* Engage Time
* Not Accepted
* Not Ready In Time
* Offered
{{!}}{{!}}Agent interaction level data.
Measures are attributed to each reporting interval in which agents handle the interactions and durations are clipped at interval boundaries.
{{!}}-
{{!}}{{!}}SummarizedState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Busy Time
* % Not Ready Reason Time
* % Occupancy
* % Ready Time
* % Wrap Time
* Active Time
* Not Ready
* Not Ready Reason Time
* Wrap
{{!}}{{!}}Agent summarized data for a session.
Measures are attributed to each reporting interval in which agents handle the calls, and durations are clipped at interval boundaries.
{{!}}}
'''Queue KPI'''enable the organization to measure and filter InfoMart data based on the queue(s) through which customer interactions pass or the Business Attributes associated with the interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Queue KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Queue
{{!}}{{!}}Examples for available KPIs:
* Period
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Abandoned Waiting
* Abandoned Time
* Not Accepted
* Redirected
* Accepted Agent
* Accepted Agent in Threshold
* Accept Time Agent
* % Service Level
* Invite Time
* Engage Time
* Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}Queue interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the queue.
{{!}}}
'''Business Attribute KPI'''enable the organization to measure and filter Info Mart data based on the business attributes that are associated with the customer interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the Contact Center.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Business Attributes KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Business Attributes
{{!}}{{!}}Examples for available KPIs:
* Period
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Entered Obj
* Abandoned Waiting
* Not Accepted
* Redirected
* Accepted
* Accepted in Threshold
* Accept Time Agent
* % Service Level
* Engage Time
* Handle Time
* Avg Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}Business Attribute interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered by business attribute.
{{!}}}
'''Accepted Agent'''enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions pass in which agents accept or answer the interaction. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Accepted Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Accepted Agent
{{!}}{{!}}Available KPIs:
* Queue Name
* Mediaedia Type
* Customerustomer Segment
* Service Type
* Service Subtype
* Accepted Waiting 1..20 Thresholds
* % Accepted Waiting 1..20 Thresholds
{{!}}{{!}}Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were accepted as well as the percentage of interactions that were accepted within a specific set of time ranges.
{{!}}}
'''Abandoned Waiting'''enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions abandoned while waiting to be answered. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Abandoned Waiting KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Abandoned Waiting
{{!}}{{!}}Available KPIs:
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Abandoned Waiting 1..20 Thresholds
* % Abandoned Waiting 1..20 Thresholds
{{!}}{{!}}Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were abandoned as well as the percentage of interactions that were abandoned, while the interactions were queued at a specific queue for a specific set of time ranges. The time ranges are configured within the InfoMart Application options.
{{!}}}
'''Interaction Details'''enable the organization to track low-level interaction details.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Interaction Detail KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Handling Attempt
{{!}}{{!}}Available KPIs:
* Interaction ID
* Connection ID
* Media Type
* Customer ID
* Customer Segment
* Service Type
* Service Subtype
* Business Result
* Interaction Type
* Start Timestamp
* End Timestamp
* Routing Target
* Resource Role
* Role Reason
* Technical Result
* Result Reason
* Queue Time
* Route Point Time
* Total Duration
* Customer Talk Time
* Customer Hold Time
* Customer Wrap Time
* ....
{{!}}{{!}}Handling Attempt detail interaction level data.

Handling Attempt details of interactions that are stored mostly in the INTERACTION_RESOURCE_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}Available KPIs:
* Agent/Queue
* Connection ID
* Media Type
* Customer ID
* Interaction ID
* Interaction Type
* Interaction Subtype
* Segment ID
* Source
* Target
* Technical Result Resource Role
* Technical Result Role Reason
* Technical Result
* Technical Result Reason
* Duration
{{!}}{{!}}Flow detail interaction level data.

Interaction-flow details of interactions that are stored mostly in the INTERACTION_FACT, INTERACTION_RESOURCE_FACT, and MEDIATION_SEGMENT_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Transfer
{{!}}{{!}}Available KPIs:
* Interaction ID
* Media Type
* Source
* Source Service Type
* Source Service Subtype
* Source Customer Segment
* Source Last Queue
* Source Technical Result
* Source Customer Engage Time
* Source Customer Hold Time
* Source Customer Wrap Time
* Source Queue Time
* Target
* Target Service Type
* Target Service Subtype
* Target Customer Segment
* Target Last Queue
* Target Technical Result
* Target Customer Engage Time
* Target Customer Hold Time
* Target Customer Wrap Time
* Target Queue Time
* ....
{{!}}{{!}}Transfer detail interaction level data.

Interaction details identifying the source and destination of transferred and conference interactions.
{{!}}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=version 1.1.3
}}
|CustomerAssumptions=* The IVR application to determine the type of request and customer ID is not part of this use case and has to be provided separately.
** Alternatively, SIP Qualification and Parking with a script controlled by routing are used if full GVP application is not required. This functionality is also not included within the use case.
* All announcements are to be provided by the customer
* A process to upload and update customer data within Genesys Context Services needs to be set up.
|Optional=CE07
|SMART_PremiseAssumptions={{SMART PremiseAssumptions
|Premise_Assumption=Implementation based on SIP Server (SIP Voice Blueprint)
}}{{SMART PremiseAssumptions
|Premise_Assumption=Routing parameters are configured through GAX operational parameter groups or Genesys Rules Engine, which are referenced in the underlying strategy / routing application
}}{{SMART PremiseAssumptions
|Premise_Assumption=Genesys Infomart and Interactive Insights is used for historical reporting
}}{{SMART PremiseAssumptions
|Premise_Assumption=WDE is used as agent desktop
}}{{SMART PremiseAssumptions
|Premise_Assumption=Pulse is used for real-time reporting.
}}
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is not supported in Cloud.
}}
}}

UseCases/Current/GenesysEngage-onpremises/CE27

2019-04-22T10:00:00Z

PLeprieult: Published

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Mitigate customer frustration by providing a better method to serve and assist customers thereby reducing customer effort
}}{{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Reduce shopping cart abandonment and increase online conversion rates
}}{{SMART Benefits
|UCBenefitID=Improved First Contact Resolution
|UCBenefit=Optimize the customer service experience by initiating a co-browse session with the customer to resolve their request the first time
}}{{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Improve understanding of request or issue and reduce the duration of the customer interaction by using co-browse
}}
|UCOverview=A customer and a contact center agent are having a conversation over the phone or through a web chat session. During the conversation, the ability to see and control the customer's browser through co-browsing functionality enables the agent to convey information more effectively and get the customer's issue resolved more quickly.
|UCSummary=During a call or a chat session between a customer and an agent, the customer can initiate a co-browse session with the agent, so both the agent and the customer share the same instance of the browser. This enables the agent to provide direct support to a customer trying to complete a request on the company's website.
|PainPoints=* Increasing competitive pressure
* High customer churn
* High purchase abandonment
* Unable to use context
* Poor customer experience scores
* Calls with long handle times
* No assisted service online
* Unable to provide a personalized assisted service experience
* Increasing calls related to online service and support
* Online help not providing the information customers need
|DesiredState=* Enable co-browse and provide specialist assistance
* Proactively offer assistance through co-browse sessions
|SellableItems=See sellable items for CE01 CE02 CE18 CE21 CE22 CE24 or CE25
|CloudAssumptions=This use case is currently not available in PureEngage Cloud
|CloudAssumptionsAdditional_Sales=Capabilities Assumption:
* This use case is currently not confirmed for use in PureEngage Cloud.
|PremiseAssumptionsAdditional_Sales=* This use case is available for Premise
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following flow describes the use case from the perspective of the customer and the contact center agent.
|BusinessImage=https://www.lucidchart.com/documents/edit/0b9ea69e-4e73-463d-9cd6-1d5214eab1b0/0
|BusinessFlowDescription=# The customer and agent are connected via a chat session or a voice call.
# The agent may propose to the customer to start a co-browse session to support him/her on the website. For security reasons, only the customer can initiate the co-browse session.
#* '''Call only:''' A session ID is displayed to the customer if he/she clicks the co-browse link in the Assistance/Channel Selector Widget. This session ID is needed to join the agent desktop with the correct browser session. The customer gives this session ID to the agent over the phone. The agent enters the session ID into the agent desktop to start the co-browse session.
#* '''Chat only:''' The customer clicks the three-dots icon on the chat widget and selects "Start Co-browse".
# When the session is established, the agent's desktop displays a view of the website in the browser window the customer is using. Agents start co-browse sessions in Pointer Mode. In Pointer Mode, the customer and the agent can see each other's mouse pointer but the agent cannot enter any information into the web page, click buttons, or navigate the customer's browser.
# If the agent needs to enter information into the web page or to navigate the browser, he/she can send the customer a request to switch the co-browse session to Write Mode.
# Once the customer accepts this request, the agent can navigate, fill forms, and click hyperlinks on the web page. Sensitive Data can be masked before presenting to the agent, and agent controls (the ability to fill certain fields or submit forms) can be blocked through instrumentation. The customer can revoke the Write Mode at any time, returning the agent to Pointer Mode.
# The co-browse session ends when any of the following events occurs:
#* The customer chooses to end the co-browse session
#* The agent chooses to end the co-browse session
#* The primary chat or voice interaction is transferred or ended by either the customer or the agent
#* Due to inactivity after a preconfigured time-out expires
The primary voice or chat interaction can continue even when co-browse has ended.
}}
|BusinessLogic='''Starting a co-browse session without primary interaction:''' Co-browse sessions take place on top of a primary interaction (in this case, chat or voice). If the customer initiates a co-browse without any primary media, the instrumentation prompts the customer to initiate a conversation via voice or chat before initiating the co-browse.
|DistributionLogic=N/A
|CustomerInterfaceRequirements=The user interface is based on Genesys Widgets.

Sample screenshots:

*Co-browsing can be started or ended from the chat widget:

[[File:DigVoCWebExp3.png]]

*Co-browsing can be started when on a voice call:

[[File:CE27live.png]]

'''Widget Functionality'''

Widgets can provide basic adaptation to customer corporate identity, including:
*Add customer logo
*Use corporate identity, colors, and fonts
|AgentDeskRequirements=The agent interface related to co-browse must:
*Enter the session ID when co-browse needs to be started from a voice call
*Automatically start a co-browse session if the session has been initiated by the customer through their chat widget
*Display the customer page view when co-browse is engaged
Transfer, Conference, and Supervision of co-browse sessions are not supported.
|RealTimeReporting=Minimum requirements:

* Implementation of standard templates in Pulse: eServices Queue KPI, eServices Agent Activity

Current Co-browse Agents

* Chat Agents: Number of agents working on chat
* Chat with Co-browse: Number of agents working on chat with co-browse
* Inbound Voice: Number of agents working on inbound voice
* Inbound Voice with Co-browse: Number of agents working on inbound voice with co-browse

Current Chat Interactions with Co-browse

*Chat: Number of chat interactions currently handled by agents
*Co-browse in Chat: Number of chat with co-browse interactions currently handled by agents
*(Co-browse in Chat)/Chat, %: Ratio of current number of chat with co-browse interactions to the total number of chat interactions
*Web Chat: Number of web chat interactions currently handled by agents
Co-browse in Web Chat: Number of web chat with co-browse interactions currently handled by agents
*(Co-browse in Web Chat)/Web Chat, %: Ratio of current number of web chat with co-browse interactions to the total number of web chat interactions

Current Voice Interactions with Co-browse

*Inbound Voice: Number of inbound voice interactions currently handled by agents
*Co-browse in Inbound Voice: Number of inbound voice with co-browse interactions currently handled by agents
*(Co-browse on Inbound Voice)/Inbound Voice, %: Ratio of current inbound voice with co-browse interactions to the total number of inbound voice interactions

Co-browse Session Details

*Current Agent State: Auxiliary statistic needed for user data retrieval
*Co-browse Session State: Alive or finished
*Co-browse Session Start Time: Session start time
*Co-browse Session ID: Session ID
*Co-browse Session Quantity: Session quantity
|HistoricalReporting=Historical Reporting is currently under development and projected for delivery in 3Q2018. Timeline is subject to adjustment.
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.1.3
}}
|CustomerAssumptions=* The Genesys customer is responsible for integration of the solution into the company website.
* The Genesys customer is responsible for tagging information and fields on their website that need to be hidden from the agent during a co-browse session, or agent controls that need to be blocked (such as a Submit form).

[[file:DigVoCWebExp2.png]]
|RequiresOr=CE01, CE01-S4B, CE02, CE18, CE21, CE22
|PremiseAssumptionsAdditional=* Workspace Desktop Edition is the agent desktop.
* Pulse is used for real-time reporting.
* Use of Genesys Widgets with limited modification to the company's corporate identity as described above, under “Widget Functionality”. Alternatively, use of custom chat widget which is not part of Genesys deliverable.
* No integration with third-party systems.
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is currently not available in PureEngage Cloud
}}
}}

UseCases/Current/GenesysEngage-onpremises/EE15

2019-04-22T10:00:00Z

PLeprieult: Created page with "{{SMART UseCase |SMART_Benefits={{SMART Benefits |UCBenefitID=Reduced Administration Costs |UCBenefit=Employees manage their development plans online, reducing administration..."

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Reduced Administration Costs
|UCBenefit=Employees manage their development plans online, reducing administration overhead.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Attrition Rate
|UCBenefit=Employees with clear and defined personalized development plans feel valued and are less likely to leave.
}}{{SMART Benefits
|UCBenefitID=Improved Agent Competency
|UCBenefit=Individual development plans are aligned with overall organization goals and can be continually reviewed to align performance.
}}
|UCOverview=Employees can build their own Personal Development Plans, aligning the plans to their own individual KPI measurements. Managers can review, update and approve the plans in line with company goals. The solution can be used across the enterprise.This use case leverages the benefits from {{#mintydocs_link:topic=EE14}} and {{#mintydocs_link:topic=EE16}}, and provides these added benefits:
* '''Online employee development plans''' – development plans can be created online, enabling the individual employee and manager to set objectives and development goals that are agreed on by both parties.
* '''Continual development reviews''' – continual reviews of individual development can be carried out between the individual and manager to measure performance improvements over time.
* '''Alignment of objectives with KPI targets''' – Key Performance Indicators can be used to set goals directly linked to individual performance.
* '''Minimize employee attrition''' – Providing each employee with a clear and defined personalized development plan and career progression.
|UCSummary=Delivers the capability to the manager to build an employee journey with objectives and targets to be met and to track it across time.
|PainPoints=* Ineffective processes for managing Performance Reviews –Process to measure the Personal Development Plans of employees is either manual or not aligned to KPIs
* No centralized view of employee development plans –Management have no holistic view of Personal Development Plans for employees which in turn hampers the development of a company-wide development strategy.
* High employee attrition– Employees are leaving the business as they don’t feel like they have clear personal development. Initial investment in employee development has slowed following onboarding training.
|DesiredState=* Clear visibility of the overall employee’s morale across the enterprise
* The ability to provide a clear and defined personalized development plans and career progression for each employee based
* Able to delivery effective and targeted learning quickly based on each employees knowledge gaps.
* Have a centralize platform to track employee skills and capability across the entire employee journey.
|SellableItems=No sellable items, Please see prerequisits
|CloudAssumptionsAdditional_Sales=Capabilities Assumption:
* The full use case outlined here is available in the cloud.
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:
* The full use case outlined here is available on premise.
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessImage=https://www.lucidchart.com/documents/edit/c688233e-0ac7-4b21-bb09-8b5314c60ff7/0
|BusinessFlowDescription=# Base-level Configuration Completed.
#* Employee creates Personal Development Plan with clear objectives and goals.
# Manager reviews Development Plan with individual and amends or adjusts as required.
#* Measurements set against KPIs and individual goals set and agreed upon.
# Approval by Manager of finalized plan.
# Periodic review carried out between manager and employee – comments added through the journey.
# Manager completes the "recommend potential capability" of employee.
# New goals and targets are set as employee progresses and improves.
}}
|BusinessLogic=Employees propose the objectives and how they are to be achieved, and must decide on the target types and targets associated to the objectives.

A review process meeting takes place between the Manager and employee to agree the final targets.

Business users create a Feedback Potential Capability Assessment.

Manager approve the proposed plan, review the results on a periodic basis, and complete a potential capability assessment of the employee.
|DistributionLogic=N/A
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=Agents access the Performance DNA Web UI with a supported browser.
See [https://docs.genesys.com/Documentation/System/latest/SOE/Welcome Supported Operating Environment Guide] for specific browser support.
|RealTimeReporting=N/A
|HistoricalReporting=The Genesys PDNA product contains a number of out-of-the-box reports. See the [https://docs.genesys.com/Special:Repository/85_skillsassessor_administrator.pdf?id=b3e6b461-2253-47c4-ae72-27f4656186c7 Skills Assessor (PDNA) Administration Guide] for details.
|RequiresOr=EE14, EE16
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.0.3
}}
}}

UseCases/Current/GenesysCloud/CE27

2019-04-22T10:00:00Z

PLeprieult: Published

{{SMART UseCase
|UCOverview=A customer and a contact center agent are having a conversation over the phone or through a web chat session. During the conversation, the ability to see and control the customer's browser through co-browsing functionality enables the agent to convey information more effectively and get the customer's issue resolved more quickly.
|UCSummary=During a call or a chat session between a customer and an agent, the customer can initiate a co-browse session with the agent, so both the agent and the customer share the same instance of the browser. This enables the agent to provide direct support to a customer trying to complete a request on the company's website.
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessImage=https://www.lucidchart.com/documents/edit/322bc033-f6b0-462f-b0a3-a9b12bafd567/0
|BusinessFlowDescription=# The customer and agent are connected via a chat session or a voice call.
# The agent may propose to the customer to start a co-browse session to support him/her on the website. For security reasons, the customer and agent have to initiate the co-browse session.
#* '''Call only''': A security ID is displayed to the agent if he/she clicks the 'screen sharing link' in the PureCloud UI. This security key is then given over the phone by the agent to the customer and entered by the customer. The customer enters the security key into the website to start the co-browse session.
#* '''Chat only''': The customer clicks the 'start sharing' option when asked the question if they want to share their screen.
# When the session is established, the PureCloud UI displays a view of the website in the browser window the customer is using. Agents start co-browse sessions in read-only mode. In read-only mode, the customer and the agent can see each other's mouse pointer but the agent cannot enter any information into the web page, click buttons, or navigate the customer's browser. The agent does have the ability to highlight sections of the page (by clicking) or to add annotations to the page to guide the customer.
# If the agent needs to enter information into the web page or to navigate the browser, he/she can send the customer a 'request navigation'.
# Once the customer accepts this request, the agent can navigate, fill forms, and click hyperlinks on the web page. Sensitive Data can be masked before presenting to the agent, and agent controls (the ability to fill certain fields or submit forms) can be blocked through instrumentation. The customer can revoke the Write Mode at any time, returning the agent to read-only mode.
# The co-browse session ends when any of the following events occurs:
#* The customer chooses to end the co-browse session
#* The agent chooses to end the co-browse session
#* The primary chat or voice interaction is transferred or ended by either the customer or the agent
#* For a WebChat session after 15 minutes of inactivity the session will be disconnected. There is no timeout when using voice.
The primary voice or chat interaction can continue even when co-browse has ended.
}}
|CustomerInterfaceRequirements=Logic on the customer website will be added to support co-browse capabilities. Customer can decide exactly how they want this functionality to look and where to place this on their website.

Agents will use the standard PureCloud user interface which will allow them to start a sharing session and generate a security key.

Transfers, Conference, and Supervision of co-browse sessions are not supported. Conversations can be transferred if the co-browse session itself has ended.
|RealTimeReporting=No realtime co-browse data is currently available, this will be added in a future release.
|HistoricalReporting=* Interactions Detail View: Co-Browse sessions are shown in the Interactions Timeline information.
* Interaction History for External Contacts: Co-browse sessions are shown in the interaction history screen for related conversations.
* Additional co-browse metrics are available via the PureCloud API's, not all of this data is currently exposed in the various performance views.
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.0.1
}}
|GeneralAssumptions=* Customer has PureCloud 3 licensing for their organization.
* Customer has prepared their website to work with Co-Browse (https://help.mypurecloud.com/articles/set-co-browse/)
* Customer has added tags to private data on their website to control what can and cannot be seen by the agent.
|CustomerAssumptions=* Customer is responsible for integration of the solution into the company website.
* Customer is responsible for tagging information and fields on their website that need to be hidden from the agent during a co-browse session, or agent controls that need to be blocked (such as Submit form).
|RequiresOr=CE01, CE18
}}

UseCases/Current/GenesysEngage-onpremises/CE01

2018-10-26T10:31:35Z

PLeprieult:

UseCases/Current/GenesysEngage-onpremises/SL06

2018-10-25T15:16:58Z

PLeprieult:

{{SMART UseCase
|CloudAssumptionsAdditional_Sales=See BO06
|PremiseAssumptionsAdditional_Sales=See BO06
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=====Model Creation====
The following flow shows how a model is created. The main actor of this flow is typically a Business Analyst / Data Analyst in charge of the model creation. The Analyst is a trained professional from Genesys, a partner, or a customer organization.
|BusinessImage=https://www.lucidchart.com/documents/edit/a4257aa9-6e73-4dc8-95f7-f592c45d78ec/0
|BusinessFlowDescription=# The team Lead / Supervisor and the Analyst agree on the outcome metric to be used. This use case uses revenue optimization as the reference metric.
# The Analyst gathers customer profile, interaction profile, and agent profile data from Info Mart, and revenue data from sales records (such as CRM) or Info Mart, if captured in the data model.
# The Analyst analyses the data to determine correlating factors/predictors and verify if the data is suitable for a predictive model.
# The Analyst creates a predictive model based on the available data set.
# The Analyst reviews the quality of the predictive model and potential for uplift. If the quality is satisfactory, the model can be provisioned.
The modeling process described above may be extended to incorporate the following changes:
* Integration of additional 3rd-party data sources for customer profile (such as CRM), agent profile (such as WFO), content analysis data (speech or text), or outcome data (such as CRM or case management)
* Selection of other KPI(s) to optimize based on Info Mart data (such as AHT) or 3rd-party data (such as NPS)
The selection, analysis, and integration of this data into the predictive model requires a project-based implementation that is supported by the Predictive Routing product, but not described in this use case. Contact Genesys Professional Services for more details.
}}{{SMART BusinessImageFlow
|BusinessFlow=====Predictive Routing for Sales====
This business flow shows the use case from the perspective of the customer and agent.
|BusinessImage=https://www.lucidchart.com/documents/edit/bd1c6f7f-98e5-441d-b014-929efe84e045/0
|BusinessFlowDescription=# The customer contacts the company using one of the available inbound channels (such as voice, e-mail, chat, mobile, work item, or Apple Business Chat).* This inbound interaction may be the result of a proactive rule on a web or mobile application.
# One of the Inbound use cases for the corresponding media type handles the interaction. The context data is captured depending on the interaction and engagement type.
# Genesys queues the interaction until at least one agent with the required skill(s) is available.
# Predictive Routing ranks the agents against expected revenue for that specific interaction and returns a ranked list with values.
# Genesys checks if the rank for at least one agent is above the threshold.
# If no agents are available within the configured timeout, the routing expands the potential target pool of agents, such as by reducing the required skill level.
# If yes, Genesys distributes to the best available agent based on the predictive model (the agent with the highest rank) and the routing rules.
# The agent disconnects the interaction.
# The outcome is mapped to an InfoMart attribute (for example, a disposition code or custom key value pair)
# Optional: The customer is offered a survey. The answer to the survey is stored in a third-party system.
# Optional: Outcome data, such as CRM sales transaction completion and value, is produced and stored by a third-party application.

The outbound scenario differs from this flow as the agent routing function is triggered by the dialing algorithm to the customer. Nevertheless, In Predictive and Progressive mode, once the customer answers, the agent distribution is based on the same predictive routing principle. As the Preview mode is not distributed through routing, this use case does not apply to Preview mode.
}}
|BusinessLogic=====Parameters and Business Rules - Create Predictive Model====
'''Model Step 1'''
* The business representative of the company decides on the KPI to be improved by Predictive Routing. This use case selects revenue as determined by the sales record system.
* The company decides which metrics to use, in this case the values for revenue.
* Other KPI types can be considered through a project-based implementation.

'''Model Step 2'''
* The user gathers the sales revenue, agent profile, interaction profile and customer profile data from Genesys Info Mart and the Sales records system.
* Predictive Routing then ingests the data into the system as the basis for the predictive model.
* Other Genesys or 3rd-party data sources can be considered through a project-based implementation.

'''Model Step 3'''
* The user assesses the data for predictability of revenue:
** The data is analyzed for variance in revenue by intention and agent. The results indicate whether a predictive model can generate significant improvement from the data.
** Each data point is analyzed for its correlating factor to revenue.
* The user prepares to create the model.

'''Model Step 4'''
* The system creates the predictive model to rank the revenue for customer-to-agent matching.
* The model can be made available for further analysis before provisioning into production.

'''Model Step 5'''
* The potential uplift of revenue using the predictive model is analyzed for effectiveness and the predictive model is then provisioned for use within customer-to-agent matching
** The analyst evaluates the model to determine the potential uplift in revenue for this predictive model.
** The system shows the expected mathematical accuracy of the model through taking a percentage (such as 80%) of the data to train the model and then using the remaining percentage (such as 20%) of the data to predict the outcome with the model. Then the system compares the predicted results with the actual results and provides model accuracy information.

====Parameters and Business Rules – Predictive Routing Revenue====
'''Routing Step 1'''
* Through Inbound, Digital, Workload Management, and other use cases, the customer creates an interaction on any media type that is stored within Info Mart for the defined FCR metric. This use case supports all inbound and outbound channels involving Genesys routing. See Use Case Interdependencies for details.
* Precondition: This use case requires one or more use cases handling inbound or outbound interactions.

'''Routing Step 2'''
* The inbound interaction use case identifies the primary intention of the customer (Service Type) and the initial target skill expression is set. The necessary predictors identified during model creation are available to the interaction and can be passed to Predictive Routing.
* Any required additional customer or agent profile data available to the interaction in run time can be integrated through a project-based implementation.

'''Routing Step 3'''
* This step queues the interaction and is designed to cover both agent surplus and customer surplus scenarios. When either one or multiple agents are available (agent surplus scenario), the flow immediately proceeds. Otherwise, Genesys queues the interaction until an agent is available (customer surplus scenario). The system starts to balance the service level with the business KPI through maintaining priority.

'''Routing Step 4'''
* Once one or more agents are available, the necessary Customer Profile, Interaction Profile, Agent Profile, and predictor information is passed to Predictive Routing to rank the customer interactions in the queue against the agent outcome. This process caters to both customer surplus and agent surplus scenarios.

'''Routing Step 5'''
* The rank for each of the interactions against each of the agents is returned to routing to bias the customer-to-agent matching towards the agent(s) that can deliver the highest FCR.
* The system works in both customer and agent surplus modes. In a customer surplus scenario, the system delivers the highest priority interaction(s) and when multiple interactions are targeting the available agent, the highest priority and then the highest FCR match applies.

'''Routing Step 6'''
* If at least one of the revenue values is above the threshold, the interaction is routed to the agent with the highest revenue.
* The system delivers the interaction normally, handling any ring on no answer and exception situations (applicable to voice, open media, or digital channels) as defined in the underlying use case.
* The customer and the agent are connected.

'''Routing Step 7'''
* Optionally: If no appropriately ranked agent become available or the available agent does not have a sufficiently high FCR value, the value threshold is reduced after the configured amount of time.
* Normal target expansion, such as relaxing skill level as configured within the underlying distribution strategy, occurs.
* The continual re-prioritization of the interaction also occurs as do any treatments and the queued customer experience.

'''Routing Step 9'''
* The outcome of the interaction is captured through the agent desktop or a server-side process. Genesys APIs are invoked automatically or after an agent action to map the outcome to a Genesys interaction attribute: custom attached data or disposition code.
* Info Mart captures this attribute with the Info Mart interaction record.

'''Routing Step 10'''
* Optionally, the customer receives a survey (the survey results are not connected with Genesys and are intended to evolve with the survey use cases)
* The survey is completed (optionally) and the outcome is collected and stored by a 3rd-party application.

'''Routing Step 11'''
* Optionally, the outcome data is produced and stored by third-party application.
|DistributionLogic=The details of the distribution of an interaction to an agent are defined in the underlying Inbound, Digital, or Outbound use cases. Refer to the flow above to understand how Predictive Routing influences the distribution logic.

Predictive Routing provides a routing lever that can be used to control how customer-to-agent matching behaves in customer surplus mode to distribute the interactions based on agent occupancy.
|SellableItems=See Prerequisits
|RequiresOr=CE16, CE18, CE19, CE20, CE24, CE01, CE02, CE11, CE12, BO01, BO02, BO03, BO04, CE29
|Exceptions=CE17, EE04
|SMART_PremiseAssumptions={{SMART PremiseAssumptions
|Premise_Assumption=This use case is for revenue optimization but can be extended to other Sales KPIs.
}}{{SMART PremiseAssumptions
|Premise_Assumption=The standard deployment materials address Inbound voice interactions only, and Informart data only.
}}{{SMART PremiseAssumptions
|Premise_Assumption=Omnichannel and outbound integrations require Genesys Product Management approval and Genesys Professional Services support.
}}{{SMART PremiseAssumptions
|Premise_Assumption=Integration of additional data sources, Genesys or 3rd-party, requires a dedicated assessment and implementation by Genesys Professional Services.
}}{{SMART PremiseAssumptions
|Premise_Assumption=Digital, Workload Management and Outbound integrations require Genesys PS, Product, and R&D support.
}}{{SMART PremiseAssumptions
|Premise_Assumption=Customer should have one or more Genesys channels.
}}{{SMART PremiseAssumptions
|Premise_Assumption=Prerequisites: An implemented use case for one or more channels and Info Mart reporting. These use cases populate the predictors in the routing and the data necessary to build the models. This solution cannot use data that is not present.
}}{{SMART PremiseAssumptions
|Premise_Assumption=The capture and analysis of Sales KPIs is not part of Info Mart out-of-box statistics and is developed during model creation.
}}{{SMART PremiseAssumptions
|Premise_Assumption=Routing to agents is based on skill expressions or group-based routing.
}}{{SMART PremiseAssumptions
|Premise_Assumption=The revenue definition chosen in this use case is illustrative and needs to be adapted for each project.
}}
|PremiseAssumptionsAdditional=See BO06
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is currently not supported in PureEngage Cloud, PureCloud, or PureConnect Premise or Cloud.
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=version 1.0.1
}}
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=This use case does not include specific agent desktop requirements.Specific data can be attached during the routing phase and may be visualized by the agent.
|RealTimeReporting=Predictive Routing real-time reports include:
====Queue KPIs By Predictive Model====
Monitor your Queue performance with the prediction scores provided by Genesys Predictive Matching to optimize your business KPI.

[[File:PRM_Queue_Group_by_Model_View_3.png]]
====Agent Group KPIs by Predictive Model====
Monitor the Agent Group Performance with the volume of answered interactions by range of predicted scores provided by Genesys Predictive Matching to optimize your business KPI.

[[File:PRM_Agent_Group_By_Model_View_1_3.png]]
|HistoricalReporting=The historical reports available within the Predictive Matching Data Store include:
* Predictive Matching Operational Report tracks Predictive Matching operational statistics.
* Predictive Matching A/B Testing Report tracks A/B testing results for Predictive Matching models and predictors.*
* Predictive Matching Agent Occupancy Report tracks Agent Occupancy while Predictive Matching is being used to optimize routing.
* Predictive Matching Daily Queue Statistics Report tracks KPIs for each Queue while Predictive Matching is being used to optimize routing.
* Predictive Matching Detail Report provides interaction level detail data about Predictive Matching use and its impact on KPIs.

*A/B reports can be developed from any standard or custom Info Mart data. If the outcomes data is NOT integrated with Info Mart, the creation of A/B reports must be evaluated as a separate effort.
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Machine learning-based matching of sales reps to prospects based on sales value directly increases revenue.
}}{{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Routing prospects to the sales reps best able to handle their sales request improves the customer experience.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Satisfaction
|UCBenefit=Increased sales success leads directly to improved satisfaction for sales reps.
}}
|UCIntro=This use case is based on {{#mintydocs_link:topic=BO06}}
|UCOverview=Business leaders want to improve their business Key Performance Indicators (KPI), leverage the innovation in Artificial Intelligence and drive business decisions with the abundance of data and context available in their business. Predictive Routing uses machine learning to support optimization of Sales KPIs.

A Sales KPI is a metric measuring the sales outcome of an interaction, in contrast to Service KPIs, which measure a Customer Experience or efficiency outcome. Sales KPIs can be a sales conversion rate, a sales revenue amount, a retention rate, a collection promise to pay. This use case focuses on improving revenue for inbound voice calls, but can also be extended to other sales-related KPIs, and other inbound, outbound, digital, or workload management channel types. The impacts of choosing another KPI or another channel type are documented in this use case wherever applicable.

Predictive Routing also applies to optimize Services KPIs. See {{#mintydocs_link:topic=BO06}}.

Traditional routing is designed to match customers to agents through skills-based or group-based logic rather than improving KPI. Unlike traditional routing, Predictive Routing uses machine learning to find signals in historical data to build a predictive model. This model improves KPIs by ranking agents before making the match with customers. This model also addresses the operational challenges that occur in understaffing and overstaffing scenarios while balancing the service level with improving KPI.

Predictive Routing has built-in A/B Testing to demonstrate the uplift of the KPI provided through blending Artificial Intelligence with humans in what Genesys terms Blended AI.
|UCSummary=Consider a retail bank that wants to upsell credit cards to its existing customers. Depending on the customer attributes (such as age or income), the bank wants to maximize both the conversion rate and the credit limit that the customer will accept, resulting in a higher overall revenue. This use case is based on a measure of sales revenue driven from a Sales reporting application (such as CRM).

In this use case, we assume that a customer interaction is associated to a credit card offer, either from the explicit customer intention (from IVR, web, or mobile) or from a business rule (such as next best action, which is out of scope of this use case).

The Contact Center Manager or Business owner wants to increase overall revenue generated per agent. The Predictive Routing solution can assist in achieving this objective.

Predictive Routing:
* Uses machine learning, a subset of Artificial Intelligence, to compare feedback of the actual outcome with the predicted outcome, helping to improve future agent-to-customer matches.
* Ranks agents predicted to maximize the expected revenue per interaction.
* Provides the finest grain match of customer contact with agent to help maximize revenue per agent.
* Provides an uplift on revenue using continuous learning to rank the expected revenue for agents servicing customers.
The direct result is that the average revenue per interaction increases. Predictive Routing usually also influences adjacent service KPIs like first contact sale, CSAT or NPS, handle time, and transfers. It is a common best practice to monitor all Sales KPIs and adjacent Service Levels to evaluate all impacts (out of scope of this use case).
|PainPoints=* Low revenue per agent or customer. Variability in business outcomes.
* Frustrated customers or repeat interactions – cannot get access to an agent providing the proper proficiency on the offer
* Resource inefficiency and high costs – agents have a low conversion rate and waste customer’s and contact center resources
* Reduced employee satisfaction – employees don’t achieve their goals.
|DesiredState=* Leverage Predictive analytics and machine learning to identify the optimal agent-customer match to improve Revenue before routing
* Employ continuous learning by feeding back actual outcomes to update predictive models
* Managers can gain insights to help identify root causes and employee training opportunities
* Managers can view reports identifying attributes that influence KPI
* A/B testing methodologies can be applied to evaluate lift
* Deep integration with Genesys routing and orchestration
}}

UseCases/Current/GenesysEngage-onpremises/EE04

2018-10-25T15:14:54Z

PLeprieult:

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Allow for more accurate and timely routing to the best agent through optimized scheduling with intelligent routing
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Enable accurate omnichannel forecasting and scheduling based on skills and schedules through the automated use of historical information and channel specific algorithms and schedule based routing
}}{{SMART Benefits
|UCBenefitID=Improved Employee Attrition Rate
|UCBenefit=Regard agent schedules including break times and shift end through schedule-based routing
}}{{SMART Benefits
|UCBenefitID=Reduce Overtime Costs
|UCBenefit=Improve schedule adherence and regard end of shift times through schedule based routing
}}
|UCIntro=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.
|UCOverview=Enrich any of the existing use cases handling inbound interactions with the ability to route calls based on WFM schedules. Doing so can help ensure a more-balanced multi-skill workload for agents and improvement in schedule adherence. Routing strategies can route based on the anticipated availability of an agent. For example, interactions are not routed to agents immediately before they are scheduled for a break or a meeting. This improves agent adherence and leads to better customer service and worker efficiency.
|UCSummary=Schedule-based routing is a powerful tool enabling contact centers to optimize employee satisfaction while reduce attrition and unnecessary overtime all while providing better coverage.
|PainPoints=* Employees receive interaction types that do not match their schedule
* Employees miss their breaks or shift ends
* Frequent unplanned overtime drives higher operating cost (increased overtime)
* Unplanned overtime increases employee stress, dissatisfaction and attrition
|DesiredState=* Route interactions to employees who are actually scheduled for the activity / interaction type
* Avoid sending interactions with long average handle times before a break starts or a shift ends
* Eliminate / reduce the number of skill changes needed to ensure appropriate coverage
* Offer a better (or the right) mix of activities to keep employees engaged (variety)
|SellableItems=No sellable items, Please reference prerequisits
|CloudAssumptionsAdditional_Sales=* Use case is not applicable for cloud
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:
* The full use case outlined here is available on premise.
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessImage=https://www.lucidchart.com/documents/edit/e0581c8c-ea3d-4054-828d-5657cacf47d3/0
|BusinessFlowDescription=# The customer contacts the company by one of the following channels:
## Voice
## E-mail
## SMS
## Social
##* *Alternatively, a new task may be created by a 3rd party source system for distribution by the Genesys system
# One of the use cases for the corresponding channel, processes the call and determines the skill profile required to handle the interaction.
# The skill profile is matched with the corresponding activity in WFM
# Genesys will identify the agents, which are currently scheduled to work on this activity. Cut off times will be taken into account, i.e. an agent shortly before his break will not receive an interaction which usually has a long average handling time.
# Genesys will check if one of these agents is available. If yes, it will distribute the interaction to this agent
# If no, Genesys will queue the call until one of these agents becomes available or a time out is reached
# If the time out is reached, the distribution logic will continue with skill-based routing and subsequent target expansions as defined in the underlying use case.
}}
|BusinessLogic='''BL1: Activity'''

It must be possible to match the possible routing targets of the underlying use case (skill expressions) to an activity in WFM. This activity will be used to identify the agent's schedules.

'''BL2: Scheduled agents and cut off time'''

Genesys scans schedules and activities stored in the WFM database periodically (every 15 minutes). This information will be used in Genesys routing decisions. Note that an agent could be working on multiple activities at any given time.

The routing cutoff time is the period that URS stops sending interactions to an agent for the activity when the schedule for a specific activity is about to end. This cutoff time should reflect the duration of a typical interaction and a threshold that an agent can allow an interaction to overlap into the time of the next scheduled activity. For example, if the typical interaction lasts 3 minutes and the threshold is 2 minutes, cutoff time might be the difference between them or 1 minute. URS would no longer send interactions specific to that activity to a particular agent when only 1 minute remains for the agent to spend doing that activity.
Cut off times will be configurable by activity.

'''BL3: Timeout to wait for a scheduled agent'''

This timeout will be configurable by activity.
|DistributionLogic=Full distribution requirements will be included in the underlying use case. The distribution requirement specific for this use case are described in the previous chapters.
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=No additional agent desktop requirements.
|RealTimeReporting=No additional real-time reporting requirements.
|HistoricalReporting=Reporting requirements in addition to the reporting functionality of the underlying use cases:
- Number of Interactions which were distributed according to schedule
- Number of Interactions overflowing back to skill based routing
|GeneralAssumptions=Workforce Management base service (WFM Use Case or Genesys WFM product) already deployed is a pre-requisite.
Depending on the channels which should be covered with this use case, Inbound or Digital Use Cases is required.
|RequiresOr=CE01, CE02, CE16, CE19, CE29, EE01, EE02
|PremiseAssumptionsAdditional=* This use case currently does not support chat as this is not included in the available WFM use cases.
* Use case is not compatible with the functional use case “predictive matching”
|CloudAssumptionsAdditional=This use case is not available in the cloud
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.0.2
}}
}}

UseCases/Current/GenesysEngage-onpremises/EE01

2018-10-25T15:12:26Z

PLeprieult:

{{SMART UseCase
|RequiresOr=CE01, CE02
|PremiseAssumptionsAdditional=* Interaction type is inbound voice only.
* Does not include any of these advanced options:
** Advanced Configuration - Digital Transactions:
*** Queues
*** Statistics
*** Importing Historical Data Volumes
*** Forecasting techniques
*** Reporting
** Advanced Configuration - Enterprise Workload Management Transactions:
*** Queues
*** Statistics
*** Forecasting techniques
*** Reporting
** Creation of more than six Security Roles
** Advanced Configuration - Schedule States development to enable shrinkage tracking
** Creation of more than six Adherence Rules
** Advanced Configuration - Exceptions development to enable shrinkage tracking
** Advanced Configuration - Agent Initiated Exceptions
** Advanced Configuration - Activity Groups
** Advanced Configuration - Email Notifications
** Advanced Configuration - Custom color schemes
** Advanced Configuration - Advanced Out-of-the-Box Reporting and Forecast Graphs
** Advanced Forecasting - Shrinkage Tracking (Planned / Unplanned Overheads)
** Advanced Scheduling - Activity Sets
** Advanced Scheduling - Task Sequences
** Advanced Scheduling - Agent Shift Trading
** Advanced Scheduling - Rotating Patterns
** Advanced Scheduling - Overtime Management
** Advanced Scheduling - Secondary Shifts
** Advanced Scheduling - Profile Scheduling
** Advanced Scheduling - Agent Shift Preferences
** Advanced Scheduling - Agent Schedule Bidding
** Advanced Scheduling - Scheduling Team Managers
** Advanced Scheduling - Shared Transportation Configuration
** Automated Time Off (stage 1) - Web Agent Application enabled for agents to request Time Off
** Automated Time Off (stage 2) - Time Off Rule Calculations with balance tracking
** Automated Time Off (stage 3) - as above + Time Off Bidding
** Automated Time Off (stage 4) - as above + Time Off Limits
** Advanced Customization - Additional tab custom content of Agent Web
** Advanced Customization - HR/Payroll Integration
** Advanced Customization - ETL Enablement
** Advanced Customization - API customization
* Any additional Exceptions, beyond the standard predefined list (provided in the FDD) will require additional effort.
* Any additional Schedule States beyond the predefined list will require additional effort and are out of the scope of this package.
* If additional agents and contracts are needed beyond the pre-defined scope, additional effort will be required.
* Historical Reporting: ICON, GIM & GI2 are not included in this package
|CloudAssumptionsAdditional=* Interaction type is inbound voice only.
* Does not include any of these advanced options:
** Advanced Configuration - Digital Transactions:
*** Queues
*** Statistics
*** Importing Historical Data Volumes
*** Forecasting techniques
*** Reporting
** Advanced Configuration - Enterprise Workload Management Transactions:
*** Queues
*** Statistics
*** Forecasting techniques
*** Reporting
** Creation of more than six Security Roles
** Advanced Configuration - Schedule States development to enable shrinkage tracking
** Creation of more than six Adherence Rules
** Advanced Configuration - Exceptions development to enable shrinkage tracking
** Advanced Configuration - Agent Initiated Exceptions
** Advanced Configuration - Activity Groups
** Advanced Configuration - Email Notifications
** Advanced Configuration - Custom color schemes
** Advanced Configuration - Advanced Out-of-the-Box Reporting and Forecast Graphs
** Advanced Forecasting - Shrinkage Tracking (Planned / Unplanned Overheads)
** Advanced Scheduling - Activity Sets
** Advanced Scheduling - Task Sequences
** Advanced Scheduling - Agent Shift Trading
** Advanced Scheduling - Rotating Patterns
** Advanced Scheduling - Overtime Management
** Advanced Scheduling - Secondary Shifts
** Advanced Scheduling - Profile Scheduling
** Advanced Scheduling - Agent Shift Preferences
** Advanced Scheduling - Agent Schedule Bidding
** Advanced Scheduling - Scheduling Team Managers
** Advanced Scheduling - Shared Transportation Configuration
** Automated Time Off (stage 1) - Web Agent Application enabled for agents to request Time Off
** Automated Time Off (stage 2) - Time Off Rule Calculations with balance tracking
** Automated Time Off (stage 3) - as above + Time Off Bidding
** Automated Time Off (stage 4) - as above + Time Off Limits
** Advanced Customization - Additional tab custom content of Agent Web
** Advanced Customization - HR/Payroll Integration
** Advanced Customization - ETL Enablement
** Advanced Customization - API customization
* Any additional Exceptions, beyond the standard predefined list (provided in the FDD) will require additional effort.
* Any additional Schedule States beyond the predefined list will require additional effort and are out of the scope of this package.
* If additional agents and contracts are needed beyond the pre-defined scope, additional effort will be required.
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=versions 1.1.2
}}
|SellableItems=Genesys Workforce Management
|CloudAssumptionsAdditional_Sales=Capabilities Assumption:
* The full use case outlined here is available in the cloud.
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:

The full use case outlined here is available on premise.
* Genesys Workforce Scheduling for Voice (EE01) and Genesys Omnichannel Workforce Scheduling (EE02) can be implemented at the same time.
|CustomerInterfaceRequirements=Genesys WFM Web Supervisor is a browser based UI that requires Java applet. Access control for specific roles (e.g., Planners, Supervisors, Forecasters, Schedulers) is handled via User Security configuration.
See [https://docs.genesys.com/Documentation/System/latest/SOE/Welcome Supported Operating Environment Guide] for specific browser support.
|AgentDeskRequirements=Agents access the WFM Web Agent UI with a supported browser. There is no Java in this UI. See [https://docs.genesys.com/Documentation/System/latest/SOE/Welcome Supported Operating Environment Guide] for specific browser support.
|RealTimeReporting=The following figure shows the reporting flow:

[[File:EE26rtr.png]]

Approved, authorized staff can generate, schedule, and distribute out-of-the-box reports in the following categories:
* Configuration
* Forecast
* Performance
* Schedule
* Adherence
* Audit
The Genesys WFM product contains a number of out-of-the-box real-time reporting elements. Details can be found in the [https://docs.genesys.com/Documentation/WM/latest/Admin/Welcome Workforce Management Administrator Guide].
|HistoricalReporting=The Genesys WFM product contains a number of out of the box real-time and historical reporting elements. Details can be found in the [https://docs.genesys.com/Documentation/WM/latest/Admin/Welcome Workforce Management Administrator Guide]

.
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow====Business Flow - Forecasting===
The business flow described below requires the base configuration of the WFM to be completed and historical data to be available. The base configuration will be done by Genesys Professional Services within the scope of this use case as described below.
|BusinessImage=https://www.lucidchart.com/documents/edit/78d82970-ee65-4661-a000-0cd48602c9d4/0
|BusinessFlowDescription=The forecaster imports historical data into the configured system.
The forecaster works through the forecast process:
# Creates a scenario or continues working on a previously saved scenario.
# Uses the Forecasting wizard to build a volume forecast:
#:* selects the appropriate forecasting methodology
#:* selects which activities to forecast
#:* forecast is generated
#:* makes manual changes
# The forecaster uses the Staffing Build Wizard to determine the FTE requirements:
#:* defines indirectly occupied
#:* defines service level targets
#:* defines shrinkage levels
#:* publishes the master forecast
# Supervisors and Agents submit requests for changes into the system:
#:* Exceptions
#:* Meetings
#:* Time off requests
# The forecaster modifies the forecast as required.
# When the forecast is ready to be published, the forecaster publishes it to become Master
# The Scheduler is notified that the Master forecast is published
}}{{SMART BusinessImageFlow
|BusinessFlow====Business Flow - Scheduling===
|BusinessImage=https://www.lucidchart.com/documents/edit/320d7e0e-3faa-4d60-8ee8-a810b4f5c9a0/0
|BusinessFlowDescription====Flow Description===

# The scheduler validates & sense checks the live forecast
# The scheduler uses the ‘Schedule Build Wizard’ to generate schedules:
#:* selects sites and build parameters for each site
# Manual modifications are made as needed
# The scheduler publishes the master schedule
# Agents are notified of the detail of their working hours
# The schedules are modified as required
# Once the schedule is ready for hand-off to Intraday Management, the Scheduler will publish the Master Schedule and Intraday Management will be informed.
}}{{SMART BusinessImageFlow
|BusinessFlow====Business Flow - Intraday===
|BusinessImage=https://www.lucidchart.com/documents/edit/fb8d2b97-f2fc-4671-9b46-2e2aa40f63a5/0
|BusinessFlowDescription=Intraday
# The forecasters, schedulers, planners or supervisors manage adds, moves and changes to existing schedules based on their individual access rights, for example:
#:* Time off / sickness requests
#:* Changing breaks & meals in response to changing demand
# Agents are notified of changes as appropriate
# Master schedule is kept current
# Scheduler and Forecaster evaluate accuracy of forecast to actual and adjust accordingly.
# Supervisors can monitor the adherence of the agents in their team to the published schedule.
}}
|BusinessLogic=A prerequisite to any basic WFM deployment is a formal Discovery process with resulting commensurate documentation.

This diagram shows the basic components that need to be considered when configuring WFM.

[[File:Employee Engagement - WFM - Configuration.png|Employee Engagement - WFM - Configuration]]


|DistributionLogic=N/A
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Allow for more accurate and timely routing to the best agent through optimized scheduling with intelligent routing
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Optimize planning and resource utilization through accurate omnichannel forecasting & scheduling and skills
}}{{SMART Benefits
|UCBenefitID=Reduced Administration Costs
|UCBenefit=Reduce manual workforce scheduling activities by decreasing the time and costs associated with manual WFM efforts through the automatic updates of data, schedule shifts and database for skills and schedules. Reduce overtime expenditures by improving accuracy and precision of staff forecasting through Genesys WFM planning
}}{{SMART Benefits
|UCBenefitID=Improved Employee Attrition Rate
|UCBenefit=Empower agents with more control over their schedules by identifying skill gaps and extending mobility and easy-to-use web-based tools
}}
|UCOverview=This use case describes how Genesys Workforce Management helps you deliver a set of optimized schedules, utilizing agent skills and contract rules whilst providing editing and monitoring capabilities in the contact center.

A critical aspect to routing the call to the right agent is having an agent with the needed skills available to meet demand. Our solution optimizes staffing levels throughout the day and week to meet demand. As caller needs are identified and available skill segment agents are known, then optimal matching of the two can occur. Getting the caller to the most appropriate resource on the first pass results in fewer transfers, shorter contacts, and improved customer satisfaction.

The solution offers visibility into current information on agent performance metrics, schedule adherence and forecast variances. With this information, our solution allows for better management of variances between target and actual availability. Our solution also allows for specific adherence tools such as thresholds for maximum acceptable handle times.

The solution enables the precise scheduling of contact center agents based on integrated forecasting of expected activity. That means organizations are more likely to have an appropriate level of staffing for all portions of the workday. The result is reduced staffing costs, reduced telephony expenditures, and improved customer satisfaction.
|UCSummary=Deliver a set of optimized schedules, utilizing agent skills and contract rules whilst providing editing and monitoring capabilities in the contact center.
|PainPoints=* Inability to consistently meet SLA
* Low customer satisfaction due to excessive wait times and low first call resolution
* Low employee engagement due to high work pressure, receiving interaction types they cannot handle and ever changing schedules
* High workforce cost due to overstaffing
* Poor CX due to understaffing
* Insufficient data for accurate forecasting
* Real performance/SLA not in line with forecast/schedule prediction

|DesiredState=* Create an accurate forecast and effective schedule across all activities/queues
* Gain better insight into effectiveness of several forecasting/scheduling scenarios
* Report on who is ’out of schedule adherence’ in real time and historically.
* Automatically gather data for accurate forecasting from contact center platform
* Real time insight into intraday SLA & schedule adherence

}}

UseCases/Current/GenesysEngage-onpremises/CE27

2018-10-25T15:10:49Z

PLeprieult:

{{SMART UseCase
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following flow describes the use case from the perspective of the customer and the contact center agent.
|BusinessImage=https://www.lucidchart.com/documents/edit/0b9ea69e-4e73-463d-9cd6-1d5214eab1b0/0
|BusinessFlowDescription=# The customer and agent are connected via a chat session or a voice call.
# The agent may propose to the customer to start a co-browse session to support him/her on the website. For security reasons, only the customer can initiate the co-browse session.
#* '''Call only:''' A session ID is displayed to the customer if he/she clicks the co-browse link in the Assistance/Channel Selector Widget. This session ID is needed to join the agent desktop with the correct browser session. The customer gives this session ID to the agent over the phone. The agent enters the session ID into the agent desktop to start the co-browse session.
#* '''Chat only:''' The customer clicks the three-dots icon on the chat widget and selects "Start Co-browse".
# When the session is established, the agent's desktop displays a view of the website in the browser window the customer is using. Agents start co-browse sessions in Pointer Mode. In Pointer Mode, the customer and the agent can see each other's mouse pointer but the agent cannot enter any information into the web page, click buttons, or navigate the customer's browser.
# If the agent needs to enter information into the web page or to navigate the browser, he/she can send the customer a request to switch the co-browse session to Write Mode.
# Once the customer accepts this request, the agent can navigate, fill forms, and click hyperlinks on the web page. Sensitive Data can be masked before presenting to the agent, and agent controls (the ability to fill certain fields or submit forms) can be blocked through instrumentation. The customer can revoke the Write Mode at any time, returning the agent to Pointer Mode.
# The co-browse session ends when any of the following events occurs:
#* The customer chooses to end the co-browse session
#* The agent chooses to end the co-browse session
#* The primary chat or voice interaction is transferred or ended by either the customer or the agent
#* Due to inactivity after a preconfigured time-out expires
The primary voice or chat interaction can continue even when co-browse has ended.
}}
|BusinessLogic='''Starting a co-browse session without primary interaction:''' Co-browse sessions take place on top of a primary interaction (in this case, chat or voice). If the customer initiates a co-browse without any primary media, the instrumentation prompts the customer to initiate a conversation via voice or chat before initiating the co-browse.
|DistributionLogic=N/A
|SellableItems=See sellable items for CE01 CE02 CE18 CE21 CE22 CE24 or CE25
|CloudAssumptions=This use case is currently not available in PureEngage Cloud
|CloudAssumptionsAdditional_Sales=Capabilities Assumption:
* This use case is currently not confirmed for use in PureEngage Cloud.
|PremiseAssumptionsAdditional_Sales=* This use case is available for Premise
|CustomerAssumptions=* The Genesys customer is responsible for integration of the solution into the company website.
* The Genesys customer is responsible for tagging information and fields on their website that need to be hidden from the agent during a co-browse session, or agent controls that need to be blocked (such as a Submit form).

[[file:DigVoCWebExp2.png]]
|RequiresOr=CE01, CE02, CE18, CE21, CE22, CE24, CE25
|PremiseAssumptionsAdditional=* Workspace Desktop Edition is the agent desktop.
* Pulse is used for real-time reporting.
* Use of Genesys Widgets with limited modification to the company's corporate identity as described above, under “Widget Functionality”. Alternatively, use of custom chat widget which is not part of Genesys deliverable.
* No integration with third-party systems.
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is currently not available in PureEngage Cloud
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.1.1
}}
|PainPoints=* Increasing competitive pressure
* High customer churn
* High purchase abandonment
* Unable to use context
* Poor customer experience scores
* Calls with long handle times
* No assisted service online
* Unable to provide a personalized assisted service experience
* Increasing calls related to online service and support
* Online help not providing the information customers need
|DesiredState=* Enable co-browse and provide specialist assistance
* Proactively offer assistance through co-browse sessions
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Mitigate customer frustration by providing a better method to serve and assist customers thereby reducing customer effort
}}{{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Reduce shopping cart abandonment and increase online conversion rates
}}{{SMART Benefits
|UCBenefitID=Improved First Contact Resolution
|UCBenefit=Optimize the customer service experience by initiating a co-browse session with the customer to resolve their request the first time
}}{{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Improve understanding of request or issue and reduce the duration of the customer interaction by using co-browse
}}
|UCOverview=A customer and a contact center agent are having a conversation over the phone or through a web chat session. During the conversation, the ability to see and control the customer's browser through co-browsing functionality enables the agent to convey information more effectively and get the customer's issue resolved more quickly.
|UCSummary=During a call or a chat session between a customer and an agent, the customer can initiate a co-browse session with the agent, so both the agent and the customer share the same instance of the browser. This enables the agent to provide direct support to a customer trying to complete a request on the company's website.
|CustomerInterfaceRequirements=The user interface is based on Genesys Widgets.

Sample screenshots:

*Co-browsing can be started or ended from the chat widget:

[[File:DigVoCWebExp3.png]]

*Co-browsing can be started when on a voice call:

[[File:CE27live.png]]

'''Widget Functionality'''

Widgets can provide basic adaptation to customer corporate identity, including:
*Add customer logo
*Use corporate identity, colors, and fonts
|AgentDeskRequirements=The agent interface related to co-browse must:
*Enter the session ID when co-browse needs to be started from a voice call
*Automatically start a co-browse session if the session has been initiated by the customer through their chat widget
*Display the customer page view when co-browse is engaged
Transfer, Conference, and Supervision of co-browse sessions are not supported.
|RealTimeReporting=Minimum requirements:

* Implementation of standard templates in Pulse: eServices Queue KPI, eServices Agent Activity

Current Co-browse Agents

* Chat Agents: Number of agents working on chat
* Chat with Co-browse: Number of agents working on chat with co-browse
* Inbound Voice: Number of agents working on inbound voice
* Inbound Voice with Co-browse: Number of agents working on inbound voice with co-browse

Current Chat Interactions with Co-browse

*Chat: Number of chat interactions currently handled by agents
*Co-browse in Chat: Number of chat with co-browse interactions currently handled by agents
*(Co-browse in Chat)/Chat, %: Ratio of current number of chat with co-browse interactions to the total number of chat interactions
*Web Chat: Number of web chat interactions currently handled by agents
Co-browse in Web Chat: Number of web chat with co-browse interactions currently handled by agents
*(Co-browse in Web Chat)/Web Chat, %: Ratio of current number of web chat with co-browse interactions to the total number of web chat interactions

Current Voice Interactions with Co-browse

*Inbound Voice: Number of inbound voice interactions currently handled by agents
*Co-browse in Inbound Voice: Number of inbound voice with co-browse interactions currently handled by agents
*(Co-browse on Inbound Voice)/Inbound Voice, %: Ratio of current inbound voice with co-browse interactions to the total number of inbound voice interactions

Co-browse Session Details

*Current Agent State: Auxiliary statistic needed for user data retrieval
*Co-browse Session State: Alive or finished
*Co-browse Session Start Time: Session start time
*Co-browse Session ID: Session ID
*Co-browse Session Quantity: Session quantity
|HistoricalReporting=Historical Reporting is currently under development and projected for delivery in 3Q2018. Timeline is subject to adjustment.
}}

UseCases/Current/GenesysEngage-onpremises/CE11

2018-10-25T15:09:43Z

PLeprieult:

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Automated and agent-assisted dialling enables efficient targeting of large numbers of prospects to increase revenue.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Automating dialling eliminates time spent on dialling and on unanswered calls to improve employee utilization and Enabling blending of inbound and outbound calls also improves employee utilization.
}}{{SMART Benefits
|UCBenefitID=Improved Right Party Contacts
|UCBenefit=Automated handling of voicemail and unanswered calls improves right party contacts.
}}
|UCOverview=A company needs to make outbound calls to initiate contact with its customers based on specific business rules for sales, marketing, care, or collections. This use case describes the ability to configure and execute outbound dialing campaigns – both automated and agent-assisted – based on customer-provided contact list(s).
|UCSummary=The Genesys system supports both agent-assisted and automated outbound calling campaigns using dialer and outbound IVR channels. Companies can blend contact strategies and escalate outreach attempts from automated to agent-assisted calls. Dialer calls can be made in predictive, progressive, preview or manual mode. The company can use its marketing, CRM, or collections system to generate contact lists based on a one-time event, recurring events, or trigger-based events. The lists will include the appropriate contact details, e.g. contact name, contact phone number, and contact reason. Delivery results will be recorded in the system to feed into reports.
|PainPoints=* Calls by agents are effective but they are expensive and can lose effectiveness over time
* Low agent utilization due to subpar predictive dialing or an overreliance on manual dialing
* Unable to efficiently pace outbound volume resulting in agent idle-time or call abandonment
|DesiredState=* Optimally pace contact attempts while taking the expected impact on inbound/outbound interactions and agent availability into consideration
* Self-service campaign management enables business users to create rules and maintain compliance
* Contact opted in consumers in accordance to their channel preferences (assumes company provides preferences as part of their contact lists)
* Let customer escalate from self-service to an agent interaction if needed
|SellableItems=Cim, CIM (HA), Workspace, Genesys Infomart, Genesys Infomart - HA (optional), Genesys Interactive Insights, SIP Interaction, SIP Interaction - HA (Optional), SIP Business Continuity, Outbound, Outbound Voice w/ Genesys CPD/ASM, Proactive Contact, Proactive Contact w/ Genesys CPD/ASM, SIP Interaction for Outbound, GVP, GVP HA (optional), ASR, TTS, Intelligent Automation Omnichannel Self-Service, Genesys Intelligent Automation Omnichannel Self-Service - HA (Optional), Genesys Outbound Voice, Genesys SIP for Outbound
|CloudAssumptionsAdditional_Sales=Capabilities Assumption:
* Use case applicable to PureEngage Cloud and Standalone Cloud
* English-only user interface
|PremiseAssumptionsAdditional_Sales=* This use case is available in Premise
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following diagram shows the main flow of the use case:
|BusinessImage=https://www.lucidchart.com/documents/edit/b65f1337-27f6-44ee-bd81-32eb7c1fd23e/0
|BusinessFlowDescription=# An Admin (or Genesys PS) configures the campaign strategy and settings in the Genesys System.
# The organization either prepares a contact list from a third-party system (such as CRM or Collections) or configures their system to utilize Genesys Rest API to insert contact record based on event, using list or API format defined by Genesys. The contacts are loaded within Genesys by the system administrator:
#* For Cloud, batch uploads can be manual, via S/FTP or API (into Engage UI)
#* For Premise, batch uploads are manual only
# The campaign begins contacting consumers based on the campaign strategy set in step 1. The Genesys system checks each contact/record against the relevant Do Not Call and suppression lists to filter out consumers who should not be contacted.
}}{{SMART BusinessImageFlow
|BusinessFlow=The following diagram shows the Outbound IVR subflow:
|BusinessImage=https://www.lucidchart.com/documents/edit/3ccc4497-f005-4aa3-a2e5-2cb9af7b83f6/0
|BusinessFlowDescription=For Outbound IVR, there are multiple resulting scenarios:
* Bad Number or No Answer - the call disconnects and the result is written back to the system.
* Answering Machine - the call will either disconnect or play a message (based on the chosen configuration in step 1) and the result is written back to the system.
* Live Party connect - the call will play the Outbound IVR message.
** The consumer has the option to opt out of future calls. This is typically done by including “Press 9 to opt out of future calls”.
** (optional) The Customer Admin may choose to offer the option to connect to a live agent (based on the chosen configuration). This is typically done by including “Press 2 to connect to a live agent”. This can be achieved by routing to a phone number provided by the company.
** The result is written back to the system.
}}{{SMART BusinessImageFlow
|BusinessFlow=The following diagram shows the Dialer sub-flow:
|BusinessImage=https://www.lucidchart.com/documents/edit/80721a68-5192-4139-99f2-b82a1eefffd2/0
|BusinessFlowDescription=* For Dialer, the dialing mode will be configured as Preview, Progressive, or Predictive.
** In Preview mode, the agent receives or retrieves a record and will initiate the call.
** In Progressive mode, the system will automatically place the call based on an agent being available for the specific campaign.
** In Predictive mode, the system will automatically place the call based on the pacing algorithm and expected agent availability
* For each call attempt, there are multiple resulting scenarios:
** Bad Number or No Answer:
*** In Preview mode, the agent will hang up and the result is written back to the system.
*** In Progressive and Predictive modes, the call disconnects and the result is written back to the system.
** Answering Machine:
*** In Preview mode, the agent will have the option to leave a message. Based on the disposition code, the call may be re-tried later. The result is written back to the system.
*** In Progressive and Predictive modes, the call will either disconnect or play a message (based on the chosen configuration in step 1) and the result is written back to the system.
** Live Party connect - the agent will be connected to the consumer.
*** The consumer has the option to opt out. In cloud, the agent will record this in the agent desktop and it will be written to a suppression list or DNC list in the premise.
*** The consumer has the option to ask for a callback. The agent will record this in the agent desktop and the callback will be scheduled.
* At the end of the call, the agent will record a disposition code and the result is written back to the system.
}}{{SMART BusinessImageFlow
|BusinessFlow=The following diagram shows the subflow when preview mode is used:
|BusinessImage=https://www.lucidchart.com/documents/edit/39272dac-ea9d-4386-8536-617f75c13adc/0
|BusinessFlowDescription=Based on the result of the call, additional contact attempts may be undertaken, either:
* in the same channel, or
* in another channel (Cloud only)
This is configured in the campaign settings in step 1.
}}
|BusinessLogic=====Parameters and Business Rules====
===BL1:===
====Contact Records – Batch Uploaded or Added On-Demand====
Contact records are either batch uploaded or added on-demand via API. This would be configured by the Customer Admin or Genesys PS based on the goals of the customer and the source of the contact. This would be completed before the list is uploaded or contacts are added on-demand. There is no limit on number of contacts.
====Channel Type – Dialer or Automated Outbound IVR====
Customer can choose which channels to use in their campaigns – Dialer (agent-assisted) or Outbound IVR (automated). This would be configured by the Customer Admin or Genesys PS prior to the list being uploaded. The Customer identifies the message content (or message template) for automated outbound calls.
====Campaign Settings====
Customer Admin or Genesys PS can configure various campaign settings: start/stop timing, frequency of contact per consumer, contact pass strategy by channel (Cloud only), mobile vs. landline filtering treatments (Cloud only), answering machine detection tuning, opt out options, connect to agent options, and assigned agent group.
====Dialer Mode - Predictive, Progressive, Preview====
Customer can choose to run dialer campaigns using Preview, Progressive, and/or Predictive modes. This would be configured by the Customer Admin or Genesys PS.
====Answering Machine Detection====
Genesys PS can tune aspects of the configuration such as listening for speech or tones, as well as length of silence between phrases. Customer can choose whether to disconnect or to play a message when an answering machine is detected.
===BL2===
====Personalization====
For Outbound IVR, the content of the message/script may contain personalized information from a third-party or customer database which will be provided by the customer along with the list. The audio file will be provided by the customer.
|DistributionLogic====DR1===
====Outbound IVR - Connect to Agent Option====

* Option 1 (Premise only) - Connect to Genesys Inbound. This requires the implementation of one of the following use cases:
** {{#mintydocs_link:topic=CE01}}
** {{#mintydocs_link:topic=CE02}} for the ability to transfer to an agent
* Option 2 - Connect to Customer's non-Genesys contact center. This will be routed to a phone number provided by the Customer.
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=* The agent must be able to add contacts to the suppression list via his desktop (Suppression List applies to PureEngage Cloud only).
* The agent must be able to enter a disposition code for each call (such as Cross Sell, Need Follow Up, Not Right Skill, Processed, Terminated, Transferred, Up Sell). Disposition codes are configured by the Customer Admin or Genesys PS (included within the corresponding use cases).
|RealTimeReporting====Premise===
Pulse, a Genesys Administrator Extension (GAX) plug-in application, offers personalized dashboards based on specific functional, geographical, or organizational needs. Includes predefined templates so you can:
* Monitor key campaign performance objectives and goals though the Campaign Activity template.
* Track campaign callback status through the Campaign Callback Status template.
* Monitor the current state of a campaign using the Campaign Group Status and Campaign Group Activity templates.
* Monitor agent efficiency using the Agent KPI template.

The sample Outbound Campaign dashboard below demonstrates usage of the Campaign Activity, Campaign Callback Status, and the Agent KPI templates. The implementation of dashboards will be customized based on the deployment.

[[File:CE11 - Pulse.png|none|Example Pulse View]]
===Cloud===
Uses Engage standard UI view for viewing real-time campaign metrics:
* List Size - The number of ‘unique’ contacts in the active list.
* Filtered - The number of contacts filtered from the list based on suppression lists, compliance rules, or strategy filter criteria definitions.
* Delivered - The number of successfully delivered calls. NOTE: This includes both LIVE person and MACHINE results.
* Retrying or Failed - The number of contacts being retried or with a current failure status.
* Not Attempted - Records remaining in the list – ‘unique’ contacts that are yet to be attempted.
* Done - Total number of dial attempts made.
* Remain – Total number of dial attempts remaining.

Due to its continuous evolution, the features available in Cloud rapidly change. Please reach out to your local Cloud Team for the latest information.
|HistoricalReporting====Premise===
Interactive Insights out-of-the-box reports:
* Assess the day-to-day operations of the contact center resources for the routing and handling of interactions.
* Dimension the out-of-the-box aggregate based GI2 reports with Routing Parameters including Attempt Disposition codes.
* User Defined Calling List fields can be mapped into the Contact Attempt subject area.
* Evaluate resource performance with a variety of reports for Outbound Campaigns, Agents and Detail facts.

There are 40+ reports available, potential reports to confirm the benefits for this use case are being met are as follows.

'''Agent Activity''' enables the organization to measure and filter Info Mart data based on the interaction-related activities that are conducted by active agents.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Agent Activity
!{{!}}Description
{{!}}-
{{!}}{{!}}Activity
{{!}}{{!}}Examples for available KPIs:
* Accepted
* Conference Initiated
* Consult Initiated
* %Transfer Initiated
* Engage Time
* Handle Time
* Hold
* Invite
* Offered
* Rejected
* Wrap
* ...
{{!}}{{!}}Agent interaction level data.
Counts and duration measures are attributed to the reporting interval in which interactions are offered to the agent.

{{!}}-
{{!}}{{!}}InteractionState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Engage Time
* % Hold Time
* % Invite Time
* % Wrap In Time
* Accepted
* Consult Received Accepted
* Engage Time
* Not Accepted
* Not Ready In Time
* Offered
* ....
{{!}}{{!}}Agent interaction level data.
Measures are attributed to each reporting interval in which agents handle the interactions and durations are clipped at interval boundaries.

{{!}}-
{{!}}{{!}}SummarizedState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Busy Time
* % Not Ready Reason Time
* % Occupancy
* % Ready Time
* % Wrap Time
* Active Time
* Not Ready
* Not Ready Reason Time
* Wrap
* ...
{{!}}{{!}}Agent summarized data for a session.
Measures are attributed to each reporting interval in which agents handle the calls, and durations are clipped at interval boundaries.

{{!}}}
'''Outbound Contact '''enables the organization, measure, and filtering of data related to Genesys Outbound Contact Server transactions.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Outbound Contact
!{{!}}Description
{{!}}-
{{!}}{{!}}Agent Contact
{{!}}{{!}}Available KPIs:
* Campaign
* Agent Group
* Agent Name
* Customer Segment
* Service Type
* Service Subtype
* Business Result
* Accepted
* Engage Time
* Hold Time
* Wrap Time
* Handle Time
* Preview
* Preview Time
* ….
{{!}}{{!}}Agent Contact Attempt aggregate level data.
Counts and duration measures based on the campaigns with which interactions are attributed to Agents handling Outbound Contact interactions.
{{!}}-
{{!}}{{!}}Contact Attempt
{{!}}{{!}}Available KPIs:
* Campaign
* Agent Group
* Agent Name
* Customer Segment
* Service Type
* Service Subtype
* Business Result
* Attempts
* Accepted
* Abandoned Waiting
* All SIT
* Answering Machine Detected
* Busy
* Canceled
* CPD Dial
* CPD Dial Time
* Dial Made
* Dropped
* Personal Callback Scheduled
* Personal Callback Missed
* Personal Callback Completed
* Fax Modem Detected
* SIT Detected
* ….
{{!}}{{!}}Contact Attempt aggregate level data.
Counts and duration measures based on the campaigns with which interactions are attributed to Outbound Contact interactions.
{{!}}}

===Cloud===
Uses Engage standard UI view for viewing and exporting historical campaign metrics. There is a wide variety of built-in reports including:
====Account Reports====

* Account Summary Reports
** Activity
** Activity with Est. Cost Acct/Camp
** Activity with Est. Cost Acct/Camp (xls)
** Dialer Compliance Summary
** Service Summary
* Account Detail Reports
** Usage Detail
** All Attempts
** All Contacts
** Client Recording
** Client Recording Manifest
** Script Recording
** Script Recording Manifest
** Service Detail
** Service Summary (new)
** Contact Center Detail
** Account Activity
** Agent Performance
** Agent Action
** Agent List
** Agent Monitor/Coach/Barge
** Dialer Compliance Detail
** List Audit
** Recording Action Tracking
** Scheduled Followup
** Session Transfer

====Campaign Reports====

* Campaign Summary Reports
** Multi-Channel Summary
** Summary
** Activity
** Activity with Est. Cost (xls)
** Contact Center Direct Connect
** Dialer Compliance Summary
** Inbound Response by Hour
** Outbound Response by Hour
** Service Summary
** Multi-Channel Summary (legacy)
* Campaign Detail Reports
** Best Contact
** All Attempts
** All Contacts
** Client Recording
** Client Recording Manifest
** Script Recording
** Script Recording Manifest
** Service Detail
** Service Summary (new)
** Dialer
** Contact Center
** Contact Center DC Summary Report
** Dialer Compliance Detail
** Scheduled Followup
** Session Transfer

====Sub-Campaign Reports====

* Sub-Campaign Summary Reports
** Summary
* Sub-Campaign Detail Reports
** Best Contact
** All Attempts
** All Contacts
** Client Recording
** Client Recording Manifest
** Script Recording
** Script Recording Manifest
** Dialer
** Contact Center
** Dialer Compliance Summary
** Dialer Compliance Detail
** Session Transfer
|CustomerAssumptions=* Customer will be providing Genesys with the contact list from their own CRM, marketing, or collections database - either flat file or on-demand trickle-feed.
* Customer will manage the information of the DNC. Genesys does not provide a UI to manage DNC. Customer to provide a web-UI or interface to manage.
* Customer is responsible for recording and providing any required announcements and recordings.
* We assume that compliance is handled by the customer, i.e. the customer has acquired proper express consent opt-in from consumers to make Sales & Marketing calls and send automated messages, maintains an auditable list, and honors opt out requests. The contact lists which are loaded into Genesys only contain customers to whom calls can be made according to the corresponding local compliance rules.
* The outbound solution can be configured based on the customer's understanding and direction of compliance with local outbound calling regulations at the site of the installation. Customer is responsible for compliance with laws and regulations with respect to outbound calling and automatic dialing. It is recommended that the customer's legal department confirm the organization is in full compliance with these regulations.
* Suppression lists should include customers who have opted out of previous campaigns as well as a country-specific Do-Not-Contact list (if applicable). When a consumer opts out of a campaign, they should be added to a suppression list. Customers can also upload another suppression list or add an individual to an existing suppression list. These suppression lists can then be applied to future campaigns at the campaign level or at the overall account level. They can be optional or mandatory for each future campaign, as configured by the Admin.
|Optional=CE01, CE02
|PremiseAssumptionsAdditional=* Campaigns are assumed to be single channel / mode only - no switching / escalating between channels. Campaign modes applicable to the use case are:
** ProgressiveGVP/PowerGVP (Outbound IVR)
** Progressive/Predictive (Dialer)
** Push Preview (Dialer)
* No chained records are supported.
* CPA (if required) is assumed to be provided by the MCP or media gateway. Resource Manager is required with the media server in order for the CPA functionality to be operable
* Customer acknowledges that integration to a media gateway, SBC, and/or carrier SIP trunk service that is not currently certified as compatible by Genesys would require a formal field validation suite to be performed
* Progressive/predictive campaigns are assumed to be using “Transfer Mode” and transfers to agents are developed to stay within the same site, under the same SIP Server, i.e., no transfers outside of the installed system.
* Customer is responsible for the preparation and loading of calling lists into the outbound solution via Genesys Administrator. The design, development, and usage of any custom method for uploading calling lists into the outbound solution (for example via API) is the responsibility of the customer
* Opt Out/In is assumed to be handled in the following way for the use case:
*# The client will be responsible for loading customer data into a Do Not Call (DNC) list. This list is centralized across all campaigns.
*# For Outbound IVR calls, where the customer answers, there will be an option to opt out of further calls. In some cases, this is required and applicable to local regulatory requirements, and will be included as an option. The opt out will add the customer to the regular DNC list. This opt-out announcement will be a recorded audio file.
*# For Dialer calls, where the customer answers and there is no agent available, there will be an option to opt out of further calls. In some cases, this is required and applicable to local regulatory requirements, and will be included as an option. The opt out will add the customer to the regular DNC list.
*# While handling an outbound interaction, agents will have the option to add a customer to the DNC list through the Workspace Desktop.
* Workspace Desktop Edition is assumed to be the agent desktop.
* Pulse is used for real-time reporting.
* Any real-time or historical reports beyond the standard reports listed in the document would be considered as additional work.
* For this use case, the linking of subsequent inbound interactions to previous outbound interactions is not in scope.
* Call backs may be scheduled by the agent through Workspace Desktop Edition provided they are currently handling an outbound interaction. It is not possible for an agent to schedule a call back while handling an inbound interaction.
* Answer machine “beep detection” is only supported with Outbound IVR campaigns. For Predictive/Progressive, when an answer machine is detected, it is transferred to a strategy and a message is played. By using a delay in this strategy before playing the message, the message can be played after any beep, but this is not an exact science and may result in some messages being clipped.
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=For Standalone Cloud, Agent Voice Portal is assumed to be the agent desktop.
}}{{SMART CloudAssumptions
|Cloud_Assumption=Engage interface, message content, and TTS are available in English only.
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.1.2
}}
}}

UseCases/Current/GenesysEngage-onpremises/CE09

2018-10-25T13:59:28Z

PLeprieult:

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Reduced Volume of Interactions
|UCBenefit=Personalizing IVR experience increases self-service rates and reduces agent call volumes.
}}{{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Personalized menus and prompts simplify the IVR, make it more effective for customers and make them feel more valued.
}}{{SMART Benefits
|UCBenefitID=Improved First Contact Resolution
|UCBenefit=Offering the most appropriate options to each customer increases first contact resolution.
}}
|UCOverview=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:
* Simplifies the menu structure (both depth and within a single menu)
* Presents meaningful options to the caller
* Increases containment and use of the IVR through ease of use and relevance of options
* Increases customer satisfaction through simpler, more relevant navigation and completion of tasks
|UCSummary=This functional use case offers several types of personalization:
* Proactively play 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. For example, play a mortgage option in the menu only if they have a mortgage, or present a promotion option only if they are eligible.
* Persona-based Personalization is the ability to change the wording of input and messages 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.
|PainPoints=* Low self-service adoption
* Unable to identify customers to provide a personalized experience
* Long handle times from increased call volume
* Low customer satisfaction due to generic IVR Experience
* Increased agent frustration and low morale due to handling of low value and monotonous queries
* Lower KPIs due to lack of segmentation
|DesiredState=* Identify caller using context or IDV data
* Personalized treatment based on context and business rules – for example:
* Proactively play status or balance update
* Proactively offer most likely call reason
* Personalized menu options
* See context for transfer to an agent
* If no personalized treatments, then continue with IVR application
|SellableItems=No sellable items, Please reference prerequisits
|CloudAssumptionsAdditional_Sales=* <span style="display: inline !important; float: none; background-color: transparent; color: rgb(0, 0, 0); font-family: Calibri,Calibri_MSFontService,Sans-Serif; font-size: 15.8px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: 0px; line-height: 0px; -ms-touch-select: none; -ms-user-select: text; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">This use case is currently not available in Cloud.
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:
* Requires GVP and Genesys Intelligent Automation
* Client has web services accessible
* Client provides access to application to validate customer identity
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The diagram outlines the personalized call flow:
|BusinessImage=https://www.lucidchart.com/documents/edit/f7a64b32-772c-4a14-9df7-db67d30085e6/0
|BusinessFlowDescription=# A customer calls a service line of the company.
# Customer progresses through routing strategy. The routing strategy is not in scope of this use case.
# An IVR application answers the call. The full IVR application is not within the scope of this use case, but the functionality in this use case can be used as a module to enhance the IVR application with personalization options.
# If the customer needs to be identified and authenticated (verified), the ID&V interaction uses one or multiple identifiers (such as Customer ID, Account Number, or similar). Customer identification may also be verified by a PIN, if required. This functionality is offered by another use case provided by Genesys, which is leveraged in this scenario {{#mintydocs_link:topic=CE07}}. The Identification and verfication functionality itself is not within the scope of this use case.
# Using the customer identifier (for example, ANI), Genesys can retrieve customer context information from a third-party system or from Genesys context services (optional).
# The personalized treatment is decided based on submitting context to business rules natively, using third-party systems or using internal data. Personalized treatments include:
#* Playing a personalized message to the customer. The caller may hang up at this point if they have all the information they require. For example: The caller is identified to be in a region with a power outage. An announcement can be played to inform the caller of the status.
#* Proactively playing status or balance before presenting any options. For example: "Your next order is due to be delivered on Thursday."
#* Proactively offering the most likely call reason. For example: "Are you calling about the loan application you have in progress?"
#* Personalizing menu options (dynamic menu). For example: "Only play mortgage option in the menu only if they have a mortgage or present an option if they are eligible."
# Sending the customer to:
#* An agent 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 main menu of the IVR application.
#* Since this use case is about personalization, the development of this main menu is out of scope.
}}
|BusinessLogic=This use case is supported by industry templates that contain examples of personalized treatments using built-in variables or external variables. See below for a sample list of these variables. Personalized treatments are confirmed during design.
====Built-in Variables====

{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}Name
{{!}}{{!}}Description
{{!}}-
{{!}}{{!}}Dialed Number
{{!}}{{!}}The number the caller dialed.
{{!}}-
{{!}}{{!}}CLI
{{!}}{{!}}Calling Line Identifier - The number the caller is dialling from (also known as Automatic Number Identification - ANI).
{{!}}-
{{!}}{{!}}Recent Failure Flag
{{!}}{{!}}Indicates if a call has failed. When a call fails, such as due to technical error, a flag is set in the database to True or False. This parameter can only use the True or False logic.
{{!}}-
{{!}}{{!}}Random Percentage
{{!}}{{!}}Used for A/B testing. A specified percentage of calls can be randomly selected to be sent down a new leg of the callflow. The results of this testing can be monitored using the reporting.
{{!}}-
{{!}}{{!}}Last Result
{{!}}{{!}}The outcome of the last callflow block. For example, for a menu this would be the menu choice or for a self-service task it could indicate if it was completed successfully. This value will be set by the speech application.
{{!}}-
{{!}}{{!}}Number of Calls Today
{{!}}{{!}}The number of times the customer has called into this callflow today.
{{!}}-
{{!}}{{!}}Number of Calls in Last Week
{{!}}{{!}}The number of times the customer has called into this callflow in the last week.
{{!}}-
{{!}}{{!}}Number of Calls in Last 2 Weeks
{{!}}{{!}}The number of times the customer has called into this callflow in the last 2 weeks.
{{!}}-
{{!}}{{!}}Number of Calls in Last 4 Weeks
{{!}}{{!}}The number of times the customer has called into this callflow in the last 4 weeks.
{{!}}-
{{!}}{{!}}Date
{{!}}{{!}}A specified date
{{!}}-
{{!}}{{!}}Time
{{!}}{{!}}A specified time of day.
{{!}}-
{{!}}{{!}}Date and Time
{{!}}{{!}}A specified date and time of that particular day.
{{!}}-
{{!}}{{!}}Current Day of the Week
{{!}}{{!}}This parameter allows you to select a day of the week. No further logic is required.
{{!}}-
{{!}}{{!}}Opening Hours Rule
{{!}}{{!}}This parameter allows you to select whether an opening hours rule is currently open or closed. No further logic is required.
{{!}}-
{{!}}{{!}}Variable
{{!}}{{!}}Variables can be populated with context from within the same dialog or by integrating with other Genesys or third-party systems.
{{!}}}

====External Variables====
In addition to the built-in variables described in the previous section, the rules can use additional customer variables:
* Retrieved from a third-party system via a web-service.
* Set by the IVR application that leverages this use case. This can for example be based on caller input.

====Business Rules====
Business rules are applied to the variables to see how they compare to the value. The outcome of the business rule determines which personalized treatment applies. Business rules consist of logical comparisons of one variable with predefined values. Examples include:
* Variable''customer segment''is equal to VIP
* Current Date is equal to 24.12.2020
* Number of calls in the last week is greater than 3
Multiple logical conditions can be combined within one business rule so that the treatment is applied only if all conditions are met. There is also the option to apply the treatment if any of the conditions are met. Examples for business rules:
* If Customer Segment = VIP and Number of Calls Today > 1, then route directly to VIP agent
* If Customer Segment = Platinum or Customer Segment = Gold, then play the preferred customer announcement

The list below defines the possible options for comparison:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Equal to
{{!}}{{!}}Compare variable with a value to see if they are equal.
{{!}}-
{{!}}{{!}}Not equal to
{{!}}{{!}}Compare variable with a value to see if they are not equal.
{{!}}-
{{!}}{{!}}Containing
{{!}}{{!}}Compare variable with a value to see if the variable contains the value.
{{!}}-
{{!}}{{!}}Not containing
{{!}}{{!}}Compare variable with a value to see if the variable doesn't contain the value.
{{!}}-
{{!}}{{!}}Matching pattern
{{!}}{{!}}Compare variable with a value to see if the variable matches the pattern in the variable.
{{!}}-
{{!}}{{!}}Not matching pattern
{{!}}{{!}}Compare variable with a value to see if the variable does not match the pattern in the variable.
{{!}}-
{{!}}{{!}}Starting with
{{!}}{{!}}Compare variable with a value to see if the variable starts with the value.
{{!}}-
{{!}}{{!}}Not starting with
{{!}}{{!}}Compare variable with a value to see if the variable doesn't start with the value.
{{!}}-
{{!}}{{!}}Ending with
{{!}}{{!}}Compare variable with a value to see if the variable ends with the value.
{{!}}-
{{!}}{{!}}Not ending with
{{!}}{{!}}Compare variable with a value to see if the variable ends with the value.
{{!}}-
{{!}}{{!}}In list (comma separated)
{{!}}{{!}}Compare variable with a comma separated list to see if the variable is one of the values in the list.
{{!}}-
{{!}}{{!}}Not in list (comma separated)
{{!}}{{!}}Compare variable with a comma separated list to see if the variable isn't one of the values in the list.
{{!}}-
{{!}}{{!}}Between
{{!}}{{!}}Compare variable with two values to see if the variable is between those two values.
{{!}}-
{{!}}{{!}}Not between
{{!}}{{!}}Compare variable with two values to see if the variable is between those two values.
{{!}}-
{{!}}{{!}}Greater than
{{!}}{{!}}Compare variable with a value to see if the variable is greater than the value.
{{!}}-
{{!}}{{!}}Greater than or equal to
{{!}}{{!}}Compare variable with a value to see if the variable is greater than or equal to the value.
{{!}}-
{{!}}{{!}}Less than
{{!}}{{!}}Compare variable with a value to see if the variable is less than the value.
{{!}}-
{{!}}{{!}}Less than or equal to
{{!}}{{!}}Compare variable with a value to see if the variable is less than or equal to the value.
{{!}}-
{{!}}{{!}}Blank
{{!}}{{!}}Check to see if variable is blank.
{{!}}-
{{!}}{{!}}Not blank
{{!}}{{!}}Check to see if variable is not blank.
{{!}}}

====Multiple Rules====
Multiple rules can be added to the business logic for personalized routing so that many different personalized treatments can be handled within the same call flow.
|DistributionLogic=N/A
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=N/A
|RealTimeReporting=The Genesys solution provides KPIs indicating the number of times a specific business rule has been used
|HistoricalReporting=The Genesys solution provides KPIs indicating the number of times a specific business rule has been used
|GeneralAssumptions=The payload of ID&V should include all data to be used by Personalization (such as Customer Segment).

The use case is supported for Premise and Platform as a Service (IVR PaaS) .

For IVR PaaS, Genesys Intelligent Automation is deployed on premise and IVR ports are in Genesys PureEngage Cloud. Agents can be enabled in Genesys PureEngage Premise or Genesys PureEngage Cloud.
|CustomerAssumptions=External variables require customer integration into a third-party system. We assume that this data can be accessed using a web service.
|RequiresAll=CE07
|RequiresOr=CE01, CE02
|PremiseAssumptionsAdditional=* This use case is defined for premise based deployments using Intelligent Automation Omnichannel Self-Service
* Genesys Intelligent Automation is a required sellable item for this use case.
|CloudAssumptionsAdditional=This use case is currently not available in PureEngage Cloud
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.1.3
}}
}}

UseCases/Current/GenesysEngage-onpremises/BO07

2018-10-25T13:47:12Z

PLeprieult:

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Isolate and track anomalies to facilitate root-cause analysis to remedy issues
}}{{SMART Benefits
|UCBenefitID=Improved First Contact Resolution
|UCBenefit=Provide visibility into call repetition pattern in reports
}}{{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Increase visibility into training needs and skills-based routing through better reporting data
}}{{SMART Benefits
|UCBenefitID=Reduced IT Operational Costs
|UCBenefit=Provide readily available reports through KPI-based reporting
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Improve utilization due to increased visibility
}}{{SMART Benefits
|UCBenefitID=Reduced Interaction Transfers
|UCBenefit=Reduce transfers because of additional visibility attained through KPIs that help identify areas of training and skills-based routing optimization
}}
|UCIntro=The reporting functionality of this use case is already incorporated within the underlying use cases handling Inbound Interactions. For PS this use case consists of a pure consulting package to help the customer analyzing his data and finding route causes of Service Level Anomalies.
|UCOverview=Business users must be able to report, monitor and make decisions regarding their contact center/customer experience to both improve business outcomes and to move the needle. Knowing when changes need to be made, the impact of the change and when not to make changes requires the ability to rapidly identify anomalies and understand root cause behind the anomalies. Maintaining alignment between routing, reporting and resources is essential in streamlining the business and driving optimization.

Companies set their business plans annually or more regularly and the key KPI objectives that they will measure customer experience success against.

To manage the company's Contact Center objectives and meet end customer's business needs, there is a set of required operational key performance indicators (KPI) that are required. A good business practice is to analyse contact center performance through Service Level review to assess areas of focus in order to identify any remediation actions.

An example of a contributing factor to Service Level is Average Handle time. As such this business has set an objective for the Average Handle Time (AHT) KPI to be under 6 minutes for voice, email and chat interactions. While in some customer environments the AHT may be longer for Chat than voice this has been simplified as this is a simplified "essential use case".

The ability to generate the report ad-hoc or on a pre-scheduled basis is supported.

Historical reporting available on 15 minute increments if needed.
|UCSummary=Improve efficiency through historical reporting to provide improved agent utilization, reduced churn and enhanced customer satisfaction scores. Based on service levels set, customers need to be able to both monitor and analyse interaction data plus discover anomalies through reviewing detailed interaction data. Mapping this against business outcomes, across all channels and where appropriate, customers need to be able to make informed strategic and operational decisions that minimize these anomalies in the future.
|PainPoints=* Limited data & reports – missing relevant business data and inconsistent data across channels
* Limited capabilities – business users unable to easily filter reports, drill down or create custom reports leveraging business data
* Reliance on IT – business users unable to take or automate actions in a timely manner
* SLA drops - Inability to identify the root cause to take appropriate and timely actions
|DesiredState=* Make informed decisions based on business outcomes
* Provide end-to-end visibility into your business performance with consistent relevant business data across channels
* Allow business users to take actions in a timely manner with easy to use applications including easy filtering, drilling down and creating custom reports with business data
* Set automated SLA targets to monitor and take timely actions
* Wide range of out of the box reports with relevant business data
* Native integration with Genesys routing and across channels
|SellableItems=No sellable items
|CloudAssumptions=This use case is not available in the cloud
|PremiseAssumptionsAdditional_Sales=Available on premises

Pre-requisite:
* Genesys CIM
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The flow below describes on how a team lead / supervisor would perform an analysis on low Service Level performance. The reports needed for this analysis are defined in the paragraphs below.
|BusinessImage=https://www.lucidchart.com/documents/edit/222d54d1-7ec6-41c3-a5ff-002db72934ef/0
|BusinessFlowDescription=# The actor (team lead, supervisor or business analyst) runs a report or a report is pushed to them.
Reference - BL1
# He reviews the report against business level KPIs for service level, handle time, customer segmentation and media type (Interaction Volume Customer Segment Report).
Reference - BL2
# If he finds anomalies in the service level, he analyses further reporting data to identify anomalies with contributing factors to Service Level. For example, he might find that Average Handling time was high as well.
Reference - BL3
# He starts to drill down into further details (e.g. by filtering against queue or media type).
Reference - BL4
# He analyses the information for anomaly details and correlations (e.g. Queue, ACW or Other KPI).
Reference - BL5
# This information helps him to identify the root cause for the Service Level anomaly. As an example, he may identify that high ACW is driven by a certain Agent ID, Agent Group, etc.…Subsequently he identifies that the root cause is the skill levels of agents servicing a particular customer segment.
Reference - BL6
# The team lead or supervisor takes appropriate action.
}}
|BusinessLogic=====Parameters and Business Rules====
'''BL1: Assign reports to roles within the company'''
* The business decides during implementation and during operation which roles will receive reports pushed out to the users and which roles can run ad hoc analysis. In this example the team leader has the ability to receive reports via email and then perform the ad hoc analysis.
* The roles are then assigned to users of reports to either receive the emails or have a login to the online reporting
* This is part of Interactive Insights standard capabilities.

'''BL2: Comparison of reports with business level KPIs:'''
* The actor analyses the Interaction Volume Customer Segment Report and notices that the service level was not met for several hours the day before.
* The actor reviews the report against business level KPIs for service level, handle time, customer segmentation and media type.
* The actor reviews the service level in the report and notices that the service level is exceeded in certain periods yesterday as is AHT and decides to investigate.

'''BL3: Analyse contributing factors'''
* The parameters that drive AHT are Talk time, Hold Time and After call work. These can be filtered by a large amount of drivers of AHT such as Agent Group, media type, customer segmentation, Queue, intention, etc.
* When an anomaly is seen in average handle time in the reports the actor investigates the cause of the anomaly and the decision can be made by evaluating the Agent Group Customer Segment Report.
* The actor (e.g. team leader) has the AHT upper and lower values (confidence level) set for their team and measures against these values. The handle time parameters are part of the reporting and the upper and lower values are known to the actor.
'''BL4: Drill down into details'''
* The reporting user starts to drill down or filter the reports to identify the underlying root cause of the high handle time identified.
* The reporting user makes a decision as to where the underlying driver of the high handle time is coming from and identifies that its being driven by certain queues (e.g. Queue 1) on certain media type (e.g. Inbound Voice) by evaluating the Agent Group Customer Segment Report.
* The service level parameters are part of Interactive Insights reporting. e.g. ACW, hold time, talk time, etc
'''BL5: Identify correlations'''
* The drill down or filtering continues to identify the underlying root cause of the high after call work time identified at point 4.
* When an anomaly is seen in the reports the actor investigates the cause of the service level anomaly and identifies that ACW has risen at the same time that the service level was not met by evaluating the Agent Group Customer Segment Report.
* The actor (e.g. team leader) is viewing the ACW time for the period that exceeded the service level. The service parameters are part of Interactive Insights reporting.

'''BL6: Identify root cause'''
* The reporting user makes a decision as to where the underlying driver of the high after call work time is coming from and identifies that its being driven by certain agent(s) and decides to look at their skill levels and tenure.
* The parameters are part of Interactive Insights reporting by evaluating the Agent Group Customer Segment Report.
* The actor then investigates the skill levels and that the newly hired agent(s) require training to reduce the handle time or if other corrective action should be taken such as changes to the routing, scheduling, skilling, etc.
|DistributionLogic=Not applicable
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=Workspace Desktop Edition (WDE), Workspace Web Edition (WWE) or Genesys enabled desktop.
|RealTimeReporting='''Not applicable.'''

This is for Omni-channel Analytics- Historical Reporting
|HistoricalReporting='''Business Results Reports'''
* Interaction Volume Customer Segment Report - It must be possible to report the following KPIs:
** % First Response Time Service Level
** Avg Handle Time
** Avg Wrap Time
* These KPIs must be available in the following dimensions:
* Customer Segment
* Media Type
'''Agent Reports'''
* Agent Group Customer Segment Report - It must be possible to report the following KPIs:
** Avg Handle Time
** Avg Wrap Time
** Engage Time
** Hold Time
** Wrap Time
* These KPIs must be available in the following dimensions:
** Media Type
** Agent Group
** Customer Segment
'''Detail Reports'''
* Interaction Handling Attempts Report
** Looking for Routing target which will contain the Skill Expression used to route the interaction to the agent.
'''Interactive Insights'''Genesys Interactive Insights allows users to run and schedule reports for automatic distribution.
** '''Additional Report Benefits'''This list of reports and benefits below are not all-inclusive. It just shows reports that are specific to troubleshooting Service Level issues. Many reports give you the data from a different perspective to help with root cause analysis.
* Agent Conduct Report
** Compare agent performance in handling interactions against the agent's group, focusing on a few specific measures that demonstrate the possible mishandling of interactions - a high number of unaccepted interactions, excessive hold and after-call work (wrap) times, and shorter-than-usual engage (talk) durations with customers.
* Agent Group Customer Segment
** agent-group performance by customer segment
* Agent Group Interaction Handling
** Enables supervisors to monitor the interaction-processing performance of one or more groups of agents during a range of days that you specify.
** Determine which agent groups are transferring too many interactions.
* Agent Group Queue Business Attribute
** Categorizes how agent-activity results by a wide range of dimensions i.e. agent group, queue type, media type, intreactioninteraction type, date
* Agent Group Service Type
** Summarizes agent-group performance by service type with respect to interactions that are received within the contact center during a range of days
* Agent Interval Based Report
** Manage contact center operations enabling viewing of key performance indicators that are related to the agents they supervise and to assess agent productivity
* Agent Not Ready Reason Code Report
** Displays times when agents logged in and out and the duration of each login session during a range of hours that you specify within a day
* Agent Not Ready Report
** Identify
*** The top five reasons (reason codes) that are used by agents cumulatively for entering the NotReady state.
*** The top five longest durations that are associated with the reasons that agents placed their devices in the NotReady state.
*** The top and bottom five agents who had the greatest and least percentage of their active time attributed to the NotReady state.
* Agent Queue Report
** Enable supervisors to monitor the interaction-processing performance, as it relates to interactions, of an agent (or all agents) by the queue from which interactions were distributed during a range of days that you specify.
** Provide the top and bottom 10% of agents who have the longest and shortest average hold times. Interaction processing (or handling) involves accepting interactions, placing calls on hold, consultations, transfers, after-call work, and conversing.
* Agent Summary Activity Report
** Obtain snapshots of agent states for a given day and to assess agent productivity for interactions that begin and end during the given day
* Agent Utilization Report
** Summarizes agent performance with respect to the customer and consults interactions that are processed within the contact center Although the Avg Engage Time and Avg Handle Time measures provide an indication of how effective an agent is in terms of customer service and handling interactions, these measures must be analyzed within the scope of the agent’s group. For example, results might show that a Tier 3 Technical Support agent has a higher average engagement time than the front-line agent who initially handled the interaction and routed it to the higher tier for further analysis. Indeed, the higher average across groups in this scenario might indicate the quality or complexity of service that is provided, rather than the proficiency of the agent in processing interactions.
* Agent Wrap Report
** Enables supervisors to monitor the after-call work (wrap) call-related activities that an agent (or agent group) performs after processing calls and during a range of hours that you specify within a particular day
** Rank the agents who spent the least (fastest 10%) and most (slowest 10%) amount of time in ACW mode.
** Especially useful for viewing the progress of new agents as they make more (or fewer) calls to complete aftercall work than more established agents. With this data, you can determine whether you need to fine-tune Genesys Info Mart configuration to, for instance, send more information about a customer (that is, attached data) to the agent’s desktop.
** Customer Perspective Report
** Summarizes contact center milestones from customer perspective providing the average response times, revenue and customer-satisfaction scores, and various service-level percentages of interactions that enter or begin with the contact center.
** Describe how much time elapsed before customers got to speak to an agents or received a response, how satisfied were they with their transactions, and how much money they spent.
* Interaction Volume Service Subtype Report
** Summarizes how interactions that enter the contact center are categorized into the service type and service subtype business attributes that are configured in your environment.
* Interaction Volume Service Type Report
** Summarizes how interactions that enter the contact center are categorized into the service type and service type business attributes that are configured in your environment.
* Interaction Handling Attempt Report
** This report summarizes segment-related details with regard to an agent's handling of contact center interactions.
* Transfer Detail Report
** This report provides the detailed information about the initiating and receiving parties of those contact center interactions that involve a transfer.
* Interaction Traffic Group Report
** This report summarizes contact center activity as interactions are offered to, abandoned within, and distributed from queues that belong to one or more queue group(s).
* Interaction Traffic Report
** This report is helpful for determining the efficiency achieved on a specific queue because it provides the volume of interactions accepted in a given period, along with the average speed of answer and maximum delays experienced before acceptance or abandonment from the perspective of the queue. When results are interpreted in concert with results from the Speed of Accept and Abandon Delay reports, the overall productivity of your queue's can be assessed.
* Queue Outline Report
** There are three main tabs in this report. The Customer Interaction tab shows how the number of interactions that entered a particular queue or queue group break down into the various queue-related measures that provide interaction counts. The Consult Interaction provides similar information for consult interactions that enter the queue/queue group. The Customer & Consults tab combines these results into one report. From this information, you can see how these measures interrelate and how they contribute to the sum total of all interactions (Entered) that entered a queue resource.
* Queue Summary Report
** This report provides measures that relate to the interactions that enter a queue and that are either abandoned or distributed and handled by any routing target, such as an agent.
* Speed of Accept (seconds) Report
** This report shows the number of interactions that were accepted within each of 10 time buckets and the percentages of interactions that were accepted in these buckets to the total number of interactions that were accepted from the queue. Pertains to short term interactions like a voice call.
|RequiresOr=CE01, CE02, CE16, CE18
|PremiseAssumptionsAdditional=* This use case is for Inbound interactions only.
* Customer must have Genesys enabled Self Service IVR/GVP, CIM, GIM and GI2, Agent desktop.
* KPIs out of box for Genesys Infomart (KPI: Various Operational metrics and/or business metrics e.g.. SL, AHT, Transfers, Occupancy, Segmentation, Intention/Call type, Disposition, Queue volume, etc.…)
* The following user roles will be supported within the scope of this use case: Team Lead, Supervisor, Business Analyst.
* Other requirements
** Assume this use case has a pre requisite use case of inbound voice and/or Genesys Email and/or Chat
** KPI captured and analyzed is part of GIM Out of box statistics
** This essential use case is based on the Service Level metric
** Once anomalies are identified in reports, the team lead/ supervisor can take actions:
*** Call agents back form lunch or breaks early
*** Call extra resources in
*** Upload an announcement notifying customers of an event causing increased hold times (Requires this be available in routing and gives the customer the option to hang up)
*** Modify overflow parameters (Requires Routing have the capability and objects to be changes)
*** Train additional agents with the impacted skill to take care of the service level influencing interactions.
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is not available in the cloud
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 1.0.1
}}
}}

UseCases/Current/GenesysEngage-onpremises/BO06

2018-10-25T13:45:20Z

PLeprieult:

{{SMART UseCase
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Target the best agents to resolve the customer call type by reducing misroutes or repeated transactions to improve customer satisfaction measures (such as Net Promoter Score and Customer Effort Score
}}{{SMART Benefits
|UCBenefitID=Improved Employee Attrition Rate
|UCBenefit=Improve Employee Experience by routing to the Agent the work that they are more efficient or “good” at more often.
}}{{SMART Benefits
|UCBenefitID=Improved First Contact Resolution
|UCBenefit=Improve Employee Experience by routing to the Agent the work that they are more efficient or “good” at more often.
}}{{SMART Benefits
|UCBenefitID=Reduced Handle Time
|UCBenefit=Reduce transfers and conferences by routing interactions to the best qualified agent and reduce handle time as more efficient workers often have a lower Average Handle Time
}}
|UCOverview=Business leaders want to improve their business Key Performance Indicators (KPI), leverage the innovation in Artificial Intelligence and drive business decisions with the abundance of data and context available in their business. Predictive Routing uses machine learning to support optimization of Service KPIs.

Service KPIs gather any types of metrics measuring a Customer Experience or Efficiency outcome of an interaction, as opposed to Sales KPIs that measure the Sales Outcome of an interaction. Service KPIs can be of two types:
* Customer Experience or Service outcome such as Net Promotor Score (NPS), Customer Satisfaction (CSAT), First Contact Resolution (FCR), and Customer Effort Score (CES)
* Operational efficiency metrics such as Handle Time (AHT), transfers, hold count, hold time, case open/closed, back office tasks opened, and field technical sent
This use case focuses on improving First Contact Resolution (FCR), captured from Genesys Info Mart or from 3rd-party surveys (for inbound voice interactions, for example) but can also be extended to other service-related KPIs, and other inbound, outbound, digital, or workload management channel types. Wherever applicable, this use case documents the impacts of choosing another channel type or another KPI, captured from Genesys data or from 3rd-party sources.

Predictive Routing also applies to Sales & Marketing KPIs. See {{#mintydocs_link:topic=SL06}}.

Traditional routing is designed to match customers to agents through skills-based or group-based logic to maintain a service level rather than improving KPI. Unlike traditional routing, Predictive Routing uses machine learning to find signals in historical data to build a model that predicts the business outcome of an customer's interaction when handled by an employee. This model improves KPIs by ranking agents before making the match with customers. This model also addresses the operational challenges that occur in understaffing and overstaffing scenarios while balancing the service level with improving KPI.

Predictive Routing has built-in A/B Testing to demonstrate the uplift of the KPI provided through blending Artificial Intelligence with humans in what Genesys terms Blended AI.
|UCSummary=The contact center manager wants to increase the percentage of the interactions achieving First Contact Resolution (FCR). The Predictive Routing solution can assist in achieving this objective. FCR can be obtained either from:
* Genesys Historical Reporting data, enabling you to define FCR. For example, FCR 7 is defined as the number of customers who didn't make a subsequent contact for the same service type in 7 days.
* A 3rd-party outcome data source (such as a survey).

Predictive Routing:
* Uses machine learning, a subset of Artificial Intelligence, to compare feedback of the actual outcome with the predicted outcome, helping to improve future agent-to-customer matches.
* Ranks agents predicted to resolve the inquiry on first contact.
* Provides the finest-grain match of customer contact with agent to improve FCR.
* Provides an FCR uplift using continuous learning to rank the expected FCR for agents servicing customers.
* In many customer environments, anchoring the optimization on a customer experience metric like FCR, CSAT, or NPS also drives benefits in adjacent KPIs such as a reduction in handle time, transfers, or multi-agent events (MAE) with manageable impact to service levels.
The result is that repeat contacts are reduced and FCR improves.
|PainPoints=* Frustrated customers or repeat interactions – increased number of transfers to identify the right person to resolve the issue
* Resource inefficiency and high costs – unable to identify the right agent to quickly solve the issue
* Reduced employee satisfaction – employees don’t feel empowered and managers are unable to identify the right training opportunities
* Reduced employee satisfaction – employees don’t feel empowered and managers are unable to identify the right training opportunities

|DesiredState=* Leverage Predictive analytics and machine learning to identify the optimal agent-customer match to improve First Contact Resolution
* Employ continuous learning by feeding back actual outcomes to update predictive models
* Managers can gain insights to help identify root causes and employee training opportunities
* Managers can view reports identifying attributes that influence KPI
* A/B testing methodologies can be applied to evaluate lift
* Deep integration with Genesys routing and orchestration
|SellableItems=At least one Inbound SMART USE Case is required, CIM, CIM HA (Optional), Genesys Infomart, Genesys Infomart - HA (optional)
|PremiseAssumptionsAdditional_Sales=* Available on premises (Conditional)
Pre-requisite:
* Genesys CIM
* Info Mart (Used as a component of Predictive Routing, or common)
* At least one Inbound, Digital or Outbound SMART USE Case (see use-case inter-dependancies section for details)
|BusinessImageFlow={{SMART_BusinessImageFlow|BusinessFlow=
====Model Creation====
The following flow shows how a model is created. The main actor of this flow is typically a Business Analyst / Data Analyst in charge of the model creation. The Analyst is a trained professional from Genesys, a partner, or a customer organization.
|BusinessImage=https://www.lucidchart.com/documents/edit/a4257aa9-6e73-4dc8-95f7-f592c45d78ec/0
|BusinessFlowDescription=
# The team Lead / Supervisor and the Analyst agree on the outcome metric to be used. This use case uses FCR as the reference metric.
# The Analyst gathers customer profile, interaction profile, agent profile, and FCR data from Info Mart, and optionally from 3rd-party data sources.
# The Analyst analyzes the data to determine correlating factors/predictors and verify if the data is suitable for a predictive model.
# The Analyst creates a predictive model based on the available Info Mart data set.
# The Analyst reviews the quality of the predictive model and potential for uplift. If the quality is satisfactory, the model can be provisioned.
The modeling process described above may be extended to incorporate the following changes:
* Integration of additional 3rd-party data sources for customer profile (such as CRM), agent profile (such as WFO), content analysis data (speech or text), or outcome data (such as NPS surveys or CRM or case management)
* Selection of other KPI(s) to optimize based on Info Mart data (such as AHT) or 3rd-party data (such as NPS)
The selection, analysis, and integration of this data into the predictive model requires a project-based implementation that is supported by the Predictive Routing product, but not described in this use case. Contact Genesys Professional Services for details.
}}

{{SMART_BusinessImageFlow|BusinessFlow=
====Predictive Routing First Contact Resolution====
This business flow shows the use case from the perspective of the customer and agent.
|BusinessImage=https://www.lucidchart.com/documents/edit/bd1c6f7f-98e5-441d-b014-929efe84e045/0
|BusinessFlowDescription=
# The customer contacts the company using one of the available inbound channels (such as voice, e-mail, chat, mobile, work item, or Apple Business Chat).* This inbound interaction may be the result of a proactive rule on a web or mobile application.
# One of the Inbound use cases for the corresponding media type handles the interaction. The context data is captured depending on the interaction and engagement type.
# Genesys queues the interaction until at least one agent with the required skill(s) is available.
# Predictive Routing ranks the agents against the FCR probability for that specific interaction and returns a ranked list with values.
# Genesys checks if the rank for at least one agent is above the threshold.
# If no agents are available within the configured timeout, the routing expands the potential target pool of agents, such as by reducing the required skill level.
# If yes, Genesys distributes to the best available agent based on the predictive model (the agent with the highest rank) and the routing rules.
# The agent disconnects the interaction.
# The outcome is mapped to an InfoMart attribute (for example, a disposition code or custom key value pair).
# Optional: The customer is offered a survey. The answer to the survey is stored in a third-party system.
# Optional: Outcome data, such as case management closure, is produced and stored by a third-party application.

*The outbound scenario differs from this flow as the agent routing function is triggered by the dialing algorithm to the customer. Nevertheless, In Predictive and Progressive mode, once the customer answers, the agent distribution is based on the same predictive routing principle. As the Preview mode is not distributed through routing, this use case does not apply to Preview mode.}}
|BusinessLogic=====Parameters and Business Rules - Create Predictive Model====
'''Model Step 1'''
* The business representative of the company decides on the KPI to be improved by Predictive Routing. This use case selects First Contact Resolution as determined by repeat callers for the Service Type.
* The company decides which metrics to use, in this case the values for First Contact Resolution X (such as 7 days) and First Contact Resolution Y (such as 35 days), to determine the periods during which the customer has contacted the company more than once.
* At least once a day the FCR metrics are evaluated against the customers that have contacted the company over the last X and Y days for each agent and service type.
* Other KPI types can be considered through a project-based implementation.

'''Model Step 2'''
* The user gathers the FCR, Agent Profile, Interaction profile, and Customer profile data from Genesys Info Mart.
* Predictive Routing then ingests the data into the system as the basis for the predictive model.
* Other Genesys or 3rd-party data sources can be considered through a project-based implementation.

'''Model Step 3'''
* The user assesses the data for predictability of FCR:
** The data is analyzed for variance in First Contact Resolution by intention and agent. The results indicate whether a predictive model can generate significant improvement from the data.
** Each data point is analyzed for its correlating factor to FCR.
* The user prepares to create the model.

'''Model Step 4'''
* The system creates the predictive model to rank the FCR for customer-to-agent matching.
* The model can be made available for further analysis before provisioning into production.

'''Model Step 5'''
* The potential uplift of FCR using the predictive model is analyzed for effectiveness and the predictive model is then provisioned for use within customer-to-agent matching.
** The analyst evaluates the model to determine the potential uplift in FCR for this predictive model.
** The system shows the expected mathematical accuracy of the model through taking a percentage (such as 80%) of the data to train the model and then using the remaining percentage (such as 20%) of the data to predict the outcome with the model. Then the system compares the predicted results with the actual results and provides model accuracy information.

====Parameters and Business Rules – Predictive Routing FCR====
'''Routing Step 1'''
* Through Inbound, Digital, Workload Management, and other use cases, the customer creates an interaction on any media type that is stored within Info Mart for the defined FCR metric. This use case supports all inbound and outbound channels involving Genesys routing. See Use Case Interdependencies for details.
* Prerequisite: This use case requires one or more use cases handling inbound or outbound interactions.

'''Routing Step 2'''
* The interaction use case identifies the primary intention of the customer (Service Type) and the initial target skill expression is set. The necessary predictors identified during model creation are available to the interaction and can be passed to Predictive Routing.
* The system integrates 3rd-party data sources for customer profiles during the interactions qualification process. Any required additional customer or agent profile data available to the interaction in run time can be integrated through a project-based implementation.

'''Routing Step 3'''
* This step queues the interaction and is designed to cover both agent surplus and customer surplus scenarios. When either one or multiple agents are available (agent surplus scenario), the flow immediately proceeds. Otherwise, Genesys queues the interaction until an agent is available (customer surplus scenario). The system starts to balance the service level with the business KPI through maintaining priority.

'''Routing Step 4'''
* Once one or more agents are available, the necessary Customer Profile, Interaction Profile, Agent Profile, and predictor information is passed to Predictive Routing to rank the customer interactions in the queue against the agent outcome. This process caters to both customer surplus and agent surplus scenarios.

'''Routing Step 5'''
* The rank for each of the interactions against each of the agents is returned to routing to bias the customer-to-agent matching towards the agent(s) that can deliver the highest first contact resolution.
* The system works in both customer and agent surplus modes. In a customer surplus scenario, the system delivers the highest priority interaction(s) and when multiple interactions are targeting the available agent, the highest priority and then the highest FCR match applies.

'''Routing Step 6'''
* If at least one of the FCR values is above the threshold, the interaction is routed to the agent with the highest FCR value.
* The system delivers the interaction normally, handling any ring on no answer and exception situations (applicable to voice, open media, or digital channels) as defined in the underlying use case.
* The customer and the agent are connected.

'''Routing Step 7'''
* Optionally: If no appropriately ranked agent become available or the available agent does not have a sufficiently high FCR value, the value threshold is reduced after the configured amount of time.
* Normal target expansion, such as relaxing skill level as configured within the underlying distribution strategy, occurs.
* The continual re-prioritization of the interaction also occurs as do any treatments and the queued customer experience.

'''Routing Step 9'''
* The outcome of the interaction is captured through the agent desktop or a server-side process. Genesys APIs are invoked automatically or after an agent action to map the outcome to a Genesys interaction attribute: custom attached data or disposition code.
* Info Mart captures this attribute with the Info Mart interaction record.

'''Routing Step 10'''
* Optionally, the customer receives a survey (the survey results are not connected with Genesys and are intended to evolve with the survey use cases)
* The survey is completed (optionally) and the outcome is collected and stored by a 3rd-party application.

'''Routing Step 11'''
* Optionally, the outcome data is produced and stored by a third-party application.
|DistributionLogic=The details of the distribution of an interaction to an agent are defined in the underlying Inbound, Digital, or Outbound use cases. Refer to the flow above to understand how Predictive Routing influences the distribution logic.

Predictive Routing provides a routing lever that can be used to control how customer-to-agent matching behaves in customer surplus mode to distribute the interactions based on agent occupancy.
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=This use case does not include specific agent desktop requirements. Specific data can be attached during the routing phase and may be visualized by the agent.
|RealTimeReporting=Predictive Matching realtime reports include:

====Queue KPIs By Predictive Model====
Monitor your Queue performance with the prediction scores provided by Genesys Predictive Matching to optimize your business KPI.

[[File:PRM_Queue_Group_by_Model_View_3.png]]
====Agent Group KPIs by Predictive Model====
Monitor the Agent Group Performance with the volume of answered interactions by range of predicted scores provided by Genesys Predictive Matching to optimize your business KPI.

[[File:PRM_Agent_Group_By_Model_View_1_3.png]]
|HistoricalReporting=The historical reports available within the Predictive Matching Data Store include:
* Predictive Matching Operational Report tracks Predictive Matching operational statistics.
* Predictive Matching A/B Testing Report tracks A/B testing results for Predictive Matching models and predictors.
* Predictive Matching Agent Occupancy Report tracks Agent Occupancy while Predictive Matching is being used to optimize routing.
* Predictive Matching Daily Queue Statistics Report tracks KPIs for each Queue while Predictive Matching is being used to optimize routing.
* Predictive Matching Detail Report provides interaction level detail data about Predictive Matching use and its impact on KPIs.

*A/B reports can be developed from any standard or custom Info Mart data. If the outcomes data is NOT integrated with Info Mart, the creation of A/B reports must be evaluated as a separate effort.
|GeneralAssumptions=The following use cases are exceptions where Predictive Routing cannot be integrated:
* {{#mintydocs_link:topic=CE17}}: Routing to a Genesys Digital Auto-response.
* {{#mintydocs_link:topic=EE04}}: Enable Schedule-based routing.
* Self-Service Use Cases
* Outbound preview + agent reservation used for Predictive and progressive outbound
* Callback, web monitor, proactive assist, co-browse, and Knowledge Management.
|RequiresOr=BO01, BO02, BO03, BO04, CE01, CE02, CE11, CE12, CE16, CE18, CE19, CE20, CE24, CE29
|Exceptions=CE17, EE04
|PremiseAssumptionsAdditional=* FCR 7 is defined as the number of customers who didn't make a subsequent contact for the same service type within 7 days.
* The Standard deployment materials address Inbound voice interactions only, Informart data only, including FCR 7.
* Omnichannel and outbound integrations require Genesys Product Management approval and Genesys Professional Services support.
* Integration of additional data sources, Genesys or 3rd-party, requires a dedicated assessment and implementation by Genesys Professional Services.
* Digital, Workload Management, and Outbound integrations require Genesys PS, Product and R&D support.
* Customer should have one or more Genesys channels.
* Prerequisites: An implemented use case for one or more channels and Info Mart reporting. These use cases populate the predictors in the routing and the data necessary to build the models. This solution cannot use data that is not present.
* The capture and analysis of FCR KPIs is not part of Info Mart out-of-box statistics and is developed during model creation.
* Routing to agents is based on skill expressions or group-based routing.
* There is no industry standard definition for FCR. The definition chosen in this use case is intended to be a guideline metric that can be repeated across our customers who have not defined this metric.
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is currently not available in PureEngage Cloud
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=v 2.0.1
}}
}}

UseCases/Current/GenesysEngage-onpremises/CE02

2018-10-25T12:02:34Z

PLeprieult:

{{SMART UseCase
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following flow describes the use case from the perspective of the main actors, i.e. the customer and the contact center agent. It provides a high-level view of the basic flow. The detailed description of the underlying call flow is described in Chapter “Distribution Logic”.
|BusinessImage=https://www.lucidchart.com/documents/edit/ce874ffd-90f0-4ccb-baa6-970732d1c52e/0
|BusinessFlowDescription=# The customer calls one of the numbers of the contact center.
# He is routed to an IVR application which is determining the service type and also performs an Identification and (optionally) Verification of the customer. This functionality is provided outside of the scope of this use case, it is assumed that the information on the requested service and customer identification is passed on to be used within this use case. The use case CE7 - Effective Identification and Validation in IVR can be used for this functionality. Alternatively, customer CLI is used for Identification.
# If the customer calls outside of out-of-office hours or if an emergency situation is in progress, an announcement is played. After this the caller may be reconnected or diverted to another number inside or outside of Genesys.
# Genesys retrieves context data on the customer based on the customer identification.#If the contact center is open the routing parameters for this particular call is set based on the type of request and the customer context. This will enable flexible and personalized call handling.
# The Expected Wait Time (EWT) for the customer is calculated and is announced to the customer (optional). If the EWT exceeds a specific threshold, an announcement is played and the caller is disconnected or routed to another number inside or outside of Genesys (optional).
# Additional announcements are played to the customer. These announcement are based on the customer context. Examples include: Quality announcements/Special promotions-offers for the customer/Announcements for potential self-service options
# If the customer has been calling recently for the same type of request, Genesys can route to the last agent (configurable based on type of request and customer context). In case this agent is not logged in or not available for this call within a specified time out, the call is routed to the requested skill
# The call is distributed to the best agent who:
#* Has the base skill(s) to handle the original request
#* Has the supplementary skill(s) determined by the customer context (optional). Examples include:Skills to upsell a defined product / service to the customer or specific empathy skills based on the customer segment or demographic
#* A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill and / or reducing the skill level on the base skill if the call cannot be distributed within specific timeouts.
# Once the call is distributed to an agent, the call context information is displayed to the agent. As an example, the agent is able to see any special offer or promotion for the customer, so he can start the relevant information. The agent handles the customer request and any potential up-/cross-sell opportunity.
# After the conversation with the customer, the agent records the outcome of the call for reporting purposes e.g. if he has acted on the presented lead
}}
|BusinessLogic=====Emergency Check====
Emergency mode activation is enabled at three levels: Global, Service (Type of Request) and Queue. The emergency mode is not only checked at the beginning of a call, but is constantly monitored during call queuing. If an emergency flag is set for a queued call, the corresponding emergency announcement is played, and the configured action applies to the call (disconnect or deflect to another number within or external to Genesys).

Furthermore, Genesys runs a parallel stream to continually check if agents are logged onto the platform. If no agents are detected, then an emergency mode is automatically activated.
====EWT Announcements====
Announcement of Expected Wait Time to customers is handled based on predefined recordings. It is a good practice to announce expected wait times approximately to not jeopardize customer expectation. Six thresholds are configured which can trigger different announcements. Default values are: 60, 120, 180, 300, 600 and 1200 seconds. The announcement text should match the threshold.
====Last Agent Routing====
The last agent(s) a customer spoke to is stored within Context Services (part of Universal Contact History) including the base skill which was required for the corresponding service. When a customer calls the contact center for the same service and Last Agent Routing is enabled, Genesys checks in Context Services for a recent contact, not older than a configurable threshold, handled by an agent with the required skill. The corresponding agent is used for Last Agent Routing.

In case of multiple matches, the most recent entry is used.
====Busy Treatment====
Messages and Music are played for queuing calls. It is possible to configure up to six messages with music treatment in between. The first two messages and associated music treatments are played once, the remaining 4 messages and music treatments are looped until the call is answered or abandoned.
====Skill Model====
=====Skill types=====
The skill model, used for distribution, is based on three logically different skill types which define attributes and knowledge of the agents:

=====Basic skill=====
This skill is required to handle a specific type of request or service. One basic skill is required for each call for the distribution of calls to agents.
=====Language skill=====
This skill type determines the language in which a call shall be answered. The requested language is provided via the IVR. If no language is provided, a default language is used. One language skill is required for the distribution of calls to agents.
=====Supplementary skill=====
Genesys Routing utilizes supplementary skills for enhanced routing logic and personalization. Supplementary skills are defined by customer specific context data.

The following provides an example:
* A customer calls the service hotline for "Account Transactions."
* He successfully identifies and authenticates within the IVR. The corresponding data are passed to Genesys.
* The caller's profile within Context Services indicates that the caller is eligible for a Platinum Credit Card up-sell.
* In this case, the call should ideally be routed to an agent with the base skill "Account_Handling" and the supplementary skill "Up-Sell" to ensure that he can handle both the original request and successfully convert the up-sell opportunity for this customer.

=====Skill level=====
Each agent has one or more skills associated to their profile and a skill level associated to each base skill, referred to in this document as proficiencies. The skill level is used to define primary, secondary and tertiary targets within the routing logic described in section "Targeting". The targets are defined as follows:
* Primary target = Agents with base skill level > N & language skill > 0
* Secondary target = Agents with base skill level > M & language skill > 0
* Tertiary target = Agents with base skill level > P & language skill > 0

N, M, and P are configurable based on request type and customer context.
====Priority Model====
Different priorities are set for calls according to business value of the type of request. If priorities are set and an agent becomes available, Genesys distributes the call with the highest priority matching the agent's skills. This is specifically relevant if the agent can receive interactions for different types of request. The priority of a call is increased over time to make sure that low-priority calls are still distributed to an agent after a potential longer waiting time (priority tuning). Priority tuning is configured via the following parameters:
* Priority start (the starting priority)
* Priority increment (the amount to increase the priority after the interval time)
* Priority interval (the time between priority increases)
* Priority limit (the maximum priority)

These values are configurable by type of request and by customer context.

In addition, a priority mark-up is configured for customers who have previously completed IDV or ID within the IVR to account for their additional time within the IVR compared to customers who did directly drop out into the queue. The priority mark-up for customers who attempted / complete IDV and ID is relative to the amount of time it takes to complete the IDV and ID verification application within the IVR.

Transferred calls and RONA calls can also get a higher priority assigned.
====Transfer====
The agents can transfer calls to defined internal agent groups or business lines (route points). The routing logic defined for these route points is similar to the routing logic defined above (without initial announcements). Only transfer route points are visible to the agent in WDE.
====Additional functionality====

* RONA-functionality: If an agent does not accept the call, the call is automatically put back into the distribution flow after a time out. The agent is set to not-ready.
* This use case can be combined with other non-voice use cases. Blending is possible. The configuration of priority values need to be synchronized with priority settings for other media types to allow an ordering of interaction within the universal queue corresponding to business requirements. Capacity rules will be configured for the agents / agent groups to define what interactions is handled in parallel (if any).

====Context Service Data====
Customer Context is stored within Genesys Context Service as part of the Universal Customer History Server. The data is provided by the organization. A regular update process has to be set up. Instructions to map the organization's specific data with the data stored in Genesys need to be determined. The following data scheme provides flexibility to map specific organizational data with data to be used within Genesys. The data is used for routing rules or for display of the agent desktop. Context data related to a list is only used if the time and date of the call is within the List Stop and List Start data. The following table shows the available data and how these are used:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Attribute'''
{{!}}{{!}}'''Definition'''
{{!}}{{!}}'''Agent Desktop'''
{{!}}{{!}}'''Routing Rules'''
{{!}}-
{{!}}{{!}}Customer ID
{{!}}{{!}}Unique identifier of the customer
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Name
{{!}}{{!}}Customer Name
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Segment
{{!}}{{!}}Customer Segment
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 1
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 2
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 3
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 4
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 5
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Display Data 1
{{!}}{{!}}Custom Attribute to be displayed at agent desktop
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Display Data 2
{{!}}{{!}}Custom Attribute to be displayed at agent desktop
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}List Name
{{!}}{{!}}This data is used to indicate that the customer is on a specific list / campaign
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Type
{{!}}{{!}}Type of the list or campaign
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Start
{{!}}{{!}}When actions for a list / campaign starts
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Stop
{{!}}{{!}}When actions for a list / campaign stops
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List pop message
{{!}}{{!}}Message to be displayed to agent
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}List actioned
{{!}}{{!}}Indicates if the list / campaign has been already actioned. If the list / campaign has been actions, no list data is displayed to an agent.
{{!}}{{!}}

{{!}}{{!}}X
{{!}}}

====Parameters available per type of request / service====
The following lists the business parameters which are configurable by service. These are configured by Genesys Administrator Extension. Please note that the list is not exhaustive as additional parameters for technical settings might be required. It also does not reflect the technical realization and naming conventions to be used. Also some of the parameters are combined for ease of readability. The list is intended for business readers to give an overview of the flexibility in the configuration of the routing logic:

{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Service Name
{{!}}{{!}}Name of the service.
{{!}}-
{{!}}{{!}}Enable Rules
{{!}}{{!}}Flag to indicate if rules are used for the service. If rules are not enabled for the service, the default parameter settings within GAX are used.
{{!}}-
{{!}}{{!}}Service Emergency Flag
{{!}}{{!}}Flag to set emergency status for the service.
{{!}}-
{{!}}{{!}}Open hours
{{!}}{{!}}Sets the opening hours of the service.
{{!}}-
{{!}}{{!}}Special Day
{{!}}{{!}}A list of exceptions to the regular open hours, for a holiday or other reason.
{{!}}-
{{!}}{{!}}After Hour Message
{{!}}{{!}}Message to be played if the call is out of business hours.
{{!}}-
{{!}}{{!}}Special Day Message
{{!}}{{!}}Message to be played if the call is on a special day.
{{!}}-
{{!}}{{!}}Emergency Message
{{!}}{{!}}Message to be played in emergency situations.
{{!}}-
{{!}}{{!}}EWT flag
{{!}}{{!}}Flag to determine if EWT shall be announced to a customer.
{{!}}-
{{!}}{{!}}EWT Thresholds
{{!}}{{!}}6 Thresholds to activate different EWT announcements (see chapter "EWT Announcements").
{{!}}-
{{!}}{{!}}EWT Announcements
{{!}}{{!}}6 pre-recorded EWT announcements corresponding to the 6 thresholds above.
{{!}}-
{{!}}{{!}}EWT Breach Threshold
{{!}}{{!}}Threshold to determine if a call is queued (see chapter "Expected Wait Time Checkâ€).
{{!}}-
{{!}}{{!}}IDV Type
{{!}}{{!}}Level of ID&V required for the type of request. Values are "None", "ID" or "ID&V". This value is displayed to the agent.
{{!}}-
{{!}}{{!}}Quality Message
{{!}}{{!}}The quality message to be announced to the customer (see chapter "Main Flow").
{{!}}}

====Parameters available per customer context and type of request / service====
The following lists the business parameters which are configurable by service and customer context. Default values for these parameters are configured by Genesys Administrator Extension per service. These base parameters are overwritten by parameters defined by rules using additionally the customer context. These rules are configured in Genesys Rules Engine. Please note that the list is not exhaustive as additional parameters for technical settings might be required. It also does not reflect the technical realization and naming conventions to be used. The list is intended to give business users an overview of the flexibility in the configuration of the routing logic:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Special Message 1&2
{{!}}{{!}}The special messages to be played after the quality message (See chapter “Main Flow”).
{{!}}-
{{!}}{{!}}Last Agent Routing enabled?
{{!}}{{!}}Flag to indicate if Last Agent Routing is enabled for the Service
{{!}}-
{{!}}{{!}}Last Agent Routing Time Out
{{!}}{{!}}Time out used to wait for the last agent.
{{!}}-
{{!}}{{!}}Basic skill
{{!}}{{!}}Basic skill required for this call
{{!}}-
{{!}}{{!}}Supplementary skill
{{!}}{{!}}Supplementary skill for this call.
{{!}}-
{{!}}{{!}}Supplementary skill timeout
{{!}}{{!}}Timeout to wait for an agent with the supplementary skill.
{{!}}-
{{!}}{{!}}Skill Level Targets 1-3
{{!}}{{!}}Skill level thresholds to define the primary, secondary and tertiary target. The skill level defined provides the minimum skill level for the corresponding target.
{{!}}-
{{!}}{{!}}Timeout 1,2
{{!}}{{!}}Timeouts to wait for the primary and secondary target.
{{!}}-
{{!}}{{!}}In Queue Messages and Music
{{!}}{{!}}Parameters to define the in busy treatments as described in chapter Busy Treatment.
{{!}}}

====Reporting Parameters====
The following five business parameters represent reporting categories and are completely customizable to your business model. You can assign different combinations of these parameters to each of your Inbound and Distribution parameter groups, to distinguish them in reporting and enable you to identify the unique properties of the parameter group.
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Department
{{!}}{{!}}Business organization used as a category for reporting
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}A business flow used as a category in reporting
{{!}}-
{{!}}{{!}}Product
{{!}}{{!}}A product or product group used in reporting
{{!}}-
{{!}}{{!}}Service
{{!}}{{!}}Business categories typically used as the top level of the call steering menu choices
{{!}}}
|DistributionImageFlow={{SMART DistributionImageFlow
|DistributionFlowIntro=====Main Distribution Flow====
|DistributionImage=https://www.lucidchart.com/documents/edit/e5947052-7250-42e7-9121-a49817f763e3/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}The customer calls one of the numbers of the contact center.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}The IVR determines the type of request (or service) and the customer ID (out of scope for this use case).
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}Genesys performs a check if the customer calls within the business hours for his requested service. The call may be: Within business hours/ After hours/ On special days (e.g. public holidays). In the last two cases, a corresponding announcement is played. The caller is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Genesys performs a check if an Emergency Condition is activated for the call. In this case, a corresponding announcement is played and the call is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}The expected wait time is calculated. If the expected wait time is beyond a configured threshold, a corresponding announcement is played and the call is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}A quality message is played to satisfy compliance requirements.
{{!}}-
{{!}}{{!}}7
{{!}}{{!}}Up to two special messages are played which depend on the type of request and the customer context.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Expected Wait Time Check====
|DistributionImage=https://www.lucidchart.com/documents/edit/8a81a389-dc26-4c83-b079-e469e9403104/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}Genesys calculates the Expected Waiting Time for the call.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}If the EWT is beyond a configurable threshold, the flow returns to the main flow to determine further processing.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}The Expected Wait Time is announced to the customer based on predefined intervals and pre-recorded announcements.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Targeting====
|DistributionImage=https://www.lucidchart.com/documents/edit/1d07ada0-6a1c-41ff-9784-5e7fdbbad52e/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}Genesys determines if Last Agent Routing is activated for the call (configurable by type of request and context data, such as customer segment).
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}If Last Agent Routing is activated, Genesys verifies if the customer has spoken to an agent for the current type of request within a configurable time period. In case of a matching entry, Genesys attempts to distribute to this agent. After a configurable timeout the call continues with the distribution to the skill.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}Genesys calculates the Expected Wait Time (EWT) for the call based on a distribution to the primary target group of all agents being able to handle the service (without any supplementary skill). If the EWT is above a configurable threshold, the routing logic immediately continues with the secondary target group.
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Genesys checks if a supplementary skill is required based on the customer context data.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}In this case, Genesys queues the call for all agents within the primary target group who also have the supplementary skill. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the full primary target group.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}Genesys targets all agents within the primary target group. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the secondary target group.
{{!}}-
{{!}}{{!}}7
{{!}}{{!}}Genesys targets all agents within the secondary target group. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the tertiary target group.
{{!}}-
{{!}}{{!}}8
{{!}}{{!}}Genesys targets all agents within the tertiary target group until an agent becomes available.
{{!}}-
{{!}}{{!}}9
{{!}}{{!}}When an agent becomes available, Genesys distributes the call to this agent.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Conversation====
|DistributionImage=https://www.lucidchart.com/documents/edit/36f7333a-d340-4b4a-8737-7d9aad8e87ee/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}When the call is distributed to the agent, all relevant information on the call and the customer context is displayed at the agent workspace.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}The agent handles the customer request.
{{!}}{{!}}.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}The customer may not have identified and verified upfront, but his request may require identification and potentially verification. In this case, the agent can handle this manually via a third party system (outside of the scope of this use case).
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Once the customer is identified (and verified), the agent can update the customer Id and Verification status in Genesys. The customer context is retrieved from Genesys and displayed to the agent.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}After the conversation, the agent can set the call outcome including the information whether he acted on a specific lead (if part of the customer’s context data). This information is used for reporting purposes.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}Additionally, the information is updated in Context Services to avoid that the customer is presented with the same lead when he calls again.
{{!}}}
}}
|DistributionLogic=====Call Qualification & Customer Identification (outside of scope of this use case)====
As a prerequisite for this use case call qualification and customer identification is handled by an IVR application upfront of the start of this use cases. This IVR application is outside the scope of this use case.Use case CE7 - Effective Identification & Validation in IVR can be used for this functionality.

The assumption is that Genesys receives the following information from the IVR:
* Type of Request / Service (either via DTMF, natural language recognition or IVR intelligence).
* Caller language
* Caller identification
** Information on the status of the identification:
*** Anonymous
*** Identification provided
*** Identification and Verification (ID&V) provided
** Customer ID
*** the customer ID might be any ID as used by the organization which identifies the customer
*** Alternatively the CLI is used for customer identification, however this is less reliable

This input is used to determine the parameters for the specific customer call.

'''Remark on naming convention in this document:'''

"Type of request/service" is the mapping of a customer call to his need by using an IVR prequalification like DTMF menu. Therefore it may be more granular than a published service number for the contact center, or a department within the contact center (e.g. Sales, Billing). The latter is sometimes also referred as service within some organizations. However, in this document, "service" is used interchangeably with "type of request" and referring to the more granular definition.
|SellableItems=CIM, CIM (HA), Interaction Workspace, Genesys Infomart, Genesys Infomart - HA (optional), Genesys Interactive Insights, SIP Interaction, SIP Interaction HA (optional), SIP Business Continuity (Optional), SIP Qualification & Parking, SIP Qualification and Parking HA (Optional), GVP, GVP HA (optional), ASR and TTS (Optional), Conversation Manager, Intelligent Automation Omnichannel Self-Service (Optional, Intelligent Automation Omnichannel Self-Service - HA (Optional)
|CloudAssumptions=This use case is not supported in Cloud.
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:
* Full set of capabilities are available.
|CustomerAssumptions=* The IVR application to determine the type of request and customer ID is not part of this use case and has to be provided separately.
** Alternatively, SIP Qualification and Parking with a script controlled by routing are used if full GVP application is not required. This functionality is also not included within the use case.
* All announcements are to be provided by the customer
* A process to upload and update customer data within Genesys Context Services needs to be set up.
|Optional=CE07
|SMART_PremiseAssumptions={{SMART PremiseAssumptions
|Premise_Assumption=Implementation based on SIP Server (SIP Voice Blueprint)
}}{{SMART PremiseAssumptions
|Premise_Assumption=Routing parameters are configured through GAX operational parameter groups or Genesys Rules Engine, which are referenced in the underlying strategy / routing application
}}{{SMART PremiseAssumptions
|Premise_Assumption=Genesys Infomart and Interactive Insights is used for historical reporting
}}{{SMART PremiseAssumptions
|Premise_Assumption=WDE is used as agent desktop
}}{{SMART PremiseAssumptions
|Premise_Assumption=Pulse is used for real-time reporting.
}}
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is not supported in Cloud.
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=version 1.1.3
}}
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=====Context Data====
When a call is distributed to an agent the following data is displayed:
* Context Services Data as defined in chapter “Context Service Data”
* Customer language
* Time in IVR and in Queue
* ID & V Status
* ID or ID & V required for service?
* Indicator if a special promotional message has been played

====Call Outcome / Disposition Code====
If a lead is presented to the agent, he can classify the outcome within the agent desktop. This outcome includes the information whether the lead has been actioned. The data if a lead has been actioned is stored in Context Services to enable rules that it is not presented to an agent again.

Additionally, the call outcome is used for reporting purposes.

Up to 10 different call outcomes / disposition codes are configured.
====ID&V====
The agent is able to handle manual Identification and (optionally) Verification if required for the specific customer request. The ID&V is handled in an application outside of Genesys. However, it is possible for the agent to update the ID&V status of the call. In this case, the call data is updated and if the customer has not been identified before, the customer-related data from context services is retrieved and displayed to the agent. See also section “Conversation”.
====General Requirements====

* Agents can transfer calls to other individual agents as out-of-the-box functionality.
* Transfer: See chapter “Transfer”
* Configuration of not-ready reason codes (e.g Admin Work, Lunch, Meeting, Pause, RONA).
|RealTimeReporting=''Pulse''' is a Genesys Administrator Extension (GAX) plug-in application that offers personalized dashboards based on specific functional, geographical or organizational needs. Pulse dashboards present information using graphical “widgets” that can be viewed as graphs or tables, showing information about specific key performance indicators, such as service level, interactions handled, and the average handle time.

With Pulse you can:
* Monitor the current state and activity of Contact Center objects to help make decisions about staffing, scheduling and call routing strategies.
* Create widgets from predefined and user-defined templates for a fast and easy text or graphical presentation of selected or user-defined object statistics.
* Predefined Inbound templates
** Agent KPIs
** Agent Group Status
** Agent Login
** Queue KPIs
|HistoricalReporting=Interactive Insights out-of-the-box reports will be used to:
* Assess the day-to-day operations of the contact center resources for the routing and handling of interactions.
* Measure the effectiveness of the Engagement Rules and efficiency of the use case with the Customer Perspective Report and the Interaction Volume Customer Segment Report.
* Dimension the out-of-the-box aggregate based GI2 reports with Routing Parameters including the Engagement Rules and the Disposition codes.
* With Disposition codes calculate the conversion success rate
* Evaluate resource performance with a variety of reports for Agents and Detail facts
There are 40+ reports available, potential reports to confirm the benefits for this use case are being met are as follows.'''Agent KPIs'''enable the organization to measure and filter InfoMart data based on the interaction-related activities that are conducted by active agents.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Sample Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Activity
{{!}}{{!}}Examples for available KPIs:
* Abandoned Inviting
* Accepted
* Conference Initiated
* Consult Initiated
* Engage Time
* Handle Time
* Hold
* Invite
* Offered
* Rejected
* Wrap
{{!}}{{!}}Agent interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the agent.
{{!}}-
{{!}}{{!}}InteractionState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Engage Time
* % Hold Time
* % Invite Time
* % Wrap In Time
* Accepted
* Consult Received Accepted
* Engage Time
* Not Accepted
* Not Ready In Time
* Offered
{{!}}{{!}}Agent interaction level data.
Measures are attributed to each reporting interval in which agents handle the interactions and durations are clipped at interval boundaries.
{{!}}-
{{!}}{{!}}SummarizedState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Busy Time
* % Not Ready Reason Time
* % Occupancy
* % Ready Time
* % Wrap Time
* Active Time
* Not Ready
* Not Ready Reason Time
* Wrap
{{!}}{{!}}Agent summarized data for a session.
Measures are attributed to each reporting interval in which agents handle the calls, and durations are clipped at interval boundaries.
{{!}}}
'''Queue KPI'''enable the organization to measure and filter InfoMart data based on the queue(s) through which customer interactions pass or the Business Attributes associated with the interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Queue KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Queue
{{!}}{{!}}Examples for available KPIs:
* Period
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Abandoned Waiting
* Abandoned Time
* Not Accepted
* Redirected
* Accepted Agent
* Accepted Agent in Threshold
* Accept Time Agent
* % Service Level
* Invite Time
* Engage Time
* Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}Queue interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the queue.
{{!}}}
'''Business Attribute KPI'''enable the organization to measure and filter Info Mart data based on the business attributes that are associated with the customer interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the Contact Center.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Business Attributes KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Business Attributes
{{!}}{{!}}Examples for available KPIs:
* Period
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Entered Obj
* Abandoned Waiting
* Not Accepted
* Redirected
* Accepted
* Accepted in Threshold
* Accept Time Agent
* % Service Level
* Engage Time
* Handle Time
* Avg Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}Business Attribute interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered by business attribute.
{{!}}}
'''Accepted Agent'''enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions pass in which agents accept or answer the interaction. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Accepted Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Accepted Agent
{{!}}{{!}}Available KPIs:
* Queue Name
* Mediaedia Type
* Customerustomer Segment
* Service Type
* Service Subtype
* Accepted Waiting 1..20 Thresholds
* % Accepted Waiting 1..20 Thresholds
{{!}}{{!}}Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were accepted as well as the percentage of interactions that were accepted within a specific set of time ranges.
{{!}}}
'''Abandoned Waiting'''enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions abandoned while waiting to be answered. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Abandoned Waiting KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Abandoned Waiting
{{!}}{{!}}Available KPIs:
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Abandoned Waiting 1..20 Thresholds
* % Abandoned Waiting 1..20 Thresholds
{{!}}{{!}}Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were abandoned as well as the percentage of interactions that were abandoned, while the interactions were queued at a specific queue for a specific set of time ranges. The time ranges are configured within the InfoMart Application options.
{{!}}}
'''Interaction Details'''enable the organization to track low-level interaction details.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Interaction Detail KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Handling Attempt
{{!}}{{!}}Available KPIs:
* Interaction ID
* Connection ID
* Media Type
* Customer ID
* Customer Segment
* Service Type
* Service Subtype
* Business Result
* Interaction Type
* Start Timestamp
* End Timestamp
* Routing Target
* Resource Role
* Role Reason
* Technical Result
* Result Reason
* Queue Time
* Route Point Time
* Total Duration
* Customer Talk Time
* Customer Hold Time
* Customer Wrap Time
* ....
{{!}}{{!}}Handling Attempt detail interaction level data.

Handling Attempt details of interactions that are stored mostly in the INTERACTION_RESOURCE_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}Available KPIs:
* Agent/Queue
* Connection ID
* Media Type
* Customer ID
* Interaction ID
* Interaction Type
* Interaction Subtype
* Segment ID
* Source
* Target
* Technical Result Resource Role
* Technical Result Role Reason
* Technical Result
* Technical Result Reason
* Duration
{{!}}{{!}}Flow detail interaction level data.

Interaction-flow details of interactions that are stored mostly in the INTERACTION_FACT, INTERACTION_RESOURCE_FACT, and MEDIATION_SEGMENT_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Transfer
{{!}}{{!}}Available KPIs:
* Interaction ID
* Media Type
* Source
* Source Service Type
* Source Service Subtype
* Source Customer Segment
* Source Last Queue
* Source Technical Result
* Source Customer Engage Time
* Source Customer Hold Time
* Source Customer Wrap Time
* Source Queue Time
* Target
* Target Service Type
* Target Service Subtype
* Target Customer Segment
* Target Last Queue
* Target Technical Result
* Target Customer Engage Time
* Target Customer Hold Time
* Target Customer Wrap Time
* Target Queue Time
* ....
{{!}}{{!}}Transfer detail interaction level data.

Interaction details identifying the source and destination of transferred and conference interactions.
{{!}}}
|PainPoints=* Cannot recognize repeat customers
* Unable to use context to enable a finer granularity in matching the customer to the best agent in the target agent group
* Calls with long handle times, with customers having to recap previous interactions
* Missed service levels within or across channels
* Increasing interaction abandonment and repeat contacts
|DesiredState=* Recognize customers in all touchpoints and channels, and match callers with the same agent with whom they previously spoke
* Carry context and orchestrate interactions between channels
* Offer self-service and call back options
* Inform customers of expected wait/process times
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Routing calls to the same agent that the customer previously spoken to may increase the chances of completing a sale.
}}{{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Using customer context enables routing to agents who can handle the customer's specific query more quickly.
}}{{SMART Benefits
|UCBenefitID=Reduced Interaction Transfers
|UCBenefit=Routing calls to agents based on customer context reduces the need for internal transfers.
}}{{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Routing calls based on customer context reduces familiarisation time and improves customer experience.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Enabling agents to handle queries more quickly improves employee utilization.
}}
|UCOverview=This functional use case has been created to enable companies to use Advanced Genesys Routing capabilities to improve customer experience by routing voice interactions to the best fit agent based on the type of request and customer context. Detailed routing behaviour is driven by configuration parameters and rules, therefore providing a highly flexible framework to adapt to specific organization needs. The base logic is based on experience and best practices from previous implementations and therefore enables the organization to use best practice scenarios to enable fast realization of benefits.
|UCSummary=A customer call is qualified within the IVR. The customer is identified and authenticated (if needed) within the IVR menu (not part of this use case). The customer ID is used to retrieve context data on the customer from Genesys Context Services. Based on his choices within the IVR and on the context data, he is routed to the best agent able to serve his request and potentially additional services, e.g. to realize up-sell potential. All relevant context information is displayed to the agent to enable high-quality service delivery. The logic of this use case is business rules driven and therefore flexible to changing needs and business environments.
}}

UseCases/Current/GenesysEngage-onpremises/CE02

2018-10-25T11:58:20Z

PLeprieult:

{{SMART UseCase
|BusinessImageFlow={{SMART BusinessImageFlow
|BusinessFlow=The following flow describes the use case from the perspective of the main actors, i.e. the customer and the contact center agent. It provides a high-level view of the basic flow. The detailed description of the underlying call flow is described in Chapter “Distribution Logic”.
|BusinessImage=https://www.lucidchart.com/documents/edit/ce874ffd-90f0-4ccb-baa6-970732d1c52e/0
|BusinessFlowDescription=# The customer calls one of the numbers of the contact center.
# He is routed to an IVR application which is determining the service type and also performs an Identification and (optionally) Verification of the customer. This functionality is provided outside of the scope of this use case, it is assumed that the information on the requested service and customer identification is passed on to be used within this use case. The use case CE7 - Effective Identification and Validation in IVR can be used for this functionality. Alternatively, customer CLI is used for Identification.
# If the customer calls outside of out-of-office hours or if an emergency situation is in progress, an announcement is played. After this the caller may be reconnected or diverted to another number inside or outside of Genesys.
# Genesys retrieves context data on the customer based on the customer identification.#If the contact center is open the routing parameters for this particular call is set based on the type of request and the customer context. This will enable flexible and personalized call handling.
# The Expected Wait Time (EWT) for the customer is calculated and is announced to the customer (optional). If the EWT exceeds a specific threshold, an announcement is played and the caller is disconnected or routed to another number inside or outside of Genesys (optional).
# Additional announcements are played to the customer. These announcement are based on the customer context. Examples include: Quality announcements/Special promotions-offers for the customer/Announcements for potential self-service options
# If the customer has been calling recently for the same type of request, Genesys can route to the last agent (configurable based on type of request and customer context). In case this agent is not logged in or not available for this call within a specified time out, the call is routed to the requested skill
# The call is distributed to the best agent who:
#* Has the base skill(s) to handle the original request
#* Has the supplementary skill(s) determined by the customer context (optional). Examples include:Skills to upsell a defined product / service to the customer or specific empathy skills based on the customer segment or demographic
#* A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill and / or reducing the skill level on the base skill if the call cannot be distributed within specific timeouts.
# Once the call is distributed to an agent, the call context information is displayed to the agent. As an example, the agent is able to see any special offer or promotion for the customer, so he can start the relevant information. The agent handles the customer request and any potential up-/cross-sell opportunity.
# After the conversation with the customer, the agent records the outcome of the call for reporting purposes e.g. if he has acted on the presented lead
}}
|BusinessLogic=====Emergency Check====
Emergency mode activation is enabled at three levels: Global, Service (Type of Request) and Queue. The emergency mode is not only checked at the beginning of a call, but is constantly monitored during call queuing. If an emergency flag is set for a queued call, the corresponding emergency announcement is played, and the configured action applies to the call (disconnect or deflect to another number within or external to Genesys).

Furthermore, Genesys runs a parallel stream to continually check if agents are logged onto the platform. If no agents are detected, then an emergency mode is automatically activated.
====EWT Announcements====
Announcement of Expected Wait Time to customers is handled based on predefined recordings. It is a good practice to announce expected wait times approximately to not jeopardize customer expectation. Six thresholds are configured which can trigger different announcements. Default values are: 60, 120, 180, 300, 600 and 1200 seconds. The announcement text should match the threshold.
====Last Agent Routing====
The last agent(s) a customer spoke to is stored within Context Services (part of Universal Contact History) including the base skill which was required for the corresponding service. When a customer calls the contact center for the same service and Last Agent Routing is enabled, Genesys checks in Context Services for a recent contact, not older than a configurable threshold, handled by an agent with the required skill. The corresponding agent is used for Last Agent Routing.

In case of multiple matches, the most recent entry is used.
====Busy Treatment====
Messages and Music are played for queuing calls. It is possible to configure up to six messages with music treatment in between. The first two messages and associated music treatments are played once, the remaining 4 messages and music treatments are looped until the call is answered or abandoned.
====Skill Model====
=====Skill types=====
The skill model, used for distribution, is based on three logically different skill types which define attributes and knowledge of the agents:

=====Basic skill=====
This skill is required to handle a specific type of request or service. One basic skill is required for each call for the distribution of calls to agents.
=====Language skill=====
This skill type determines the language in which a call shall be answered. The requested language is provided via the IVR. If no language is provided, a default language is used. One language skill is required for the distribution of calls to agents.
=====Supplementary skill=====
Genesys Routing utilizes supplementary skills for enhanced routing logic and personalization. Supplementary skills are defined by customer specific context data.

The following provides an example:
* A customer calls the service hotline for "Account Transactions."
* He successfully identifies and authenticates within the IVR. The corresponding data are passed to Genesys.
* The caller's profile within Context Services indicates that the caller is eligible for a Platinum Credit Card up-sell.
* In this case, the call should ideally be routed to an agent with the base skill "Account_Handling" and the supplementary skill "Up-Sell" to ensure that he can handle both the original request and successfully convert the up-sell opportunity for this customer.

=====Skill level=====
Each agent has one or more skills associated to their profile and a skill level associated to each base skill, referred to in this document as proficiencies. The skill level is used to define primary, secondary and tertiary targets within the routing logic described in section "Targeting". The targets are defined as follows:
* Primary target = Agents with base skill level > N & language skill > 0
* Secondary target = Agents with base skill level > M & language skill > 0
* Tertiary target = Agents with base skill level > P & language skill > 0

N, M, and P are configurable based on request type and customer context.
====Priority Model====
Different priorities are set for calls according to business value of the type of request. If priorities are set and an agent becomes available, Genesys distributes the call with the highest priority matching the agent's skills. This is specifically relevant if the agent can receive interactions for different types of request. The priority of a call is increased over time to make sure that low-priority calls are still distributed to an agent after a potential longer waiting time (priority tuning). Priority tuning is configured via the following parameters:
* Priority start (the starting priority)
* Priority increment (the amount to increase the priority after the interval time)
* Priority interval (the time between priority increases)
* Priority limit (the maximum priority)

These values are configurable by type of request and by customer context.

In addition, a priority mark-up is configured for customers who have previously completed IDV or ID within the IVR to account for their additional time within the IVR compared to customers who did directly drop out into the queue. The priority mark-up for customers who attempted / complete IDV and ID is relative to the amount of time it takes to complete the IDV and ID verification application within the IVR.

Transferred calls and RONA calls can also get a higher priority assigned.
====Transfer====
The agents can transfer calls to defined internal agent groups or business lines (route points). The routing logic defined for these route points is similar to the routing logic defined above (without initial announcements). Only transfer route points are visible to the agent in WDE.
====Additional functionality====

* RONA-functionality: If an agent does not accept the call, the call is automatically put back into the distribution flow after a time out. The agent is set to not-ready.
* This use case can be combined with other non-voice use cases. Blending is possible. The configuration of priority values need to be synchronized with priority settings for other media types to allow an ordering of interaction within the universal queue corresponding to business requirements. Capacity rules will be configured for the agents / agent groups to define what interactions is handled in parallel (if any).

====Context Service Data====
Customer Context is stored within Genesys Context Service as part of the Universal Customer History Server. The data is provided by the organization. A regular update process has to be set up. Instructions to map the organization's specific data with the data stored in Genesys need to be determined. The following data scheme provides flexibility to map specific organizational data with data to be used within Genesys. The data is used for routing rules or for display of the agent desktop. Context data related to a list is only used if the time and date of the call is within the List Stop and List Start data. The following table shows the available data and how these are used:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Attribute'''
{{!}}{{!}}'''Definition'''
{{!}}{{!}}'''Agent Desktop'''
{{!}}{{!}}'''Routing Rules'''
{{!}}-
{{!}}{{!}}Customer ID
{{!}}{{!}}Unique identifier of the customer
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Name
{{!}}{{!}}Customer Name
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Segment
{{!}}{{!}}Customer Segment
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 1
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 2
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 3
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 4
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Customer Data 5
{{!}}{{!}}Additional information on the customer to be used in rules
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}Display Data 1
{{!}}{{!}}Custom Attribute to be displayed at agent desktop
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}Display Data 2
{{!}}{{!}}Custom Attribute to be displayed at agent desktop
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}List Name
{{!}}{{!}}This data is used to indicate that the customer is on a specific list / campaign
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Type
{{!}}{{!}}Type of the list or campaign
{{!}}{{!}}X
{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Start
{{!}}{{!}}When actions for a list / campaign starts
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List Stop
{{!}}{{!}}When actions for a list / campaign stops
{{!}}{{!}}

{{!}}{{!}}X
{{!}}-
{{!}}{{!}}List pop message
{{!}}{{!}}Message to be displayed to agent
{{!}}{{!}}X
{{!}}{{!}}

{{!}}-
{{!}}{{!}}List actioned
{{!}}{{!}}Indicates if the list / campaign has been already actioned. If the list / campaign has been actions, no list data is displayed to an agent.
{{!}}{{!}}

{{!}}{{!}}X
{{!}}}

====Parameters available per type of request / service====
The following lists the business parameters which are configurable by service. These are configured by Genesys Administrator Extension. Please note that the list is not exhaustive as additional parameters for technical settings might be required. It also does not reflect the technical realization and naming conventions to be used. Also some of the parameters are combined for ease of readability. The list is intended for business readers to give an overview of the flexibility in the configuration of the routing logic:

{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Service Name
{{!}}{{!}}Name of the service.
{{!}}-
{{!}}{{!}}Enable Rules
{{!}}{{!}}Flag to indicate if rules are used for the service. If rules are not enabled for the service, the default parameter settings within GAX are used.
{{!}}-
{{!}}{{!}}Service Emergency Flag
{{!}}{{!}}Flag to set emergency status for the service.
{{!}}-
{{!}}{{!}}Open hours
{{!}}{{!}}Sets the opening hours of the service.
{{!}}-
{{!}}{{!}}Special Day
{{!}}{{!}}A list of exceptions to the regular open hours, for a holiday or other reason.
{{!}}-
{{!}}{{!}}After Hour Message
{{!}}{{!}}Message to be played if the call is out of business hours.
{{!}}-
{{!}}{{!}}Special Day Message
{{!}}{{!}}Message to be played if the call is on a special day.
{{!}}-
{{!}}{{!}}Emergency Message
{{!}}{{!}}Message to be played in emergency situations.
{{!}}-
{{!}}{{!}}EWT flag
{{!}}{{!}}Flag to determine if EWT shall be announced to a customer.
{{!}}-
{{!}}{{!}}EWT Thresholds
{{!}}{{!}}6 Thresholds to activate different EWT announcements (see chapter "EWT Announcements").
{{!}}-
{{!}}{{!}}EWT Announcements
{{!}}{{!}}6 pre-recorded EWT announcements corresponding to the 6 thresholds above.
{{!}}-
{{!}}{{!}}EWT Breach Threshold
{{!}}{{!}}Threshold to determine if a call is queued (see chapter "Expected Wait Time Checkâ€).
{{!}}-
{{!}}{{!}}IDV Type
{{!}}{{!}}Level of ID&V required for the type of request. Values are "None", "ID" or "ID&V". This value is displayed to the agent.
{{!}}-
{{!}}{{!}}Quality Message
{{!}}{{!}}The quality message to be announced to the customer (see chapter "Main Flow").
{{!}}}

====Parameters available per customer context and type of request / service====
The following lists the business parameters which are configurable by service and customer context. Default values for these parameters are configured by Genesys Administrator Extension per service. These base parameters are overwritten by parameters defined by rules using additionally the customer context. These rules are configured in Genesys Rules Engine. Please note that the list is not exhaustive as additional parameters for technical settings might be required. It also does not reflect the technical realization and naming conventions to be used. The list is intended to give business users an overview of the flexibility in the configuration of the routing logic:
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Special Message 1&2
{{!}}{{!}}The special messages to be played after the quality message (See chapter “Main Flow”).
{{!}}-
{{!}}{{!}}Last Agent Routing enabled?
{{!}}{{!}}Flag to indicate if Last Agent Routing is enabled for the Service
{{!}}-
{{!}}{{!}}Last Agent Routing Time Out
{{!}}{{!}}Time out used to wait for the last agent.
{{!}}-
{{!}}{{!}}Basic skill
{{!}}{{!}}Basic skill required for this call
{{!}}-
{{!}}{{!}}Supplementary skill
{{!}}{{!}}Supplementary skill for this call.
{{!}}-
{{!}}{{!}}Supplementary skill timeout
{{!}}{{!}}Timeout to wait for an agent with the supplementary skill.
{{!}}-
{{!}}{{!}}Skill Level Targets 1-3
{{!}}{{!}}Skill level thresholds to define the primary, secondary and tertiary target. The skill level defined provides the minimum skill level for the corresponding target.
{{!}}-
{{!}}{{!}}Timeout 1,2
{{!}}{{!}}Timeouts to wait for the primary and secondary target.
{{!}}-
{{!}}{{!}}In Queue Messages and Music
{{!}}{{!}}Parameters to define the in busy treatments as described in chapter Busy Treatment.
{{!}}}

====Reporting Parameters====
The following five business parameters represent reporting categories and are completely customizable to your business model. You can assign different combinations of these parameters to each of your Inbound and Distribution parameter groups, to distinguish them in reporting and enable you to identify the unique properties of the parameter group.
{{{!}} class="wikitable"
{{!}}-
{{!}}{{!}}'''Name'''
{{!}}{{!}}'''Description'''
{{!}}-
{{!}}{{!}}Department
{{!}}{{!}}Business organization used as a category for reporting
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}A business flow used as a category in reporting
{{!}}-
{{!}}{{!}}Product
{{!}}{{!}}A product or product group used in reporting
{{!}}-
{{!}}{{!}}Service
{{!}}{{!}}Business categories typically used as the top level of the call steering menu choices
{{!}}}
|DistributionImageFlow={{SMART DistributionImageFlow
|DistributionFlowIntro=====Main Distribution Flow====
|DistributionImage=https://www.lucidchart.com/documents/edit/e5947052-7250-42e7-9121-a49817f763e3/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}The customer calls one of the numbers of the contact center.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}The IVR determines the type of request (or service) and the customer ID (out of scope for this use case).
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}Genesys performs a check if the customer calls within the business hours for his requested service. The call may be: Within business hours/ After hours/ On special days (e.g. public holidays). In the last two cases, a corresponding announcement is played. The caller is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Genesys performs a check if an Emergency Condition is activated for the call. In this case, a corresponding announcement is played and the call is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}The expected wait time is calculated. If the expected wait time is beyond a configured threshold, a corresponding announcement is played and the call is either disconnected or deflected to a different number inside or outside of Genesys for further processing.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}A quality message is played to satisfy compliance requirements.
{{!}}-
{{!}}{{!}}7
{{!}}{{!}}Up to two special messages are played which depend on the type of request and the customer context.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Expected Wait Time Check====
|DistributionImage=https://www.lucidchart.com/documents/edit/8a81a389-dc26-4c83-b079-e469e9403104/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}Genesys calculates the Expected Waiting Time for the call.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}If the EWT is beyond a configurable threshold, the flow returns to the main flow to determine further processing.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}The Expected Wait Time is announced to the customer based on predefined intervals and pre-recorded announcements.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Targeting====
|DistributionImage=https://www.lucidchart.com/documents/edit/1d07ada0-6a1c-41ff-9784-5e7fdbbad52e/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}Genesys determines if Last Agent Routing is activated for the call (configurable by type of request and context data, such as customer segment).
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}If Last Agent Routing is activated, Genesys verifies if the customer has spoken to an agent for the current type of request within a configurable time period. In case of a matching entry, Genesys attempts to distribute to this agent. After a configurable timeout the call continues with the distribution to the skill.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}Genesys calculates the Expected Wait Time (EWT) for the call based on a distribution to the primary target group of all agents being able to handle the service (without any supplementary skill). If the EWT is above a configurable threshold, the routing logic immediately continues with the secondary target group.
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Genesys checks if a supplementary skill is required based on the customer context data.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}In this case, Genesys queues the call for all agents within the primary target group who also have the supplementary skill. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the full primary target group.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}Genesys targets all agents within the primary target group. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the secondary target group.
{{!}}-
{{!}}{{!}}7
{{!}}{{!}}Genesys targets all agents within the secondary target group. If an agents becomes available before the configurable timeout is reached, the call is distributed to this agent. Otherwise, the target is expanded to the tertiary target group.
{{!}}-
{{!}}{{!}}8
{{!}}{{!}}Genesys targets all agents within the tertiary target group until an agent becomes available.
{{!}}-
{{!}}{{!}}9
{{!}}{{!}}When an agent becomes available, Genesys distributes the call to this agent.
{{!}}}
}}{{SMART DistributionImageFlow
|DistributionFlowIntro=====Conversation====
|DistributionImage=https://www.lucidchart.com/documents/edit/36f7333a-d340-4b4a-8737-7d9aad8e87ee/0
|DistributionFlowDescription={{{!}} border="1"
{{!}}-
!{{!}}Nr.
!{{!}}Description
{{!}}-
{{!}}{{!}}1
{{!}}{{!}}When the call is distributed to the agent, all relevant information on the call and the customer context is displayed at the agent workspace.
{{!}}-
{{!}}{{!}}2
{{!}}{{!}}The agent handles the customer request.
{{!}}{{!}}.
{{!}}-
{{!}}{{!}}3
{{!}}{{!}}The customer may not have identified and verified upfront, but his request may require identification and potentially verification. In this case, the agent can handle this manually via a third party system (outside of the scope of this use case).
{{!}}-
{{!}}{{!}}4
{{!}}{{!}}Once the customer is identified (and verified), the agent can update the customer Id and Verification status in Genesys. The customer context is retrieved from Genesys and displayed to the agent.
{{!}}-
{{!}}{{!}}5
{{!}}{{!}}After the conversation, the agent can set the call outcome including the information whether he acted on a specific lead (if part of the customer’s context data). This information is used for reporting purposes.
{{!}}-
{{!}}{{!}}6
{{!}}{{!}}Additionally, the information is updated in Context Services to avoid that the customer is presented with the same lead when he calls again.
{{!}}}
}}
|DistributionLogic=====Call Qualification & Customer Identification (outside of scope of this use case)====
As a prerequisite for this use case call qualification and customer identification is handled by an IVR application upfront of the start of this use cases. This IVR application is outside the scope of this use case.Use case CE7 - Effective Identification & Validation in IVR can be used for this functionality.

The assumption is that Genesys receives the following information from the IVR:
* Type of Request / Service (either via DTMF, natural language recognition or IVR intelligence).
* Caller language
* Caller identification
** Information on the status of the identification:
*** Anonymous
*** Identification provided
*** Identification and Verification (ID&V) provided
** Customer ID
*** the customer ID might be any ID as used by the organization which identifies the customer
*** Alternatively the CLI is used for customer identification, however this is less reliable

This input is used to determine the parameters for the specific customer call.

'''Remark on naming convention in this document:'''

"Type of request/service" is the mapping of a customer call to his need by using an IVR prequalification like DTMF menu. Therefore it may be more granular than a published service number for the contact center, or a department within the contact center (e.g. Sales, Billing). The latter is sometimes also referred as service within some organizations. However, in this document, "service" is used interchangeably with "type of request" and referring to the more granular definition.
|SellableItems=CIM, CIM (HA), Interaction Workspace, Genesys Infomart, Genesys Infomart - HA (optional), Genesys Interactive Insights, SIP Interaction, SIP Interaction HA (optional), SIP Business Continuity (Optional), SIP Qualification & Parking, SIP Qualification and Parking HA (Optional), GVP, GVP HA (optional), ASR and TTS (Optional), Conversation Manager, Intelligent Automation Omnichannel Self-Service (Optional, Intelligent Automation Omnichannel Self-Service - HA (Optional)
|CloudAssumptions=This use case is not supported in Cloud.
|PremiseAssumptionsAdditional_Sales=Capabilities Assumption:
* Full set of capabilities are available.
|CustomerAssumptions=* The IVR application to determine the type of request and customer ID is not part of this use case and has to be provided separately.
** Alternatively, SIP Qualification and Parking with a script controlled by routing are used if full GVP application is not required. This functionality is also not included within the use case.
* All announcements are to be provided by the customer
* A process to upload and update customer data within Genesys Context Services needs to be set up.
|Optional=CE07
|SMART_PremiseAssumptions={{SMART PremiseAssumptions
|Premise_Assumption=Implementation based on SIP Server (SIP Voice Blueprint)
}}{{SMART PremiseAssumptions
|Premise_Assumption=Routing parameters are configured through GAX operational parameter groups or Genesys Rules Engine, which are referenced in the underlying strategy / routing application
}}{{SMART PremiseAssumptions
|Premise_Assumption=Genesys Infomart and Interactive Insights is used for historical reporting
}}{{SMART PremiseAssumptions
|Premise_Assumption=WDE is used as agent desktop
}}{{SMART PremiseAssumptions
|Premise_Assumption=Pulse is used for real-time reporting.
}}
|SMART_CloudAssumptions={{SMART CloudAssumptions
|Cloud_Assumption=This use case is not supported in Cloud.
}}
|SMART_HybridAssumptions={{SMART HybridAssumptions
|Hybrid_Assumption=version 1.1.2
}}
|CustomerInterfaceRequirements=N/A
|AgentDeskRequirements=====Context Data====
When a call is distributed to an agent the following data is displayed:
* Context Services Data as defined in chapter “Context Service Data”
* Customer language
* Time in IVR and in Queue
* ID & V Status
* ID or ID & V required for service?
* Indicator if a special promotional message has been played

====Call Outcome / Disposition Code====
If a lead is presented to the agent, he can classify the outcome within the agent desktop. This outcome includes the information whether the lead has been actioned. The data if a lead has been actioned is stored in Context Services to enable rules that it is not presented to an agent again.

Additionally, the call outcome is used for reporting purposes.

Up to 10 different call outcomes / disposition codes are configured.
====ID&V====
The agent is able to handle manual Identification and (optionally) Verification if required for the specific customer request. The ID&V is handled in an application outside of Genesys. However, it is possible for the agent to update the ID&V status of the call. In this case, the call data is updated and if the customer has not been identified before, the customer-related data from context services is retrieved and displayed to the agent. See also section “Conversation”.
====General Requirements====

* Agents can transfer calls to other individual agents as out-of-the-box functionality.
* Transfer: See chapter “Transfer”
* Configuration of not-ready reason codes (e.g Admin Work, Lunch, Meeting, Pause, RONA).
|RealTimeReporting=''Pulse''' is a Genesys Administrator Extension (GAX) plug-in application that offers personalized dashboards based on specific functional, geographical or organizational needs. Pulse dashboards present information using graphical “widgets” that can be viewed as graphs or tables, showing information about specific key performance indicators, such as service level, interactions handled, and the average handle time.

With Pulse you can:
* Monitor the current state and activity of Contact Center objects to help make decisions about staffing, scheduling and call routing strategies.
* Create widgets from predefined and user-defined templates for a fast and easy text or graphical presentation of selected or user-defined object statistics.
* Predefined Inbound templates
** Agent KPIs
** Agent Group Status
** Agent Login
** Queue KPIs
|HistoricalReporting=Interactive Insights out-of-the-box reports will be used to:
* Assess the day-to-day operations of the contact center resources for the routing and handling of interactions.
* Measure the effectiveness of the Engagement Rules and efficiency of the use case with the Customer Perspective Report and the Interaction Volume Customer Segment Report.
* Dimension the out-of-the-box aggregate based GI2 reports with Routing Parameters including the Engagement Rules and the Disposition codes.
* With Disposition codes calculate the conversion success rate
* Evaluate resource performance with a variety of reports for Agents and Detail facts
There are 40+ reports available, potential reports to confirm the benefits for this use case are being met are as follows.'''Agent KPIs'''enable the organization to measure and filter InfoMart data based on the interaction-related activities that are conducted by active agents.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Sample Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Activity
{{!}}{{!}}Examples for available KPIs:
* Abandoned Inviting
* Accepted
* Conference Initiated
* Consult Initiated
* Engage Time
* Handle Time
* Hold
* Invite
* Offered
* Rejected
* Wrap
{{!}}{{!}}Agent interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the agent.
{{!}}-
{{!}}{{!}}InteractionState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Engage Time
* % Hold Time
* % Invite Time
* % Wrap In Time
* Accepted
* Consult Received Accepted
* Engage Time
* Not Accepted
* Not Ready In Time
* Offered
{{!}}{{!}}Agent interaction level data.
Measures are attributed to each reporting interval in which agents handle the interactions and durations are clipped at interval boundaries.
{{!}}-
{{!}}{{!}}SummarizedState & Reason
{{!}}{{!}}Examples for available KPIs:
* % Busy Time
* % Not Ready Reason Time
* % Occupancy
* % Ready Time
* % Wrap Time
* Active Time
* Not Ready
* Not Ready Reason Time
* Wrap
{{!}}{{!}}Agent summarized data for a session.
Measures are attributed to each reporting interval in which agents handle the calls, and durations are clipped at interval boundaries.
{{!}}}
'''Queue KPI'''enable the organization to measure and filter InfoMart data based on the queue(s) through which customer interactions pass or the Business Attributes associated with the interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Queue KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Queue
{{!}}{{!}}Examples for available KPIs:
* Period
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Abandoned Waiting
* Abandoned Time
* Not Accepted
* Redirected
* Accepted Agent
* Accepted Agent in Threshold
* Accept Time Agent
* % Service Level
* Invite Time
* Engage Time
* Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}Queue interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered to the queue.
{{!}}}
'''Business Attribute KPI'''enable the organization to measure and filter Info Mart data based on the business attributes that are associated with the customer interactions. Counts and duration measures are attributed to the reporting interval in which interactions entered the Contact Center.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Business Attributes KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Business Attributes
{{!}}{{!}}Examples for available KPIs:
* Period
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Entered
* Entered Obj
* Abandoned Waiting
* Not Accepted
* Redirected
* Accepted
* Accepted in Threshold
* Accept Time Agent
* % Service Level
* Engage Time
* Handle Time
* Avg Handle Time
* Transfer Initiated Agent
* ….
{{!}}{{!}}Business Attribute interaction level data.

Counts and duration measures are attributed to the reporting interval in which interactions are offered by business attribute.
{{!}}}
'''Accepted Agent'''enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions pass in which agents accept or answer the interaction. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Accepted Agent KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Accepted Agent
{{!}}{{!}}Available KPIs:
* Queue Name
* Mediaedia Type
* Customerustomer Segment
* Service Type
* Service Subtype
* Accepted Waiting 1..20 Thresholds
* % Accepted Waiting 1..20 Thresholds
{{!}}{{!}}Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were accepted as well as the percentage of interactions that were accepted within a specific set of time ranges.
{{!}}}
'''Abandoned Waiting'''enable the organization to measure and filter Info Mart data based on the queue(s) through which customer interactions abandoned while waiting to be answered. Counts and duration measures are attributed to the reporting interval in which interactions entered the queue.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Abandoned Waiting KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Abandoned Waiting
{{!}}{{!}}Available KPIs:
* Queue Name
* Media Type
* Customer Segment
* Service Type
* Service Subtype
* Abandoned Waiting 1..20 Thresholds
* % Abandoned Waiting 1..20 Thresholds
{{!}}{{!}}Service quality data for interactions in Queue.

Gauges service quality by indicating how many interactions were abandoned as well as the percentage of interactions that were abandoned, while the interactions were queued at a specific queue for a specific set of time ranges. The time ranges are configured within the InfoMart Application options.
{{!}}}
'''Interaction Details'''enable the organization to track low-level interaction details.
{{{!}} class="wikitable"
{{!}}-
!{{!}}
!{{!}}Interaction Detail KPIs
!{{!}}Description
{{!}}-
{{!}}{{!}}Handling Attempt
{{!}}{{!}}Available KPIs:
* Interaction ID
* Connection ID
* Media Type
* Customer ID
* Customer Segment
* Service Type
* Service Subtype
* Business Result
* Interaction Type
* Start Timestamp
* End Timestamp
* Routing Target
* Resource Role
* Role Reason
* Technical Result
* Result Reason
* Queue Time
* Route Point Time
* Total Duration
* Customer Talk Time
* Customer Hold Time
* Customer Wrap Time
* ....
{{!}}{{!}}Handling Attempt detail interaction level data.

Handling Attempt details of interactions that are stored mostly in the INTERACTION_RESOURCE_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Flow
{{!}}{{!}}Available KPIs:
* Agent/Queue
* Connection ID
* Media Type
* Customer ID
* Interaction ID
* Interaction Type
* Interaction Subtype
* Segment ID
* Source
* Target
* Technical Result Resource Role
* Technical Result Role Reason
* Technical Result
* Technical Result Reason
* Duration
{{!}}{{!}}Flow detail interaction level data.

Interaction-flow details of interactions that are stored mostly in the INTERACTION_FACT, INTERACTION_RESOURCE_FACT, and MEDIATION_SEGMENT_FACT Info Mart tables.
{{!}}-
{{!}}{{!}}Transfer
{{!}}{{!}}Available KPIs:
* Interaction ID
* Media Type
* Source
* Source Service Type
* Source Service Subtype
* Source Customer Segment
* Source Last Queue
* Source Technical Result
* Source Customer Engage Time
* Source Customer Hold Time
* Source Customer Wrap Time
* Source Queue Time
* Target
* Target Service Type
* Target Service Subtype
* Target Customer Segment
* Target Last Queue
* Target Technical Result
* Target Customer Engage Time
* Target Customer Hold Time
* Target Customer Wrap Time
* Target Queue Time
* ....
{{!}}{{!}}Transfer detail interaction level data.

Interaction details identifying the source and destination of transferred and conference interactions.
{{!}}}
|PainPoints=* Cannot recognize repeat customers
* Unable to use context to enable a finer granularity in matching the customer to the best agent in the target agent group
* Calls with long handle times, with customers having to recap previous interactions
* Missed service levels within or across channels
* Increasing interaction abandonment and repeat contacts
|DesiredState=* Recognize customers in all touchpoints and channels, and match callers with the same agent with whom they previously spoke
* Carry context and orchestrate interactions between channels
* Offer self-service and call back options
* Inform customers of expected wait/process times
|SMART_Benefits={{SMART Benefits
|UCBenefitID=Increased Revenue
|UCBenefit=Routing calls to the same agent that the customer previously spoken to may increase the chances of completing a sale.
}}{{SMART Benefits
|UCBenefitID=Reduce Handle Time
|UCBenefit=Using customer context enables routing to agents who can handle the customer's specific query more quickly.
}}{{SMART Benefits
|UCBenefitID=Reduced Interaction Transfers
|UCBenefit=Routing calls to agents based on customer context reduces the need for internal transfers.
}}{{SMART Benefits
|UCBenefitID=Improved Customer Experience
|UCBenefit=Routing calls based on customer context reduces familiarisation time and improves customer experience.
}}{{SMART Benefits
|UCBenefitID=Improved Employee Utilization
|UCBenefit=Enabling agents to handle queries more quickly improves employee utilization.
}}
|UCOverview=This functional use case has been created to enable companies to use Advanced Genesys Routing capabilities to improve customer experience by routing voice interactions to the best fit agent based on the type of request and customer context. Detailed routing behaviour is driven by configuration parameters and rules, therefore providing a highly flexible framework to adapt to specific organization needs. The base logic is based on experience and best practices from previous implementations and therefore enables the organization to use best practice scenarios to enable fast realization of benefits.
|UCSummary=A customer call is qualified within the IVR. The customer is identified and authenticated (if needed) within the IVR menu (not part of this use case). The customer ID is used to retrieve context data on the customer from Genesys Context Services. Based on his choices within the IVR and on the context data, he is routed to the best agent able to serve his request and potentially additional services, e.g. to realize up-sell potential. All relevant context information is displayed to the agent to enable high-quality service delivery. The logic of this use case is business rules driven and therefore flexible to changing needs and business environments.
}}