View table: SMART_BusinessImageFlow

Jump to: navigation, search

Table structure:

  • BusinessFlow - Wikitext
  • BusinessImage - String
  • BusinessFlowDescription - Wikitext

This table has 238 rows altogether.

Page BusinessFlow BusinessImage BusinessFlowDescription
UseCases/Current/GenesysCloud/CE07 https://www.lucidchart.com/documents/edit/c88e425c-c449-427b-a283-ecbaa810b672#
  1. The IVR answers a call.
  2. If enabled, Genesys Cloud CX identifies a customer using the Automatic Number Identification (ANI) / Caller Line Identification (CLI). BL1
  3. If ANI / CLI are available, Genesys Cloud CX performs a lookup in the company's back-end system (for example, the CRM) to identify the caller.
  4. If identification via ANI / CLI is disabled or fails, Genesys Cloud CX asks for a separate Identifier (for example customer ID, account number, tracking number, or alternate phone number) to identify the customer. The caller must respond to this question by entering a numeric value. If the customer does not have the required information, they can opt out and proceed down an unauthenticated path.
  5. The customer input is validated against the enterprise/organization's back-end system (for example, the CRM). If a match cannot be found, Genesys Cloud CX asks the customer for their identifier. Genesys Cloud CX requests this information up to a maximum of three times after failure. The number of retry attempts is configurable. If Genesys Cloud CX cannot successfully validate the customer, the customer is transferred to a queue for agent-assisted service.
  6. If needed for security purposes, Genesys Cloud CX can ask for additional information to validate the caller's identity. The caller must respond to this question by entering a numeric value.
  7. Genesys Cloud CX validates the information entered against the organization's back-end system (for example, the CRM). If this validation is unsuccessful, Genesys Cloud CX asks the customer for security information again, up to a maximum of three times after failure. The number of retry attempts is configurable. If Genesys Cloud CX cannot successfully validate the customer, Genesys Cloud CX transfers customer to a queue for agent-assisted service.
  8. After successful identification and verification, Genesys Cloud CX transfers the call to the next step of the overall call flow. This step could be an agent-assisted service or a self-service application. To simplify subsequent interactions during this call, Genesys Cloud CX retains the customer identifier and verification status. Later Genesys Cloud CX can display this information to an agent by using scripts.
UseCases/Current/GenesysCloud/CE08 https://www.lucidchart.com/documents/edit/7f7b2238-16e4-4281-b911-88ef0f341726/0
  1. A customer is transferred to the payment capture IVR application. This transfer can occur either from another IVR application (outside of the scope of this use case) or by an agent who initiates a secure payment transfer. When an agent transfers a customer to the secure payment capture IVR application, the agent is temporarily removed from the call and is unable to listen to the conversation. In Genesys Cloud CX, the agent remains reserved to resume the call after the payment processing is completed.
  2. Genesys Cloud CX checks whether the customer has been identified. If not, Genesys Cloud CX routes the customer to a separate application for identification and verification. This functionality is covered by a separate use case, Genesys Customer Authentication (CE07) for Genesys Cloud.
  3. If identification and verification succeeds, the customer moves to the next step. If not:
    • If the payment attempt is fully automated, the customer is transferred to a queue with context for manual processing by an agent.
    • If the payment attempt is agent-assisted, the caller is transferred back to the agent and the customer and agent continue their conversation.
  4. Genesys Cloud CX prompts the caller with the payment amount. This amount could be any of the following:
    • Retrieved by the IVR via a data dip (outside of the scope of this used case)
    • Based on what an agent has entered before initiating the payment capture IVR application
    • Entered by the caller. If this is the case, Genesys Cloud CX enables the customer to enter a payment amount. (If the payment attempt is agent assisted, only DTMF input is permitted). 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 retrieved from the IVR or the agent.
  5. The customer enters their card number.
    • Genesys Cloud CX checks via the integration whether the card number is valid and what type of card it is. Depending on the type of card, the customer is requested to provide further details (such as expiration date and/or CVV code).
    • After every field entry (for example, card number, expiration date, and CVV code), the entry is read back and the customer confirms or re-enters the entry.
  6. Genesys Cloud CX accesses the payment gateway or CRM to process the payment. This will either be rejected or successful.
  7. If rejected, the customer can re-enter their card details until the maximum number of rejections is met, at which point:
    • If the payment attempt is fully automated, Genesys Cloud CX transfers the customer to a queue with context for manual processing.
    • If the payment attempt is agent-assisted, Genesys Cloud CX transfers the caller back to the agent, and the customer and agent continue their conversation.
  8. If the payment is successful, Genesys Cloud CX 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.
  9. If the payment attempt is fully automated, the call continues in the IVR application. If the payment attempt is agent-assisted, the caller can be transferred back to the original agent (optionally). The result of the payment is attached to the call for further processing.
UseCases/Current/GenesysCloud/CE09 https://www.lucidchart.com/documents/edit/e58fc719-abbd-4197-be1c-ecf1f3720874/0
  1. A customer calls a service line that belongs to the company and progresses through the routing strategy. The routing strategy is not in the scope of this use case.
  2. An IVR application answers the call. The full IVR application is not within the scope of this use case. However, but the functionality in this use case can be used as a model to enhance the IVR application with personalization options.
  3. If the customer must be identified and authenticated (verified), the identification and verification (ID&V) interaction uses one or more identifiers (for example, customer ID or account number). Customer identification may be verified by a PIN, if necessary. This functionality is offered byGenesys Customer Authentication (CE07)use case, which this scenario leverages. The identification and verification functionality itself is not within the scope of this use case.
  4. Using the customer identifier (for example, ANI), Genesys can retrieve customer context information from a third-party system (optional).
  5. The decision to provide personalized treatment comes from submitting context to business rules natively, using third-party systems or using internal data. Personalized treatments include:
    • Play a personalized message to the customer.If the customer has all required information, they may hang up at this point. For example, the system identifies that the caller is in a region with a power outage and plays an announcement to convey the status.
    • Proactively play a status or balance before presenting any options to the customer. For example, “Your next order is due to be delivered on Thursday.”
    • Proactively offer the most likely call reason. For example, “Are you calling about the loan application that you have in progress?”
    • Offer menu variations that are personalized for different contexts. For example, only play the main menu variant, which includes mortgage option if they have a mortgage or present a promotion option if they are eligible.
    • Send the customer to:
      • A queue with updated context.
      • A self-service application (not in scope).
      • A generic menu if the caller does not fit any of the configured personalization options. In this case, the caller continues to the standard main menu of the IVR application. Since this use case is about personalization, the development of this main menu is out of scope.
UseCases/Current/GenesysCloud/CE11 (1) https://www.lucidchart.com/documents/edit/c7359fcc-d975-4181-b638-5b16f0a6523b
  1. An admin (or Genesys PS) configures the campaign strategy and settings in Genesys Cloud CX.
  2. The admin loads the contact(s) in Genesys Cloud CX. This is done either manually via a .csv file or via the API.
  3. The campaign begins contacting consumers based on the campaign strategy set in Step 1. Before starting a call, Genesys Cloud CX checks each contact or record against the associated Do Not Call lists. Genesys looks at the callable time set or the time zone mapping (depending on the customer's preference), and any other custom rules the customer has designed. (BL1, BL2)
  4. The person constructing the campaign in Genesys Cloud CX configures the dialing mode as Preview, Progressive, Power, Predictive, or Agentless - see Outbound Dialing Flow for details
  5. For an outbound IVR, there are several possible results (BL1, BL2, DR1) - See Outbound IVR flow for details
  6. Based on the call result, Genesys Cloud CX may make additional attempts to reach the contact in the same channel. This is configured in the campaign settings in Step 1 of this use case. (DR1)
UseCases/Current/GenesysCloud/CE11 (2) Outbound IVR Flow https://www.lucidchart.com/documents/edit/d1b8eded-e0ec-429f-b7c8-309ed4e1de24/0 For an outbound IVR, there are several possible results (BL1, BL2, DR1):
  • Bad number or no answer
    • The call disconnects.
    • Genesys Cloud CX automatically stores the call result.
  • Answering Machine
    • The call either disconnects, is sent to a queue to be handled by an agent, or a message is played (based on the chosen configuration in Step 1).
    • Genesys Cloud CX automatically stores the call result.
  • Live party connect
    • The call plays the outbound IVR message.
    • The contact can opt out of future calls. To do this, include the IVR option, “Press 9 to opt out of future calls.”
    • (Optional) The customer's admin can offer the option to connect to a live agent (based on the chosen configuration.) To do this, include the IVR option, “Press 2 to connect to a live agent” and then route calls to a phone number provided by the company.
    • If the contact does not choose to connect to a live agent, the call disconnects.
    • Genesys Cloud CX automatically stores the call result.
UseCases/Current/GenesysCloud/CE11 (3) Outbound Dialing Flow https://www.lucidchart.com/documents/edit/e88803bb-06ae-42e7-8a92-0f58459b6d07/0 The person constructing the campaign in Genesys Cloud CX configures the dialing mode as Preview, Progressive, Power, Predictive, or Agentless:
  • In Preview mode, the agent receives or retrieves a record and initiates the call. An optional timer automatically launches the call for the agent.
  • In Progressive mode, Genesys Cloud CX automatically places the call-based agent availability for the specific campaign. Call analysis ensures connections (human or machine answers).
  • In Power mode, Genesys Cloud CX automatically places calls in parallel based on a pacing algorithm that determines when an agent is available.
  • In Predictive mode, Genesys Cloud CX automatically places the call based on the pacing algorithm and expected agent availability.
  • In Agentless mode, Genesys Cloud CX automatically places calls based on the number of lines specified in the campaign settings. Depending on whether a machine or live person answers the call, the call can either be transferred to an outbound flow (IVR) or disconnected.
  • For each call attempt, there are several possible results:
    • Bad number or no answer:
      • In Preview mode, the agent hangs up and chooses a wrap-up code that Genesys Cloud CX stores with the call record.
      • In Progressive, Power, Predictive, or Agentless modes, the call disconnects and Genesys Cloud CX automatically stores the call result.
    • Answering machine:
      • In Preview mode, the agent can optionally leave a message. Based on the wrap-up code chosen by the agent, Genesys Cloud CX could try the call again later. Genesys Cloud CX automatically stores the call result.
      • In Progressive, Power, Predictive, or Agentless modes, the call can be disconnected, sent to an agent's queue, or sent to the outbound Architect flow (IVR) to hear a message (based on the chosen configuration in Step 1). Genesys Cloud CX automatically stores the call result.
    • Live party connect:
      • The call plays the outbound IVR message.
      • The contact can opt out of future calls. To do this, include the IVR option, “Press 9 to opt out of future calls.”
      • (Optional) The customer's admin can offer the option to connect to a live agent (based on the chosen configuration.) To do this, include the IVR option, “Press 2 to connect to a live agent” and then route calls to a phone number provided by the company.
      • If the contact does not choose to connect to a live agent, the call disconnects.
      • Genesys Cloud CX automatically stores the call result.
UseCases/Current/GenesysCloud/CE12 (1) Trigger-based SMS https://www.lucidchart.com/documents/edit/41ff724d-36fb-48cc-a949-d42891c59a68/0
  1. Create or use an existing OAuth client
    • Customers need an OAuth client with the Conversation:Message:Create permission assigned to the OAuth client. See link for more info.
  2. Generate an OAuth client token
    • To call the endpoint to send agentless outbound SMS notifications, customers need to use an OAuth client to generate a token.
      They need to make sure to build the basePath for the correct Genesys Cloud CX region they are working in. For more information, see link.
  3. Use the OAuth client token to call the agentless outbound SMS endpoint. For more information reference the tutorial.


UseCases/Current/GenesysCloud/CE12 (2) Campaign-Based SMS d78c4195-c2f7-44c3-97fe-d74c07ec6dd4
  1. An Admin (or Genesys PS) configures the campaign settings in Genesys.
  2. The organization either prepares a contact list from a third-party system (such as CRM) or configures their system to use Genesys REST 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.
  3. The customer can specify the SMS message body for each contact record by assigning a column in the list as the message column. Customers can also use a message content template to create a dynamic message using data from the contact list. Best practice recommends that if hyperlinks are used in the message body that the total message content is no greater 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.
  4. The campaign is started and begins contacting consumers based on the settings configured in the first step. The Genesys system checks each contact/record against the Do Not Call lists assigned to the campaign to filter out consumers who should not be contacted.
  5. Message send fail or success status is stored on the interaction.
  6. 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, and the mobile number is added to a suppression list by the aggregator so further messages are blocked by the aggregator.
    • For a START or UNSTOP keyword, the aggregator begins allowing further messages to the consumer.
UseCases/Current/GenesysCloud/CE16 This flow describes the use case from the perspective of the main actors. For example, the customer and the contact center agent. https://www.lucidchart.com/documents/edit/71057e1f-566f-432e-a5b1-a7148f4ab964/0
  1. A customer sends an email to the email address in a registered domain (for example, orders@abc.org) that is configured in the Genesys Cloud CX solution.
  2. Emails are delivered to Genesys Cloud CX via forwarding to a predefined email address, or via direct DNS routing with configured MX records.
  3. Genesys Cloud CX captures the new email and identifies “From,” “To,” "Reply-To," “Subject,” and "Body" as meta data.
  4. Genesys Cloud CX determines whether the email is a new email or a reply email.
    1. If it is a a new email, the system starts a new inbound email flow.
    2. If it is a reply email from a customer, the Genesys Cloud CX attempts to route the email to the agent who previously assisted the customer, if available. If that agent is not available, Genesys Cloud CX starts the inbound email flow.
  5. Optional: The system sends a receipt acknowledgement email to the customer with a predefined template for the “To” address.
  6. Genesys Cloud CX determines the requested skills and transfers the conversation to a queue that can provide those skills.
  7. When an agent with the requested skills is available, Genesys Cloud CX routes the email to the appropriate agent. The agent's interface displays all relevant information about the email.
  8. When the agent reads the email, the agent decides if a reply is needed.
    1. If a reply is needed, the agent creates an outbound reply email. The agent can optionally use a standard response template.
    2. If not, the agent marks the e-mail as done.
  9. The agent sets a wrap-up code to mark the business outcome for reporting purposes.
  10. Optional: A supervisor reviews the email.
UseCases/Current/GenesysCloud/CE18 This flow describes the use case from the perspective of the main actors. For example, the customer and the contact center agent. The diagram shows the business flow of the use case: https://www.lucidchart.com/documents/edit/d5f6c93c-f49e-4ab7-8b73-7ccb20e6de67/0
  1. The customer requests to chat with a live agent via the webpage.
  2. The chat pop-up window opens for the customer.
  3. Based on chat configuration, the customer receives a welcome message from Genesys.
  4. Genesys searches for an available chat agent.
    • If no agent is available, the chat interaction is queued until an agent becomes available.
    • If the customer ends the chat session, the business flow ends.
  5. When an agent becomes available, the chat request is routed to an agent.
  6. The agent either accepts or ignores the chat interaction. If the agent does not accept the chat interaction, after a specified timeout Genesys attempts to route it to another agent (Step 4) and sets the first agent to Not Responding.
  7. If the agent accepts the chat interaction, the chat session between the agent and the customer is established. The agent can use standard responses based on libraries that are available to them for the chat interaction with the customer.
  8. When the chat session ends, the agent can set a disposition, or wrap-up, code to register the outcome of the chat for reporting purposes.
UseCases/Current/GenesysCloud/CE27 https://www.lucidchart.com/documents/edit/322bc033-f6b0-462f-b0a3-a9b12bafd567/0
  1. The customer and agent are connected via a chat session or a voice call.
  2. The agent may propose to the customer to start a co-browse session to support him/her on the website. For security reasons, the customer and agent have to initiate the co-browse session.
    • Call only: A security ID is displayed to the agent if he/she clicks the 'screen sharing link' in the Genesys Cloud CX UI. This security key is then given over the phone by the agent to the customer and entered by the customer. The customer enters the security key into the website to start the co-browse session.
    • Chat only: The customer clicks the 'start sharing' option when asked the question if they want to share their screen.
  3. When the session is established, the Genesys Cloud CX UI displays a view of the website in the browser window the customer is using. Agents start co-browse sessions in read-only mode. In read-only mode, the customer and the agent can see each other's mouse pointer but the agent cannot enter any information into the web page, click buttons, or navigate the customer's browser. The agent does have the ability to highlight sections of the page (by clicking) or to add annotations to the page to guide the customer.
  4. If the agent needs to enter information into the web page or to navigate the browser, he/she can send the customer a 'request navigation'.
  5. Once the customer accepts this request, the agent can navigate, fill forms, and click hyperlinks on the web page. Sensitive Data can be masked before presenting to the agent, and agent controls (the ability to fill certain fields or submit forms) can be blocked through instrumentation. The customer can revoke the Write Mode at any time, returning the agent to read-only mode.
  6. The co-browse session ends when any of the following events occurs:
    • The customer chooses to end the co-browse session
    • The agent chooses to end the co-browse session
    • The primary chat or voice interaction is transferred or ended by either the customer or the agent
    • For a WebChat session after 15 minutes of inactivity the session will be disconnected. There is no timeout when using voice.

The primary voice or chat interaction can continue even when co-browse has ended.

UseCases/Current/GenesysCloud/CE29 The following flow describes the use case from the perspective of the main actors, that is user and contact center agent. https://www.lucidchart.com/documents/edit/57ba7272-f944-4204-ad49-41200eb525a4/0
  1. A customer sends an SMS to a company long code, toll-free number, or short code. Reference Resource Center for more information regarding SMS and supported countries.
  2. Genesys Cloud CX receives the SMS message, including the customer's phone number as metadata.
  3. Genesys triggers an Architect inbound message flow for the incoming SMS message.
  4. The Architect flow attempts to recognize the customer by performing a search in External Contacts or external data source (optional).
  5. The inbound message flow performs routing decisions based on the data returned from External Contacts (or External Data source as an option) and also based on message content analysis and keywords
  6. When an agent within the queue is available, the SMS message routes to the agent. A screen pop displays related SMS information. Relevant conversation information appears in the agent script. The agent receives full context of the SMS conversation.
  7. The agent reads the SMS message and determines if a reply is necessary.
    1. If reply is not necessary, the agent disconnects the SMS and assigns a wrap-up code that indicates a response is not necessary.
    2. If a reply is necessary, the agent replies in the chat window, potentially using a standard response template.
    3. If they expect the customer to respond quickly, the agent can leave the conversation open. If not, they can close the conversation.
  8. When the conversation closes, the agent sets a disposition code to mark the business outcome for reporting purposes after the interaction disconnects.
UseCases/Current/GenesysCloud/CE31 When a customer interacts through a supported Genesys digital channel, a chatbot starts. The chatbot first attempts to use context to anticipate why the customer may be engaging and in turn provides personalized messages to resolve the query. If no personalization options exist, the chatbot asks the customer an open question, such as "How may I help?".

Once the customer responds, the chatbot tries to interpret the request to determine intent and then decide what to do next. For example, if the customer replies with “I want to check my balance,” the chatbot would first identify and verify them before showing their balance.

Once the task finishes, the chatbot asks if the customer needs more help. The customer can respond by asking another question, requesting to chat with an advisor, or replying 'no'. If the customer replies with 'no', the chatbot can offer a survey based on context.


If intent is not established or understood, the chatbot passes the customer to an advisor.

If the customer chooses to speak or chat with an agent and there is a long wait time or it is outside business hours, then the chatbot can present a suitable message.

The chatbot continues in this fashion, creating a conversational loop and building context between itself and the customer to better solve their query.


The following diagram shows the business flow of the use case:

92307f69-8aad-4aa1-bcb9-c9848f85e677
  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:
    • Customer profile information in External Contacts
    • API call to third-party data source
  4. The customer receives a personalized message or is handed over to an agent. Examples include:
    • Custom message or update: "Your next order is due to arrive on Thursday before 12."
    • Customer is handed over directly to an agent because they owe an outstanding balance.
    • 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 interaction is sent to a chatbot (for example Genesys Dialog Engine) which asks an open-ended question like: “How may I help you?” to determine intent and capture the customer's response.[BL1]
    • If intent and slots are returned, the conversation moves to the correct point in the interaction flow, for example;
      • Automated notification task (such as display balance)
      • Handoff to live agent
    • If intent and slots are not returned, the conversation returns to the interaction flow and the customer is handed off to an agent.
  6. Upon completion of a task,the interaction is sent to a chatbot (for example Genesys Dialog Engine) which asks a follow-up question like: "Is there anything else I can help you with?"
    • If the customer responds “yes,” they return to Step 5: "How may I help you?”
    • If the customer responds “no,” then the conversation returns to the interaction flow
    • If the customer responds with a more advanced answer, then determine intent and entities for further processing.
  7. Customer information and/or context is retrieved to determine whether to offer a survey.[BL2]
    • If a survey is offered, the interactions is sent to a chatbot.
    • If no survey is offered, the interaction flow shows a goodbye message and ends
  8. The survey is executed. The survey questions are configurable by the customer on a business-as-usual basis in the chatbot and therefore no dialog flow is defined here.
  9. The interaction flow presents a goodbye message and ends the chat
UseCases/Current/GenesysCloud/CE34 Approval Flow 9d6152af-f701-49d4-8bfb-19d89c3e9cdc
  • WhatsApp
    • If the brand was approved by WhatsApp, they can engage with us to get on-boarded to Genesys. We can help with pre-approvals, but a brand should not assume they are pre-approved, because they expressed interest with us, or purchased Genesys Messaging for WhatsApp from us.
    • The customer can go live with Genesys Messaging for WhatsApp. While in beta, WhatsApp may want to check out the company’s implementation before allowing them to go live.
    • WhatsApp tracks a quality score which determines how many unique customers a business may contact per day (1000, 10,000, or up to 100,000). A decrease in quality score may temporarily reduce the number of customers the business may contact.
    • Repeated violations of WhatsApp Terms of Service or persistent low-quality scores may disqualify a business from using the WhatsApp platform.
UseCases/Current/GenesysCloud/CE34 Messaging Flow https://www.lucidchart.com/documents/edit/251ea9e5-0984-4e6b-997e-bd43f1e75e10/0
  1. Company invites the customer to initiate a conversation via messaging e.g. via a custom Click to Action button in their app, on their website, or in an email or promotional materials.
  2. The customer clicks the message icon and sends an initial message to begin the conversation.
  3. The Genesys system checks to see if it can recognize the customer.
  4. For brand new interactions, Genesys Web Messaging, Facebook, Twitter, and LINE pass platform-specific unique IDs; the end customer must volunteer additional information for identity matching. WhatsApp passes the phone number of the customer to help identify who initiated the conversation.
  5. For customers who have initiated a conversation previously, the system pulls the conversation history and presents it to the agent.
  6. The Genesys system determines if the message is part of an ongoing conversation by checking if a message from the same user was received within the last 72 hours.
  7. If the message is part of an ongoing conversation, it is routed to the last agent if they are available.
  8. If the message is not part of an ongoing conversation, it may be routed to a Bot (outside the scope of this use case), or
  9. If the message is not part of an ongoing conversation, the message may be processed by a Genesys Cloud CX Architect Flow and assigned required skills based on keywords.
  10. The message is transferred by skills-based ACD to an Agent queue.
  11. When routed to an agent, the customer and agent begin a conversation. Depending on the conversation topic, the agent can send the customer messages including text, emojis, stickers, URLs, and images.
  12. Customer and agent interact via messaging service and after conversation is complete, agent dispositions the interaction.
UseCases/Current/GenesysCloud/CE37 Main Flow https://www.lucidchart.com/documents/edit/b5e987d7-954c-4cf7-bbc9-bb8390753f61/0
  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 their data and the conversation with Genesys Blended AI Bots (CE31 Use Case) starts. In the registration form, customer can either manually enter their contact details (name, email) or contact details are 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


UseCases/Current/GenesysCloud/CE37 Routing


This diagram details the routing that takes place before and during the chat.

https://www.lucidchart.com/documents/edit/38673dbe-49ce-47b8-aba2-4a876d0d4fd7/0
  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.
UseCases/Current/GenesysCloud/CE41 When a customer calls Genesys Cloud CX, a Voicebot can be initiated. The system asks the customer an open question, such as "How may I help?".

After the customer responds, the Voicebot attempts to interpret the intent of the request and then decides the next step. For example, if the customer replies, "I want to check the status of my flight," then the Voicebot prompts the user for a flight number to fill the required slot for the intent. Once, the intent is detected and all the slots are filled the call returns to the Genesys IVR for fulfillment. For example, a back-end web-service call on the flight number can be used to return the flight status which is then played back to the caller.

If the Voicebot cannot establish or understand the customer's intent, the system routes the call to an agent.

After the Voicebot task ends, the Genesys IVR asks if the customer needs any additional help. The customer can ask another question, request to speak to an adviser, or indicate that no further assistance is needed. If the customer needs no further assistance, the call ends.

If the customer chooses to speak or chat with an agent but faces a long wait-time to reach an agent, or the request.

https://www.lucidchart.com/documents/edit/1502e31d-3752-434c-892b-a7d9b416b728/0
  1. An inbound call interaction starts.
  2. The customer receives a standard welcome message from the system.
  3. The system asks an open-ended question. For example “How may I help you?” to determine intent and capture the customer's response. One intent is always "I want to speak to an agent." (BL1)
  4. The customer response routes to the voicebot. The voicebot converses with the customer to determine intent. The voicebot prompts the customer, as needed, to determine intent and collect all required slots. If intent is recognized and slots are returned, the conversation moves to the correct point in the flow. Otherwise, after a configured number of retries, return a failure message. (BL2, BL1, BL3)
  5. If the flow steers to fulfillment for the intent, then the system uses the slot information returned from the voicebot to complete fulfillment for the intent.
  6. After the task ends, the system asks if the customer needs further assistance. The voicebot can be called on again. The greeting for the second and subsequent invocations can be customized.
  7. If the customer replies that they require no further assistance, the system presents a good-bye message and ends the call.



UseCases/Current/GenesysCloud/CE43 https://www.lucidchart.com/documents/edit/b7f716eb-5283-489e-b7f0-313eb024cff2/0
1 The customer calls one of the contact center numbers.
2 If a personalized flow is configured, the customer optionally routes to it.
3 Depending on the date and time, the caller routed according to predefined announcements and schedules. These announcements are based on the customer context. For example, quality announcements or special promotions and offers for the customer, announcements for potential self-service options. Then direct the caller to:
a. Holiday announcements and routing.
b. After hours announcements and routing.
c. Emergency announcements and routing.
4 The open hours messages play and the caller routes to an IVR menu.
5 The caller selects a topic or option from the IVR menu. If agents are available, they can then route to a callback flow or Expected Wait Time (EWT) flow.
6 The call is distributed to the best agent who:
  • Has the base skills to handle the original request
  • Has the supplementary skills determined by the customer context (optional).
  • If the call cannot be distributed within specific timeouts, A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill and / or reducing the skill level on the base skill.
7 After the conversation with the customer, the agent records the disposition of the call for reporting purposes.
UseCases/Current/GenesysCloud/EE31 Proactive Knowledge Surfacing https://www.lucidchart.com/documents/edit/b9642209-6872-48ef-9455-6b7a91fcc312/0
  1. Genesys connects the user to the live agent.
  2. The agent sees the context (for example bot intents and slots) of the users journey in the agent desktop.
  3. Genesys Agent Assist monitors the voice conversation.
  4. During the voice conversation, the following happens:
    • Real-time audio of the voice interaction is streamed to Google Agent Assist service.
    • Agent Assist displays the real-time transcription of the voice call.
    • Google Agent Assist service returns real-time knowledge suggestions.
    • The suggested content is displayed to the agent automatically in a live stream of suggestions during the conversation.
  5. The agent can do the following with the live stream of suggestions:
    • Click to expand the suggested content or click the address to open the full knowledge base article (BL1).
    • Read the suggested content directly to the customer or use it to assist with the interaction (BL2).
    • Share the recommended content by email, SMS, WhatsApp or other channels*.
  6. The agent can rate (upvote/downvote) to improve the AI suggestions model over time. The more that Agent Assist is used and content rated by agents, the better the suggestions will be in the future. (BL3, BL4).

* Sharing content - future.

UseCases/Current/GenesysCloud/OP01 (1) Inbound PBX Call or Call to a Business User https://www.lucidchart.com/documents/edit/bbafce35-04a3-45a3-b53f-cd34a52e4704/0 Call options provided
  1. The call routes to a business user via Direct Inward Dial (DID) See flow at bottom for Company Directory example.
  2. The business user uses the client to pick up the call.
    1. If the business user has find-me/follow-me configured, the call routes to the configured forward number.
    2. 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 voicemail.
  3. Unified communications provide notification of pending voicemail.

ACD user connects to Business user via chat.

  1. The ACD user searches Directory to find a SME (based on name, department, title, or skills).
  2. The ACD user contacts the back-office SME via chat tool.

ACD user connects to Business user via video.

  1. The ACD user searches Directory to find a SME (based on name, department, title, or skills).
  2. The ACD user opens an internal video and receives product training via screen share tool.

ACD user connects to Business user via mobile application.

  1. The ACD user can still reach Business users in the field via mobile device.

The Company Directory feature allows customers to call an IVR and say the name of the Genesys Cloud CX user they want to reach.

  1. Customer contacts a Genesys Cloud CX user that does not have a DID (or they do not know the DID).
  2. Customer calls the main IVR no. and says the name of the Genesys Cloud CX user they want to reach.
  3. The system automatically connects the caller to the Genesys Cloud CX user.
  4. Notes:"https://help.mypurecloud.com/articles/enable-company-directory-support-menus/"
UseCases/Current/GenesysCloud/OP01 (2) https://www.lucidchart.com/documents/edit/641536f4-a37b-4508-a839-03f2766cb40a/0 ACD user connects to PBX user.


1. The ACD agent reaches out to a subject matter expert in the enterprise.

2. The ACD user sees the status of the subject matter expert in the client.

3. The ACD user performs a warm-transfer to the subject matter expert.

UseCases/Current/GenesysCloud/OP02 Business Flow Description https://www.lucidchart.com/documents/edit/398f72c2-d038-4eea-9473-30090ec24a6a/0
  1. Call enters the IVR.
  2. Based on the customer's phone number, the data action searches for records in the CRM.
    • 2a Caller is identified. CRM record types can include contacts, accounts, cases, custom objects, etc.
    • 2b Caller is not identified. If the caller is not identified based on phone number, the customer can be prompted for other identifying information to locate the contact.
  3. Caller is addressed by name.
  4. Key information from the CRM record is used to make routing decisions and select the appropriate queue.
    • Examples: Subscription level, priority account, products purchased, and NPS.
  5. Information from CRM record is used to set up to five skills required to handle the interaction.
    • Examples: Language, product knowledge, and account retention specialty.
  6. Reference to the CRM record is attached to the interaction using a Set Participant Data action.
  7. The ACD system routes to the available agent with the designated skills in the selected queue.
  8. Agent is presented with the call in a client embedded inside their CRM.
    • Alerting call includes information the agent needs to begin the conversation.
      • Examples: Queue call in on, skills on the interaction, subscription level.
  9. The agent answers call using client embedded inside the CRM.
  10. The embedded client performs screenpop to the CRM record used in the IVR.
UseCases/Current/GenesysCloud/OP04 https://www.lucidchart.com/documents/edit/0467329f-6d1b-4df8-95aa-d6ee35c0c11a/0
UseCases/Current/GenesysCloud/OP04 A Cloud-Based carrier Device


Configure a SIP trunk that connects your on-premises Edge to a carrier device in the cloud.

https://www.lucidchart.com/documents/edit/5739004f-60e4-48da-8c88-51b3f06b52dd/0
UseCases/Current/GenesysCloud/OP04 A Cloud-based PBX Device https://www.lucidchart.com/documents/edit/bb155910-5b6b-4fa4-93f2-8f2fd7e303e9/0
UseCases/Current/GenesysCloud/OP04 A Premises-based Carrier Device https://www.lucidchart.com/documents/edit/3a8aa7fe-2771-49e4-b5fd-2179d4692708/0
UseCases/Current/GenesysCloud/OP04 A Premises-based PBX Device https://www.lucidchart.com/documents/edit/34a1e78f-35b0-4b2b-bd29-660ac40680a9/0
UseCases/Current/GenesysCloud/OP04 BYOC Cloud solutions

With Genesys Cloud CX’s BYOC Cloud solution, you can choose one of two methods to implement either your Carrier connection or your PBX connection.

  • Configure BYOC Cloud by means of a cloud-based carrier device or a premises-based carrier device.
  • Configure BYOC Cloud by means of a cloud-based PBX device or a premises-based PBX device.

The following diagrams illustrate each of these options. For more information, see https://help.mypurecloud.com/articles/byoc-cloud-solutions/.

A Cloud-Based Carrier Device

https://www.lucidchart.com/documents/edit/6ceadaee-e9fb-44d4-8de7-d1aabc7f0dee/0
UseCases/Current/GenesysCloud/OP04 BYOC premises solutions

With Genesys Cloud CX’s BYOC premises solution, configure SIP trunks between your premises-based Edge appliances and a third-party carrier using one of two methods. Use a premises-based carrier device or use a cloud-based carrier device. The following diagrams illustrate both options.

A premises-based carrier device


Configure a SIP trunk that connects your on-premises Edge to an on premises carrier device. For more information, see https://help.mypurecloud.com/articles/byoc-premises-solutions.

https://www.lucidchart.com/documents/edit/8b0a4312-35ad-4033-bb27-46058fab575f/0
UseCases/Current/GenesysCloud/OP04 How does Genesys Cloud CX Voice work?

After an organization enables Genesys Cloud CX Voice, the Genesys Cloud CX Voice administrator purchases new phone numbers or ports current phone numbers to the service. They can then assign phone numbers to users, IVRs, managed phones, or campaigns.

When you use Genesys Cloud CX Voice with a phone, it securely connects over the public Internet to the nearest available Genesys Cloud CX Voice region. After the phone connects to the Genesys Cloud CX Voice region, the phone authenticates and registers with the customer’s Genesys Cloud CX services. TLS encryption secures the communications between the phone and Genesys Cloud CX Voice service.

For more information, see https://help.mypurecloud.com/articles/how-does-purecloud-voice-work/.

https://www.lucidchart.com/documents/edit/be5e832b-dc72-42b2-88be-9bd283b2b0e7/0
  1. Our customer's customer calls an 800 number for sales or support assistance.
  • Our customer purchases a toll-free (1-800-xxx-xxxx) number from a carrier of choice.
  • Anyone can call this 800 number from a mobile device or landline and reach our customer via the PSTN.
  1. PSTN routes the call to the appropriate cloud carrier that is registered to the 800 number.
  2. The cloud carrier connects to Genesys Cloud CX Media Tier & Trunking Services over the Internet.
  3. The call connects to a Genesys Cloud CX ACD or business user via the Internet.
UseCases/Current/GenesysCloud/OP07 Genesys Cloud CX BYOC-Cloud Carrier + Zoom Phone Carrier and PBX 3630a90f-1395-4ba7-9050-36b30f89564e

Genesys Cloud CX BYOC-Cloud + Zoom Phone

Use Case: Zoom Phone inbound call transfer to Genesys Cloud CX IVR

  • Inbound call from PSTN to Zoom Phone IVR
  • Zoom Phone Integration initiates call transfer to Genesys Cloud CX
  • Zoom Phone routes call through Genesys Cloud CX BYOC-Cloud Trunk to Genesys Cloud CX IVR
  • PSTN caller hears Genesys Cloud CX IVR and selects from available options
  • Genesys Cloud CX IVR routes call to correct entity (user, group, queue, etc.)

   

Genesys Cloud CX User warm transfers* call to Zoom Phone User

  • Genesys Cloud CX User initiates warm transfer to Zoom Phone User
  • Genesys Cloud CX initiates call Genesys Cloud CX BYOC-Cloud Trunk to Zoom Phone
  • Genesys Cloud CX ‘Dial Plan’ routes call through Genesys Cloud CX BYOC-Cloud trunk to Zoom Phone
  • Zoom Phone initiates call transfer to Zoom Phone User
  • Zoom Phone routes call through Zoom Phone Trunk to Zoom Phone User
  • Genesys Cloud CX User disconnects from call
UseCases/Current/GenesysCloud/OP07 MS Teams (Calling Plans) + Genesys Cloud CX PCV + MS Teams (Cloud) w/ Cloud SBC 111bf9f8-5b1c-419e-86d7-ebb0c73356ae

Genesys Cloud CX BYOC-Cloud + MS Teams (Cloud)

Use Case: Genesys Cloud CX inbound call transfer to MS Teams Remote User

  • Inbound call from PSTN to Genesys Cloud CX IVR
  • Genesys Cloud CX IVR flow initiates call transfer to MS Teams Phone System (Cloud) User DID
  • Genesys Cloud CX Dial Plan routes call through Genesys Cloud CX BYOC-Cloud Trunk to MS Teams Phone System (Cloud)
  • MS Teams Phone System (Cloud) initiates call transfer to MS Teams Remote User
  • MS Teams Phone System (Cloud) routes call through MS Teams Phone Trunk to MS Teams Remote User

   

MS Teams Remote User warm transfer* call to Genesys Cloud CX User

  • MS Teams Remote User initiates warm transfer to Genesys Cloud CX User DID
  • MS Teams Phone System (Cloud) initiates call through MS Teams Direct Routing Trunk to Genesys Cloud CX
  • MS Teams ‘Dial Plan’ routes call through MS Teams Direct Routing Trunk to Genesys Cloud CX
  • Genesys Cloud CX initiates call transfer to Genesys Cloud CX User
  • Genesys Cloud CX routes call through Genesys Cloud CX Phone Trunk to Genesys Cloud CX User
  • MS Teams user disconnects from call
UseCases/Current/GenesysCloud/WE01 (1) Overall Quality Management Process flow https://www.lucidchart.com/documents/edit/af2bcbd7-4530-45ec-b1fd-1b57afe6c85e/0 Overall Quality Management Process flow

This process flow provides a overview of the complete process of the Quality Management, Recording and STA.

  1. Policies are created to manage the action to be taken on interactions. These actions include delete, retain, archive, export, initiate screen recording, assign for evaluation or calibration, initiate a survey, transcribe audio.
    1. If the Policy action is to Delete the recording - no other actions can be applied to the interaction.
  2. If the Policy action is to retain recording then an interaction is recorded and stored
  3. If policy includes Screen recording - a separate recording for screen activity is available and plays in sync with the interaction recording.
  4. If transcription is enabled then interaction is transcribed into text.
  5. If the interaction is assigned for evaluation - Evaluators receive a notice of assigned evaluations/calibrations
    1. Evaluator completes and releases the evaluation
      1. If assigned for agent evaluation - agent receives a notice when there is completed evaluation available for them to review and optionally comment. Agents can view all of their evaluations through Performance > My Performance > Evaluations.
      2. Supervisors can view performance of their agents through Performance > Agents > Evaluations tab
  6. If assigned for Calibration - Evaluators receive notice of assigned Calibration. Evaluators complete the calibration
    1. Quality Administrator accesses results to compare scoring variations between evaluators
  7. If the policy is assigned to send a survey for an interaction then customer receives survey invitation via email with the survey link. Customer feedbacks from the surveys will be linked to the interaction
  8. Quality and Survey results are linked to recorded interaction and viewed on Interaction Detail. Summary result views provide scoring results and can export for reporting needs.
  9. Supervisor/ Evaluator schedules Agent Coaching session Refer to Use Case WE03.
UseCases/Current/GenesysCloud/WE01 (2) Voice and Digital Recording https://www.lucidchart.com/documents/edit/7662ca7c-9be2-4048-bbf1-04a7fedc805a/0
  1. Quality Management uses policies to manage all ACD recordings. Policies define the criteria that Genesys Cloud CX uses to determine which interaction recordings to retain, archive, delete, export, initiate screen recording, assign for evaluation, and/or calibration, and initiate surveys.
  2. Customer contacts one of the service lines of the company.
  3. For Voice channel, Genesys Cloud CX IVR (Optionally) plays an announcement that the call is going to be recorded.
    1. If Configured for Consent Option - The customer chooses whether to give consent to the recording. For more information about enabling participant recording, see About recording in Genesys Cloud CX and Enable line recording.
      1. If the customer gives consent, Genesys Cloud CX will record the call.
      2. If the customer does not give consent, Genesys Cloud CX does not start recording the call.
  4. Voice -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. For more information, see Genesys Personalized Routing with Callback (CE43) for Genesys Cloud CX. The Inbound Voice routing strategy is not within the scope of this use case.
  5. Agent answers the call from any desk within the site.
    1. The agent may (if enabled) pause or resume the recording manually via the standard script ability when the agent needs to enter sensitive data.
  6. For all Digital routing information, visit the Digital use cases. The routing strategy for chat, email, and messaging is not within the scope of this use case.
  7. Customer or Agent disconnects the interaction.
  8. Recordings are available for use in the Quality Evaluation, Calibration, and Survey Process
UseCases/Current/GenesysCloud/WE01 (3) Screen Recording https://www.lucidchart.com/documents/edit/f7ead9d1-fa47-4c8f-b1cd-f15803bd76c1/0
  1. Add screen recording to a recording policy as one of your actions for any available interaction channel.
  2. In the recording policy, define the length of retention for screen recording.
  3. if the policy specifies that ACW (After call work) should be recorded then ACW is recorded.
  4. The customer makes contact on one of the available interaction channels.
  5. The recording begins. If a matching policy exists, recording begins and is retained.
  6. The agent or API can pause or resume recording.
  7. The conversation ends and streams are synchronized.
  8. The retained recordings are stored.
  9. The supervisor can search for or locate the interaction recording and play it, along with the screen recording of the desktop activity.
  10. Use screen recording along with interaction recording to assess agent performance, training needs, and contact center process improvement opportunities.
UseCases/Current/GenesysCloud/WE01 (4) Quality Evaluation https://www.lucidchart.com/documents/edit/f7eca437-e128-4705-95d2-9fa893a5e46a/0
  1. Set up users. Genesys Cloud CX administrator sets up user roles and a related set of permissions. Standard users include:
    • Quality Admin
    • Evaluator
  2. The Quality admin creates evaluation forms to define key elements of agent behaviors needed to meet contact center business and customer requirements. The form includes:
    • Evaluation form name
    • Question groups
    • Question group weighting (default is even weighting – weights can be adjusted and will always auto balance to equal 100%)
    • Question group properties (NA enabled, default to highest scoring or NA)
    • Questions
      • Question types (template, multiple choices, range, yes/no)
      • Question properties (NA enabled, critical and/or fatal, visibility conditions, comments required)
      • Question Value (numeric whole numbers)
    • Quality admin selects form to publish to make it available for use in assigning evaluations.
  3. Evaluation/Calibration Planning. The Quality admin adds evaluation criteria to recording policies for contact center agent groups or individual agents. The Quality admin sets policy actions to assign interactions randomly to evaluators, including criteria such as number of interactions to be scored per month/week/day. Tasks include:
    • Select interaction type and criteria
    • Select forms
    • Select evaluators
    • Select for agent evaluation or for calibration
    • Optionally: An evaluator with assignment permission selects from list of interactions and assign evaluation to self or to other evaluator.
  4. The evaluator is notified of assigned evaluations. The evaluator proceeds with the reviews for their assigned agents. Genesys Cloud CX evaluator dashboard provides insight to assigned and completed evaluations.
  5. The evaluator releases the evaluation for agent to review. Agent receives notification of completed evaluation available for their review.
  6. Agent accesses quality results in the Genesys Cloud CX ->Performance-> My Performance-> Evaluations tab
    1. Agent checks off acknowledgment they reviewed evaluation and can add any comments.
    2. If agent requests further review - Quality administrator or Evaluator can review and rescore the interaction.
      1. Agent receives notification of rescored evaluation available for their review and same steps as above.
  7. Quality evaluators and Supervisors can access the completed evaluations in the Genesys Cloud CX -> Performance -> Agents -> Evaluations.
UseCases/Current/GenesysCloud/WE01 (5) Post Interaction Survey https://www.lucidchart.com/documents/edit/9220ebd9-d29e-4c6d-b265-1d0e43c94743/0
  1. Create the Survey Form.
  2. Create a survey Canned Response for Get External Contact.
  3. In Architect, create a Survey Invite Flow.
  4. Create a survey policy action to deploy the survey.
  5. The customer receives survey invitation via email that includes a web link to the survey.
  6. Survey results are received and viewable in Genesys Cloud CX:
    • View on the interaction
    • Survey Summary view
    • Survey Details view
    • Add survey data to Queues Performance view
UseCases/Current/GenesysCloud/WE01 (6) Speech and Text Analytics https://www.lucidchart.com/documents/edit/48852f7f-5505-4f5a-9bd2-900dd554244b/0
  1. Voice interaction or digital interaction is recorded in Genesys Cloud CX.
  2. Genesys Cloud CX transcribes voice interaction in near real time based on Queue settings or Flow action; audio is transcribed to speaker separated text.
  3. Words and phrases in voice and digital transcripts are analyzed for customer sentiment; customer sentiment score and sentiment trend are calculated.
  4. Words and phrases in voice and digital transcripts are matched against phrases; based on strictness; for topic spotting.
  5. Users can search for, and pinpoint interactions, based on transcript words or phrases or customers sentiment score or trend.
  6. Users can play back and view interaction transcript and view location of found events (sentiment and topics).
  7. Users can see aggregate sentiment information across agents, queues and flows based through views.
UseCases/Current/GenesysCloud/WE01 (7) Programs and Topics 6cbcb0ed-25f6-489e-9f43-0e2d7d7e986c#
  1. Create a program and map it to the desired Queues and Flows (Create a Program)
  2. Set the program as Default (Select a Default Program)
  3. Create or Update out-of-the-box topics (Create out-of-the-box topics)
    1. Admin -> Speech and Text Analytics -> Actions
    2. Select dialect (i.e. English USA, etc)
    3. If this is a new deployment, select Add new topics
    4. If this is an existing deployment with existing topics, select Merge topics and phrases
    5. Click Generate
  4. Assign the newly created topics to the program created in step #1
    1. Admin -> Programs
    2. Select the program created in step #1
    3. Click on the Selected topics tab
    4. Select the checkbox for the newly created topics
    5. Click Save Draft or click Publish
UseCases/Current/GenesysCloud/WE01 (8) Content Search c9ae4fd6-6d64-49e0-953b-97ee64c40a35#
  1. Go to Performance -> Content Search
  2. Search by voice transcript content
    1. Transcript content – Displays interactions that contain specific word(s) in a transcription, with options to look for exact match, similar or not similar
  3. Search by Sentiment
    1. Sentiment Score: Filter interactions by the customer’s overall sentiment from -100 to +100. This score weighs all positive and negative markers at the end of the interaction to provide an indication of how the customer experienced their interaction with the contact center.
    2. Sentiment Trend: Filter interactions by the customer’s sentiment trend, which is determined by comparing the sentiment in the first half or more of the interaction to the sentiment in the last few phrases of the interaction. 
  4. Search by Topics
    1. Search for transcripts that include selected topics: Interactions that have one or more phrases detected for the selected topics will be returned
    2. Search for transcripts that exclude selected topics: Interactions that do not have any detected phrases for the selected topics will be returned
  5. Save view selections
UseCases/Current/GenesysCloud/WE02 (1) Operation Rules / Basic configuration https://www.lucidchart.com/documents/edit/5d36294a-9a9f-4319-a4ac-f8da975747cd/0
  1. Configure Business Units
    1. Add Business Unit name, Start Day of week, Timezone, Division
    2. Select Historical weeks in Short-term forecasting
  2. Configure Management units
    1. Add Management Unit Name, Division
    2. Add Planning Period, Maximum occupancy %, Planning period length
    3. Set Adherence Thresholds, Target, and Exceptions
    4. Enable or Disable Shift trading and set criteria for automatic review
  3. Configure service goal templates
    1. Add Service goal Group Name
    2. Set Service goals consisting of Interactions answered %, Enable average speed of answer and Abandonment rate
  4. Configure planning groups
    1. Add Planning group name
    2. Select a Service goal template for the planning group
    3. Verify the Agents list who can handle the planning Group are displayed.
  5. Configure/edit time off
    1. Add new Activity Code name
    2. Set Activity category, Length, Enable, or Disable activity code as Paid Time or Work time
    3. Set Time-off limit
    4. Configure Time-off plan
UseCases/Current/GenesysCloud/WE02 (2) Work Plan configuration https://www.lucidchart.com/documents/edit/97fb8731-4c4a-4689-9508-209a55c32e2a/0
  1. Complete the Operational rules/ Basic configuration workflow
  2. Create a new work plan by Adding a new work plan or copy an existing work plan
  3. Create and configure the shifts:
    1. Specify start / end-time for each shift.
    2. Set up break / meal and any other shift-related setting.
  4. Edit Work plan details
    1. Set weekly constraints
      1. Enable or disable weekly paid time
      2. Set minimum and maximum workdays per week
      3. Set minimum consecutive time off per week
    2. Set weekend constraints
    3. Set planning period constraints consisting of
      1. Minimum and maximum days off per planning period
      2. Minimum and maximum paid time per planning period
    4. Set general constraints consisting of Daily paid time divisible, Maximum consecutive working days, and minimum time between shifts
  5. Add Agents to the work plan.
  6. Validate and Save work plan.
UseCases/Current/GenesysCloud/WE02 (3) Forecasting https://www.lucidchart.com/documents/edit/f52d5e33-ccf3-43de-b327-64be17d2e0c1/0
  1. Add a new forecast
  2. Select the start week
  3. Select creation method
    1. Automatic best method selection
    2. Weighted historical index
    3. Weighted historical index with source data import (example)
    4. Import forecast data (example)
  4. Select number of weeks based on the creation method
  5. Add/Generate forecast
  6. In case of Weighted historical index method, select source tab you apply the Source data weight factors for more emphasis on a specific period
  7. Review forecast in the weekly view and multi-week view
  8. Forecasters can manually perform modifications to the forecast
  9. Save forecast
UseCases/Current/GenesysCloud/WE02 (4) Time off Planning https://www.lucidchart.com/documents/edit/b23aeb38-eb75-4a98-a901-f30250b33996/0
  1. Configure the time off Request permissions
    1. Supervisors can Administer time off request Permissions through:
      1. Workforce Management > time off Requests > Add, Administer, Delete, Edit, View and Notify.
      2. Workforce Management > time off limit > Add, Edit, View and Delete.
      3. Workforce Management > time off plan> Add, Edit, View and Delete.
    2. Agents can view and make their time off request through: Performance > Overview > Agent tab > Schedule.
  2. Configure/edit time off Activity code(s).
  3. Set time-off limits.
  4. Configure time-off plans as manual or automated.
  5. Configure time-off limits for auto approve time-off plans.
  6. Supervisor can also Add/approve/deny/edit time off request(s).
UseCases/Current/GenesysCloud/WE02 (5) Scheduling https://www.lucidchart.com/documents/edit/96053bc0-82aa-4451-b675-76604bbf2c98/0
  1. The Workforce manager starts the generation of a new schedule based on a forecast or by adding a blank schedule
  2. Generate schedule
    1. Select Schedule start week
    2. Select number of weeks
    3. Schedule duration
    4. Description
  3. The Schedule engine generates an unpublished schedule.
  4. The Workforce planner opens the generated schedule and manually updates / changes the schedule. The workforce planner can edit the following in a schedule:
    1. Add, move, delete activity
    2. Swap shifts between agents
    3. Add shifts to agents
    4. Reschedule
    5. Publish schedule
  5. View a Published schedule, edit/adjusting activities would change schedule for the agents concerned
    1. Reforecast workload and reschedules
  6. When ready, the workforce manager publishes the schedule and makes it available for the agents.
  7. Modifications to the schedule require republishing the schedule
UseCases/Current/GenesysCloud/WE02 (6) Shift Trading https://www.lucidchart.com/documents/edit/b617f714-489c-4f03-a93c-cf7896fca176/0
  1. Configure trade rules.
    1. Auto approval rules
    2. Agent matching criteria
    3. Activity category trade rules
  2. Configure permissions for agents to participate in shift trades
  3. Manually approve trades that aren’t auto approved
UseCases/Current/GenesysCloud/WE02 (7) Intraday Management https://www.lucidchart.com/documents/edit/05b43867-e606-4327-818b-a5f3a452ebd6/0
  1. View intraday monitoring
  2. View real-time adherence
  3. Edit schedule
  4. Reforecast workload
  5. Reschedule
  6. View historical adherence
UseCases/Current/GenesysCloud/WE03 Coaching https://www.lucidchart.com/documents/edit/58a4f242-8e73-4c36-bd53-2c1c0ff42ce9/0
  1. Genesys Cloud is configured with appropriate user roles and licenses.
  2. Users with relevant permissions such as Supervisors and Quality Administrators can schedule a coaching appointment by:
    1. Clicking on the Schedule Coaching button from the Interaction Detail view to create a Coaching appointment with that interaction included or can add that interaction to an existing Coaching appointment.
      1. Supervisors or Quality Evaluators can find interaction of interest to use for Coaching in multiple ways:
        1. Searching for interactions of interest in Performance > Interactions > Interactions tab using various meta data filter criteria.
        2. Searching for interactions of interest in Performance > Interactions > Content tab using various meta data and speech and text analytics filter criteria.
        3. Directly from a policy based or Ad-hoc Evaluation.
    2. Scheduling a Coaching session by navigating to the Development tabs in the analytics section. In this instance the Coaching session does not necessarily need to be linked to an interaction, allowing Coaching sessions to be created for all requirement
  3. The Coaching Appointment specifies:
    • Date, Time and Duration
    • Agent and Facilitator
    • Interactions
    • Documents
    • Links to URLs
    • Notes – public or private
  4. If the Organization is using Workforce Management for scheduling, the system will return the best 10 time slots for the Coaching Appointment based on existing schedules and staffing levels.
    • A Coaching session is scheduled in the attendee and facilitator’s schedule.
    • If Organization is not using Workforce Management then Coaching is scheduled without a timeslot
  5. Once scheduled, notifications about the Coaching Appointment are sent to all attendee through their Inbox.
  6. Attendees can click on Activity or go to Performance > My Performance > Development tab to see and access any upcoming Coaching Appointments.
  7. Attendees can add notes and complete the Coaching Appointment when done.
UseCases/Current/GenesysCloud/WE03 Development and Feedback https://www.lucidchart.com/documents/edit/5db640ca-31aa-47ce-8264-db108d34d90a/0
  1. Genesys Cloud is configured with appropriate user roles and licenses.
  2. Development and Feedback Modules are created to deliver content to Employees
  3. Modules can contain: Documents, Images, Audio, Videos and Links to URLs
  4. Modules can be assigned to users in one of two ways:
    1. Auto-assignment rules are configured which can include or exclude Employees for assignment based on Groups, Queues, ACD Skills or Divisions.
      1. Modules are Published and delivered to Employees immediately or overnight if Group, Queue, ACD Skill or Division memberships are updated.
    2. Users with relevant permissions are able to navigate to the Development tabs within Analytics and assign modules at an individual level by selecting from a list of available modules. This allows Managers to assign content to individuals at the point of need to resolve challenges at an individual level
  5. Once assigned, a notification about the assigned Modules is sent to the Employee through their Inbox.
  6. Employees can click on Activity or go to Performance > My Performance > Development tab to see and access any assigned Modules.
  7. Employees can mark a Module as Complete when done.
UseCases/Current/GenesysCloud/WE03 Performance Management and Gamification https://www.lucidchart.com/documents/edit/a34d9685-e739-45af-99e3-80f682392871/0
  1. Genesys Cloud is configured with appropriate user roles and licenses.
  2. The Gamification Profile is updated with the specific set of Metrics to include as part of managing the performance of your Employees.
    1. For each Metric, specific objectives are set, along with the number of points to award based on the performance achieved.
  3. Gamification is globally activated for the Organization, subsequently, the system monitors performance and awards/subtracts points accordingly.
    1. Admins can also set a Start Date for Gamification.
  4. For those Employees participating in Performance Management and Gamification, the correct permissions must be assigned so that they can access the Activity page.
  5. The Activity page provides Employees with one-click access to all of their upcoming and outstanding tasks as well as access to their performance information, this includes:
    1. Today’s schedule for the Employee, highlighting what activity is next if scheduled through workforce management.
    2. Any upcoming Coaching Appointments or assigned Development and Feedback Modules.
    3. Performance Scorecard with historical trend information.
    4. Leaderboards for overall and per metric performance.
  6. Supervisors can view an Employees’ Scorecard through Performance > Agents > Scorecard tab.
  7. Supervisors can view overall Leaderboards through Performance > Agents > Leaderboards tab.
  8. Supervisors and Admins can reset the Gamification if needed.

UseCases/Current/GenesysEngage-cloud/BO02 (1) Part 1 - Capture and Distribution / Lead Generation

The diagrams in the following chapters show the business flow of this use case.


https://www.lucidchart.com/documents/edit/1e839c49-d7a9-4362-81ed-c8fa6dc8bb54/0
  1. The system creates a new item in the system with all attached data necessary to process. For leads, see the "Attributes" topic. The source system requires an employee to handle a work item. The source system is the BPM, CRM, or business system that stores and processes the work items associated with said business process. Genesys intelligent Workload Distribution creates the corresponding work item via the Genesys Cloud CX RESTful Capture Adapter.
  2. Genesys captures the new work item and handles the creation of a new interaction in the system.
  3. The interaction is classified and prioritized according to specific lead rules and the business value of the lead (or) the nature of the work item. The lead and work items reprioritize continually if they fail distribution to an employee.
  4. The lead/work item is queued with all other interactions in the Genesys system. The priority of these items defines the position in the global queue. Once an employee with the right skill profile becomes available to handle the work item, the item distributes to that employee. If the system cannot assign it within a specified period, it remains reprioritized.
  5. The respective employee (could be lead development representative or an Agent) is able to open the task in the Workspace Desktop to manage or complete the task.
  6. The lead development representative could use the contact provided by the customer to contact the lead. For work items, the agent could open them with their respective CRMs to further handle the task.
UseCases/Current/GenesysEngage-cloud/BO02 (2) Part 2 - Work Item Handling https://www.lucidchart.com/documents/edit/1ade4795-a196-4e7c-a9d7-8c3a907bd6e5/0
  1. The employee handles the lead/work item (either an outbound call for leads or through source system for work items). After finishing their work, they decide on the next step.
  2. The employee may be able to complete the work item so that no further action is required.
    • After the outbound call the lead representative could record the result for reporting purposes (converted, not converted) (or) the source system updates Genesys that the work item is completed and Genesys can archive the work item
    • Alternatively, the employee completes the task within the Workspace desktop (using the "mark done" button).
  3. The employee may choose not to finish their work immediately, for example, if they are waiting for a callback from the customer or a colleague. In this work item, the employee can park the work in their personal workbin.
  4. The employee may need to reschedule the work item, for example, if the customer is only available on the next day. They reschedule the work item via the source system.
  5. The employee may not be able to handle the work item because it is wrongly classified. They reclassify the work item via the source system. (not applicable for leads)
  6. The employee might not take any action in the source system(not applicable for leads):
    • The employee may accidentally finish the work item in the employee desktop without any update in the source system ("mark done"). To prevent this mistake, the mark done button can be disabled in Genesys Desktop.
    • Genesys does not receive an update of the work item via the Cloud REST Capture Adapter. In this scenario, the source system needs to check for these tasks and update/restart the tasks in Genesys.
UseCases/Current/GenesysEngage-cloud/BO06 This business flow shows the use case from the perspective of the customer and agent. 7deb8693-2294-4b64-8b50-9b3e115b9a89
  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.
UseCases/Current/GenesysEngage-cloud/CE01 The flow describes the use case from the perspective of the caller and contact center agent. The following diagram shows the business flow of the use case: https://www.lucidchart.com/documents/edit/ee59a752-1e08-4be8-8caa-e0fe31f5f353/0
  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 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 a DTMF tone entered on the handset. If the caller does not choose an option or chooses an unavailable option, the menu is repeated up to two times. If the caller still does not choose a valid menu option, the call is handled with default routing parameters.
  8. The call is distributed to the best-fit agent for the chosen topic based on the agent's skill and skill level (see Distribution Logic for details).
  9. At the end of the call, the agent sets a disposition code to record the call outcome for reporting purposes.
UseCases/Current/GenesysEngage-cloud/CE03 (1) Callback Request

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

https://www.lucidchart.com/documents/edit/2b1b0540-f555-43f2-ab64-ccc481b34f63/0
  1. A customer calls a service line of the company.
  2. The customer requests to speak with an agent.
  3. The system verifies the expected wait time for the particular request. If the wait time is below the specified thresholds or within the optional blackout period, the caller is immediately transferred to the corresponding queue to wait for an agent with the requested skill. Please note that the logic to route calls to agents is not within the scope of this use case. This use case relies on existing inbound voice functionality.
  4. When the Estimated Wait Time threshold is reached outside the optional blackout period, a wait time announcement can be played to the caller.
  5. After the announcements, the options for callback will be announced to the customer.
  6. If the customer chooses either an Immediate or Scheduled Callback, they are asked if the ANI on which they called in is the callback number. If the customer confirms, move to next step. If the customer does not confirm, they enter the new callback number and are asked to confirm it. If the customer chooses an Immediate Callback, they are placed in the router's queue (Go To "Callback" section next). If the customer chooses a Scheduled Callback, they are asked for when they want the callback. (Go To "Register Scheduled Callback" section next.)
  7. If the customer does not accept the callback, the call is transferred to the corresponding waiting queue.
  8. Optionally, you can offer a description of a callback, which is a recorded message.
UseCases/Current/GenesysEngage-cloud/CE03 (2) Register Scheduled Callback https://www.lucidchart.com/documents/edit/d686168c-1d22-43cb-8499-5cda3d672f85/0
  1. From a selection of configured days and times, the customer chooses the day, then the time, for their callback.
  2. If the time slot is available, the system confirms it. If the time slot is not available, the system offers the next available time.
  3. The customer can accept the offered time slot. If the customer does not accept the next available time slot, they are asked to enter a day and time again. This loop occurs five times (5 is the default, and this is a configurable option).
  4. Once the customer accepts the time slot, Genesys registers the callback request and ends the call.
UseCases/Current/GenesysEngage-cloud/CE03 (3) Callback https://www.lucidchart.com/documents/edit/c20fa572-1025-449a-b3de-c09f4dbe49a9/0
  1. The callback is either scheduled for later or immediate
    • For a Scheduled Callback, at the requested time of the callback, the call is queued to be distributed to an agent with the right skill.
    • For an Immediate Callback, when the caller's turn in queue is reached, they are put in position number one.
  2. Based on predicted agent availability for the callback, a call is initiated to the customer phone. Call progress detection is used to detect if a human has accepted the call.
  3. Up to three call attempts to reach the customer is performed. If the customer does not accept the request after the third attempt, then the callback is canceled.
  4. If the customer accepts the call, an announcement is played to inform the customer that this is the callback they requested. A sample announcement text could be: “This is your requested callback from company XYZ. Please press 1 to confirm that you requested this callback and you will be connected to an agent."
    Other configurable options include:
    • Confirm that the right party has been reached and offer the ability to speak to an agent
    • Request more time to get the right party on the line
    • Reschedule the callback
    • Cancel the callback
  5. Depending on the configuration options that are offered, the customer can confirm the callback by pressing “1.” If they do not confirm that the call is ended. No further callback attempt is done.
  6. If the customer confirms the callback, they are connected to the agent
UseCases/Current/GenesysEngage-cloud/CE07 Figure 1: Example Business Flow https://www.lucidchart.com/documents/edit/7900f9a9-9588-4d06-a701-d451a08fc803/0
  1. Call is transferred into the application. This self-service module can be integrated into a broader IVR application that answers the call. At some point, the application may decide that Identification and Verification of the customer is required and will initiate the flow of this use case. 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).
  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 (for example 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 match is found, Genesys asks for additional information validating the caller's identity for security purposes. This question must require 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 separate ID&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 want to reorder 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 should be routed to next. The possible options are shown in the following list. However, these options are outside the scope of the ID&V use case:
    • Agent assisted service - the result of the identification and verification are displayed to the agent making both the customer and agent experience better.
    • Self-service IVR such as transfer funds, 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
UseCases/Current/GenesysEngage-cloud/CE08 (1) The following flow describes the use case from the perspective of the main actors, especially customers: https://www.lucidchart.com/documents/edit/cadb422e-2b76-41a4-aa52-b1589f18d84b/0
  1. A customer is transferred to the payment application by another IVR application (which is outside 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, Customer Authentication (CE07) for Genesys Multicloud CX.
  3. If identification and verification are successful, 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 want 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 states whether the details entered are correct or incorrect. The option to read back only the last four 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 payment is either rejected or successful.
  9. If rejected, the customer can reenter their card details until the maximum number of rejections is met, when 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.
UseCases/Current/GenesysEngage-cloud/CE08 (2) Scenario 2 - Agent Conference https://www.lucidchart.com/documents/edit/0753b69a-e2c9-42bf-866c-2db86bd63d97/0
  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 Genesys Multicloud CX.
  3. If identification and verification succeed, 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 states whether the details entered are correct or incorrect. The option to read back only the last four 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 payment is either rejected or successful.
  9. If rejected, the customer can reenter 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 can also play dynamic information such as a transaction reference or order number.
  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.
UseCases/Current/GenesysEngage-cloud/CE11 (1) Business Flow

The following diagram shows the main flow of the use case:

https://www.lucidchart.com/documents/edit/78d0855d-9d55-4107-ac6f-a0f67c5af0b4/0 1. The administrator or Genesys PS configures a campaign template, dialing profile, session profile, and settings in the Genesys system.

2. The organization prepares a contact list from a third-party system (such as a CRM), then uploads the list using batch upload, the user interface, or FTP list automation capabilities.

3. The Campaign Group begins contacting consumers based on the campaign template, dialing profile, and session profile from step 1, filtering out those contacts that meet the settings criteria defined in the dialing profile.

4a. For Dialer, see the Dialer flow below.

4b. For Outbound IVR, see the Outbound IVR flow below.

5. Call results are written back to the Genesys system and utilized to determine next actions.

6. Depending on the call result, additional contact attempts may be undertaken. If additional contact is required, the contact treatment configured in step 1 continues at step 3. If no additional contact is required, the contact treatment ends and all records are updated in the system.

UseCases/Current/GenesysEngage-cloud/CE11 (2) Outbound IVR

The following diagram shows the Outbound IVR subflow:

https://www.lucidchart.com/documents/edit/2b67cb46-8bfc-476a-a9c0-5bcee01ced73/0 For Outbound IVR, there are multiple resulting scenarios:
  • Bad Number or No Answer - the call disconnects and the result is written back to the system.
  • Answering Machine - the call either disconnects or plays a message (based on the chosen configuration in step 1) and the result is written back to the system.
  • Live Party connect - the call plays the Outbound IVR message.
    • The consumer can choose to opt out of future calls. This choice is typically done by including “Press 9 to opt out of future calls.”
    • Optionally, the Customer Admin may offer the option to connect to a live agent (based on the chosen configuration). This is typically done by including “Press 2 to connect to a live agent.” This can be achieved by routing to a phone number provided by the company.
    • The result is written back to the system.
UseCases/Current/GenesysEngage-cloud/CE11 (3) Dialer

The following diagram shows the Dialer subflow:

https://www.lucidchart.com/documents/edit/e0a78b25-6822-47f5-877f-c3009c1f3cf1/0
  • For Dialer, the dialing mode is configured as Preview, Progressive, or Predictive.
    • In Preview mode, the agent receives or retrieves a record and initiates the call.
    • In Progressive mode, the system automatically places the call based on an agent being available for the specific campaign.
    • In Predictive mode, the system automatically places the call based on the pacing algorithm and expected agent availability.
  • For each call attempt, there are multiple resulting scenarios:
    • Bad Number or No Answer:
      • In Preview mode, the agent hangs up and the result is written back to the system.
      • In Progressive and Predictive modes, the call disconnects and the result is written back to the system.
    • Answering Machine:
      • In Preview mode, the agent can choose to leave a message. Based on the disposition code, the call may be retried later. The result is written back to the system.
      • In Progressive and Predictive modes, the call either disconnects or plays a message (based on the chosen configuration in step 1) and the result is written back to the system.
    • Live Party connect - the agent is connected to the consumer.
      • The consumer can choose to opt out. In cloud, the agent records this in the agent desktop and it is written to a suppression list or Do Not Call list in the premise.
      • The consumer can choose to ask for a callback. The agent records this callback in the agent desktop and the callback is scheduled.
    • At the end of the call, the agent records a disposition code and the result is written back to the system.
UseCases/Current/GenesysEngage-cloud/CE11 (4) Preview

The following diagram shows the subflow when preview mode is used:

https://www.lucidchart.com/documents/edit/d49e9120-4048-40c8-b785-37926a0054ff/0 Based on the result of the call, additional contact attempts may be undertaken, either:
  • in the same channel, or
  • in another channel (Cloud only)

This is configured in the campaign settings in step 1.

UseCases/Current/GenesysEngage-cloud/CE12 https://www.lucidchart.com/documents/edit/81de890f-1bcf-4e4a-ba04-e9d078e582c8/0
  1. An Admin (or Genesys PS) configures the campaign strategy and settings in Genesys.
  2. The organization either prepares a contact list from a third-party system (such as CRM or Collections) or configures their system to utilize Genesys REST API to insert contact records based on an event, a list, or an API format defined by Genesys.
    • Batch Upload Option: Customer contacts are loaded through the User Interface or utilizing List Automation configured jobs.
    • API Upload Option: Customer contacts are loaded through the standard Genesys Engage APIs.
  3. The campaign begins contacting consumers based on the campaign template, strategy, and settings configured in the first step, filtering out those contacts that meet the settings criteria. The Genesys system checks each contact/record against the relevant Do Not Call and suppression lists to filter out consumers who should not be contacted.
  4. Genesys compiles the SMS text from a standard template using up to four custom fields provided with the contact list, or the customer creates the SMS message using the self-service capabilities within the User Interface (self-service capabilities must be enabled by Genesys PS). For more information, see SMS Self-Service. Best practice recommends avoiding message splitting. The customer is responsible for following character limitations set for each country; for example, the maximum size in the U.S. is 160 characters.
  5. The delivery result, if available, is recorded in Genesys.
  6. Consumer may decide to respond to the SMS message. Genesys stores replies together 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 customer-specified text is sent to the consumer, and the mobile number is added to a suppression list. It is the organization’s responsibility to process the opt-out requests and guarantee that the consumer is not included in any further contact list.
    • ADD-ON: For a predefined keyword, the system can either send an automated response or trigger a RESTful API push into the customer’s system (Genesys PS must scope API connections). For an unstructured/unexpected response, the system stores the response but does not reply unless a wildcard response has been configured (a wildcard response is a standard response that is sent as a response to all unrecognized responses).
UseCases/Current/GenesysEngage-cloud/CE13 (1) The following shows the main flow: https://www.lucidchart.com/documents/edit/47d04b63-12b0-498e-9218-76fc016d07b3/0
  1. An Admin (or Genesys PS) 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 utilize the Genesys REST API to insert contact records based on events, using a list or API format defined by Genesys:
    • The contacts are loaded within Genesys by the system administrator.
    • Batch uploads can be manual, via S/FTP or API.
  3. The campaign begins contacting consumers based on the campaign strategy set in step 1. The Genesys system checks each contact/record against the relevant Do Not Call and suppression lists to filter out consumers who should not be contacted.
  4. Based on the result of the call/message, more contact attempts may be undertaken, either:
    • in the same channel
    • in another channel
    Contact attempts are configured in the campaign settings in step 1.
UseCases/Current/GenesysEngage-cloud/CE13 (2) The following diagram shows the Dialer option of the flow: https://www.lucidchart.com/documents/edit/fd02ad3b-247a-4bb9-a202-55dd4d314451/0 For Dialer, the dialing mode is configured as Preview, Progressive, or Predictive.
  • In Preview mode, the agent receives or retrieves a record and initiates the call.
  • In Progressive mode, the system automatically calls based on an agent being available for the specific campaign.
  • In Predictive mode, the system automatically calls based on the pacing algorithm and expected agent availability.

For each call attempt, there are multiple resulting scenarios:

  • Bad Number or No Answer:
    • In Preview mode, the agent hangs up and the result is written back to the system.
    • In Progressive and Predictive modes, the call disconnects and the result is written back to the system.
  • Answering Machine:
    • In Preview mode, the agent leaves a message. Based on the disposition code, the call may be retried later. The result is written back to the system.
    • In Progressive and Predictive modes, the call is either disconnected or plays a message (based on the configuration chosen in step 1) and the result is written back to the system.
  • Live parties connect - the agent is connected to the consumer.
    • The consumer can opt out. The agent records the opt-out request in the agent desktop and it is written to a suppression list.
    • The consumer can ask for a callback. The agent records the callback in the agent desktop and the callback is scheduled.

At the end of the call, the agent records a disposition code and the result is written back to the system.

UseCases/Current/GenesysEngage-cloud/CE13 (3) The following diagram shows the Outbound IVR option of the flow: https://www.lucidchart.com/documents/edit/bd035516-06d0-4384-9ef4-cd659ac37e36/0 For Outbound IVR, there are multiple resulting scenarios:
  • Bad Number or No Answer - the call disconnects and the result is written back to the system.
  • Answering Machine - the call disconnects or plays a message (based on the chosen configuration in step 1) and the result is written back to the system.
  • Live parties connect - the call plays the Outbound IVR message.

The consumer can opt out of future calls. Opt-out is typically done by including “Press 9 to opt out of future calls.”

Optionally, the Customer Admin may choose to offer the option to connect to a live agent (based on the chosen configuration). Connecting to a live agent is typically done by including “Press 2 to connect to a live agent” and can be achieved by routing to a phone number provided by the company.

The result is written back to the system.

UseCases/Current/GenesysEngage-cloud/CE13 (4) The following shows the SMS option of the flow: https://www.lucidchart.com/documents/edit/8b00aa67-ee28-412a-9e70-c2ec4d5d4ece/0 For SMS, Genesys compiles the text message from a standard template for the contact list with or without personalization. Customer is responsible for following character limitations per country (Max size is 160 characters in the U.S.). Concatenation is supported for message content that is longer than a single SMS.
  • Delivery result, if available, is recorded in the Genesys system
  • The consumer may decide to respond to the SMS message. All replies are stored in the Genesys system together with the available metadata from the SMS message to identify the consumer.
    • For a HELP keyword, a standardized help text is sent to the consumer.
    • For a STOP keyword, a standardized text is sent to the consumer, and the mobile number is added to a suppression list. It is the organization’s responsibility to process the opt-out requests and guarantee that the consumer is not included in any further contact list.
    • ADD-ON: For a predefined keyword, the system can either send an automated response or trigger an API push into the customer’s system.
    • For an undefined keyword, the system stores the response but it does not reply. As an ADD-ON, the organization may choose to send undefined words to an agent.
UseCases/Current/GenesysEngage-cloud/CE13 (5) The following shows the email option of the flow: https://www.lucidchart.com/documents/edit/c81944db-d443-4447-bdb7-c2fc1adefacc/0 For Email, the consumer can take various actions after receiving the message:
  • Do nothing / delete the message.
  • Click the link in the message (optional).
    • The website is hosted by the customer (websites that are hosted by Genesys are not in scope).
  • To opt out, click the Unsubscribe link.
    • This action can either be configured to go into a suppression list hosted by Genesys or go to a customer-hosted website for managing subscriptions.
  • Reply to the email message with a phone call.
    • Customer could include a 1–800 number to call for more information in the email. To track how many inbound calls an email campaign generates, the customer must assign a unique 1–800 number to each campaign.
  • Responses to email campaign are funneled through a unique inbox.
  • In all cases, the delivery result is written back to the system.
UseCases/Current/GenesysEngage-cloud/CE13 (6) Outbound Collections Flow:

The actors of the business flow are:

  • Collections Agent
  • Customer
  • Systems
    • Touchpoints (Dialer, Outbound IVR, Email, Text/SMS)
    • CRM / Collections System
    • Payment Processor
    • Genesys Outbound
      • Stand-alone Cloud
      • CX Contact, OCS, and Proactive Contact (Premise)
    • Admin: Collection system management configuration, Genesys campaign configuration
https://www.lucidchart.com/documents/edit/84f0f8c0-3f93-4445-89ae-c9c59531b81f/0
  1. Payments / Collections Department loads a list of relevant records to Genesys. Customer (dialer, outbound IVR, email, SMS).
    • Minimum Mandatory Fields: Customer Number / Client ID and Devices (phone numbers, email address)
    • Advanced Fields: User-Defined fields that may be used for personalization or splitting criteria to assign record to the correct list and channel.
  2. A Customer Admin (or Genesys PS) configures the campaign strategy in the Genesys System (see Business Logic section for more detail)
    • Create Campaign: Configure template settings
    • Choose Channel Type: Dialer, Outbound IVR, SMS, and/or Email
    • Choose Dialer Mode (if applicable): Predictive, Progressive, Preview (Push or Pull)
    • Configure 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
  3. Genesys determines the channel on which the customer should be contacted based on selection rule criteria during import.
  4. In case the channel is SMS, the system sends an SMS with a payment link to the customer or phone number to call to talk with an agent or make a payment.
  5. In case the channel is email, the system sends an email with a payment link to the customer.
  6. In case the customer should be contacted via an outbound call, Genesys initiates an outbound call to customer telephone number provided in the contact list. There are three options for this scenario:
    • Immediately connect to a live agent using progressive or predictive dialing modes
    • Present the record to an agent using preview dialing mode
    • Connect to an automated IVR application
  7. If the customer could not be reached, there are multiple response types:
    • Bad no./No Answer: the call disconnects and the result is written back to the system
    • Answering Machine: the call disconnects or plays a message (based on the chosen configuration) and the result is written back to the system. Based on the call result, the outbound campaign can decide on the next step (contact the customer on the same channel again / escalate to another channel through copy_contact treatment to move record to appropriate campaign).
  8. Customer is connected to a live agent who can discuss the debt and the payment options. Agent can also send an SMS or and email (Step 8).
  9. Customer is greeted by an IVR which informs the customer about the outstanding payment and offers:
    1. Transfer to an agent (step 11)
    2. Make a payment using automated system (step 10 if available)
    3. To send an SMS with payment methods (step 14)
    4. To send an email with payment methods (step 15)
  10. Customer makes payment using automated IVR application. The automated payment application is not within the scope of this use case. Two options exist:
  11. IVR connects customer to a live agent who can discuss the debt and the payment options.
  12. The agent can process the outstanding payment. The call result is stored in the system for reporting purposes.➞AD2
  13. The customer may want to reschedule the call. In this case, the agent initiates a personalized callback for the customer. The callback request is written back to the campaign list, so the callback can be handled at the requested time.➞AD3
  14. The agent / IVR may send an SMS message with a link to a payment system to the customer.
  15. The agent / IVR may send an email message with a link to a payment system to the customer.
UseCases/Current/GenesysEngage-cloud/CE16 https://www.lucidchart.com/documents/edit/0c20a3d9-63d8-4adf-830d-66b24e211dd6/0
  1. A customer sends an email to one of the email addresses monitored by the Genesys Multicloud CX email solution (e.g. support@company.com).
  2. Genesys periodically checks corporate inboxes for new emails, using Graph API, Gmail API or IMAP protocols.
  3. The new email is captured by Genesys including “From,” “To,” “Subject” & "Body" as metadata. These contents are used to segment and prioritize.
  4. The system sends out a receipt acknowledgment email to the customer using a predefined template.
  5. The email is assigned a category based on segmentation rules set by the business. Each category is associated with a prioritization schema which assigns a priority score to the email to determine its place in the universal queue.
  6. The system constantly re-prioritizes emails in the backlog as new emails come in. When the email reaches a priority threshold, the email is routed to the right agent to process this email.
  7. The agent desktop application shows a screen pop with “From,” “To,” and “Subject” information.
  8. Genesys verifies if the corresponding user exists as a contact within the Genesys Contact History (by email address). If the contact does exist, any available contact information and previous contact history is displayed. If the contact does not exist yet, Genesys creates the contact. The email and any response by the agent are attached to the contact.
  9. Once the agent accepts and reads the email, they need to decide if a reply is needed.
    • If no reply is needed, the agent marks the email as done.
    • If a reply is needed, the agent creates an outbound reply email, potentially using a standard response template.
  10. Optionally, emails can be routed to a supervisor for review. If the email is flagged for the supervisor review, the supervisor can take the following actions:
    • Accept & send to consumer
    • Edit & send to consumer
    • Send it back to the agent for further review with comments
  11. The agent can set a disposition code to mark the business outcome for reporting purposes.
UseCases/Current/GenesysEngage-cloud/CE18 https://www.lucidchart.com/documents/edit/831536f9-aff6-4f84-ae3c-35ac52eb4b6b/0 1. The User requests to Chat with a live agent using Web / Mobile Channel.

2. Genesys System checks whether User has any previous Chat Sessions which are active.

a. If user has previous Chat Session active, then we restart the prior Asynchronous chat Session which is still active and not ended.

b. If user does not have any previous chat session active, then it continues to next step.

3. User enters the required Contact Information via form to initiate the chat. Attributes which are captured in the form are First Name, Last Name, Nickname, Subject, and Email Address.

4. Check whether User provides required contact Information in the form.

a. If User does not provide contact information, then No Contact is created for Chat. Anonymous Chat Session is created and no transcript is saved or emailed to the User.

b. If User provides the required contact information, then check whether User contact exists in the contact history.

i. If no contact exists with email ID specified, Genesys System creates a new contact. The Chat Session is associated to new contact and the Chat transcript is stored under new contact which was created.

ii. If contact exists with email ID specified, then check whether we have any Chat Session still exists for the contact. If the Chat Session exists, then restart the prior Asynchronous Chat Session. If the Chat Session does not exist, then create new Chat Session and associate it with the contact.

5. In the scenario where Chat Session exists and it has been restarted.

a. Check whether any interaction exists under the Chat Session.

i. If no interaction exists, then create new interaction and associate with current Chat Session.

ii. If interaction exists, the then continue associating with the same interaction.

6. In the scenario of new Chat Session then create new interaction and associate the interaction with new Chat Session.

7. The Chat window pops up.

8. Genesys System checks whether Office Hours definition exists.

a. If Office Hours definition does not exist, then continue with Step 9.

b. If an Office Hours definition exists, then check whether office is open. If Office is open, then continue with Step 9. If Office is not open, then follow the below steps.

i. Genesys System sends the message defined in ‘OfficeClosed_Message’ available from Data Table. If no message defined in ‘OfficeClosed_Message’, then Genesys System sends the standard Office closed message “Welcome to Genesys Chat!" Our Apologies, we are closed at this time. Please leave your message and our Agents will get back during Office Open Hours.”

ii. Place the interaction in Parking Queue with the time frame defined to pull the interaction from the parking queue.

iii. Pull the interaction from the parking queue during the time frame defined (When the Office Hour Opens).

iv. Reroute the interaction back to Regular Queue.

9. Genesys System reads the title of the page ‘_genesys_pageTitle’ from where the Chat is initiated.

10. Genesys System checks whether any skill expression matches to the Page Title.

a. If skill expression exists for Page Title, then it reads the skill expression.

b. If no skill expression exists for Page Title, then it takes any skill set.

11. The Customer receives a welcome message which is defined in ‘Welcome_Message’ available in the data table. If no message defined in the ‘Welcome_Message’ then Genesys System sends the standard welcome message “Welcome to Genesys Chat! Please leave your message and our Agents will connect with you shortly.”

12. Genesys System tries to find an agent with the skill level matching the skill expression for 120 seconds.

a. If no agent found with the matching skill expression, then Genesys System changes the skill level to any skill level.

b. After attempting to find agent with any skill level. If Genesys System was not able to find an agent with any skill level before specific timeout. The interaction is routed back to Regular Queue again to find the right agent.

13. Genesys System is able to find the agent with the right skill level which matches the skill expression.

a. When the agent becomes available, the chat request is routed to the agent.

b. The agent can either accept or ignore the Chat interaction.

c. If the agent does not accept the interaction, then the system will attempt to route it to another agent after a specific time-out.

d. If the agent accepts the Chat interaction, then Chat Interaction between the agent and the User is established.

e. The agent can use standard responses for the Chat Interaction with the User.

f. When the Chat Interaction is finished, the agent can set a disposition code to register the outcome of the Chat for reporting purposes.

g. If the User has provided their email address during the registration process, then they receives a transcript of the Chat Session via email.

h. The Chat Session can continue until User Ends the Chat Session.

UseCases/Current/GenesysEngage-cloud/CE19 Facebook/Twitter Interactions (Public and Private)

The following flows describe the use case from the perspective of the main actors, i.e. social media user and contact center agent. The first flow shows how a public interaction is handled:

https://www.lucidchart.com/documents/edit/1a115497-808f-4213-8053-6f076440afa8/0
  1. The user searches in Facebook or Twitter for the company's account. User will post or tweet to the attention of the company, by posing a customer care issue.
  2. Genesys verifies if a corresponding contact already exists in Genesys contact history. The customer is identified in the contact history by their Facebook / Twitter handle (if available).
    • If yes, then it attaches the interaction to an existing session.
    • If a contact does not exist (social handles are not associated to a registered user), Genesys creates a contact in the universal contact database based on the customer data. Any following messages and agent replies are stored under this customer.
  3. Genesys checks if the agent is available to take the interaction.
    • If the agent is available, then Genesys creates a new interaction for the agent to accept and continue/start the conversation
    • If no agent is available, the interaction is placed in the queue until an agent is made available. A new interaction is created for the next agent.
  4. When the agent is available, an open media pop up for Public Interaction / a chat window pop up for Private Interaction appears in Workspace Web for the agent to accept or reject the request. If this interaction is sent to a subscribed agent:
    • The agent sees a pop up to “Show/Deny” the message. If the agent denies it / timeout occurs, it is placed in their communication panel queue to pull once the agent is available.
  5. Once the agent accepts the new interaction, the customer contact will be added into their subscription list to enable last agent routing for any future interactions.
  6. The interaction is sent to the agent for an appropriate response. Once the agent accepts, this session begins and is alive until the agent has completed the conversation and decides to close the interaction. When the interaction is finished, the agent can set a disposition code to register the outcome for reporting purposes.
UseCases/Current/GenesysEngage-cloud/CE22 (1) The following flows describe the use case from the perspective of the main actors, such as a user or customer and a contact center agent, the first a request from a website, the second a request from a mobile application. https://www.lucidchart.com/documents/edit/c056b34c-663a-410d-8237-6a7e93e8abfc/0 Website Flow
  1. The customer browses the company's website and requires help.
  2. The customer clicks the “callback” button/widget, powered by Genesys Widgets.
  3. The website widget displays a brief registration page to the customer. Genesys provides a standardized widget for Callback.
  4. The customer enters their name and phone number. Optionally, the name and phone number can be automatically set if the customer is authenticated within the website.
  5. Using the information collected in the previous step, including the content of the page the user is visiting, Genesys determines the appropriate agent skill, then calculates agent availability. The customer may choose either:
    • Immediate Callback: In this case, the callback is immediately queued and then initiated once an agent with the required skill is available.
    • Scheduled Callback: In this case, the customer chooses from available time slots. Time slots can be configured in 15, 30, or 60-minute intervals. Capacity at each slot is configurable within the Callback user interface by the company’s administrator.
  6. The customer chooses a callback option and the corresponding callback request is created within the Genesys system.
  7. At the requested time (or immediately if there is Immediate Callback), the callback is queued to be distributed to an agent with the right skill. By default, the skill target is specified on the Genesys Callback Service object configuration.
  8. When an agent with the requested skill becomes available, the agent is reserved and an outbound call is initiated to the customer phone number.
    • a. If the caller answers the call, an announcement is played to inform the customer that this is the callback they requested. A sample announcement could be: “This is your requested callback from company XYZ. Please press 1 to confirm that you requested this callback, and you are connected to an agent.” The customer can confirm the callback by pressing “1,” and they are connected to the agent.
    • b. If the customer does not answer or confirm the callback, another attempt occurs after 10 minutes (configurable). This includes the cases that the caller is busy, the call is connected to voicemail, the caller rejects the call, or other scenarios in which no agent is requested. The number of call attempts is configurable, but best practice is no more than three call attempts. If they still do not accept the call, the request is canceled.
  9. After the conversation between the agent and the customer, the agent can classify the call for reporting purposes via their agent desktop.
UseCases/Current/GenesysEngage-cloud/CE22 (2) Business Flow—Mobile App (available in Premise-only) https://www.lucidchart.com/documents/edit/b83810c2-791f-4c06-b540-f1164e86ec38/0 Mobile Flow
  1. The customer browses the company's mobile application and requires help.
  2. The customer clicks the “callback” button or link in the mobile app.
  3. The app displays a brief registration page to the customer.
  4. The customer enters their name and phone number. Options:
    • Name and phone number can be automatically set if the customer is authenticated within the app.
    • Depending on the implementation of the callback logic in the mobile app, the option to select a specific skill is based on the particular page from where the callback is requested.
  5. Using Genesys APIs, the website widget retrieves the Expected Wait Time (EWT) for an immediate callback and available time slots for a scheduled callback for a specific service, and displays the options to the customer. (Note: The request from the app to Genesys must contain one of a set of predefined subjects which are used to determine the requested skill for an agent, the current EWT, and the available time slots.) The customer may choose either:
    • Immediate Callback: In this case, the callback is immediately queued and then initiated once an agent with the required skill is available.
    • Scheduled Callback: In this case, the customer chooses from available time slots. Time slots can be configured in 15, 30, or 60-minute intervals. Capacity at each slot is configurable within the Callback user interface by the company’s administrator.
  6. The customer chooses a callback option and the corresponding callback request is created within the Genesys system.
  7. At the requested time (or immediately in the case of Immediate Callback), the callback is queued to be distributed to an agent with the right skill. By default, the skill target is specified on the Genesys Callback Service object configuration.
  8. When an agent with the requested skill becomes available, the agent is reserved and:
    • a. For customers who opt in for push notifications, a push notification is sent to the customer indicating their callback is ready. If this notification is accepted, an outbound call is initiated. The customer may select to further delay the callback or cancel it entirely. This ability for the customer to accept, delay, or cancel can be configured within the app and push notification.
    • b. For customers who do not opt for push notifications, an outbound call is initiated. For customers who do not answer or confirm the callback, another attempt occurs after 10 minutes (configurable). This includes the cases that the caller is busy, the call is connected to voicemail, the caller rejects the call, or other scenarios in which no agent is requested. The number of call attempts is configurable, but best practice is no more than three call attempts. If they still do not accept the call, the request is canceled.
  9. After the conversation between the agent and the customer, the agent can classify the call for reporting purposes via their agent desktop.
UseCases/Current/GenesysEngage-cloud/CE27 The following flow describes the use case from the perspective of the customer and the contact center agent. https://www.lucidchart.com/documents/edit/0b9ea69e-4e73-463d-9cd6-1d5214eab1b0/0
  1. The customer and agent are connected via a chat session or a voice call.
  2. The agent may propose to the customer to start a co-browse session to support them on the website. For security reasons, only the customer can open the co-browse session.
    • Call only: A session ID is displayed to the customer if they click the co-browse link in the Assistance/Channel Selector Widget. This session ID is needed to join the agent desktop with the correct browser session. The customer gives this session ID to the agent over the phone. The agent enters the session ID into the agent desktop to start the co-browse session.
    • Chat only: The customer clicks the three-dots icon on the chat widget and selects "Start Co-browse."
  3. When the session is established, the agent's desktop displays a view of the website in the browser window the customer is using. Agents start co-browse sessions in Pointer Mode. In Pointer Mode, the customer and the agent can see each other's mouse pointer but the agent cannot enter any information into the webpage, click buttons, or navigate the customer's browser.
  4. If the agent needs to enter information into the webpage or to navigate the browser, they can send the customer a request to switch the co-browse session to Write Mode.
  5. Once the customer accepts this request, the agent can navigate, fill forms, and click hyperlinks on the webpage. Sensitive Data can be masked before presenting to the agent, and agent controls (the ability to fill certain fields or submit forms) can be blocked through instrumentation. The customer can revoke the Write Mode at any time, returning the agent to Pointer Mode.
  6. The co-browse session ends when any of the following events occurs:
    • The customer chooses to end the co-browse session
    • The agent chooses to end the co-browse session
    • The primary chat or voice interaction is transferred or ended by either the customer or the agent
    • Due to inactivity after a preconfigured time-out expires

The primary voice or chat interaction can continue even when co-browse has ended.

UseCases/Current/GenesysEngage-cloud/CE28 (1) Employee Knowledge https://www.lucidchart.com/documents/edit/a50394f4-5891-4de9-9f48-967f1862eb2a/0 Authoring for Knowledge Authors
  1. Go to the Knowledge workbench to create knowledge documents
  2. Save, train, test and update knowledge documents
  3. Once finalized, the author ‘publishes’ knowledge documents to make it available to Agents or customers (as set by the author in the document)
  4. Documents that are published by the author for agents are now available for agents to search through
  5. Documents that are published by the knowledge author for customers are now available to Bot authors to also use in Self Service use cases  

Knowledge surfacing to Agents

  1. Agent logs into Workspace either Web Edition or Desktop Edition
  2. Agent goes to the knowledge tab and enters a search query
  3. Agent can go through the knowledge results, add the content in knowledge results directly as a response to the customer or browse through the knowledge base to find the required knowledge
UseCases/Current/GenesysEngage-cloud/CE29 https://www.lucidchart.com/documents/edit/fcc3f853-4205-4e6d-8cce-2f6c4d4c919a/0
  1. A Consumer sends an SMS to an enterprise long code / short code / toll-free number.
  2. Genesys Multicloud CX receives the SMS message, including the customer’s phone number as metadata.
  3. Genesys System check whether Customer Contact exists with us. If Customer contact does not exist, then new contact is created and move to next step
  4. Genesys System checks whether Consumer has any previous SMS Sessions which are active
    • If Consumer has previous SMS Session active, then we restart the prior SMS Session which is active
    • If Consumer does not have any previous SMS Session active, then it continues to next step
  5. In the scenario where SMS Session exists and it has been restarted. Check whether any interaction exists under the SMS Session
    • If there is no interaction that exists, that then create new interaction and associate with current SMS Session
    • If an interaction exists, then continue associating with the same interaction
  6. In the scenario of new SMS Session, then create new interaction and associate the interaction with new SMS Session.
  7. Genesys system checks whether an Office Hours definition exists
    • If Office Hours definition does not exist, then continue with Step 8
    • If Office Hours definition exists, then check whether office is open. If Office is open, then continue with Step 8. If Office is not open, then follow the below steps.
      • (i) Genesys System sends the message “Our Apologies, we are closed at this time. Please leave your message our Agents will get back during Office Open Hours”
      • (ii) Interaction is placed in parking queue with the time frame defined to pull the interaction form the parking queue
      • (iii) Pull the interaction from the parking queue during the time frame defined (when the office hour opens)
      • (iv) Reroute the interaction back to regular queue
  8. Genesys sends an acknowledgment SMS to the consumer
  9. Genesys System tries to find an agent with the right skill.
  10. After finding the agent with the right skills, when the agent becomes available the interaction will be routed to the agent
  11. Agent checks whether interaction needs reply
  • If interaction does not need a reply, then agent marks the SMS interaction as done and ends the interaction
  • If interaction needs a reply, then agent replies to interaction and marks the SMS interaction as done
UseCases/Current/GenesysEngage-cloud/CE31 When a customer interacts through a supported Genesys digital channel, a chatbot is initiated. The chatbot first attempts to use context to anticipate why the customer may be engaging and in turn provides personalized messages or options to resolve the query. If no personalization options exist, the chatbot asks the customer an open question, such as "How may I help?".

Once the customer responds, the chatbot tries to interpret the request to determine intent and then decide what to do next. For example, if the customer replies with “I want to check my balance”, the chatbot would first identify and verify them before showing their balance.

If intent is not established or understood, it presents a retry or max retries message.

Once the task is completed, the chatbot asks if the customer needs more help. The customer can respond by asking another question, requesting to chat with an advisor, or replying 'no'. If the customer replies with 'no', the chatbot can offer a survey based on context.

If the customer chooses to speak or chat with an agent and there is a long wait time or it is outside business hours, then the chatbot can offer a callback option or present a suitable message.

The chatbot continues in this fashion, creating a conversational loop and building up context between itself and the customer to better solve their query.

The following diagram shows the business flow of the use case:

https://www.lucidchart.com/documents/edit/b290f7e9-1ca6-4a49-a080-5adf25e6f851/0
  1. A chat interaction is started (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:
    • Customer profile information in UCS
    • Genesys User Data (e.g. Altocloud Segment or from the website passed by Genesys Widgets)
    • 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."
    • Customer is handed over directly to an agent because they owe an outstanding balance.
    • 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.
  6. The customer's response is then sent to a supported third-party NLU engine. [BL1-BL2]
    • 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 (or microapps):
      • Identification & Verification
      • Automated business process (such as payment collection microapp)
      • Handoff to live agent
    • 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?"
    • 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 to offer them a survey or not (see step 8).
    • If the customer responds with a more advanced answer, the response is sent to a supported third-party NLU engine to determine intent and entities for further processing.
  8. Customer information and/or context is retrieved to determine whether to offer a survey. [BL3]
    • If a survey is to be offered, the chatbot continues to the step 9.
    • If no survey is to be offered, the chatbot shows a goodbye message and ends.
  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 are shown a goodbye message and the chatbot ends.
  10. The survey is executed using the Designer survey microapp.
    • 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.
UseCases/Current/GenesysEngage-cloud/CE34 Approval Flow https://www.lucidchart.com/documents/edit/23aa9b23-4959-4879-b47b-101e1e14b41c/0
  • The brand must be pre-approved by WhatsApp before they can engage with and get on-boarded to Genesys. We can help with pre-approvals. Purchasing, or expressing an interest in, Genesys Messaging for WhatsApp from us does not mean that a brand is pre-approved for WhatsApp by us.
    * The brand purchases Genesys Messaging for WhatsApp (including Hosting Fees and Incidental sellable items) from Genesys, uses the on-boarding guide to get their channels set up in Genesys Hub, and begins development of the messaging use cases.
    * The brand can go live with Genesys Messaging for WhatsApp. While in beta, WhatsApp might want to validate the brand’s implementation before allowing them to go live.
  • No approval is needed for Facebook Messenger.
UseCases/Current/GenesysEngage-cloud/CE34 Messaging Flow https://www.lucidchart.com/documents/edit/e7fa4a3d-3af7-4204-a9d0-5a97881991c2/0
  1. The brand invites their customer to initiate a conversation via messaging (for example, via a custom Click to Action button in their app, on their website, or in an email). For Facebook Messenger, the customer finds the brand's page and sends a message to initiate an interaction.
  2. The customer clicks the chat message icon and sends an initial message to begin the conversation.
  3. The Genesys system checks to see if it can recognize the customer.
  4. WhatsApp passes the phone number of the customer to help identify who initiated the conversation. Facebook passes the Page Scoped ID that is unique for every customer reaching out to that page.
  5. For customers who have initiated a conversation previously, the system pulls the conversation history and presents it to the agent.
  6. The Genesys system determines whether to offer an automated chatbot to the customer or route the customer to a contact center agent.
  7. If a chatbot is offered, go to the use case Genesys Chatbots (CE31) for Genesys Multicloud CX.
  8. If routed to an agent, the customer and agent begin a conversation.
  9. Depending on the conversation topic, the agent can send the customer various interaction types in addition to text, emojis, and images. Pre-approved (by WhatsApp) notification templates can be sent to the customer (see below).
  10. Customer and agent interact via the messaging service and after the conversation is complete, the agent dispositions the interaction.

For WhatsApp, the agent can also send pre-approved WhatsApp notification templates. These can be free or paid.

  • Using these interaction types can save time for agents and reduce errors from the customer. Agents can choose these templates from the standard response library so they don't have to assemble pick lists on-the-fly.
  • After the conversation between an agent and a customer, the agent can classify the chat for reporting purposes via the agent desktop.
UseCases/Current/GenesysEngage-cloud/CE37 (1) Main Flow https://www.lucidchart.com/documents/edit/b5e987d7-954c-4cf7-bbc9-bb8390753f61/0
  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 their data and the conversation with Genesys Blended AI Bots (CE31 Use Case) starts. In the registration form, customer can either manually enter their contact details (name, email) or contact details are 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


UseCases/Current/GenesysEngage-cloud/CE37 (2) Routing


This diagram details the routing that takes place before and during the chat.

https://www.lucidchart.com/documents/edit/38673dbe-49ce-47b8-aba2-4a876d0d4fd7/0
  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.
UseCases/Current/GenesysEngage-cloud/CE41 https://www.lucidchart.com/documents/edit/f5718b0c-badc-4bd1-b1cc-4c450c4a8657/0
  1. A voice interaction is started (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 in UCS
    • 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 if, for example, 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, 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.
    • Sources include:
      • Customer profile information in UCS
      • API call to third-party data source
      • Logic defined in Designer
    • Customer information and/or context is retrieved to determine whether to offer a survey.
      • If a survey is to be offered, the voicebot continues to the step
      • If no survey is to be offered, the voicebot shows a goodbye message and ends.
    • The voicebot 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 are shown a goodbye message and the voicebot ends.
    • The survey is executed using the Designer survey microapp.
      • 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.
UseCases/Current/GenesysEngage-cloud/CE43

(1) Inbound Call Flow

932a4925-c567-4fe7-8081-aedcb69a3564
  1. The customer calls one of the contact center numbers.
  2. A welcome message is played, followed by generic announcements.
  3. The service type is identified using a call steering DTMF menu or (optionally) an IVR application.
  4. Depending on the service type, if the customer is calling outside of business hours or while an emergency is in progress, an announcement is played. The customer can then be reconnected or diverted to another number inside or outside of your Genesys environment.
  5. The customer can be identified using the CLI or (optionally) the use case Genesys Customer Authentication (CE07) for Genesys Multicloud CX (which eventually also provides customer verification).
  6. Based on the customer identification, customer context data can be added to the interaction. If the contact center is open, the routing parameters for this particular call are set based on the type of request and the customer context. This context enables flexible and personalized call handling.
  7. Optionally, the Expected Wait Time (EWT) for the customer is calculated and announced to the customer. If the EWT exceeds a specific threshold, an announcement is played and the caller is disconnected, routed to another number, or offered the option to receive a callback.
  8. Based on the customer context, the customer hears other announcements, such as quality announcements, special promotions, or announcements for potential self-service options.
  9. If the customer has been calling recently for the same type of request, Genesys can route to the Last Called Agent. If that agent is not available within a specified time-out, the call is routed to the requested skill.
  10. The call is distributed to the best agent who:
    • Has the base skills to handle the original request, or
    • Has supplementary skills such as upselling a defined product, service to the customer, or specific empathy skills based on the customer segment or demographic.
    A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill or reducing the skill level on the base skill if the call cannot be distributed within specific timeouts.
  11. Once the call is distributed to an agent, the agent views the context information. For example, the agent can see any special offers or promotions that are available for that customer. The agent handles the customer request and any potential up-/cross-sell opportunities.
  12. When the conversation with the customer ends, the agent records the outcome of the call for reporting purposes (for example, if they acted on the presented lead).
UseCases/Current/GenesysEngage-cloud/CE43

(1) Inbound Call Flow

932a4925-c567-4fe7-8081-aedcb69a3564
  1. The customer calls one of the contact center numbers.
  2. A welcome message is played, followed by generic announcements.
  3. The service type is identified using a call steering DTMF menu or (optionally) an IVR application.
  4. Depending on the service type, if the customer is calling outside of business hours or while an emergency is in progress, an announcement is played. The customer can then be reconnected or diverted to another number inside or outside of your Genesys environment.
  5. The customer can be identified using the CLI or (optionally) the use case Genesys Customer Authentication (CE07) for Genesys Engage cloud (which eventually also provides customer verification).
  6. Based on the customer identification, customer context data can be added to the interaction. If the contact center is open, the routing parameters for this particular call are set based on the type of request and the customer context. This context enables flexible and personalized call handling.
  7. Optionally, the Expected Wait Time (EWT) for the customer is calculated and announced to the customer. If the EWT exceeds a specific threshold, an announcement is played and the caller is disconnected, routed to another number, or offered the option to receive a callback.
  8. Based on the customer context, the customer hears other announcements, such as quality announcements, special promotions, or announcements for potential self-service options.
  9. If the customer has been calling recently for the same type of request, Genesys can route to the Last Called Agent. If that agent is not available within a specified time-out, the call is routed to the requested skill.
  10. The call is distributed to the best agent who:
    • Has the base skills to handle the original request, or
    • Has supplementary skills such as upselling a defined product, service to the customer, or specific empathy skills based on the customer segment or demographic.
    A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill or reducing the skill level on the base skill if the call cannot be distributed within specific timeouts.
  11. Once the call is distributed to an agent, the agent views the context information. For example, the agent can see any special offers or promotions that are available for that customer. The agent handles the customer request and any potential up-/cross-sell opportunities.
  12. When the conversation with the customer ends, the agent records the outcome of the call for reporting purposes (for example, if they acted on the presented lead).
UseCases/Current/GenesysEngage-cloud/CE43

(2) Request a callback

If wait times are too great, the caller can request a callback.

98e968c8-452b-4c7f-921d-db471e3bc54d
  1. A customer calls the contact center during regular office hours and wants to speak with an agent.
  2. The system verifies the expected wait time for the particular request. If the wait time is below the specified thresholds or within the optional blackout period, the caller is immediately transferred to the corresponding queue to wait for an agent with the requested skill.
  3. When the Estimated Wait Time threshold is reached outside the optional blackout period, the wait time can be announced to the caller (optional). It's best to offer the wait time as a range, rather than an exact value; for example, "Your wait time is between 15 and 20 minutes”.
  4. When callback is configured, a menu is played to offer the caller an Immediate or Scheduled Callback. Optionally, the callback offer can include a description of callback. The caller also has the option to refuse the callback offer, in which case the call stays connected, the caller remains on the line, and the call is transferred to the corresponding waiting queue.
  5. When the customer chooses to receive a callback, the system requests confirmation that the ANI on which they called in is the one to use for the callback.
    • If the customer does not confirm the ANI on which they called in as the one to use for the callback, then they are asked to enter the new callback number and to confirm it.
    • If the customer confirms the ANI, the call progresses:
      • For a Scheduled Callback, the customer is asked to select a day and time.
      • For an Immediate Callback, the call is placed in the router's queue.
  6. For an Immediate Callback, the customer's call remains in queue until it reaches the top of the queue. For a Scheduled Callback, the call is queued at the time requested for the callback.
  7. If the customer accepted a callback option, the system makes the outbound call to the customer when the customer's call reaches the top of the queue and an agent with the required skills enters the Ready state. The agent that triggered the callback is not reserved, though, and might take another call while the system tries to reconnect with the customer.
    • Routing of callback requests to agents is based on agents' skills. The required skills for a callback request depend on the type of request and the language. The mapping between subject and skill is configurable.
    • Settings such as skill expressions and the optional blackout period are configured for each callback queue in the Callback Settings Data Table in Designer.
  8. Up to three attempts are made to connect with the customer. The maximum number of times to attempt the outbound call is configured for each callback queue in the Callback Settings Data Table.
    • If the customer does not accept the request after the third attempt, then the callback is cancelled.
    • If the customer accepts the call, then call progress detection is used to detect if a human has accepted the call. An announcement is played to inform the customer that this is the callback he or she requested.
UseCases/Current/GenesysEngage-cloud/CE43

(3) Schedule a callback

The caller can specify a callback time.

8c13dfa1-6014-443d-8928-c2453c9b8849
  1. From a selection of configured days and times, the customer chooses the day, then the time, for their callback. For information about configuring business hours, see Business controls. For information about using those business hours to schedule callbacks, see Callback Settings Data Table.
  2. If the time slot is available, the system will confirm it. If the time slot is not available, the system will offer the next available time.
  3. The customer can accept the offered time slot. If the customer does not accept the next available time slot, they are asked to enter a day and time again. This loop will occur 5 times (5 is the default, and this is a configurable option).
  4. Once the customer accepts the time slot, Genesys registers the callback request and ends the call.
UseCases/Current/GenesysEngage-cloud/EE12 (1) The following diagrams show the business flow of the use case.

The business flow described below requires the base configuration of Training Manager and WFM to be completed by Genesys Professional Services with future schedule and forecast data built and Training Manager configuration.

https://www.lucidchart.com/documents/edit/102b4903-7ef2-4092-ae75-2e6c3c32f8f2/0 Ad-hoc meetings
  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:

    • 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.
  1. 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.
UseCases/Current/GenesysEngage-cloud/EE12 (2) Recurring Meetings https://www.lucidchart.com/documents/edit/fc2f1e8e-d820-4a7d-b8ea-bb10ce144edc/0 Recurring Meetings
  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.
UseCases/Current/GenesysEngage-cloud/EE12 (3) Training Requests

For each schedule run / creation, update the date range and run a new optimized search. The user is notified of any team changes that have taken place since the last meeting was scheduled.

https://www.lucidchart.com/documents/edit/b14de742-e776-431b-acb5-32613ae53858/0 Training Requests
  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:

    • 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.
  1. 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.
UseCases/Current/GenesysEngage-cloud/EE21 The following diagram shows the business flow of the use case: https://www.lucidchart.com/documents/edit/43c92f08-e625-4c4b-8166-8ebef7424863/0 Customer makes a call to one of the service lines of the company.
  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.
UseCases/Current/GenesysEngage-cloud/EE27 https://www.lucidchart.com/documents/edit/d91f2af3-6141-4b03-919a-ef751f8baea0/0-
  1. Identify the data elements that need to be synchronized.
  2. Confirm the third party system provides access to the needed data element.
  3. Define the most appropriate methodology for synchronizing the data elements:
    • Frequency
    • Data exchange medium
  4. Create and implement integration.
UseCases/Current/GenesysEngage-cloud/EE28 https://www.lucidchart.com/documents/edit/773da6d3-3538-4406-b209-2d9c53429967/0 : CONFIGURATION:
  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.
UseCases/Current/GenesysEngage-cloud/SL06 Predictive Routing for Sales

This business flow shows the use case from the perspective of the customer and agent.

7deb8693-2294-4b64-8b50-9b3e115b9a89
  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.
UseCases/Current/GenesysEngage-cloud/WF01 (2) Scheduling 320d7e0e-3faa-4d60-8ee8-a810b4f5c9a0
  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 publishes the Master Schedule and Intraday Management is informed.
UseCases/Current/GenesysEngage-cloud/WF01 (3) - Intraday fb8d2b97-f2fc-4671-9b46-2e2aa40f63a5
  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.
UseCases/Current/GenesysEngage-cloud/WF01 (4) - Employee Schedule Preferences and Time-Off - Supervisor and Agent Flows fedf78ce-8fb4-48e2-9aaf-8110da642d34 Supervisor Flow
  1. Base configuration complete.
  2. Supervisor logs in to 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 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.

Agent Flow

  1. Agent creates a 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 the 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 the published schedule is not enabled, the supervisor navigates to the WFM Calendar and filters on time off entries.
  5. Supervisor grants/declines time off requests based on business criteria.

Schedule Preference Self-Management

  1. Agent logs in to the WFM Web Agent UI and navigates to the Preferences tab.
  2. Agent selects desired preferences:
    • Shift
    • Availability Pattern
    • Day Off
  3. Supervisor manually approves or declines the submitted preferences.

More...