View table: SMART_UseCase

Parameters and Business Rules

• Customer identification by ANI / CLI - Step 3 in the business flow can be enabled or disabled depending on specific business requirements. If this step is disabled, the flow always asks for a customer identifier. (for example customer ID, account number, or tracking number.) You can set this parameter for each company service line.
• General: Voice Prompts - The business can configure all voice prompts within this flow.

Parameters to be Passed to the Payment Application

The payment capture IVR application requires the following parameters:

• Customer or Account Identifier (recommended)
• Outstanding Balance or Payment Amount (recommended)
• Payment Reference (optional)

Configuration Settings

The following parameters are configurable within the system:

• The maximum number of declined payments allowed before exiting the flow
• The allowed cards for payment (such as Amex and Visa)
• The currency of the payment
• Setting and details on the payment provider
• Optionally a minimum payment amount in case the customer can specify the payment amount. For payment requests below this amount, there is an error flow where the application asks the customer to enter the amount they want to pay.
• The result to return when the customer reaches the maximum attempts, possibly to send the call to an agent, or initiate some other handling

Built-in Variables

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

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

Business Rules

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

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

Multiple Rules

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

BL1

Contact Records

The admin loads the contacts in Genesys Cloud CX. Genesys does not configure the API calls from external systems to add contacts. A custom solution can do this work as a custom SOW at extra cost.

Agentless Campaigns

The customer can configure their campaigns with various dialing modes, including Agentless (IVR). The customer or Genesys PS configures the dialing mode of a campaign before uploading the contact list. The admin or Genesys PS also configures any pre-recorded messages and IVR flows for automated outbound calls.

Campaign Settings

The customer admin or Genesys PS configures various campaign settings such as:

• Scheduling
• Maximum attempts
• Do Not Call (DNC) options
• Default* agent script
• Contact list
• Pacing
• Rule sets
• Priority
• Sorting (Dynamic or Static)
• Caller ID
• Filter
• ACD queue
• Time zone mapping

^*More advanced scripts are part of the Genesys services catalog.

Dialing Mode: Preview, Progressive, Power, Predictive, Agentless

A customer can choose to run outbound dialing campaigns using Preview, Progressive, Power, Predictive, or Agentless modes. Either the customer admin or Genesys PS configures the campaign. A customer can also designate specific contacts to always be dialed in Preview mode (Precise Dialing). Preview mode ensures that an agent is available when the specific customer answers.

If Preview mode is used, customers can assign ownership to an agent so they will only those records. This is helpful by combining several individual campaigns into a single one.

Answering Machine Detection (AMD

Call analysis (CPD) that includes AMD detects whether an answering machine or a live person is answering the phone before connecting the call to an agent. A customer can also choose whether to disconnect, play a message, or send the call to an IVR flow when a call connects. A customer can also disable AMD for compliance reasons, or if the customer wants to have agents handle all connected calls to ensure that an agent is available when the customer answers.

BL2

DNC Lists

Do Not Contact lists should include customers who have opted out of previous campaigns and a country-specific DNC list (if applicable). A customer can apply multiple DNC lists to a campaign. When a consumer opts out of a campaign, they should be added to the DNC list. Customers can also upload another DNC list or add an individual to an existing DNC list. These suppression lists can then be applied to future campaigns at the campaign level. DNC lists can also be outsourced to one of our integrated partners, DNC.com, or Gryphon Networks. They can manage their subscriptions to those services and customize several options including wireless and VoIP identification.

For internal DNC lists, users can now set an expiration time/date for a DNC record. After this time, the system will ignore the entry and proceed with making an attempt. Our DNC.com integration features the ability to block restricted days such as state holidays as well as specific time of day restrictions.

Personalization

For Agentless (IVR) campaigns, the content of the messaging can be personalized (TTS audio).

Agentless SMS and Email Notifications

Customers typically use agentless SMS / Email notifications when triggering a message based on an event such as: purchase, scheduled appointment, two factor authorization, and so on. The customer must have an external system invoking the API call to send the message. These trigger-based notifications are not sent all at once. As such, trigger-based notifications do not use traditional outbound campaigns. However, they are included within interaction views and reporting.

Standard SMS Keywords

Standard opt-out keywords include STOP and UNSUBSCRIBE and additional variations including: END, QUIT, CANCEL and STOPALL

Standard help keywords include HELP and INFO.

Standard opt-in keywords include START, YES and UNSTOP.

SMS Campaigns

Contact List

• The organization either prepares a contact list from a third-party system (such as CRM) or configures their system to use Genesys Cloud CX APIs to insert contact records.
• Batch Upload Option: Customer contacts are loaded through the User Interface using a .csv file.
• API Upload Option: Customer contacts are loaded through a Genesys Cloud CX API call. Customers can set a flag in the API to add the contact to the top of the list.

Campaign

• The campaign is started and begins contacting consumers based on the campaign settings configured. The Genesys Cloud CX system checks each contact record against the Do Not Contact list(s) assigned to the campaign to filter out consumers who should not be contacted. The message body can be specified in a SMS campaign templated associated with the campaign. Alternatively, the customer can specify the SMS message body for each contact record by assigning a column in the list as the message column. Best practice recommends that if hyperlinks are used in the message that the total message content is no more than 160 characters to avoid splitting the hyperlink across multiple text messages.
• The consumer’s mobile phone provider determines the concatenation of an long message. Messages longer than 160 characters may be concatenated into one message by the mobile provider or may arrive as multiple messages. Genesys stores the SMS sent success or failure status of a message on the interaction. Consumer may decide to respond to the SMS message. Responses will thread with the original outbound SMS message for a configured amount of time with the available metadata from the SMS message to identify the consumer. For a HELP keyword, a customer-specified help text is sent to the consumer. For a STOP keyword, a default or customer-specified text is sent to the consumer, the mobile number is added to a suppression list by the aggregator, and further messages are blocked by the aggregator. For a START or UNSTOP keyword, the aggregator begins allowing further messages to be sent to the consumer.

Email Campaigns

Contact List

• The organization either prepares a contact list from a third-party system (such as CRM) or configures their system to use Genesys Cloud CX APIs to insert contact records.
• Batch Upload Option: Customer contacts are loaded through the User Interface using a .csv file.
• API Upload Option: Customer contacts are loaded through a Genesys Cloud CX API call. Customers can set a flag in the API to add the contact to the top of the list.

Campaign

• The message body can be specified in an email campaign template associated with the campaign.
• The outbound domain used for sending messages is provisioned in Genesys Cloud.
• The campaign is started and begins contacting consumers based on the campaign settings configured.
• The Genesys Cloud CX system checks each contact record against the Do Not Contact list(s) assigned to the campaign to filter out consumers who should not be contacted.
  

Capturing of Incoming Emails

In step 2 of the business flow, emails are delivered to Genesys Cloud CX. The following configuration options are available:

• Direct customer-sent email messages to the yourAccountName.myGenesys Cloud CX.com domain.
• Register the business domain with Genesys Cloud CX for email routing (MX Records)
• Forward existing email addresses from corporate email platform to Genesys Cloud CX.

Note: Genesys Cloud CX does not allow an organization to use their own email platform. However, an organization could forward email from their corporate mail platform to an email address that is registered with Genesys Cloud CX. The downside of this approach is that the email responses from the agent to the customer include a different email address in the email header. However, the email address in the Reply To field is correct.

Quality Management

Email interactions are available for Quality Management just like all other media types.

• Intents: The goal of the interaction. For example, a "switch flight" intent returned by the NLU indicates that the customer receives a payment business process.
• Slots: Additional pieces of key information returned by the NLU. These pieces can accelerate the conversation by prepopulating answers to subsequent questions.

BL1: Agent Handoff: The customer can ask to connect to an available agent. At that point, the chatbot disconnects and the chat transcript (excluding sensitive data) appears in the agent desktop.

BL2: Survey: The customer can determine whether to address a survey or not. This survey can be based on:

• Customer profile information in External Contacts
• Customer journey data
• API call to third-party data source

Important:

• Genesys Web Messaging
  • Conversations will be threaded until a maximum period of 72 hours of inactivity is reached. If an agent wraps up an interaction and there is no further activity within the 72-hour period, the conversation session will be terminated and the consumer will see a brand new session when they revisit the Messenger. This 72-hour threading window can be configured to be less than 72 hours if desired, however the customer’s view of the conversation in Messenger will always be based on the 72 hours of inactivity.

• Facebook Messenger
  • Businesses using the Facebook Messenger platform have up to 24 hours to respond to a message sent by a person in Messenger when using standard messaging. A bot may also send one additional message after the 24-hour time limit has expired. The 24-hour limit is refreshed each time a person responds to a business through one of the eligible actions listed in Messenger Conversation Entry Points. This limit is commonly referred to as the '24 + 1 policy'.
  • Customers must agree to and comply with the Facebook Messenger Platform Policy Overview.
• Twitter Direct Message
  • You may not use Twitter for sending bulk, aggressive, high-volume unsolicited replies or Direct Messages; repeatedly sending identical Direct Messages; and repeatedly ending Direct Messages consisting of links shared without commentary, so that this contains the bulk of your Direct Message activity.
  • Customers agree to comply with Twitter Rules and Spam / Platform Manipulation Policies.
• LINE
  • LINE prohibits activities such as sending messages indiscriminately to numerous Users or any other activities deemed to be spamming; activities that use the Service for sales, marketing, advertisement, soliciting or other commercial purposes (except for those purposes approved by LINE); and activities that are related to religious activities or invitations to certain religious groups.
  • Customers agree to comply with the LINE terms/ Terms and Conditions of Use.
• WhatsApp (beta)
  • A brand has 24 hours to respond to a consumer. Within that timeframe, bots and agents are allowed to send as many templated or free-form messages as they want. Any response by the consumer resets that 24-hour limit.
  • Template Message support is a near-term roadmap feature for Genesys Cloud CX. Once the 24-hour limit has expired, only paid WhatsApp-approved Template Messages (called "paid notifications") can be sent until the consumer responds. Once the consumer responds, another 24-hour window opens for agents, bots, and the consumer to communicate.

BL1 – Customer Identification

The system can use cookies to detect returning visitors and associate them with previous site visits. Identity information provided during the journey (such as email address or phone number) is captured after it is explicitly submitted from the web page and can identify the visitor even across devices. After the customer is identified, all tracking data collected is associated to that specific customer. All customer information collected is done in a GDPR-compliant fashion.

BL2 – Segment and Outcome Configuration

Segments are a way to categorize visitors on the website based on common behavior and attributes. Segments are configured upfront during system provisioning. A segment can be made up of one or both of these components:

• Attributes, such as browser type, device type, location, marketing campaign they are associated with, UTM parameters, and the referral website.
• Journey pattern, such as web browsing behavior, searches performed on the website, items clicked, returning users, cart abandoner, and high-order value.

Outcomes or goals are specific tasks you want your visitors to perform on your website. As with segments, they are configured upfront. Typical outcomes include:

• Check order status or return status
• Open or check status of a trouble ticket
• Locate warranty or return policy
• Application submission
• Online purchase confirmation
• Submit payment
• Online quote
• Book a demo or appointment

Genesys uses predictive analytics to evaluate in real-time the probability for a specific outcome to be achieved, based on segment and visitor behavior on the website (the outcome score).

BL3 – Action Map Configuration

Action maps determine the way to engage with the website visitor. Within action maps, you define the triggers that result in an action to the customer. These triggers can be based on any combination of:

• Segment
• User activity
• Outcome score (typically, a drop in outcome score for a specific segment can trigger a webchat)

BL4 – Customer Invite and Registration Window

Genesys Widgets are used for:

• Invite messages for webchat
• Collection of visitor's contact details
• Engagement over chat session

BL2: Retries: In the voicebot management interface, configure the number of retries for self-service tasks and questions. Configure the dialog to, upon maximum retries, present a message, or hand-off to an agent. Or through IVR configuration, offer a callback if the agent is busy or the request is outside business hours through IVR configuration.

BL3: Response Type: Configure the interaction flows to accept natural language responses and closed responses such as account number, date of birth, and yes or no questions. This process means that customers can backtrack to a different point in the dialogue when required. For example, if a customer is midway through getting flight information and says, “actually just tell me where your nearest ticket counter is,” then voicebot informs the customer of the location of the nearest counter.

Parameters influencing voicebot behavior

This use case is supported across industry verticals. The basic features of voicebot business logic, such as personalization, are parameterized. Example parameters include:

NLU

• Intents: The goal of the interaction. For example, a "switch flight" intent returned by the NLU indicates that the customer should receive a payment business process.
• Slots. More pieces of key information returned by the NLU. These pieces can accelerate the conversation by prepopulating answers to subsequent questions.

Agent Handoff

• Based on user choice, such as "I want to speak to an adviser."
• Based on default handling, such as retries, timeouts, and global commands.
• Based on application logic, such as the customer owes money and application decides to transfer.

Parameters to Configure Service Level Announcements

• 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 (such as a power outage or general closure)

Emergency Check

• Emergency mode activation is enabled at the beginning of the call. If an emergency flag is set for an incoming call, the corresponding emergency announcement plays, and the configured action applies to the call (disconnect or transfer to another number within or external to Genesys).

Estimated Wait Time (EWT) Announcements

• Announcement of EWT to customers is handled based on predefined recordings. It is good practice to announce expected wait times to not jeopardize customer expectation.

Busy Treatment

• Messages and music play for queuing calls and can be looped until the call is answered or abandoned.

Skill Model

• Basic skills: Skills can be used to route a specific type of request or service. Genesys routing utilizes skills for enhanced routing logic and personalization, and to route callers to the most appropriate agent with the matching skill set.

• Language skills: Language skills can be used to determine the language in which a call is answered. The requested language is provided via the IVR, and if no language is provided, a default is used.

Interaction Priority

• Priority may be set on interactions as they enter and leave the IVR flow. 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 process 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 still route to an agent after a potential longer waiting time.

Transfers

• Agents can transfer calls to other agents directly, to other queues, or even to external contacts. Genesys Cloud CX supports standard blind and consult transfer functionality to help agents direct callers to the right location.

Parameters to Define Call Routing / DTMF Menus

Customers can configure up to four levels of DTMF menus, with a maximum of nine sub-options for each level. A caller's choice of DTMF menus and sub-options determines the service they need and the agent skill required to best meet that need.

These DTMF levels and sub-options provide the greatest flexibility to adapt the use case to specific company requirements. However, to avoid a poor customer experience, we recommend that customers use the minimum number of levels and menu choices.

Reporting Parameters

Customers use different combinations of reporting parameters to analyze the unique properties of each parameter group in reports. Reporting parameters include:

• Queue - The target agent queue to which the interaction was routed. Customers can optionally filter queue performance data based on skill requirements.
• Agent - The agent or agents who handled the interaction.
• Wrap-up code - The wrap-up, or disposition, code that the agent or agents apply to the interaction.

Audio Resources

The following audio resources are configurable by service line:

• Business Hours - A message announcing office closure and inviting the caller to call again at opening time
• Please Wait on Hold - A message inviting the caller to wait
• Welcome - A greeting message
• Emergency - An emergency message
• Special Day - A message announcing office closure due to a special day (such as a bank holiday)
• Music waiting in queue - Music
• Main DTMF Menu Message - The main call routing menu announcement
• Sub-DTMF Menu Messages (multiple messages) - The sub-menu messages for the call steering menu as required

BL2: Leverage knowledge: The agent communicates relevant information to the end-customer, or they use the information to perform the required "back-end" actions to resolve the customer issue.

BL3: Rate knowledge: Agent assist may provide an agent with multiple pieces of information during the interaction. Agents should rate the information using the thumbs up / thumbs down buttons to verify as relevant or irrelevant.

BL4: Resolve issue or continue conversation: If the end-customer issue is not adequately resolved, the agent continues the conversation with the end-customer to trigger Agent Assist to surface additional information. If Agent Assist is unable to provide appropriate information to resolve the end-customers issue, Agents should follow their corporate escalation policy to ensure that expectations are fulfilled.

• Does the customer have an existing carrier relationship?

• Does the customer want to keep this existing carrier relationship or port services to Genesys Cloud CX Voice?

The first example uses a toll-free 800 number. The number in this example can also be interchanged with the DID number. For example, any number reachable from the PSTN.

Example 1

• Customer has an existing relationship with Carrier ABC that owns their 800 numbers.

• Customer selects BYOC open and integrates our solution with Carrier ABC for PSTN services.

Example 2

• Customer does not have an existing relationship with any carriers and needs to buy net-new 800 numbers.

• Customer selects Genesys Cloud CX Voice and purchases new 800 numbers from within our platform.

Example 3

• Customer has an existing carrier relationship with Carrier ABC that owns their 800 numbers. Customer wants to consolidate and sees efficiencies in porting these numbers to Genesys Cloud CX Voice.

• Customer selects Genesys Cloud CX Voice and completes the necessary paperwork to transfer or port services from their previous carrier to Genesys Cloud CX Voice. For 800 numbers, this process is referred to 'resporg'. It updates the PSTN so that it knows what carrier to route the traffic to. In this example, PSTN has to be notified that the 800 number is now registered to Genesys Cloud CX Voice.

Archiving and Deleting Criteria

Genesys Cloud CX Policy can be configured to defined a archive and deletion actions for recordings and screen recordings. For more information Recording Policy

Pause / Resume recording

Agents can pause or resume recordings as needed for compliance reasons. The ability for an agent to pause or resume a recording from the agent desktop is enabled or disabled based on customer requirements. APIs are also used to pause or resume a recording. If a recording of the interaction is paused for an interaction that is also being screen recorded, the pause/resume action is synchronized.

View and Download recording and screen recording

An interaction can have multiple recordings, including screen recordings. If applicable, navigate through the recordings associated with the interaction and to play the screen recording. For ,more information-> View a screen recording and Download recording

Quality Manager/ Administrator

Roles will determine the access to recording and screen recording of users. Roles can be provided additional permissions based on business requirement. The Quality Administrator and Quality Evaluator roles have the additional permissions than a user for viewing quality and recordings. For more information ->  Roles and Permissions

Evaluation Sessions

To help ensure an agent's handling of interactions aligns with specific business requirements, evaluators receive assigned evaluations that they must complete according to the assignment process. A completed evaluation form provides a view into how an agent communicates with a customer. When used as part of evaluation sessions, these forms provide consistent and regular feedback and can help surface insightful results, comments, and suggestions. This can lead to formal skills training and action plans to improve agent performance. For more information-> Evaluation form

• Genesys Cloud is configured with appropriate user roles and licenses.
• Business rules must be set up to assign the learning items to the agent target group.
• Genesys Cloud Coaching permissions are needed to schedule a Coaching session.
• Genesys Cloud Workforce Management is needed for optimizing scheduling.
• Gamification/ Performance Manager must decides on the Performance data that needs to be measured.
• Supervisor and Agents need to finalize the performance objectives that are to be achieved including the KPI that needs to be tracked.
• Periodic review process with necessary learning items and coaching should take place between the Supervisor and agent to agree the final targets.
• Agents can view their Assigned Learning Module from Module Icon in the Inbox
• Agents can also view their Assigned Learning items with appropriate due dates in the Activity Tab of Genesys Cloud.
• Agent feedbacks should always be incorporated to enhance the system on a periodic basis.

Genesys system analyzes work items created within to be able to:

• Be associated with the right business process, department, queue, prioritization schema, and employees. The Genesys system assigns work to the business process in real-time based on employee presence and capacity rules.
• The source systems can optionally assign the due date and priority settings for handling the work item (so called work item prioritization).
• Distribution schema applied to the work items is crucial for both steps above. For example, the business process, department and metadata define needed the skills to handle the work item. Segmentation and prioritization depend on the attributes associated to work items and on business requirements. The following sections describe these attributes or metadata.

Attributes

Work item segmentation and prioritization depend on metadata input from one or more source systems. To apply the segmentation and prioritization within the Genesys system, a set of business attributes (parameters) must arrive from the source system. These attributes captured by the capture event are within the Genesys capture adapter.

The global task list includes work captured. Genesys intelligent Workload Distribution Manager applies segmentation rules to separate work items using core attributes and custom attributes:

• For the work item to pass from the source system, it must be a core attribute. A core attribute is a fixed attribute passed from the source system, otherwise the system rejects (external identifier) it.
• Custom attributes can guide the work item to an employee and reflect in the routing and reporting. At the beginning of the project, generation of the mapping between the source system to Genesys iWD attributes occurs. The business user can manage their environment, once establishing the environment. Screen pops on the agent workspace and segmentation in iWD Manager occur through work item and custom attributes.

For detailed Attribute List for Leads, refer to the respective Leads Attribute List section below:

Business Rules

Business Rules define or mirror both the operating principles and constraints of an organization. A few examples:

• All work items associated with Sales Department and Customer Segment Gold shall be handled within 72 hours.
• If the work item attribute department equals Sales and the Customer Segment equals Gold then the Service Level Agreement (SLA) is 72 hours.

These and finer-grained segmentation rules established in iWD Manager and managed by the business user. The GRE & ORS applications controls the distribution strategy for work items to the desired employees.

iWD Manager uses the attributes from the captured work item to assign the task. It can assign directly to an employee, agent group, combination of skills, or skill proficiency levels. Importance of the work relative to other work items is a key factor that determines prioritization in the global task list. Work in the longest routing status distributes first when there are multiple work items with the same priority targeting the same employees.

The same applies for leads, the priority schema defined within iWD manager is highly flexible and business users can adjust the priority curve to suit their business needs.

In the following sales example, the business value of the lead degrades over time. When a promotion runs for leads that didn't convert within six days, the business user raises the priority between six and eight days after capturing the lead.

Note: In a blended environment, the priority ranges used for leads align with the priority ranges for other media types to ensure the right behavior (distribution order) within the environment. For example, if the employee is answering both phones calls and leads, the sales manager decides that phone calls have a higher priority. The result is voice calls priority starts higher than work items maximum priority. If there is an inflection point where the leads are more important than voice calls, then the prioritization strategy should reflect that. For example, leads within 2 hours of their due date and time are more important than voice calls that are in the queue for 30 seconds.

Business Context and Segmentation

Genesys intelligent Workload Distribution assigns every work item to a business process. Assignment of work items occurs after capture based on the segmentation defined within iWD Manager. The Finance and Sales Departments example shows the split of the processes according to the respective segment, and it reflects the different types of skills and proficiencies. The departments and process names adapt easily according to the changing organization's requirements.

Intelligent Workload Distribution Manager configuration segmentation example table:

Unspecified business processes use a default segmentation, prioritization, and distribution scheme.

Priority Schema

The system applies the priority schema to the work item/lead initially after capture and again periodically, according to defined prioritization schema. The reprioritization follows the logic defined below.

Rules define the logic to increase the priority over time by.

• Setting an initial value for the priority
• Setting a priority increment
• Setting the various periods between priority increments
• Setting the due date and time
• Set an overdue priority
• Setting the overdue or at SLA value of the priority

The priority of each work item or lead represents the urgency and business value at that point in the life cycle of the item. The prioritization schema allows a balance of work items representing different Service Level Agreements (SLA). The prioritization allows items of a shorter SLA to increase faster and reach the maximum priority compared with items of equal business value with a longer SLA. The values selected along the graph reflect the different SLAs. In other words, maximum priority culminates with the due date. In a blended environment, priority ranges used for items must broadly align with the priority ranges for other media types to ensure the right behavior (distribution order) within the environment.

As an example, for employees answering phone calls and items, phone calls have priority. The priority of voice calls is higher than items. If there is an inflection point where work items/leads are more important than voice calls, then the prioritization strategy should reflect that. For example, work items/leads within 2 hours of their SLA are more important than voice calls that have waited in queue less than 5 minutes.

Work item/lead life cycle (or) Work item/lead completion - Option 1 in source system and in Genesys

Genesys work items complete via the source system. The logical flow is as follows:

1. The employee completes a work item/lead in the source system.
2. The employee presses "Mark Done" in Genesys to signal that they have finished working on the work item/lead. The employee is then ready for the distribution of their next work item/lead.
3. The source system sends an update via the Capture Adapter to complete the item. If the update does not arrive within a specified timeout, the item goes back into distribution with the same priority. The calculation of priority referenced is in the graph described in the section "Priority Rules." The item going back to distribution ensures that the item avoids a stuck state in the Genesys system. If the employee accidentally presses "Mark Done" in Genesys, the redistribution of the item takes place.

Work item/lead life cycle (or) Work item/lead completion - Close in source system

Genesys work items complete via the source system. The logical flow is as follows:

1. The employee completes a work item/lead in the source system.
2. The source system sends an update via the Capture Adapter to complete the work item/lead. If this update does not arrive within a specified timeout, the item goes back into distribution with same priority. The priority calculated from the graph described in the section 'Priority Rules'. If the employee accidentally presses "Mark Done", the item goes back to distribution preventing a stuck status in the Genesys system. Disabling the "Mark Done" button within the Genesys agent workspace is an option to prevent this scenario from occurring.

Parking work items/lead in the personal workbin

If an employee is unable to complete the task, they can store it in their personal workbin for later. When they need to access the item, the employee can just pull it from their workbin to continue working on it. The use of workbin is helpful when employees are sick or taking time off. Supervisors manage workbins through the desktop to prevent stuck items in an employee's workbin. Items return to queue or assigned to another team member.

Rescheduling work items/leads

An employee may also need to reschedule a work item/lead, when a customer is available the following day. The source system handles rescheduling and depending on its functionality and integration with Genesys intelligent Workload Distribution. The logical flow is as follows:

1. The employee determines to reschedule a work item/lead.
2. The employee updates the source system, optionally setting an activation date in the source system. Most important, the employee sets the new SLA date and time in the source system.
3. The employee sets Mark Done in the agent workspace. The employee is available to work on the next work item/lead.
4. The source system updates the work item/lead in Genesys with a so-called activation date which is the date set by the employee. Updating the date prevents the item from distributing before the activation date. The work item/lead is prioritized following the logic described above, starting with the activation date. If the activation date fails to set, then the source system updates the work item/lead based on the new SLA.

Reclassifying work items/leads

An employee might also need to reclassify a work item/lead. The source system handles resegmentation which depends on the functionality and integration to Genesys intelligent Workload Distribution

The logical flow is as follows:

1. The employee reclassifies a work item/lead.
2. The employee updates the source system and sets the new date in the source system. 

3. The employee sets Mark Done in their agent workspace. The employee is available to work on the next work item/lead.
4. The source system updates the work item/lead in Genesys with the new attributes. The process of classification of the work item runs according to the new attributes. The item distributes to an employee with the right skill profile

Leads Attribute List

The attributes used for one or multiple of the following purposes:

•Segmentation (See topic 'Business Context and Segmentation')

•Prioritization (see topic “Priority Rules”).

•For display within the agent workspace.

The following table lists the attributes and its purpose which is available as part of this use case.

The table focuses on the attributes actively used within the configuration of this use case, however the iWD data model contains a broader list of attributes.

Workbin handling

Workbins contain a list of tasks that an agent can pull. While the agent is free to choose the tasks from the workbin, there is still a level of control as they are fully managed through defined business rules. Tasks within workbins may be reprioritized or redistributed automatically to support evolving Service Levels and business priorities.

Personal workbins

Personal workbins, assigned to a single agent, enable the agent to receive more than one work item (depending on the distribution rules) from the Global task list. Conceptually you can think of workbins as an agent's personal queue. Agents can place work items in their personal workbins when they cannot complete the work, and can also transfer work items from their workbin to other colleagues or supervisors. While agents cannot see work items in other workbins, supervisors and managers can. Personal workbins are equipped with an automated escalation capability, which means that work items are sent to a supervisor or back to the Global Task List automatically if they are not handled before the threshold is reached. This capability adheres to service levels and ensures that no work item remains in a workbin for too long.

Group workbins

Group workbins are assigned to a group of agents (could be considered a bucket of centrally managed tasks that are allocated to a virtual group of agents). More than one work item can be transferred from the Global Task List to the group workbins (depending on the distribution logic). Agents assigned to a group workbin can work on any of its tasks and transfer tasks to other colleagues or supervisors. Like personal workbins, group workbins are equipped with an automated escalation capability, ensuring that no work item remains in a workbin for too long without handling.

Business Rules

In addition to the Business Rules detailed in the use case Genesys Work and Lead Distribution (BO02) for Genesys Engage on premises, Optimized Pull requires:

• Definition of the maximum number of tasks allocated to a group or personal workbin at one time. This parameter is configurable per agent or agent group.
• A threshold time that determines when a task is pulled from a group or personal workbin and reprioritized and/or reassigned. This threshold time is based on a percentage of the Service Level for this task and can be set on the department level within iWD.
• A threshold time that determines when a task should be escalated to a Supervisor/Coach/Escalation Manager for supervisor attention or reassignment. This threshold time is based on a percentage of the Service Level and can be set on the process level within iWD.

• Using a supported channel and media type, the customer creates an interaction. As the interaction is handled and traced through your environment, data is captured that enables you to determine the outcome for the metric you want to optimize.
• Prerequisite: This use case requires inbound call routing.

Routing Step 2

• The interaction use case identifies the customer's primary intention (Service Type) and sets the initial target skill expression.

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).

Routing Step 4

• The predictor information along with necessary call information (Customer Profile, Interaction, Agent Profile) passes to Predictive Routing as a scoring request once one or more agents are available. The relevant machine learning model processes the request, resulting in a score for each available agent for that interaction. This process handles both customer surplus and agent surplus scenarios.

Routing Step 5

• The customer-to-agent matching provides the interaction score for each of the agents to the routing engine to identify the agents that can deliver the highest benefit to the target KPI. In an agent surplus scenario, the model compares the score of the highest ranked agent to the configured minimum score threshold. If the score is below the threshold, then the interaction is held until a higher-ranked agent becomes available or the threshold is reduced.
• In a customer surplus scenario, where multiple interactions are waiting when an agent becomes available, the agent’s scores for each waiting interaction are compared with the minimum score threshold. If the agent score exceeds the threshold for at least one interaction, the system proceeds to route the highest scoring interaction. If not, then the agent remains unassigned until a lower-scored interaction becomes available or the threshold is reduced.

Routing Step 6

• The minimum score threshold is reduced over time according to the preconfigured fallback strategy.
• The checks in Routing Step 5 repeat regularly until an agent-interaction matchup meets the threshold requirements.
  • Normal target expansion, such as relaxing skill level as configured within the underlying distribution strategy, occurs.
  • The continual reprioritization of the interaction also occurs, as do any treatments and the standard queued customer experience.

Routing Step 7

• The system delivers the interaction, handling any ring on no answer and exception situations as defined in the underlying use case.
• The customer and the agent connect.

Routing Step 8

• The interaction ends when the customer or agent disconnects the call.

Routing Step 9

• The agent workspace or a server-side process captures the interaction outcome. Genesys APIs invoke, either automatically or after an agent action, to map the outcome to a Genesys interaction attribute, which can be custom attached data or a disposition code.
• Genesys Info Mart captures this attribute in the Info Mart interaction record.

Routing Step 10

• Optionally, the customer receives a survey.
• If the customer completes the survey, the system collects and stores the outcome through a 3rd-party application.

Routing Step 11

• Optionally, a third-party application produces and stores the outcome data.

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.

For this Use-Case, we have foreseen three ways of initiating a new case. A new case can be created:

1. Via a web form on a public or internal website. By completing this form, a web service call is triggered which will create a new case in DCM via its open API.

2. Via DCM user interface. An Advisor or Expert can create a new case manually. This method can be used if email or voice channels are used. The Advisor (agent) who handles the call or email will manually create a new case.

see:

3. Via the Smart API. This allows the creation of Cases by other backend systems.

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:

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.

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.

Audio Resources

The following audio resources are configurable by service line:

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 workspace. 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:

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:

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:

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.

Callback Offer

The system verifies the estimated queue wait time for the type of request before transferring a call. The returned wait time is checked against the system configurable setting:

• If the expected wait time is greater than or equal to this threshold, a message is played before offering callback to the customer. The message can be generic or provide a range of time (best practice) for the estimated wait.
• Estimated Wait Time (EWT) uses one of 3 available options:
  • URS analyzes callback processing speed and pending callbacks while ignoring agent availability.
  • URS analyzes callback processing speed and pending callbacks while accounting for the agents who have historically handled interactions of the Virtual Queue.
  • Query EWT from Stat Server.

The business can configure the thresholds and messages played for various queues.

Register Scheduled Callback

Potential time slots for scheduled callback include these options:

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

Callback

Configurable voice prompts for announcements / treatments for the callback:

• Voice prompt in case the callback is answered by an automated answering machine
• Announcement once the customer is connected
• Treatment while waiting for the agent to be connected
• Announcement in case no agent could be connected to the call after a certain timeout
• It is possible to assign a priority to callback requests. This is important in case this use case is used in combination with other inbound media types (such as inbound calls or e-mail). All callback requests will have the same priority.

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

Customer identification by ANI / CLI

Step 3 in the flow above can be enabled or disabled depending on specific customer requirements. If this step is disabled, the flow will always ask for a customer identifier (for example customer ID, account number, or tracking number). This parameter can be set per company service line.

Configuration to define the next steps

After Identification and Verification has been performed successfully, the call will be transferred to the next step of the overall callflow. This might be an agent assisted service, a self-service application or an IVR menu. This parameter can be set per company service line.

Progressive ID&V: Configuration to define preceding authentication question(s) - Configuration can be set from within the ID&V module to give the business user control on the order of authentication questions. The configuration of other ID&V modules that contain these questions are out of scope for this use case.

Omnichannel ID&V: Passing of ID&V token - This authentication use case can be configured to pass an ID&V token from IVR to a visual IVR, so a customer can continue their journey on visual IVR if previously identified.

General: Voice Prompts

The customer can flexibly change all voice prompts within this flow.

Built-in Variables

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:

• Variablecustomer segmentis 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:

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.

Parameters and Business Rules

BL1:

Contact Records – Batch Upload

Contact records are batch uploaded, as configured by the customer administrator or Genesys PS based on the goals of the customer and the source of the contact. There is no limit to the number of contacts.

Channel Type – Dialer or Automated Outbound IVR

Customers can choose which channels to use in their campaigns: Dialer (agent-assisted) or Outbound IVR (automated). Channels are 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

The customer administrator or Genesys PS can configure various campaign settings: start/stop timing, frequency of contact per consumer, contact strategy, mobile filtering treatments, answering machine delivery options, connect to agent options, and assigned agent group.

Dialer Mode– Predictive, Progressive, Preview

Customers can choose to run dialer campaigns using Preview, Progressive, and/or Predictive modes, configured by the customer administrator or Genesys PS.

Answering Machine Detection

Genesys PS can tune aspects of the configuration such as listening for speech or tones, as well as the length of silence between phrases. Customers can choose whether to disconnect or to play a message when an answering machine is detected.

BL2

Personalization

For Outbound IVR, the message or script may contain personalized information from a third-party or customer database, to be provided by the customer along with the list. The audio file is also provided by the customer.

Contact Records

The 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 (via API, for example) is the responsibility of the customer.

Campaign Settings

One campaign is configured within the system. Customer Admin or Genesys PS can configure campaign settings such as start/stop timing and interaction design.

Text Message Content Template

One template is used for compiling the SMS message. The wording of the SMS message can be personalized using calling list data.

BL1

Contact Records – Batch Uploaded or Added On-Demand

Contact records are either batch uploaded or added on-demand via API. An API integration would be configured by the Customer Admin or Genesys PS based on the goals of the customer and the source of the contact. The integration 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, Outbound IVR, SMS, or Email

The customer can choose which channels to use in their campaigns – Dialer (agent-assisted), Outbound IVR, SMS, and/or Email. The channel configuration is done by the Customer Admin or Genesys PS before the list being uploaded. The Customer identifies the message content (or message template) per channel.

Campaign Settings

The customer Admin or Genesys PS can configure various campaign settings: start/stop timing, frequency of contact per consumer, contact pass strategy by channel, mobile vs. landline filtering treatments, answering machine detection tuning, opt-out options, connect to agent options, and assigned agent group.

Dialer Mode - Predictive, Progressive, Preview

The customer can choose to run dialer campaigns using Preview, Progressive, and/or Predictive modes. The modes are 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, and the length of silence between phrases. The customer can choose whether to disconnect or to play a message when an answering machine is detected.

BL2

Personalization

For Outbound IVR, SMS, and Email, the content of the message/script may contain personalized information from a third-party or customer database provided by the customer.

Text Message Content Template

One template is used for compiling the SMS and Email messages. The template can be personalized with specific customer-defined fields (such as customer name) from a third-party or customer database provided by the customer.

BL3

Suppression Lists

Suppression lists should include customers who have opted out of previous campaigns and 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.

BL4

Standard SMS Keywords

It is possible to configure multiple keywords to detect an opt-out (STOP) or help request. Standard keywords include STOP and HELP and variations including: END, QUIT, CANCEL, UNSUBSCRIBE, OPTOUT, NO, STOPALL, STOP ALL, HLEP, and HLP and variations including the organization's language. A list of keywords that triggers STOP or HELP scenarios is defined with the organization at the beginning of the project.

Capturing of Incoming Emails

In step 2 of the business flow, the Genesys system checks a set of mailboxes for new emails. The following configuration options are available:

• Address of email server for mail box
• Authentication details for mail box
• Protocol for communication (POP3, IMAP, Exchange Web Services Protocol)
• Delete email (any emails captured by Genesys are deleted from the mailbox)
• Polling frequency (how often the mailbox is checked for new emails)
• Maximum size (the maximum size of emails accepted by Genesys). Emails larger than this size are left in the mailbox and not captured by Genesys

Blacklist

It will be possible to configure and manage a blacklist of e-mail addresses. An administrator can add / delete e-mail addresses from this blacklist. E-mails coming from an address on the blacklist will not be distributed to agents.

Automatic replies

In step 4a, the Genesys system checks for automatic / system replies from the mail server to automatically stop email processing when no agent intervention is needed.

This includes:

• Detection of automated answers to prevent “ping-pong” between mail servers by answering with auto-acknowledge on e-mails of type auto-response or auto acknowledgement.
• NDR Handling (Non-Delivery Report Handling): The system recognizes automatic responses due to failed delivery (assuming these automatic responses are following standards).

Email Categorization

There are two methods of categorizing emails: Advanced Content Analysis and Keyword Matching. This is a system wide setting and only one method will be used at any given time. Configuration of up to twelve different categories are supported within the scope of this use case. Additional categories can be added by the company or by Genesys Professional Services on request.

Keyword Categorization

Keyword matching allows the system administrator to configure a number of screening rules to identify emails belonging to different categories. E.g. an email that contains the word “order” in the body of the email, would be categorized as a sales email. Screening rules can be configured to look for regular expressions that look for different words or phrase patterns that help categorize emails. Screening rules will be applied to the e-mail body and subject.

Additionally, screening rules can be used to detect patterns like credit card numbers, customer ID, and account number to be able to mask sensitive information to the agent. Configuration of up to three regular expressions to display to the agent / mask information are within the scope of this use case.

Advanced Content Analysis (optional)

Advanced Content Analysis is an optional extension to Keyword Categorization. This option requires additional licenses and services effort.

Incoming Email is analyzed using natural-language processing (please see the comments on supported languages below) to analyze the e-mail body. The result of analysis is an assignment to one or more categories of the category structure.

Content Analyzer creates its analysis algorithms by training: that is, by working its way through a number of emails that are classified according to the category system.

Training operates on a training object, which is a category tree and a group of emails classified using that category tree. A training object combines a category tree and a set of text objects, with each text object assigned to one category in the tree (categorized). The text objects are typically emails, but you may choose to have the set of text objects also include the standard responses associated with the category tree.

Training scans the text objects and forms a statistical model of the words and phrases that tend to occur in each category.

There are five possible sources of categorized text objects:

• Emails that have been assigned to categories
• Text objects (in the form of emails) that are created in Knowledge Manager
• Responses that are used when creating standard responses
• Objects that are used when creating other training objects
• Emails that are categorized when adding uncategorized emails using the Training Object Data Analyzer

The result of training is a model. This classification model - a statistical representation of a category tree - is applied to an incoming email and produces a list of the categories that the interaction is most likely to belong to. Each likely category is assigned a percentage rating indicating the probability that the interaction belongs to this category.

An email will be assigned to the category with the highest percentage of probability if this percentage is above a configurable threshold. Otherwise it will be categorized with a default category.

QA Process/Supervisor Review of Outbound Emails (Configurable by agent)

After an agent completes an outbound reply email, the system checks the agent configuration and if the agent is marked for the QA process, the email is queued for a supervisor to review or distributed into a supervisor workbin. If the e-mail cannot be distributed to a supervisor within a specific time frame or if he does not pull the e-mail from his workbin within this time frame, the e-mail will be sent automatically to the customer.

The supervisor has the option to edit the email then send to the customer, or add some notes and send back to the original agent. If the email needs to be sent back to the original agent, the supervisor will set a specific disposition code. Genesys routing functionality will attempt to distribute the email back to the original agent. If the agent is not available, the target can be expanded to the pool of agents for the respective category.

The system administrator can configure for each agent whether to enable/disable the QA function.

Standard responses

The Genesys Workspace displays standard responses available to the agent, grouped by category. Standard Responses accepts parameters, such as Customer Name, which will be filled in automatically when inserting the standard response into outgoing emails. The customer must provide the standard responses.

Available parameters for configuration by customer

The following lists the parameters used for the distribution logic. These parameters are configurable by category:

• Skill / skill level for the first, second, third and fourth target
• Supervisor skill / skill level for the first, second, third and fourth target
• Overflow timeouts for overflowing from last agent routing to skill-based routing and from overflowing between targets. These timeouts are based on age of interaction.
• Priority tuning parameters

o Priority increment (the amount to increase the priority after the interval time) o Priority interval (the time between priority increases) o Priority limit (the maximum priority) o Priority start (the starting priority)

• Enable / disable last agent routing
• Time-out for workbin escalation
• Time-out for Supervisor QA check

The following parameter is configurable by the “To” address:

• Auto-acknowledge message

Confidence Level Threshold

It is assumed that an automated response would only be sent if the confidence level is high, where a suggested response would be sent to an agent if the confidence level isn't high enough to warrant an automated response, but high enough to send to an agent as a suggestion. To do this, two confidence level thresholds must be configured in the strategy for the following actions:

• The first threshold indicates the minimum confidence level required for an automated response to be sent to the customer. For example, 80 would indicate 80 percent confidence.
• The second threshold indicates the minimum confidence level required for a suggested response to be sent to an agent. For example, 60 would indicate 60 percent confidence.

If the confidence level is below both thresholds, the email inquiry is forwarded to an agent without a suggested response.

Distribution logic

The following table shows the parameters, which can be configured, based on the subject:

Standard responses

The workspace will display suggested responses to the agent based on the chosen subject. Genesys will prepare the possibility to associate a specific subject with suggested responses using examples. The standard responses will need to be provided by the customer.

The first part describes the engagement rules of the social customer care. The second part describes any additional rules verified before the final decision.

For information about setting up and using social media channels in Genesys Engage on-premises, refer to the following articles:

• Set up Twitter and Facebook channels
• Handle Twitter interactions
• Handle Facebook interactions

Engagement Scenarios

The following 4 scenarios describe typical social customer care engagement which have been used successfully.

Scenario 1: Twitter - tweet to company

This scenario depicts an engagement when the customer is tweeting to the company's handle.

The customer uses their account to post a message.

Genesys Social Engagement captures this message according to predefined business logic (see below) and evaluates actionability.

Customer profile details are received with the message through the Twitter API. The profile details are attached to the interaction. The twitter message will be stored in the Genesys Contact History.

The original incoming twitter interaction is delivered to the agent workspace. The desktop identifies that this message was directed to the business and if the author is a follower of the business' twitter account

The agent reads the incoming twitter message and sends a public response. Alternatively, he/she may mark the tweet as “favorite” (Like), and/or mark this interaction as “Done”, assign a disposition code and not take any further action.

The workflow creates an interaction an outgoing twitter interaction and associates it with the same customer contact.

Genesys Social Engagement sends the reply back to the customer.

Scenario 2: Twitter - Direct Message (DM) to company

In this scenario, a customer is sending a DM to a company's twitter handle. Please note that this is only possible when one of the following conditions is satisfied:

• the flag “Receive Direct Messages from anyone” is activated in Twitter (not recommended as this might result in a high volume of messages)
• the customer is a follower
• a previous conversation was already established in the past to receive help

Please note that the Twitter policies which allow to send unsolicited Direct Messages may change. This is outside Genesys control and the flow and / or preconditions to send Direct Messages may change.

User sends a DM to the company:

The user must be a follower of the company, so that the company can send a direct message back. Therefore, non-followers are sent a follow request, e.g. “Please follow @Genesys for us to assist you”. This allows the User to assist customers over Twitter privately.

The tweet is stored in Genesys Contact History as an outgoing twitter message and associated with the same contact.

Genesys Social Engagement sends the Twitter message to the customer.

The customer sees the tweet and responds by following the @Genesys Twitter account.

The company then has a different choice of actions to perform, also according to what other channels are available for the agent and customer. If no other channel is available, the agent can reply to the direct message with the intended information and the interaction is closed.

Scenario 3: Facebook - post on Company's timeline (wall) or comment to post (Reply)

The customer uses his account to post a message on the company's timeline (wall) or posts a reply to a post from the company's timeline.

Genesys Social Engagement queries this page's wall and finds the new post with comments. The query is run on a configurable timer.

Genesys Social Engagement captures the message and creates an interaction in Genesys. The interaction consists of an original post plus comments which are posted within the query's timeframe. Additional attributes describing the post author's and commentators' profiles are also part of the interaction structure.

A customer contact will be created / updated for the initial author of the original post. Based on your business requirements you can decide whether you want to create a contact record for each author of a potential reply to the original post or only for the initial author (recommended).

The strategy stores the post including comments in Genesys contact history and associates it with the contact(s).

NOTE: while the interaction representing the initial post and comments is in the queue, further comments could be added. The query could pick up these additional comments and create another interaction. The agent receiving the first interaction will be notified of the remaining pending interactions.

The Incoming Facebook interaction will be delivered to an agent.

The agent processes the incoming Facebook message and sends a response if required. Also he/she may mark this interaction as “Done” and not take any further actions.

Genesys stores the message text of the outgoing Facebook interaction in Genesys Contact History for the same contact.

Please NOTE: The outbound Facebook message will be a child of the original message. (Reply)

Scenario 4: Facebook - private messaging

Facebook messenger can only be initiated by the end user.

The user needs to invite the company to a chat session via the “Message” button on the main Facebook page.

Genesys receives the chat request and distributes to an agent. The customer's public Facebook info is passed with the chat request.

The agent is alerted of an incoming Chat session with a "toast" indicating the chat is with the Facebook customer.

The agent accepts the chat interaction and begins a chat conversation with the customer.

Genesys Social Engagement sends the reply back to the customer.

Keyword mapping

There are two entities taking care of actionability detection and keyword mapping:

• The cloud driver software
• The on-premise content analyzer

Cloud driver logic

The cloud driver can be configured to monitor either a specific account (=all interactions that are related to the account) or keywords (such as hashtags or specific words that are relevant to the social customer care task). Please be careful when specifying keywords as common words or hashtags may result in a large number of interactions that are both filtered and routed at the on-premise server, thus impacting the overall performance of the architecture. In addition to this, Twitter and Facebook have policies that might prevent or block the account from receiving all those interactions, or might throttle message processing, if they receive too many processing requests, resulting in lost messages or delays in sending or receiving messages.

Content analyzer / Knowledge Manager

You can use Genesys Content Analyzer to run a secondary analysis on the actionability of interactions that are brought into the system by the Cloud Driver Logic. Genesys supplies samples, which demonstrate these capabilities.

Knowledge Manager provides additional key-word spotting abilities.

Content Analyzer provides Natural Language Processing Capabilities.

You can use the sample training objects to produce new models, improving the quality by making adjustments such as:

• Altering the settings such as those for quality level.
• Using the Mail Editor to edit the content of the messages in the training object.
• Using the Mail Editor to add more sample messages to the training object.

Genesys also provides sample-screening rules for detecting sentiment and actionability.

Please see the latest product documentation for supported languages.

Please note: this channel type is a hybrid between chat and social. It is a chat session but can also receive offline messages and these can be delivered via Facebook (i.e. messages sent by the customer after the chat interaction with the agent has been finished). These will be handled as a new interaction. Sending offline messages from the agent workshop is currently: if the agent needs to send info via FB Messenger, the end user must initiate the conversation and re-open the chat session.

Parameters and Business Rules

BL1:

Genesys checks the personalized routing database to see if there is a unique match for the available customer Identifier. Customer identifier will vary based on the inbound interaction channel:

• E-mail address for e-mail and chat
• Phone number for SMS

BL2:

Genesys uses the available Customer Identifier to see if there is a matching record in the Context Services Database. Where there is a match, Genesys will also establish if personalized handling of the interaction is required. This decision is based on the available data for the customer entry and the configured business rules.

The following section describes the information that can be sent to / utilized by the Personalized Routing DB in order to influence the routing.

• Repeat Calls
• Abandoned Calls
• Pending Interactions (e.g. unanswered e-mail, SMS / Twitter, Facebook)
• Customer Segment (stored by Genesys)

BL3: Treatments Available by Use Case Level

This section covers the treatments that can be applied to an inbound interaction based on the available data outlined in BL2.

• High Priority Routing (next available agent)
• Route Customer to Specific Skill / Skill combination
• Personalized message, i.e.
  • Personalized auto-answer in case of e-mail and SMS
  • Personalized greeting message in case of chat

The agent skill required for a specific call depends on the call origination. Up to four subjects are standard; any additions require customization. This logic needs to be defined based on the DNIS number for incoming interactions.

Assign priority based on subject

Different priorities can be assigned for different subjects. Three priority values are defined per subject based on the status of the call (Initial, Overflow, or RONA).

• Potential time slots for scheduled callback:
  • Duration of the time slots for requesting a scheduled callback. Business hours are separated into time slots of 15, 30, or 60 minutes that users can request to be scheduled in.
  • Maximum number of connection requests per time slot. This number is valid for all time slots.
  • These time slots do not apply to immediate callback.
• Business hours for the service, including holidays and special days.
• Voice prompts for announcements.
  • While the Callback UI allows reference to audio files, unrelated to language, for purposes of this use case, one language is configured as the default language to be used if this information is not available.
• Assigning a priority to callback requests. This is important when this use case is used in combination with other inbound media types (such as inbound calls or email). All callback requests have the same priority.