Cargo query

The forecaster works through the forecast process:

1. Creates a scenario or continues working on a previously saved scenario.
2. Uses the Forecasting wizard to build a volume forecast:

   • selects the appropriate forecasting methodology
   • selects which activities to forecast
   • forecast is generated
   • makes manual changesThe 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

1. The scheduler validates & sense checks the live forecast
2. The scheduler uses the ‘Schedule Build Wizard’ to generate schedules:

   • selects sites and build parameters for each site

3. Manual modifications are made as needed
4. The scheduler publishes the master schedule
5. Agents are notified of the detail of their working hours
6. The schedules are modified as required
7. Once the schedule is ready for hand-off to Intraday Management, the Scheduler will publish the Master Schedule and Intraday Management will be informed.

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

2. Agents are notified of changes as appropriate
3. Master schedule is kept current
4. Scheduler and Forecaster evaluate accuracy of forecast to actual and adjust accordingly.
5. Supervisors can monitor the adherence of the agents in their team to the published schedule.

When staffing for deferred items, like back office and digital interactions, different options are presented in the staffing build wizard:

• The initial queue is the size of the backlog
• The service level objectives are expressed differently
  • % of Deferred Work completed in an amount of time (hours, minutes, seconds)
  • Non-interrupted time is a 24-hour clock, meaning if an interaction with a 12 hour SLA arrives at 08:00 (opening time) then it must be completed by 20:00.
  • Interrupted time is based on the opening hours of that activity. In the above example, the contact center closes at 17:00, the interaction must be complete by 11:00 the following day.
  • Business Days is the number of days in between opening and closing time, for example, an interaction arrives Monday it must be completed by Tuesday.
• A different forecasting algorithm is invoked when using deferred activities which does not use Erlang-C logic.
• The schedule generated by this forecast works in the same way as an inbound voice forecast: consumers of the calendar screen see the type of work that users are scheduled to contribute to.
• The end result of this process is a schedule that contains optimal working hours for all agents in the contact center rather than just those working frontline, immediate types of work.

1. The forecaster accesses the overheads view within the forecasting module and makes a choice. Do they wish to:
   • use actual historical values via a saved template, or
   • manually enter projected values.
2. The forecaster then chooses the activity/activities that the shrinkage values apply to.
3. The forecaster builds or modifies a staffing forecast using the required staffing wizard, comparing calculated and required FTE values where:
   • Calculated does not account for shrinkage
   • Required does account for shrinkage so FTE requirement will be higher
4. The forecaster decides to publish to master forecast as described in base package use case.
5. The scheduler reviews shrinkage running totals and makes adjustments to live schedule as necessary.
6. Team leaders monitor and manage live schedules.

1. The customer contacts the company by one of the following channels:
   1. Voice
   2. E-mail
   3. SMS
   4. Social
      • *Alternatively, a new task may be created by a 3rd party source system for distribution by the Genesys system
2. One of the use cases for the corresponding channel, processes the call and determines the skill profile required to handle the interaction.
3. The skill profile is matched with the corresponding activity in WFM
4. 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.
5. Genesys will check if one of these agents is available. If yes, it will distribute the interaction to this agent
6. If no, Genesys will queue the call until one of these agents becomes available or a time out is reached
7. 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.

Step 2: An announcement will be played to the customer that the call is going to be recorded.

Step 3: The call is handled and routed to an agent following the logic of the Inbound Voice distribution strategy which is implemented for the Service Line. This can be either the use case "Genesys Call Routing (CE01)" or "Genesys Personalized Routing (CE02)". The Inbound Voice routing strategy is not within the scope of this use case.

Step 4: Genesys Interaction Recording starts the recording.

Step 5: Agent answers the call from any desk within the site.

Step 5a: The agent may (if enabled) pause/resume the recording manually via the standard integration with Genesys Workspace when sensitive data needs to be entered.

Step 6: Customer or Agent disconnects the call.

Step 7: Genesys Interaction Recording stops and stores the recording.

Step 8: Supervisor searches for, retrieves and listens to a recording made by one of their agents.

Step 9: Legal and Compliance officer checks the system for compliance and retrieves recordings for legal purposes.

Step 10: Genesys Interaction Recording archives and purges recordings according to the rules defined in the system.

Step 2: The IVR announces that the call is going to be recorded

Step 3a: The call is handled and routed to an agent following the logic of the Inbound Voice distribution strategy which is implemented for the Service Line. This can be one of the existing Inbound Voice use cases (please see the documents of these use cases for more detail). The Inbound Voice routing strategy is not within the scope of this use case.

Step 3b: Based on a percentage, which is set in Genesys by the administrator, it is determined if the screen needs to be recorded.

Step 4a: Genesys Interaction Recording starts the voice recording.

Step 4b: If in Step 3b, it is determined that the screen needs to be recorded, Genesys will start screen recording as soon as the agent answers the call.

Step 5: The agent can answer the call from a single, dedicated desk within the site (product limitation).

Step 5a: The agent may (if enabled) pause/resume the recording manually via the standard integration with Genesys Workspace when sensitive data needs to be entered. This pauses both voice and screen recording.

Step 6: Customer or agent disconnects the call.

Step 7: Genesys Interaction Recording stops the voice recording. Screen recording will be stopped after the ACW period has ended.

Step 8: Genesys uploads the screen recording files to the central system immediately, or at configured intervals.

Step 9: Genesys Interaction Recording combines audio and screen into single files.

Step 10: Supervisor searches for, retrieves and listens to a recording made by one of their agents.

Step 11: Legal and Compliance officer checks the system for compliance and retrieves recordings for legal purposes.

Step 12: Quality Manager searches for, retrieves and listens to recordings to use in agent evaluations

Step 13: Genesys Interaction Recording archives and purges recordings according to the rules configured

1. Set up Users.

   The IT Administrator sets up user roles and a related set of permissions. Standard users include:

   • Admin
   • Form Designer
   • Evaluation Planner
   • Evaluation Reviewer
   • Supervisor
2. Set up Question Library:

   The form designer sets up a question library to be used in evaluation forms and creates the following:

   • categories
   • questions
   • answers
   • scoring type
3. Create Form by selecting Library questions.
   • The form designer creates a form by selecting the appropriate library questions, together with the model of scoring where low performers and high performers can be identified within a certain threshold.
4. Plan Evaluation and Calibration.

   The evaluation planner plans review sessions for CC sites, groups, or individual agents. He decides how many interactions need to be scored per month/week/day, setting a quota where it is recommended to start small to test reviews, such as two calls per agent/week based on metadata criteria (such as longer than 3 minutes) and concerning a specific call reason. Keep in mind that random is not possible and needs an interaction criteria set up for each planned review. Detailed tasks include:

   • Attach Forms.
   • Attach Evaluators.
   • Select interactions.
   • Specify scheduling (of recurrence, if any).
   • Activate schedule.
5. Select an evaluation session.

   The evaluation planner or supervisor proceeds with the actual reviews for the teams he is allowed to review and give feedback for, insight in how many reviews need to take place and what has been done, and what is in progress or still pending. Detailed actions include:

   • Select interaction.
   • Play back interaction.
   • Score session.
   • Save scored session.
6. Create an action item.
   • The evaluator sends out an action item containing the completed evaluation, along with any relevant feedback to the agent.
   • Agent reviews action item.
   • Agent reviews evaluation received, providing any additional comments back to the evaluator.
7. Using the available report templates/widgets, the evaluator sets up a performance view to monitor the progress of team performance and individual agent performance views.

1. Base configuration complete (Use Case EE01).
2. Supervisor logs into Web Supervisor application and navigates to Calendar > Time Off Limits.
3. Supervisor enters values for Time Off Limits (void = unlimited).
4. Supervisor navigates to Policies > Time Off Types.
5. Supervisor configures Time Off Types and associates with Schedule State Groups.
6. Supervisor navigates to Policies > Time Off Rules.
7. Supervisor creates Time Off Rules to calculate time-off balance (usually based on agent’s contract).
8. Supervisor assigns Time Off Rules to agents with an effective start date (end date is populated automatically by the system).
9. Several Time Off Rules can be assigned to each agent, mirroring their career path and possible increased entitlement.
10. Agent creates new request in Web Agent application outside of published schedule dates.
11. Time off is automatically granted, providing that the agent has enough hours remaining and the Time Off Limits have not been met.
12. WFM Builder automatically picks up the time-off request during the schedule build for the appropriate dates.

1. Agent creates a new request in the Web Agent application within the published schedule dates.
2. Settings previously configured in WFM Application Options determine whether the time-off request is automatically processed in the published schedule.
3. Time off is pushed to WFM Calendar in Preferred status, providing that the agent has enough hours remaining and the Time Off Limits have not been met.
4. If auto-approval in published schedule is not enabled, supervisor navigates to WFM Calendar and filters on Time Off entries.
5. Supervisor grants/declines time-off requests based on business criteria.

1. Base configuration complete (use case EE01, EE02, or EE26).
2. In Web Agent application, user navigates to Add Exception.
3. Agent selects how she wants to schedule the exception:
   • Best fit/optimized
   • Specific time/date
4. If supervisor approval is required, the supervisor navigates to Master Schedule Changes Approval view and approves/declines the agent-initiated exception.
5. Exception is visible to agents and supervisors in the master schedule.
6. If the supervisor declines the request it appears as declined in the master schedule view.

1. Agent logs into WFM Web Agent UI and navigates to the Preferences tab.
2. Agent selects desired preferences:
   • Shift
   • Availability Pattern
   • Day Off

SUPERVISOR

1. Supervisor logs into the WFM Web Supervisor UI and navigates to the Schedule Scenario view.
2. Supervisor invokes the Schedule Build Wizard and selects the Preference Fulfillment option for the desired site(s).
3. Supervisor adjusts preference fulfillment options until the desired balance between coverage and percentage of granted preferences is met (might require multiple rebuilds).
4. Supervisor publishes the master schedule.
5. Granted preferences visible in WFM Web Agent Schedule view.
6. Supervisor can optionally add preferences for an agent in the Calendar view.
7. Optionally, Supervisors can produce the Calendar Items Report to show granted preferences.

1. Employee becomes aware of upcoming or current lateness/early-departure occurrence with desire for payback.
2. In the Schedule view of the WFM Agent Web interface, the employee selects "Add Exception with Payback" for the relevant day where lateness/early-departure is needed.
3. Employee selects Shift Used For Exception.
4. Employee selects the exception and start and end time to be used to represent the lateness period.
5. Employee selects the Marked Time type to represent the payback period.
6. Employee selects the method of payback and date and time frame:
   • Add work to start/end of shift
   • Reduce length of meal on a specific date
7. Employee submits lateness/early-departure payback.

1. Supervisor is notified by employee of upcoming or current lateness/early-departure occurrence with desire for payback.
2. Supervisor opens Schedule Intraday view and locates the relevant employee schedule for the date in question.
3. Supervisors inserts Exception with Payback into the employee's schedule.
4. Supervisor selects the Exception and start and end time to be used to represent the lateness period.
5. Supervisor selects the Marked Time type to represent the payback period.
6. Supervisors select method of payback and date and time frame:
   • Add work to start/end of shift
   • Reduce length of meal on a specific date
7. Supervisor saves schedule.

1. Base Configuration Complete (Use Case EE01).
2. Supervisor creates Profiles in the WFM Contracts.
3. Supervisor assigns skills to the profiles related to real agent skill sets/WFM activities.
4. Supervisor creates a Bidding schedule scenario selecting Profile Agents.
5. Supervisor builds schedule containing Profile Agents for optimum coverage.
6. Supervisor selects which agents can bid on the schedule and enters open/close times for the Bidding period.
7. The Profile Schedules are now available for agents to bid on.
8. Agents enter values associated with the schedules they most / least want to work.
9. The Bidding time expires, and agents can no longer bid on schedules.
10. Supervisor can optionally assign a real agent to a profile schedule.
11. Supervisor auto-assigns agents to schedules.
12. Supervisor can optionally activate Seniority and/or Rank.
13. Supervisor publishes Schedule to Master.
14. Supervisor can run Schedule Bidding Report.

1. Scheduler builds the Training Manager environment:
   • Defines Meeting Types.
   • Defines Locations and Rooms.
   • Optimizes Search parameters.
   • Maps Parameters to Meeting Types.
   • Enables auto-scheduling of requests.
2. Scheduler verifies that there is a current / future forecast and schedule.
3. Team Manager creates meeting request via the web portal:
   • Selects Meeting Type.
   • Specifies date range and times of day.
   • Selects the Manager to facilitate the meeting.
   • Selects the Location where the meeting should take place.
   • Selects the Attendees for the meeting based on the WFM hierarchy.
4. Submits the Meeting to the Automated queue.

The queued request is processed on a first-come-first-served basis and automatically triggers the search algorithm, which:

1. • Collects staffing Requirements, Staffing Levels, Agent Availability, and Manager Availability from WFM.
   • Collects Room Availability from Exchange.
   • Schedules the meeting(s) at an optimized time to suit the business, Manager, and Attendees.
   • Adds failed requests to a work queue for a Scheduler to review manually.
2. Automated processes:
   • Write Work Exceptions to WFM.
   • Create room bookings in Exchange calendars.
   • Email the facilitating Manager and Attendees with the details of the meeting.
   • Update product Manager and Agent calendars.
   • Notify the person making the request of its progress.

1. Scheduler builds the Training Manager environment:
   • Defines Meeting Types.
   • Defines Locations and Rooms.
   • Optimizes Search parameters.
   • Maps Parameters to Meeting Types.
   • Enables auto-scheduling of requests.
2. Scheduler verifies that there is a current / future forecast and schedule.
3. Scheduler creates the Meeting Template:
   • Selects Meeting Type.
   • Specifies date range and times of day.
   • Selects the Manager to facilitate the meeting.
   • Selects the Location where the meeting should take place.
   • Configures recurrence rules.
     • Daily / Weekly / Monthly recurrence
     • Recurrence frequency, every X days, weeks, months
     • Minimum number of days between meetings, to prevent monthly one-to-one meetings happening in the same week, such as the 30th of one month and the 4th of the next.
   • Selects the Attendees for the meeting based on the WFM hierarchy.
4. Scheduler selects the meeting and runs an Optimized Search. The search algorithm:
   • Collects staffing requirements, staffing levels, agent availability and manager availability from WFM.
   • Collects room availability from Exchange.
   • Schedules the meetings at an optimized time to suit the business, manager, and attendees.
   • Adds failed requests to a work queue for a scheduler to review manually.
5. Automated processes:
   • Write Work Exceptions to WFM.
   • Create room bookings in Exchange calendars.
   • Email the facilitating manager and attendees with the details of the meeting.
6. Updates appear in the manager and agent calendars.

1. Scheduler builds the Training Manager environment:
   • Defines Meeting Types.
   • Defines Locations and Rooms.
   • Optimizes Search parameters.
   • Maps Parameters to Meeting Types.
   • Enables auto-scheduling of requests.
2. Scheduler verifies that there is a current / future forecast and schedule.
3. Learning and Development creates a Training Template:
   • Selects a Training Type.
   • Specifies date range and times of day.
   • Selects the Trainer to facilitate the Training.
   • Selects the Location where the Training should take place.
   • Select the Attendees for the Training based on the WFM hierarchy.
4. Submit the training to the automated queue.

The queued request is processed on a first-come-first-served basis and automatically triggers the search algorithm, which:

1. • Collects staffing requirements, staffing levels, agent availability and manager availability from WFM.
   • Collects room availability from Exchange.
   • Schedules the training at an optimized time to suit the business, manager, and attendees.
   • Adds failed requests to a work queue for a scheduler to review manually.
2. Automated processes:
   • Write Work Exceptions to WFM.
   • Create room bookings in Exchange calendars.
   • Email the facilitating Trainer and Attendees with the details of the Training.
   • Update in product Trainer and Agent calendars.
   • Notify the person making the request of its progress.

When used in conjunction with Performance DNA the Learning and Development team can target specific agent learning or levels of learning based on:

• Performance trends across the organization.
• Individual performance trends.
• Results from previous training / learning / coaching sessions.
• WFM skill.
• Correlation analysis: other agents that performed well in a specific training went on to improve in a skill. For example, agents that performed well in the ”understanding customer needs” training went on to improve their NPS score.

1. Performance DNA has been provisioned andconfiguration has been completed in the cloud
2. Locate Employee Data from HR file extract, and or WFM, including First Name, Last Name, Employee ID, and Team Information. Configure Org Data to import HR information daily. For configuration details see the Performance DNA Admin guide.
3. Create or modify a suite of baseline assessments.
4. Agents complete a suite of baseline assessments.
5. Collate Assessment results to provide holistic knowledge and capability measurement.
6. Assign Learning Items to support agent progression:
   • Based on Knowledge results, automatically suggest or assign relevant Learning Items.
   • Manually assign a personalized learning plan.
7. Agents to complete the Assessments and Knowledge Nudges assigned to them.
   • If successful, communicate improvement to Manager and continue through the process.
   • If unsuccessful, repeat part 4, for ongoing development and feeding results into the DNA blueprint.
8. Notify the manager on the completion of the Learning Item and arrange a performance review and create ongoing development plans for the agent.

1. Performance DNA has been provisioned and configuration has been completed in the cloud.
2. Complete the branding of application in line with the customer’s brand, including fonts, colors, and logos.
3. Locate Employee Data information from HR file extract and/or WFM (refer to HR data requirements listed under the Customer header in the Assumptions section).
4. Configure Org Data to import Employee Data automatically on a daily basis. For configuration details see the Performance DNA admin guide.
5. Collate KPI Data from Genesys solutions and/or third-party systems (refer to performance data requirements listed under the Customer header in the Assumptions section).
6. Build a high-performer DNA blueprint using KPI data, to identify the high and low performers:
   • Build DNA blueprint in line with business objectives.
   • Use high performers' KPI and Knowledge results to set thresholds and targets.
7. Map employees to DNA blueprints based on job roles.
   • Compare other employees against top performers to the relevant blueprint for their role.
8. Measure Employee Performance
   • Identify gaps in individual performance.
   • Collate and review KPI data for ongoing development and improvement.
   • Optionally, send DNA blueprint/strand data for employees to Predictive Routing to aid in determining correlating factors/predictors of optimal outcomes

1. Base-level Configuration Completed.
   • Employee creates Personal Development Plan with clear objectives and goals.
2. Manager reviews Development Plan with individual and amends or adjusts as required.
   • Measurements set against KPIs and individual goals set and agreed upon.
3. Approval by Manager of finalized plan.
4. Periodic review carried out between manager and employee – comments added through the journey.
5. Manager completes the "recommend potential capability" of employee.
6. New goals and targets are set as employee progresses and improves.

1. Performance DNA has been provisioned and configuration has been completed in the cloud.
2. Complete the branding of application in line with the customer’s brand, including fonts, colors, and logos.
3. Complete use case Genesys Performance Management (EE14) for Genesys Engage on premises.
4. Complete use case Genesys Skills Assessment (EE13) for Genesys Engage on premises.
5. Correlate agent knowledge and KPI Data to identify top performers.
6. Build high-performer DNA ‘blueprint’
   • Build DNA blueprint in line with business objectives.
   • Use high performers' KPI and Knowledge results to set thresholds and targets.
7. Compare other employees against the top performers to the relevant blueprint for their role.
   • Identify gaps in individual knowledge and performance.
   • Create personalized learning plans for each skill gap to support agent progression.
8. Assign Learning Items to support agent progression.
   • Based on Performance and Knowledge results, automatically suggest or assign relevant Learning Items.
   • Manually assign personalized learning plan.
9. Agents to complete the Assessments and Knowledge Nudges assigned to them.
   • If successful, communicate improvement to manager and continue through process.
   • If unsuccessful, repeat step 4, feeding results into performance blueprint.
10. Notify the manager on the completion of the Learning Item and arrange performance review and create ongoing development plans for the agent.
11. KPI and measurable targets are collated and reviewed, feeding back into the continuous improvement cycle.

1. Complete Performance DNA base configuration, including:
   • Complete use case EE16, Align Employee Skills and Capability with Operational Performance.
   • Complete branding of application in line with customer’s brand, including fonts, colors, and logos.
2. Compare current DNA performance between outsourcers and identify skill gaps.
3. Assign Assessments and remedial training to bridge knowledge gaps
4. Employees complete the assessments and training:
   • Agent performance is tracked over time.
   • If an agent fails the assessment, additional learning can be scheduled.
5. Skills and capability data is viewed in Performance DNA, and comparison reporting is carried out between individuals, teams, centers, or outsource partners.
6. Performance of each outsourcer is measured providing a skills distribution matrix across the enterprise.

1. Complete Performance DNA base configuration, including:
   • Complete Genesys Skills Assessment (EE13) for Genesys Engage on premises.
   • Complete branding of application in line with the customer’s brand, including fonts, colors, and logos.
2. Create or modify a suite of certification assessments, building certificates to be assigned to successful employees.
3. Agents complete a suite of certification assessments.
4. Collate Assessment results.
   • Unsuccessful attempts can be automatically reset.
   • Additional supporting learning items can be assigned.
5. Manager is notified on completion and can review results and arrange coaching or additional learning.
6. On completion, the certification report is updated with the names and dates of certified employees.

1. Complete Performance DNA base configuration:
   • Completed use case Genesys Skills Assessment (EE13) for Genesys Engage on premises.
   • Complete branding of application in line with the customer’s brand, including fonts, colors, and logos.
2. Create knowledge assessments specifically in line with onboarding program requirements, utilizing onboarding learning programs and subject matter experts to identify core learning content.
3. Employees are trained and relevant assessments are completed at the end of each training day. Organizations can configure a linear approach where assessments must be completed in order and in line with the learning delivered.
4. The trainer uses real-time reporting to identify any gaps and individual knowledge.
5. The trainer addresses learning gaps with each individual.
6. Employee completes end-of-learning assessments to ensure all core knowledge has been understood. Knowledge assessment questions from the mid-week knowledge assessments above can be reused, allowing for clear comparison of knowledge improvements.
   • Certificates can be provided to the employee upon completion of the knowledge assessment.
   • Employees failing end-of-block knowledge assessments can be retrained in the specific gaps identified. Employees may not be allowed to progress to the next stage until a minimum standard has been achieved.

1. The call is routed to the IVR.
2. An announcement is played to the customer that the call is going to be recorded.
3. Genesys Interaction Recording starts the recording.
4. If needed, the customer or the system transfers the call to an agent.
5. Customer or IVR disconnects the call.
6. Genesys Interaction Recording stops and stores the recording.
7. Supervisor searches for, retrieves, and listens to a recording made by one of their agents.
8. Legal and Compliance officer checks the system for compliance and retrieves recordings for legal purposes.
9. Genesys Interaction Recording archives and purges recordings according to the rules defined in the system.

1. Interaction is recorded.
2. Audio is transcribed to text.
3. Words and phrases in transcribed texts are automatically clustered in terms of frequency and changes in frequency.
4. Users can access search functionality to search for content in interactions.
5. Users can access discovery functionality to identify emerging trends and word clusters.
6. Users can play back interactions and read contents of transcription.

Note that in GIR, recordings are automatically fed to Interaction Analytics, while 3rd-party recording solutions require call recordings to be fed using batch processes.

1. The voice interaction is recorded (GIR or 3rd-party recorder) or the digital (text) interaction is completed (Genesys eServices or 3rd-party data source).
2. During a KPI workshop, identify the business opportunity to be addressed:
   • Reduce call volume
   • Improve FCR
   • Reduce AHT
   • Improve CSAT/NPS
   • Improve agent performance
3. Identify the specific areas of measurement to support the improvement of the business opportunity.
4. During a PS discovery workshop, identify the required measurement elements (topics) to address the KPIs. A typical engagement for one business unit deploying use cases Genesys Speech Analytics (EE22) for Genesys Engage on premises and Genesys Advanced Text and Speech Analytics (EE23) for Genesys Engage on premises is 12 weeks of PS effort, covering 30 topics.
5. Build the required measurement elements inside GIA with associated reports.
6. PS conducts user training using customer's system and data.
7. Customer conducts analysis with GIA to determine how to improve performance.
8. Customer implements solutions within the business operation.
9. Customer tracks the resulting performance improvement.
10. Genesys Business Consulting provides business consulting through the first few projects.

1. Identify sales area and campaigns on which to focus--new sales conversion, up-sell/cross-sell, retention.
2. Identify "topics" included in sales calls based on sales methodology or script steps, such as features, benefits, objection handling, asking for the sale, campaign messages, and qualifying questions.
3. Create lists of phrases or words associated with topics.
4. Classify calls based on sales outcomes (using content from within the calls, such as taking payment and confirming the order).
5. Optional: Append metadata (such as sales value, new/existing customer information, segmentation) to calls from other systems.
6. Classify agent performance as "high" or "low" based on conversion rates.
7. Compare topics included in calls by high- and low-performing sales agents.
8. Identify topics that differentiate between high and low performing agents.
9. Focus training for agents on differentiating topics using high-performing agents as a model, and reduce call duration by reducing or eliminating time spent on non-differentiating topics.
10. Compare topics included in calls with successful vs unsuccessful outcomes.
11. Identify topics that differentiate between successful and unsuccessful outcomes.
12. Refine campaign messages and scripts to focus on topics that differentiate in favor of successful outcomes, reduce emphasis, or eliminate topics that are non-differentiating.
13. Monitor effectiveness of refined campaigns and newly trained agents to quantify improvement in sales outcomes.

1. The voice interaction is recorded (GIR or 3rd-party recorder) or the digital (text) interaction is completed (Genesys eServices or 3rd-party data source).
2. Customer provides a list of compliance requirements.
3. Identify the required compliance events (topics) and the events that trigger a compliance requirement (topics and/or metadata). A typical engagement for one business unit deploying use cases Genesys Speech Analytics (EE22) for Genesys Engage on premises and Genesys Text and Speech Analytics for Compliance (EE25) for Genesys Engage on premises is 12 weeks of PS effort, covering 20 topics.
4. Build the required measurement elements inside GIA with associated reports. (Genesys PS)
5. Conduct user training using customer's system and data. (Genesys PS)
6. Conduct analysis with GIA to determine which compliance areas need improvement. (Customer)
7. Implement training programs within the business operation to improve agent compliance performance. (Customer)
8. Track the resulting performance improvement. (Customer)

Business consulting is provided through the first few projects.

• Step 1: Validate that the historical data has been collected and stored accurately.
• Step 2: Workforce Planner or Supervisor creates or edits a forecast scenario.
  • Workforce Planner or Supervisor uses the Forecasting Build Wizard to build a volume forecast.
  • Workforce Planner or Supervisor uses the Staffing Build Wizard to determine the requirements.
  • Authorized user can modify the forecast.
• Step 3:The Forecast Scenario is then published to the Master Forecast.
• Step 4:Forecaster notifies the scheduler that the Master forecast is published.

Scheduling Flow Description

• Step 5:Scheduler creates the Schedule Scenario.
• Step 6:Scheduler builds the schedule.
• Step 7:Scheduler publishes the schedule scenario to the Master Schedule.

Intraday Flow Description

• Step 8:The forecasters, schedulers, planners, or supervisors manage adds, moves, and changes to existing schedules based on their individual access rights.
• Step 9:Agents are notified of changes via email.
• Step 10:Scheduler and Forecaster evaluate accuracy of forecast to actual and adjust accordingly.
• Step 11:Supervisors can monitor the adherence of the agents in their team to the published schedule.

1. Create an Activity representing the desired task in question. Repeat for each desired Task. Some commonly configured tasks include:
   • Manual outbound dialing
   • Email-box cleanup
   • Manual correspondence
   • Customer Callbacks
2. Create an Activity Set.
3. Associate an Activity Task with the set.
4. Create a Shift Rule dictating how the Agents' schedules can be optimized.
5. Create a Task Sequence within the Shift Rule dictating what order within the day Tasks should occur.
6. Associate Shift Rule with an existing Contract or Rotating Pattern in WFM.
7. Scheduler creates the Schedule Scenario.
8. Scheduler builds the schedule.
9. Scheduler publishes the schedule scenario to the Master Schedule.

1. Customer makes a call to one of the service lines of the company.
2. An announcement is played to the customer that the call is going to be recorded. (*Compliance step)
3. The call is handled and routed to an agent following the logic of the Inbound Voice distribution strategy that is implemented for the Service Line. This can be either the use case Genesys Call Routing (CE01) for Genesys Engage on premises or Genesys Personalized Routing (CE02) for Genesys Engage on premises.
4. Genesys Interaction Recording starts the recording.
   • The interaction is recorded with reliability. (*Compliance step)
   • The communication between components is secured. (*Compliance step)
5. Agent answers the call from any desk within the site.
   • The agent may (if enabled) pause and resume the recording manually via the standard integration with Genesys Workspace when sensitive data needs to be entered.
6. Customer or Agent disconnects the call.
7. Genesys Interaction Recording stops and stores the recording.
   • The recording is encrypted, and is stored encrypted at rest. (*Compliance step)
8. Supervisor searches for, retrieves, and listens to a recording made by one of their agents.
   • Access to the recording is controlled. (*Compliance step)
   • User access and activity is available for audit. (*Compliance step)
9. Legal and Compliance officer checks the system for compliance and retrieves recordings for legal purposes.
10. Genesys Interaction Recording archives and purges recordings according to the rules defined in the system.

1. Customer makes a call.
2. IVR announces recording.
3. Call is processed according to the inbound use case.
4. Selective recording metadata triggers are met: percentage, business unit, customer type, language.
5. Call is routed according to the inbound use case, with the recording flag set.
6. Interaction Recording starts recording.
   • Agent pauses or resumes the recording.
7. Customer or agent disconnects the call.
8. Interaction Recording stops and stores the recording.
9. Supervisor listens to the recording.
10. Interaction Recording archives and purges the recordings.

1. The customer contacts the company using the inbound voice channel. This inbound interaction can be the result of a proactive rule on a web or mobile application.
2. One of the Inbound use cases for the corresponding media type handles the interaction and captures interaction context data. The exact data captured depends on the interaction and engagement type.
3. Based on the interaction context, Genesys selects an initial group of agents with the required skill(s) as possible routing targets to handle the interaction.
4. Predictive Routing calculates the scores of the agents in the target group using a machine learning model that takes into account the agents' historic performance on similar interactions.
5. When there are multiple agents available, Genesys attempts to route the interaction to the available agent with a highest score.
6. If there is an interaction surplus and an agent becomes ready, Genesys selects an interaction from the queue taking into account the priority of each waiting interaction, the score the agent has for each interaction, and the time the interactions were queued.
7. If no agents are available within the configured timeout, the routing strategy expands the potential target pool of agents by reducing the skill requirements and then repeats the target agent selection using Predictive Routing.
8. After dealing with the customer call, the agent disconnects the interaction.
9. The outcome is mapped to Genesys Info Mart attribute (for example, a disposition code or custom key-value pair).
10. Optional: The customer is offered a survey. The answer to the survey is stored in a third-party system.
11. Optional: Outcome data, such as case management closure, is produced and stored by a third-party application.

1. The source system (the BPM / CRM / business system storing and processing the work items associated with business processes) requires an employee to handle one of its work items. The source system uses the Genesys Generic Objects API to create a corresponding task in Genesys.
2. Genesys captures the new task and creates a new interaction in the system.
3. The interaction is prioritized according to the configuration.
4. The task is queued with all other interactions in the system. The priority of the task defines the position of the task in the queue. Once an employee with the right skill becomes available to handle the task, the task is distributed to the employee.
5. The task opens on the employee desktop.
6. The Genesys employee desktop opens the corresponding work item URL in the source system.
7. The employee handles the task in the source system.

1. The employee finishes working on the task in the source system, then decides on the next step.
2. The employee may be able to complete the task so that no further action is required.
   • The employee completes the task in the source system.
   • Then the work is finished within the Genesys employee desktop (“Disconnect”).
   • The employee then selects the appropriate wrap-up code.
3. The employee may need to reschedule the task because, for example, the customer is available only on the next day. In this case, the employee reschedules the task via the source system (see Reschedule Task).
4. The employee may not be able to handle the task because it is wrongly classified. In this case, the employee reclassifies the task via the source system (see Reclassify Task).
5. The employee may coincidentally finish the task in the Genesys employee Desktop without any update in the source system (“Disconnect”). In this case, no further action is taken by Genesys.

1. The actor (team lead, supervisor, or business analyst) runs a dashboard. Reference - BL1
2. The supervisor reviews the dashboard and checks it against business level KPIs for service level, interactions answered, and customer segmentation. Reference - BL2
3. If the supervisor finds anomalies in the service level target, they analyze further reporting data to identify anomalies with factors that contribute to service level. Reference - BL3
4. For further analysis, the supervisor looks at the service level target against the other variables and notices that the number of interactions answered is trending lower. Reference - BL4
5. The supervisor analyzes the information for anomaly details and correlations and finds out that there were a few agents with higher than normal average talk times.(For example, workgroup, agent statistics KPI). Reference - BL5
6. This information helps the supervisor identify the root cause for the service level anomaly. As an example, the supervisor looks into an agents’ interactions and discovers a very long interaction with multiple holds. After talking to the agent or listening to the call, the supervisor determines that the call was complex for agents to handle and it required multiple holds to get assistance. Subsequently, the supervisor identifies that the root cause is the training of agents who service a particular customer segment. Reference - BL6
7. The team lead or supervisor takes appropriate action.

1. The actor (team lead, supervisor or business analyst) runs a dashboard. Reference - BL1
2. The supervisor reviews the dashboard against business level KPIs for agent performance and customer segmentation. Reference - BL2
3. If the supervisor finds anomalies in the average agent score, they analyze further reporting data to identify anomalies with factors that contribute to agent score. For example, the supervisor might be able to determine which workgroup and/or agent show high average agent negative/positive scores. Reference - BL3
4. The supervisor looks further into the details (for example, by filtering and sorting against workgroup and agent). Reference - BL4
5. The supervisor analyzes the information for anomaly details and correlations (for example, workgroup, agent statistics KPI). Reference - BL5
6. This information helps the supervisor identify the root cause for the average agent score anomaly. As an example, they may identify that high average agent negative/positive score is driven by certain agent statistics, Workgroup, etc. Subsequently, the supervisor identifies that the root cause is a particular agent servicing a particular customer segment. Reference - BL6
7. The team lead or supervisor takes appropriate action.

1. A customer/employee is browsing the company website portal or intranet
2. On the site, a form is presented. Upon completion, a new instance of that specific case type is started
3. An automated email is sent to the customer, based on the provided email address in the form, to confirm that the case is now created
4. After the case starts, a new task is created and sent to a workgroup or Advisor, based on ACD properties such as Skill, Priority, etc.
5. Advisor picks up the work in the client application task form, for the Advisor to provide all information needed to complete that task
6. If Advisor cannot resolve the task, it can be escalated, meaning send the task/case to another (2nd Level / Expert) group to work on
7. If Advisor can complete the task, the case will be closed and an automated email with results sent to the customer
8. If Expert can complete the task, the case will be closed and an automated email with results sent to the customer, or the Expert can choose the option to send it back to the original Advisor for closure (verification)

1. The caller initiates an inbound voice call to the contact center.
2. The system checks if the day is configured as a special day. In this case a special day announcement is played and the call is disconnected.
3. The system checks if the call is within the contact center's business hours. If not, an out-of-office announcement is played, a voicemail option is provided if desired, and the call is disconnected.
4. The system checks if an emergency announcement is activated. In this case an emergency announcement is played and the call is disconnected.
5. A call steering message (DTMF menu) is played with various menu options (optional).
6. A greeting announcement is played.
7. The caller chooses a menu option using DTMF tones entered on a handset. If the caller does not choose an option or chooses a non-available option, the menu can be repeated one or more times. If the caller still does not choose a valid menu option the call will be handled with default routing parameters.
8. The ACD system distributes the call to the best fit agent for the chosen topic based on the agent's skill and skill level (see Agent Score Calculation for details).

1. Caller is transitioned from CE01.
2. The caller is routed to an IVR application that attempts to determine the caller's identity and service request. If explicit identification and verification are needed, CE07 provides this functionality.
3. If the call is outside of office hours or if an emergency situation is in progress, an announcement is played. The caller may then be reconnected or diverted to another number inside or outside of Genesys. If the call is within office hours, a greeting announcement is played.
4. Genesys retrieves context data about the caller based on identification.
5. If the contact center is open, the routing parameters for this call are set based on the type of request and the customer context. This enables flexible and personalized call handling.
6. Prompts may be played based upon customer context (optional)
7. The expected wait time (EWT) is calculated and announced to the caller (optional). If the EWT reaches a specific threshold, an announcement is played and the caller is disconnected or routed to another number inside or outside of Genesys (optional).
8. Hold music or additional announcements are played to the customer
9. 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 context (optional).
   • Examples: Skills to up-sell a defined product, provide service to the customer, or specific empathy skills based on the customer segment or demographic
10. After the conversation with the caller, the agent records the outcome of the call for reporting purposes, if they have acted on the presented lead.

1. A customer calls a service line of the company.
2. The call is handled by the IVR
3. At some point the customer needs assistance and chooses a menu option for agent transfer. The type of request and the agent skill(s) necessary to handle the call are determined by logic applied when the caller leaves the IVR.
4. The system verifies the expected wait time for the particular request. If the wait time is below the thresholds, the caller is immediately transferred to the corresponding queue to wait for an agent with the requested skill(s) necessary to handle the call.
5. If the expected wait time is above the threshold, the system plays a wait time announcement to the caller. This can be a generic announcement or the amount of estimated wait time rounded to minutes.
6. After the announcements, the option for callback is announced to the customer.
7. If the customer does not accept the callback, the call is transferred to the corresponding waiting queue. In case the customer accepts the callback offer, the system continues with the registration of the callback.
8. When the callback interaction is next in queue, it is presented to the agent to place an outbound call.
9. Agent places the call.
10. After the conversation between the agent and the customer, the agent can classify the call for reporting purposes via their agent desktop.

1. Call is transferred into the application. This self-service module can be integrated into a broader IVR application. The call is answered by this application. If ID&V is required then the application initiates the flow of this use case. If the customer has already been identified in a previous channel, transaction or step then it skips this flow. If not it continues to step 3.The broader IVR application is not within the scope of this use case.
2. If enabled, Genesys identifies a customer using the Automatic Number Identification (ANI) / Caller Line Identification (CLI). (Reference Business Logic 1 - BL1)
3. If ANI / CLI are available, Genesys performs a lookup in the company's database to identify the caller.
4. If identification via ANI / CLI is disabled or fails, Genesys asks for a separate Identifier (e.g. customer ID, account number, tracking number) to identify the customer. This question must require numeric entry. If the customer does not have the necessary information, Genesys asks the customer to press a specific DTMF tone.
5. The customer input is validated against the customer database. If no match is found, the customer is asked for their identifier, up to a maximum of three times after failure. The number of retry attempts is configurable.If the customer is still not successfully validated, the customer is forwarded to agent assisted service.
6. If a customer match is found, Genesys asks for additional information validating the caller's identity for security purposes. This question requires numeric entry.Progressive ID&V, i.e.: higher levels of authentication based on customer profile information and/or requested transaction, occurs during self-service depending on the type of interaction. Progressive ID&V is defined in a separateID&V module and is not within the scope of this use case. The preceding level of authentication should be configurable by a business user in real time should they wish to re-order authentication questions.
7. Genesys looks up and validates the security information entered by the caller within a third party application. If this validation is not successful, the system asks the customer for security information again, up to a maximum of three times after failure.If the system cannot successfully validate the customer, the system forwards the customer to agent assisted service.
8. Genesys plays a prompt that confirms the validation or informs the customer of the failure.
9. A configuration parameter determines where the caller is routed to next.The possible options are listed below. However, these options are outside the scope of the ID&V use case:· Agent assisted service - the result of the identification and verification is displayed to the agent, making both the customer and agent experience better. This functionality requires implementation of the use case Genesys Personalized Routing (CE02) for PureConnect.· Self service IVR - such as transfer funds or make a payment. Progressive ID&V could occur before self-service depending on the type of interaction. This option would be defined in a separate self-service module outside the scope of this use case.· IVR main menu for identification of the type of caller request.(Reference Business Logic 2 - BL2)

1. A customer is transferred to the payment application by another IVR application. (outside of the scope of this use case). The requested payment amount is transferred to the payment application.
2. The system checks whether the Customer has been identified. If not, the customer is routed to a separate application for Identification and verification. This functionality is covered by a separate use case,Genesys Customer Authentication (CE07) for PureConnect
3. If identification and verification succeeds, the customer moves to the next step. If not, the customer is transferred to an agent with context.
4. The system determines if the caller is to pay a predefined amount or if the caller is permitted to enter the amount they wish to pay. If the latter, the system then enables the customer to enter a payment amount. The system checks if the entered amount is within allowed values before proceeding. The system can also allow the caller to choose to pay the full amount.
5. A voice prompt is played to ask the customer to enter their card details. The following happens:
   • The customer enters their card number.
   • The system checks if it is a valid card number and what type of card it is (the list of allowed card types is configurable). Finally, depending on the type of card, the customer is requested to provide further details (such as expiration date and CVV code).
6. The system plays back the payment details and asks the caller to confirm so that the payment can be processed. The caller will state whether the details entered are correct or incorrect. The option to read back only the last 4 digits of the card number is configurable.
7. If the caller states that the payment details are incorrect, the system asks the caller which of the previously entered information (such as card number or expiration date) was incorrect. Based on the caller’s choice, the system asks for the information again before returning to the confirmation step.
8. If the caller states that the payment details are correct, the system accesses the payment gateway or CRM to process the payment. This will either be rejected or successful.
9. If rejected, the customer can re-enter their card details until the maximum number of rejections is met, then the Customer is transferred to an agent with context.
10. If the payment is successful, Genesys plays an appropriate announcement to the customer and at this point, dynamic information, such as a transaction reference or order number, can also be played.
11. The call transfers back and continues in the IVR application. The result of the payment is attached to the call for further processing.

1. A customer is transferred to the payment application by conference from an agent with DTMF (Dual Tone Multi Frequency) clamping enabled. The agent is part of the call. The requested payment amount is transferred to the payment application.
2. The system checks whether the Customer has been identified. If not, the customer is routed to a separate application for Identification and verification. This functionality is covered by a separate use case,Genesys Customer Authentication (CE07) for PureConnect.
3. If identification and verification succeeds, the customer moves to the next step. If not, the IVR is removed from the conference, and the customer and agent continue their conversation.
4. The system determines if the caller is to pay a predefined amount or if the caller is permitted to enter the amount they wish to pay. If the latter, the system then enables the customer to enter a payment amount. The system checks if the entered amount is within allowed values before proceeding. The system can also allow the caller to choose to pay the full amount.
5. A voice prompt is played to ask the customer to enter their card details. The following happens:
   • The customer enters their card number.
   • The system checks if it is a valid card number and what type of card it is (the list of allowed card types is configurable). Finally, depending on the type of card, the customer is requested to provide further details (such as expiration date and CVV code).
6. The system plays back the payment details and asks the caller to confirm so that the payment can be processed. The caller will state whether the details entered are correct or incorrect. The option to read back only the last 4 digits of the card number must be enabled as the agent is part of the conference.
7. If the caller states that the payment details are incorrect, the system asks the caller which of the previously entered information (such as card number or expiration date) was incorrect. Based on the caller’s choice, the system asks for the information again before returning to the confirmation step.
8. If the caller states that the payment details are correct, the system accesses the payment gateway or CRM to process the payment. This will either be rejected or successful.
9. If rejected, the customer can re-enter their card details until the maximum number of rejections is met, then the Customer is transferred to an agent with context.
10. If the payment is successful, Genesys plays an appropriate announcement to the customer and at this point, dynamic information, such as a transaction reference or order number, can also be played.
11. The IVR is removed from the conference and the customer and agent continue their conversation.The result of the payment is attached to the call for further processing

1. A customer calls a service line of the company and progresses through the routing strategy. The routing strategy is not in scope of this use case.
2. An IVR application answers the call. The full IVR application is not within the scope of this use case, but the functionality in this use case can be used as a module to enhance the IVR application with personalization options.
3. 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, Genesys Customer Authentication (CE07) for PureConnect. The identification and verification functionality itself is not within the scope of this use case.
4. Using the customer identifier (for example, ANI), Genesys can retrieve customer context information from a third-party system (optional).
5. The 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 menu if they have a mortgage or present a promotion 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.

1. An admin or Genesys Professional Services configures the campaign strategy and settings in the Genesys system.
2. The organization either prepares a contact list from a third-party system (such as CRM or collections) or configures their system to use a Genesys PureConnect API to insert contact records. The organization defines the schema for each list.
3. The campaign begins contacting consumers based on the campaign strategy set in step 1. The Genesys system checks each contact/record against the configured Do Not Call list to filter out consumers who should not be contacted. Each call result is recorded. See Cloud or On Premises and On Premises Only options below.
4. The organization uses the real-time monitoring tools or historical reports to evaluate campaign success.

Cloud or On Premises Options from item# 3

• Manual upload of file with Contact List Import Wizard
• Use API to insert records in real-time or batches

On Premises Only

• Organization manages the contact list database directly, inserting records using SQL (Oracle of MSSQL)

1. An outbound call is dialed automatically.
2. Call Analysis Detection determines which path to take:
   • Live Party - the call either disconnects, plays a recorded message, or uses IVR tools to create a call flow to produce a tailored message, which may include:
     • Text-to-speech playback of contact data from list
     • Decision trees based on contact data to personalize the message
     • The option to opt out of future calls. This is typically done by including “Press 9 to opt out of future calls”
     • The option to connect to a live agent
     • Speech analysis to interpret consumer words instead of using touch-tone buttons, as available
     • Any other IVR-related feature, such as transferring to self-service
   • Answering Machine - the call either disconnects, plays a recorded message, or uses IVR tools to create a call flow to produce a tailored message, which may include:
     • Text-to-speech playback of contact data from list
     • Decision trees based on contact data to personalize the message
   • Other call results, such as No Answer or Bad Number, disconnects the call
3. In each case, the call is disconnected and the result is written back to the system.

1. In Power mode, the system automatically places some number of calls based on the pacing algorithm and when the agent becomes available for the specific campaign. In Predictive mode, the system automatically places some number of calls based on the pacing algorithm and expected agent availability for the specific campaign.
2. For each call attempt, the following are the Outbound Scenarios:
   • Live Party connect - the agent is connected to the contact.
   • Other Call Outbound, that is, Bad Number or No Answer: the call disconnects and the result is written back to the system.
   • Answering Machine: the call either disconnects or plays a message (based on the chosen configuration in step 1)
3. At the end of the call, the agent selects a result code, or the system automatically assigns a result code if not handled by an agent. The following are some of the optional agent dispositions that may be configurable:
   • The contact has the option to ask for a callback. The agent selects a date and time for the campaign to place another call to that contact.
   • The contact may choose to opt out of future calls. That contact is added to a Do Not Call list for future scrubbing for this campaign.
4. The call is disconnected. The result is written back to the system.

1. In Preview mode, the agent receives a record prior to the call being placed.
2. Based on configuration, either that agent initiates the call or the campaign places the call after a configurable number of seconds. There is also a separate, configurable Skip result if the agent does not place the call.
3. The agent determines the result from a provided list, whether No Answer, Bad Number, Answering Machine, or any number of live party potential outcomes.
4. The selected result is written back to the system.

1. A customer sends an email to one of the public addresses (e.g., orders@abc.org) monitored by the Genesys email solution.
2. Genesys periodically checks corporate inboxes for new emails. Genesys analyzes the email to capture From, To, Subject, and body content as metadata.
3. Conversation tracking option: Genesys verifies whether the corresponding user already exists as a contact within the Tracker system (by email address). Tracker is an additional, licensable product. The email and any agent responses are attached to the contact.
4. The system checks whether the email is new or a reply.
   1. In case of a new email, the system classifies the email based on keyword analysis (see the Keyword Categorization section).
   2. In case of a reply email from the customer, the system attempts to route it to the previous workgroup (see details in the Distribution Logic section). After a timeout, the system routes the email to the originally specified workgroup.
   3. In case of an automatically generated reply email, the email will not be distributed to an agent and the flow will stop.
5. The system sends out a receipt acknowledgement email to the customer with a predefined template for the To address.
6. Once an agent with the requested skill is available, the email is routed to the agent's desktop with a screen pop from the email editor displaying the content.
7. Once the agent reads the email, he or she decides whether a reply is needed.
   1. If no reply is needed, the agent marks the email as done.
   2. If a reply is needed, the agent creates an outbound reply email, potentially using a standard response template.
8. The agent sets a disposition code to mark the business outcome for reporting purposes.

1. The website visitor requests to chat with a live agent via the webpage.
2. Genesys checks if agents are available, logged in, and (through the use of Genesys APIs) is able check the wait time to make intelligent decisions as to when to offer the chat feature to website visitors.
   • If no agents are logged in, the chat is disconnected and the website visitor receives a disconnect message.
   • If agents are logged in, routing takes place.
3. The chat pop-up window opens.
4. The website visitor gets a welcome message from the Genesys system. Welcome text varies, depending on the workgroup.
5. The Genesys system searches for an available chat agent.
   • If no agent is available, the chat interaction is queued (see section “Distribution Logic,” for the queuing logic) until an agent becomes available. Wait time and the option to leave a chat voicemail can be configured to send to the website visitor during wait time.
   • If the website visitor ends the chat session, the business flow ends.
   • If the final timeout is reached, the chat is ended and the website visitor is informed. The business flow ends.
6. When the chat request is routed to an agent, the agent can either accept or ignore the chat interaction. If the agent does not accept the chat interaction, Genesys attempts to route the interaction to another agent after a specified timeout. The first agent is set to not ready (Did Not Answer).
7. If the agent accepts the chat interaction, the chat session between the agent and the website visitor is established. The agent sees the full chat session and context within the desktop. The agent can use standard responses based on the workgroup for the chat interaction.
8. When the chat session is finished, the agent can set a disposition code to register the outcome of the chat for reporting purposes.
9. The website visitor has the ability to print a transcript of the chat session. Additionally, with the optional Interaction Recorder license, visitors can receive an email with a transcript of the chat session.

1. The user searches in Twitter/Facebook for the company's handles.
2. User reports a customer care issue via a Tweet, Twitter DM, Facebook Post, or Facebook Messenger message to the attention of the company.
3. Genesys monitors the Twitter/Facebook handles via predefined events and filters the message using keywords to determine actionability (routing to workgroups).
4. Genesys searches for an available agent within the configured workgroup.
   1. If an agent is available, the interaction is routed to an agent.
   2. If no agent is available, the interaction is queued until an agent becomes available.
5. The interaction is sent to the next available agent for appropriate response.
6. The agent will decide if the interaction requires private comments.
   
   • If no private answer is required, the agent will reply via the company Facebook page or company's Twitter handle.
   • If private messaging is required, the interaction will be moved out of the public comment space and will be dealt with via private messaging (Twitter direct message or Facebook Messenger private message).
   • Best practice for the agent is to respond to a public message with a public response, indicating that the conversation might be moved to private.
7. When the interaction is finished, the agent can set a wrap-up code to register the outcome for reporting purposes.

1. The website visitor browses the company's website and requires help.
2. Customer checks if agents are available, logged in, the wait time (through the use of Genesys APIs) or creates their own schedules to be able to make intelligent decisions as to when to offer the callback feature to their visitors. The visitor clicks the Callback button.
3. The website has the option to display a brief registration page to the visitor. Genesys provides a standardized template for the company website to configure callback options.
4. The visitor enters their name and phone number. The following are options the customer can develop for website or mobile visitors:
   1. Automatically set the name and phone number for an authenticated visitor.
   2. Use page-specific logic to designate a specific workgroup for call routing, based on the webpage from which the callback is requested.
5. The visitor chooses to make the callback and a corresponding callback request is created within the Genesys system.
6. The visitor receives the message that an agent will call back. The message also includes the average wait time for the queue.
7. The callback is queued to be distributed to the appropriate workgroup.
8. When an agent becomes available, the agent receives a callback pop-up. The agent initiates the call.
   1. If the site visitor does not answer the callback, the agent is given the option to disconnect or retry later.
   2. If the agent selects disconnect, the callback ends.
   3. If the agent selects retry later,the system uses a configurable time and number of attempts for the callback.
   4. Callback is presented for the agent to retry for the number of attempts designated in the system.
9. The callback recipient accepts the call and is connected to the agent.
10. After the conversation between the agent and the callback recipient ends, the agent can mark the callback as successful and set a wrap-up code for reporting purposes via the agent desktop.

1. A customer sends an SMS to a company short code or long code number. The SMS message is captured from a carrier and passed to Genesys to be handled by agents.
2. The new SMS message is captured by Genesys, including the customer's phone number as metadata.
3. Genesys will pull in additional customer information available within IC agent desktop. (Tracker data)
4. The system can send out a receipt acknowledgement SMS to the customer with a predefined template configured in Administrator. (Optional)
5. Once an agent within the workgroup for the short/long code is available, the SMS is routed to the agent's desktop application with screen pop showing related SMS information. Any available contact information from Tracker data will be displayed.
6. Once the agent reads the SMS, he or she needs to decide if a reply is needed.
   • If no reply is needed, the agent marks the interaction as done.
   • If a reply is needed, the Agent replies in the chat window, potentially using a standard response template.
7. The agent sets a disposition code to mark the business outcome for reporting purposes once they disconnect the interaction.

1. A chat interaction is initiated (reactive or proactive) across a supported channel.
2. The customer receives a standard welcome message from the chatbot.
3. Customer information and/or context is retrieved from:
   • Genesys User Data (e.g. Altocloud Segment or from the website passed by Genesys Widgets)
   • Journey context available from Altocloud or customer journey data
   • API call to third-party data source
4. The customer receives a personalized message/menu or is handed over to an agent. Examples include:
   • Custom message or update: "Your next order is due to be delivered on Thursday before 12."
   • Most likely contact reason: "Do you want to find out about the loan application you have in progress?"
   • Tailored menu with most likely options: "Main menu: you can choose Balance, Payments, or TopUps."
   • Self-service task, such as loan application, is executed based on Segment provided by Altocloud or other attached user data.
   • Customer is handed over directly to an agent because they have an outstanding balance (or is able to request a callback).
   • If the customer is not handed over to an agent, the customer could end their chat, confirm the contact reason, or continue.
5. Assuming the customer has moved on from the Personalization stage, the chatbot asks an open-ended question like: “How may I help you?” to determine intent and capture the customer's response. (BL3)
6. The customer's response is then sent to a third-party NLU engine via API. (BL1-BL4)
   • If intent and entities are returned, the conversation moves to the correct point in the interaction flow, which could be within one of the following sub-flows (or microapps):
     • Identification and Verification.
     • Automated business process (such as payment collection microapp).
     • Hand-off to live agent or request a callback (see the relevant use case for the channel).
   • If intent and entities are not returned the chatbot returns a retry message like: "Sorry, we didn’t understand your question. Please ask another question or reply AGENT for live assistance."
     
7. Upon completion of a task, the chatbot asks a follow-up question like: "Is there anything else I can help you with?" (BL2-BL3)
   • If the customer responds “yes,” they're brought back to Step 5: "How may I help you?”
   • If the customer responds “no,” the chatbot decides whether or not to offer them a survey (see the next step).
   • If the customer responds with a more advanced answer, the response is sent to a third-party NLU engine via API to determine intent and entities for further processing.
8. Customer information and/or context is retrieved to determine whether to offer a survey. (BL5)
   • Logic defined in Intelligent Automation
   • If a survey is to be offered, the chatbot continues to the next step.
   • If no survey is to be offered, the chatbot continues to step 11 and shows a goodbye message.
9. The chatbot asks the customer: "Would you like to participate in our survey?"
   • If the customer answers "yes," then they continue to the next step and engage in a survey.
   • If the customer answers "no," then they continue to the final step and are shown a goodbye message.
10. The chatbot offers the customer a survey. The survey questions are configurable by the customer on a business-as-usual basis and therefore no dialog flow is defined here. This dialog uses the Intelligent Automation Questionnaire Builder microapp.
    • The chatbot presents a concluding message and ends the chat.
      

1. The customer starts browsing the company website.
2. Genesys determines whether the customer is new or returning to the website, and associates data from previous journeys.
3. The combination of segment and variations in outcome score can trigger an offer to chat with an agent or with a chatbot while the customer is browsing the website.
4. An algorithm determines the predicted availability of agents to handle the interactions.
5. If the customer accepts the invitation for chat, a registration window pops up where the customer can enter his data and the conversation with Genesys Blended AI Bots (CE31 Use Case) will start. In the registration form, customer can either manually enter his contact details (name, email) or contact details will be pre-filled if already known to Genesys.
6. In Genesys Routing logic, a decision can be made based using context (for example, customer segment, customer lifetime value) and current agent availability
   

1. Genesys routes the interaction to an agent based on the skills, media, language, and other ACD routing choices.
2. An agent and customer are in conversation. The agent has access to full visitor context such as segment, journey information, and outcome score.
3. After the conversation ends, the agent sets a disposition code within their desktop to record the outcome of the conversation.

1. A voice interaction is initiated (reactive or proactive) on the voice channel.
2. The customer hears a standard welcome message from the voicebot.
3. Customer information and/or context is retrieved from:
   • Customer profile information stored in PureConnect
   • Genesys User Data
   • API call to third-party data source
4. The customer hears a personalized message or menu or is handed over to a voice agent. Examples include:
   • Custom voice message or update, such as "Your next order is due to be delivered on Thursday before 12"
   • Most likely contact reason, such as "Do you want to find out about the loan application you have in progress?"
   • Customer is provided personalized menu options.
   • Customer is routed over directly to a voice agent. For example, if they have an overdue payment or a callback is scheduled. If the customer is not handed over to a voice agent, then at this point the customer could end their call, confirm the contact reason, or continue.
5. Once the customer has moved on from the Personalization stage, the voicebot asks an open-ended question like: “How may I help you?” to determine intent (and entities) and capture the customer's response.
   • The customer speaks to the voicebot in natural language. For example, the customer could say “I missed a bill payment and want to check my balance because I think I'm in arrears”
   • The voicebot listens to the customer and converts the raw spoken utterance into text.
6. The voicebot then sends the customer's response to the configured NLU engine. If intent and entities are returned, the conversation moves to the correct point in the interaction flow, which could be within one of the following subflows:
7. Identification and Verification (ID&V)
   • Automated business process (such as Payment Collection microapp)
   • Handoff to live voice agent or schedule a callback (see the relevant use case for the channel).
   • If intent and entities are not returned and the organization has Genesys Knowledge Center (GKC) or of third-party Knowledge Base, the system passes the raw textual transcription to be Knowledge Base to look for a result using the Knowledge Base API. If a relevant knowledge article is found, the results are played back to the customer and the customer moves to the next step. If a relevant knowledge article is not found, the voicebot plays a prompt like: "Sorry, I didn’t find any results. Re-phrase or say AGENT for live assistance." If intent and entities are not returned and the customer does not have a Knowledge Base, the voicebot plays a prompt such as: "Sorry, I didn’t understand your question. Please ask me another question or say AGENT for live assistance."
   • Fall back to DTMF is an optional capability that can be quoted by Professional Services separately as it is not included in the scope of this use case.
8. Upon completion of a task, the voicebot asks a follow-up question like: "Is there anything else I can help you with?"
   • If the customer says something like “yes”, they're brought back to Step 5: "How may I help you?”
   • If the customer says something like “no”, the voicebot decides whether to offer them a survey (see the next step). If the customer responds with a more advanced answer, the NLU Engine determines intent and entities for further processing.
9. Customer information and/or context is retrieved from the following sources to determine whether to offer a survey which is available within Genesys Intelligent Automation only (steps 8–10):
   • Customer profile information stored in PureConnect
   • Genesys User Data
   • API call to third-party data source
   • logic defined in Intelligent Automation
   • If a survey is to be offered, the voicebot continues to the next step.
   • If no survey is to be offered, the voicebot shows a goodbye message and ends.
10. The voicebot asks the customer:"Would you like to participate in our survey?"
    • If the customer answers something like "yes", then they continue to the next step and engage in a survey.
    • If the customer answers something like "no", then the customer is shown a goodbye message and the voicebot ends.
11. Optional: If the survey results meet a certain criteria based on the configured evaluation parameters, a specific action can be taken. For example, if the customer provides a negative response, they can be routed to a live agent.

1. Customer calls one of the service lines of the company.
2. An announcement is played to the customer that the call is going to be recorded.
3. The call is handled and routed to an agent following the logic of the Inbound Voice distribution strategy which is implemented for the Service Line. This can be either the use case "CE01 - Connect a voice interaction to right resource" or "CE02 - Personalized & Value Based Voice Routing". The Inbound Voice routing strategy is not within the scope of this use case.
4. Genesys Interaction Recorder starts the recording.
5. Agent answers the call from any desk within the site.
   • The agent may (if enabled) pause/resume the recording manually via the standard configuration with Genesys CIC Client when sensitive data needs to be entered.
6. Customer or Agent disconnects the call.
7. Genesys Interaction Recorder stops and stores the recording.
8. Supervisor searches for, retrieves and listens to a recording made by one of their agents.
9. Legal and Compliance officer checks the system for compliance and retrieves recordings for legal purposes.
10. Genesys Interaction Recorder archives and purges recordings according to the rules defined in the system.

1. Customer makes a call to one of the service lines of the company.
2. The IVR announces that the call will be recorded.
3. The call is handled and routed to an agent following the logic of the inbound voice distribution strategy which is implemented for the service line. This can be one of the existing inbound voice use cases (see these use cases for more details). The inbound voice routing strategy is not within the scope of this use case.
   • Based on initiation policies, which the administrator sets in Genesys, it is determined if the screen needs to be recorded.
4. Genesys Interaction Recorder starts the voice recording.
   • If step 3a determines that the screen needs to be recorded, Genesys Interaction Recorder starts screen recording as soon as the agent answers the call.
5. The agent can answer the call from a single, dedicated desk within the site (product limitation).
   • The agent may (if enabled) pause or resume the recording manually via the standard configuration with the Genesys Customer Interaction Center client when sensitive data is required.
6. The customer or agent disconnects the call.
7. Genesys Interaction Recorder stops the voice recording. Screen recording stops after the configured ACW period has ended.
8. Genesys uploads the screen recording files to the central system immediately or at configured intervals.
9. The supervisor searches for, retrieves, and listens to a recording made by one of their agents.
10. The legal and compliance officer checks the system for compliance and retrieves recordings for legal purposes.
11. The quality manager searches for, retrieves, and listens to recordings to use in agent evaluations.
12. Genesys Interaction Recorder archives and purges recordings according to the configured rules.

1. Set up Users: The IT Administrator sets up user roles and a related set of permissions. Standard users include:
   • Admin
   • Form Designer
   • Evaluation Planner
   • Evaluation Reviewer
   • Supervisor
2. Setup up questionnaire directories by assigning
   • Role-based access rights for questionnaire directory access.
   • Additional metadata configuration (relevant to QM).
   • Initiation and retention policies criteria and actions to auto-assign questionnaire scorecards to recordings and scoring users.
3. Setup the questionnaire directory and questionnaire: From within IC Business Manager, use the Quality Manager views to create and save a Questionnaire with the following:
   • Questionnaire ranking
   • Questionnaire group
   • Questionnaire questions
   • Scoring requirements
4. Publish the questionnaire once the evaluation strategy has been completed to allow the questionnaire scorecards to be assigned to recordings and used for reporting purposes.
5. Evaluation/calibration planning: The evaluation planner plans review sessions for CC sites, groups or individual agents. The planner decides how to configure Interaction Recorder initiation and retention policies to auto-assign questionnaire scorecards based on incoming recorded interactions. Questionnaire scorecards may also be manually assigned to recorded interactions from within IC Business Manager, based on other interaction criteria or recording attributes. Details tasks:
   • Attach questionnaire scorecard forms to recorded interaction
   • Assign evaluators (scoring users)
6. Complete assigned questionnaire scorecard: The evaluation planner/supervisor conducts reviews of the appropriate teams and gives feedback and insight into how many reviews need to take place, what has been done, and what is in progress or still pending. Detailed actions:
   • Select a recording.
   • Play back the selected recording.
   • Score a recording with the auto-assigned questionnaire scorecard.
   • Score a recording with a manually assigned questionnaire scorecard.
   • Finish the scorecard.
7. Create Quality Management Reports: The evaluation reviewer monitors performance on progress results displays and uses report templates that are relevant for the actors' role to display. This can be part of a dashboard, background report, or email subscription. Detailed actions:
   • Run an instance of a selected Quality Management report.
   • Run a calibration report for completed scorecards that were marked for calibration.
8. Supervisor reviews scorecards with agents: The supervisor pushes a report to the agent to provide feedback. The agent is informed about their performance.
   • Agents review their recently completed scorecards.
   • Agents acknowledge and provide comments (sign-off) for completed scorecards that require action.

Call options provided

1. The call routes to a business user.
2. The business user can use the client to pick up the call.
   • If the business user has the find-me/follow-me option configured, the call is routed to the forward number configured.
   • If the business user does not pick up either at the desktop client or at the find-me/follow-me number, the call goes to voice mail.
3. Unified communications provides notification of pending voice mail.