View table: SMART_BusinessImageFlow

1. A new task is created in the source system (BPM, CRM, or Workflow) and is then created in Genesys Cloud via Restful API.
2. Based on predefined business logic from the known worktype, prioritization and routing logic are applied and the workitem is sent into a selected queue to be handled by the appropriately skilled agents.
3. Using any number of different routing methods, Genesys looks for an agent / knowledge worker with the matching skills to meet the needs of the task at hand. Should no agents be immediately available, business logic may be defined to increase the priority of the waiting workitem, change queues, or even sent alerts to supervisors who may help get the work assigned.
4. If the task is not handled within the time threshold (calculated as a percentage of the SLA), the task is sent back to Genesys for escalation handling. Escalation handling may include:
   1. Distribution to another agent / agent group workbin, or
   2. Distribution to a supervisor workbin
   • Tasks continue to be reprioritized at regular intervals, even if they are distributed to a workbin, to ensure that their priority reflects the proximity of the due date.
5. Genesys Work Automation supports two different workflows:
   1. Push - Agents are assigned the work item, get notified of the new assignment, and work directly on it on the Genesys UI. Genesys supports both automated assignment via routing or manual assignment from the task list.
   2. Pull - Agents can view all work item in a work bin and select from the list which task they want to work on.
      For both Push and Pull use cases, when the work is completed, Genesys generates a trigger for the source system to synchronize any changes in attributes to the source system and closes the task.

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.

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.

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.

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)

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

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

1. Create or use an existing OAuth client.
   • Customers will need an OAuth client with the appropriate permission assigned to the OAuth client. See link for more info.
2. Generate an OAuth client token
   • To call the endpoint to send agentless 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 region they are working in. For more information, see link.
3. Use the OAuth client token to call the agentless outbound endpoint. For more information reference the agentless SMS tutorial.

1. An Admin configures the campaign settings in Genesys Cloud.
2. The organization either prepares a contact list from a third-party system (such as CRM or Collections) or configures their system to use Genesys REST API 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. Customers can use a message content template to create a dynamic message using data from the contact list. Alternatively, The customer can specify the SMS message body for each contact record by assigning a column in the list as the message column. Best practice recommends that if hyperlinks are used in the message 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.
5. The Genesys system checks each contact/record against the Do Not Contact lists assigned to the campaign to filter out consumers who should not be contacted.
6. Message send fail or success status is stored on the interaction.
7. 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.
8. Interaction closed if customer doesn't respond by a configurable setting.

1. An Admin configures the campaign settings in Genesys Cloud.
2. The organization either prepares a contact list from a third-party system (such as CRM or Collections) or configures their system to use Genesys REST API 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. Customers use an email content template to create a dynamic message using data from the contact list.
4. Customers provision an outbound sending domain to be used on behalf of the campaign.
5. The campaign is started and begins contacting consumers based on the settings configured in the first step.
6. The Genesys system checks each contact/record against the Do Not Contact lists assigned to the campaign to filter out consumers who should not be contacted.
7. Message send fail or success status is stored on the interaction.
8. Consumer may decide to respond to the email. Responses will thread with the original outbound email for a configured amount of time with the available metadata from the email to identify the consumer.

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

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.

1. The customer and agent are connected via a web messaging session, 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.
   • Web messaging only: The customer clicks the "Accept" option when asked the question if they want to share their screen.
   • 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 web messaging, chat or voice interaction is transferred or ended by either the customer or the agent
   • For a web messaging session, after 2 minutes of inactivity the Co-browse session will be disconnected.
   • For a WebChat session after 15 minutes of inactivity the session will be disconnected. There is no timeout when using voice.

The primary voice, web messaging or chat interaction can continue even when Co-browse has ended.

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.

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

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

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.

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
   

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

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

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

4.During the voice conversation, the following happens:

For Voice Interactions:

• Real-time audio of the voice interaction is streamed to Genesys Transcription service.
• Agent Assist displays the real-time transcription of the voice call.
• 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.

For Digital Interactions:

• 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 to read more (BL1).
• For Voice: Read the suggested content directly to the customer or use it to assist with the interaction (BL2).
• For Digital: one click copy the content to the chat window.

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

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/"

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.

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.

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

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

1. Policies are created to manage the action to be taken on interactions. These actions include delete, retain, archive, export of an interaction recording. Policy actions can also include initiate screen recording, assign for evaluation or calibration, initiate a customer survey,
   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.
      3. If assigned for Calibration - Evaluators receive notice of assigned Calibration. Evaluators complete the calibration
      4. Quality Administrator accesses results to compare scoring variations between evaluators
6. 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
7. 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.
8. Supervisor/ Evaluator schedules Agent Coaching session Refer to Use Case WE03.

1. Customer contacts one of the service lines of the company.
2. 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.
3. 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. The Inbound Voice routing strategy is not within the scope of this use case.
   1. 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.
4. 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.
5. Customer or Agent disconnects the interaction.
6. Genesys Cloud stops and stores the recording. Recordings are available for use in the Quality Evaluation, Calibration, and Survey Process.
7. A supervisor listens to the recording.
8. Legal and Compliance officer checks Genesys Cloud / retrieves recordings.

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.

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)
     • Addition of Evaluation assistance conditions
     • 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. Supervisor can also manaully create a Evaluation at the interaction level and complete it against the interaction.
4. 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.
5. 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.
6. The evaluator releases the evaluation for agent to review. Agent receives notification of completed evaluation available for their review.
7. 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.
8. Quality evaluators and Supervisors can access the completed evaluations in the Genesys Cloud CX -> Performance -> Agents -> Evaluations.

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

1. Voice interaction or digital interaction is recorded in Genesys Cloud CX.
2. Genesys Cloud CX transcribes voice interaction through Genesys Native or Extended Voice Transcription Services
3. The transcription is performed in real time based on Queue settings or Flow action; audio is transcribed in to speaker separated text.
4. Words and phrases in voice and digital transcripts are analyzed for Customer Sentiment; a Customer Sentiment Score and Sentiment Trend are calculated for each interaction.
5. Words and phrases in voice and digital transcripts are matched against phrases; based on strictness for Topic Spotting.
6. Add business-specific words or phrases within new or existing topics to improve voice transcription. https://help.mypurecloud.com/faqs/how-do-i-increase-the-accuracy-of-voice-transcription/
7. Users can search for, and pinpoint interactions, based on transcript words or phrases, detected topics or customers sentiment score or trend.
8. Users can play back and view interaction transcript and view location of found events (sentiment and topics).
9. Users can see aggregate topic and sentiment information across agents, queues and flows through Analytics Views.
10. Users can drill down in to specific interactions from these Analytics Views to do root cause analysis

1. 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. US English, 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
2. Add business-specific words or phrases within new or existing topics to improve voice transcription. https://help.mypurecloud.com/faqs/how-do-i-increase-the-accuracy-of-voice-transcription/
3. Use Topic Miner to use key-phrase extraction to get a list of business specific topics that are already occurring within conversations; create Topics based on what is discovered through Topic Miner ( https://help.mypurecloud.com/articles/about-the-topic-miner/)
4. Set a Default Program, so that is there is no mapping to a Queue or Flow, then there is a fallback (Select a Default Program)
5. Create a new program and map it to the desired Queues and Flows (Create a Program)
6. Assign any relevant out-of-the-box topics and newly created topics to the new program
   1. Admin -> Programs
   2. Select the program created above
   3. Click on the Selected topics tab
   4. Select the checkbox for the required topics
   5. Click Save Draft or click Publish

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

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

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.

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

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

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

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.

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.

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.
   
   

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 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) will be able to open the task in the Workspace Desktop to manage and/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.

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 couple complete the task within the Workspace desktop (using the "mark done" button).
3. The employee may choose not to finish their work immediately if, for example, they are waiting for a call back 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 if, for example, 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 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.

1. A new task is created in the source system (BPM, CRM, or Workflow).
2. Genesys captures the task from the source system and creates an interaction in the system. The interaction is classified and prioritized according to business rules and the task type (see Business Logic). The tasks are reprioritized within certain periods of time.
3. Genesys looks for an available slot in a personal or group workbin of agents with the required skills. The distribution logic fills up the workbin until the maximum number of tasks is reached (or no task for the corresponding skill is available). If no workbin has an available slot, Genesys queues the task and reprioritizes in predefined intervals until it can be distributed.
4. If the task is not handled within the time threshold (calculated as a percentage of the SLA), the task is sent back to Genesys for escalation handling. Escalation handling may include:
   1. Distribution to another agent / agent group workbin, or
   2. Distribution to a supervisor workbin
   • Tasks continue to be reprioritized at regular intervals, even if they are distributed to a workbin, to ensure that their priority reflects the proximity of the due date. Tasks are temporarily removed from the workbin for reprioritization.
5. The agent can pull a task via the Genesys desktop, which displays the task and opens the corresponding work item within the source system.
6. Task handling functionality occurs exactly as in Genesys Work and Lead Distribution (BO02) for Genesys Engage on premises.

1. A task is created in the source (CRM/BPM/workflow) system.
2. Genesys captures the new tasks from the source system through existing capture adapters and creates a new interaction in iWD. See Genesys Work and Lead Distribution (BO02) for Genesys Engage on premises for details.
3. During the classification process iWD initiates one or more data lookups to fetch context data from third-party systems or from Genesys context services. This data can be used as additional attributes to distribute or prioritize tasks.
4. Based on the parameters available with task creation and the additional parameters fetched from another system, the interaction is classified based on business rules (see Business Logic section on Genesys Personalized Task Distribution (BO04) for Genesys Engage on premises).
5. The interactions in the GTL (Global Task List) are reprioritized within specified intervals based on task attributes and/or additional context data.
6. iWD Interactions in the universal queue get routed to an employee or supervisor based on routing logic. Once an employee with the right skill becomes available to handle the task, the task is distributed to the employee. If it cannot be assigned within a specified period of time it is reprioritized.
7. The Genesys employee desktop opens the corresponding work item within the source system. The employee handles the task in the source system, as in Genesys Work and Lead Distribution (BO02) for Genesys Engage on premises.

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

1. The actor (team lead, supervisor or business analyst) runs a report or a report is pushed to them.

Reference - BL1

1. He reviews the report against business level KPIs for service level, handle time, customer segmentation and media type (Interaction Volume Customer Segment Report).

Reference - BL2

1. If he finds anomalies in the service level, he analyses further reporting data to identify anomalies with contributing factors to Service Level. For example, he might find that Average Handling time was high as well.

Reference - BL3

1. He starts to drill down into further details (e.g. by filtering against queue or media type).

Reference - BL4

1. He analyses the information for anomaly details and correlations (e.g. Queue, ACW or Other KPI).

Reference - BL5

1. This information helps him to identify the root cause for the Service Level anomaly. As an example, he may identify that high ACW is driven by a certain Agent ID, Agent Group, etc.…Subsequently he identifies that the root cause is the skill levels of agents servicing a particular customer segment.

Reference - BL6

1. The team lead or supervisor takes appropriate action.

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

1. The caller initiates an inbound voice call to the contact center. Optionally, Skype For Business Platform can be used.
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 2 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.

1. The customer calls one of the numbers of the contact center.
2. He is routed to an IVR application which is determining the service type and also performs an Identification and (optionally) Verification of the customer. This functionality is provided outside of the scope of this use case, it is assumed that the information on the requested service and customer identification is passed on to be used within this use case. The use case CE7 - Effective Identification and Validation in IVR can be used for this functionality. Alternatively, customer CLI is used for Identification.
3. If the customer calls outside of out-of-office hours or if an emergency situation is in progress, an announcement is played. After this the caller may be reconnected or diverted to another number inside or outside of Genesys.
4. Genesys retrieves context data on the customer based on the customer identification.#If the contact center is open the routing parameters for this particular call is set based on the type of request and the customer context. This will enable flexible and personalized call handling.
5. The Expected Wait Time (EWT) for the customer is calculated and is announced to the customer (optional). If the EWT exceeds a specific threshold, an announcement is played and the caller is disconnected or routed to another number inside or outside of Genesys (optional).
6. Additional announcements are played to the customer. These announcement are based on the customer context. Examples include: Quality announcements/Special promotions-offers for the customer/Announcements for potential self-service options
7. If the customer has been calling recently for the same type of request, Genesys can route to the last agent (configurable based on type of request and customer context). In case this agent is not logged in or not available for this call within a specified time out, the call is routed to the requested skill
8. The call is distributed to the best agent who:
   • Has the base skill(s) to handle the original request
   • Has the supplementary skill(s) determined by the customer context (optional). Examples include:Skills to upsell a defined product / service to the customer or specific empathy skills based on the customer segment or demographic
   • A cascading mechanism enlarges the potential agent pool by suppressing the supplementary skill and / or reducing the skill level on the base skill if the call cannot be distributed within specific timeouts.
9. Once the call is distributed to an agent, the call context information is displayed to the agent. As an example, the agent is able to see any special offer or promotion for the customer, so he can start the relevant information. The agent handles the customer request and any potential up-/cross-sell opportunity.
10. After the conversation with the customer, the agent records the outcome of the call for reporting purposes e.g. if he has acted on the presented lead

1. A customer calls a service line of the company.
2. The customer requests to speak with an agent.
3. The system verifies the estimated wait time (EWT) for an agent qualified to handle the request. If the wait time is below the specified threshold, 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 described in the prerequisites CE01 or CE02.
4. When the Estimated Wait Time threshold is exceeded, a wait time announcement can be played to the caller. This can be a generic announcement or, ideally, a broader range estimate like "between 5 and 10 minutes" or "less than 10 minutes."
5. After the announcements, the customer hears callback options.
6. If the customer chooses 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 are prompted to 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 (see the Callback flow below). If the customer chooses a Scheduled Callback, they are asked when they want the callback (see the Register Scheduled Callback flow below).
7. If the customer does not accept the callback offer, the call is transferred to the corresponding waiting queue.
8. Optionally, you can play a recorded description of a callback.

1. Consumers can request a scheduled or immediate callback:

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

   b. 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 are performed. If the customer does not accept the request after the third attempt, then the callback is cancelled.
4. If the customer accepts the call, an announcement informs the customer that this is the requested callback. 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."
5. Customer confirms their desire to connect to the agent.
6. Customer and agent are connected.

1. The customer chooses a day and time for their callback from a selection of configured times.
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 can 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.

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 will identify 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 will ask for a separate Identifier (e.g. customer ID, account number, tracking number) to identify the customer. This question must require numeric entry. If the customer does not have the necessary information, Genesys asks the customer to press a specific DTMF tone.
5. The customer input is validated against the customer database.
   • If no match is found, the customer is asked for their identifier, up to a maximum of three times after failure. The number of retry attempts is configurable.
   • If the customer is still not be 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 wish to re-order authentication questions.
7. Genesys looks up and validates the security information entered by the caller within a third party application. If this validation is not successful, the system asks the customer for security information again, up to a maximum of three times after failure.
   • If the system cannot successfully validate the customer, the system forwards the customer to agent assisted service.
8. Genesys plays a prompt that confirms the validation or informs the customer of the failure.
9. A configuration parameter determines where the caller should be routed to next. The possible options are listed below. However, these are outside the scope of the ID&V use case:
   • Agent assisted service - the result of the identification and verification will be displayed to the agent making both the customer and agent experience better. This functionality requires implementation of the use case Genesys Personalized Routing (CE02) for Genesys Engage on-premises.
   • 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

1. A customer calls a service line of the company.
2. Customer progresses through routing strategy. The routing strategy is not in scope of this use case.
3. An IVR application answers the call. The full IVR application is not within the scope of this use case, but the functionality in this use case can be used as a module to enhance the IVR application with personalization options.
4. If the customer needs to be identified and authenticated (verified), the ID&V interaction uses one or multiple identifiers (such as Customer ID, Account Number, or similar). Customer identification may also be verified by a PIN, if required. This functionality is offered by another use case provided by Genesys, which is leveraged in this scenario Genesys Customer Authentication (CE07) for Genesys Engage on premises. The Identification and verfication functionality itself is not within the scope of this use case.
5. Using the customer identifier (for example, ANI), Genesys can retrieve customer context information from a third-party system or from Genesys context services (optional).
6. The personalized treatment is decided based on submitting context to business rules natively, using third-party systems or using internal data. Personalized treatments include:
   • Playing a personalized message to the customer. The caller may hang up at this point if they have all the information they require. For example: The caller is identified to be in a region with a power outage. An announcement can be played to inform the caller of the status.
   • Proactively playing status or balance before presenting any options. For example: "Your next order is due to be delivered on Thursday."
   • Proactively offering the most likely call reason. For example: "Are you calling about the loan application you have in progress?"
   • Personalizing menu options (dynamic menu). For example: "Only play mortgage option in the menu only if they have a mortgage or present an option if they are eligible."
7. Sending the customer to:
   • An agent with updated context.
   • A self-service application (not in scope).
   • A generic menu, if the caller does not fit any of the configured personalization options. In this case, the caller continues to the main menu of the IVR application.
   • Since this use case is about personalization, the development of this main menu is out of scope.

1. A customer calls one of the company’s service lines.
2. The IVR application answers the call.
3. If complex input/output is required, the IVR application offers a Visual IVR to the customer. Genesys offers the visual option (through a voice announcement) to the caller and asks if they would like to proceed. The voice announcement also informs the caller that a smart phone is required.
4. Callers who do not want to proceed with the visual option can continue with the voice-only IVR.
5. Genesys asks if customer wants to proceed with visual interaction
   • If the caller accepts and provides their phone number (as needed), Genesys sends the caller an SMS with a hyperlink to initiate the visual interaction. The voice channel remains active.
   • If the caller clicks on the link in the SMS, the visual interaction on the caller’s mobile web browser is started in parallel to the voice channel. Context can be passed from the voice channel to the visual channel.
6. Genesys displays visual flow while the voice channel helps the caller. During the Visual Interaction phase, the IVR actively disables caller voice input.
7. The customer completes the task on the visual user interface and selects the next option, potentially repeating the previous step.
8. The customer completes all of their tasks and opts to leave the self-service. Once the customer completes the visual IVR task, a regular voice-only IVR may resume the application. For example, once an address change is completed visually, the call might not end and continue via other self-service application and/or escalate to an agent.
9. Genesys ends the session.

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, the dialing mode is configured as Progressive, Predictive (seizing is optional and recommended), or Preview.

• In Preview mode, the agent receives or retrieves a record and the call is initiated by the agent.
• In Progressive mode, the system automatically places the call based on an agent being available for the specific campaign. 1-to-1 is the default for progressive mode. CX Contact also supports a progressive multiplier, 1-to-many.
• 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 potential results. For example:

• Bad Number or No Answer:
  • In Preview mode, the agent hangs up, and the disposition and the result are 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 has the option to leave a message then disposition the call. Based on the call result code the call may be retried later. The result is written back to the system.
  • In Progressive and Predictive modes, the call either disconnects, bridges to an agent, or plays a message (based on the Destination DN configured in step 1) and the result is written back to the system.
• Live Party (Call Result = Answered) connect: the agent is connected to the consumer.
  • The consumer can opt out. The agent records this result in the agent desktop and it is written to a system DNC list. Access to this DNC list requires a Care ticket and intervention.
  • The consumer can ask for a callback. The agent records this result 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.
  • Call result status and record type are written to the list.
  • Info Mart and the BI Extract are required for agent disposition results.

4b. For Outbound IVR, there are multiple potential results. For example:

• Bad Number or No Answer - the call disconnects and the result is written back to the Genesys system (Info Mart and Contact List).
• Answering Machine - the call either disconnects or plays a message (based on the configuration chosen in step 1) and the result is written back to the Genesys system.
• Live Party connect - the call plays the Outbound IVR message.
  • The consumer can opt out of future calls, typically done by including “Press 9 to opt out of future calls”.
  • Optionally, the administrator may choose to offer the option to connect to a live agent, typically done by including “Press 2 to connect to a live agent”.
    • If the agent is part of the Genesys environment then calls can predictively be paced to keep the agent busy. Progressive mode is also available in a default 1-to-1 or progressive multiplier 1-to-many configuration.
    • If the agent is external to the Genesys environment, connection can also be achieved by routing to a phone number provided by the company, external to Genesys. In this case pacing is managed with the number of outbound calls in predictive or progressive (recommended) modes. Pacing cannot determine the availability of agents that are not part of the Genesys environment
      • Consideration: Outbound voice trunks have limits and sizing should be considered to enable the proper dialing rate
      • The result is written back to the Genesys system.

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 will continue at step 3. If no additional contact is required, the contact treatment ends.

• 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 has the option to opt out of future calls. This 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.

• 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 has the option to leave a message. Based on the disposition code, the call may be re-tried later. The result is written back to the system.
    • In Progressive and Predictive modes, the call either disconnects or plays a message (based on the configuration chosen in step 1) and the result is written back to the system.
  • Live Party connect - the agent is connected to the consumer.
    • The consumer has the option to opt out. In cloud, the agent records this in the agent desktop and it is written to a suppression list or DNC list in the premise.
    • The consumer has the option to ask for a callback. The agent records this 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.

1. An Admin (or Genesys PS) configures the campaign and interaction strategy in the Genesys System. The organization prepares a contact list for the campaign.
2. The campaign begins contacting consumers based on the campaign strategy set in the previous step.
3. The Genesys system checks each contact/record against the Do Not Call list to filter out consumers who should not be contacted.

   3a. All records flagged with DNC are not sent.

   3b. Genesys compiles the SMS text from a template using fields provided with the contact list for personalization. Best practice recommends adhering to character limits, though the Genesys aggregation platform supports concatenation for messages exceeding in-country limits (for example, the maximum size in the U.S. is 160 characters).

   3c. Genesys system updates contact/record result, which is recorded in the contact list.

   3d. The customer receives the message.

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.

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

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

• 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 pre-defined 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.

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

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, e-mail 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 e-mail, the system sends an e-mail 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 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:
    • Genesys Voice Payment (CE08) for Genesys Engage on premises
    • Use custom payment application
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 e-mail message with a link to a payment system to the customer.

1. A customer sends an email to one of the public addresses (such as orders@abc.org) monitored by the Genesys Email solution. Alternatively he can submit an email using a web form based on Genesys widgets.
2. Genesys periodically checks corporate inboxes for new emails using POP3, IMAP, or Exchange Web Services Protocol.
3. The new email is captured by Genesys including “From”, “To”, and “Subject” as metadata.
4. Genesys verifies if the corresponding user already exists as a contact within the Genesys Universal Contact History (by email address). If the contact does not exist yet, Genesys creates the contact. The email and any answer by the agent is attached to the contact.
5. The system verifies if the “From” email address is on the email blacklist. Emails from blacklisted email addresses are not distributed to agents.
6. The system checks if the email is a new email or a reply email.
   • In the case of a new email, the system analyzes the content to classify the email.
   • In the case of a reply email from the customer, the system attempts to route to the previous agent.
   • In the case of an automatically generated reply email, the email is not distributed to an agent and the flow stops.
7. The system sends out a receipt acknowledgement email to the customer with a predefined template for the “To” address.
8. Once an agent with the requested skill is available, the email is routed to the agent's workspace application with screen pop showing “From”, “To”, and “Subject” information. Any available contact information from the Genesys Contact History (customer name, for example) and previous contact history is also displayed.
9. Once the agent reads the email, he or she needs 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. The agent sets a disposition code to mark the business outcome for reporting purposes.
11. After the agent sends the email, the email can be passed to a supervisor for review before sending it to the user. The decision is made based on the agent.

2. The Genesys system monitors the mailboxes that handle these consumer messages.

3. When a message arrives, the request is captured with context data, and the routing strategy determines how to handle the request. The strategy tries to identify the consumer in Genesys contact history. If the consumer does not yet exist in the database, a new record is created. Optionally, a web form gathers additional information (such as language) about request elements such as case, reason for contact, and location.

4. The original message is stored in the Genesys contact history.

5. If this is a new message (not a reply), the content analyzer compares the message to a series of models to determine the intent (classification) of the message. It may also use models to determine sentiment and actionability of the message. The result of these comparisons is a numeric confidence level from 1 - 100.

• If the inbound email is a web form email and the Language field is populated, then the content analyzer model uses the specified language.

• If the language in the user data is not populated (either because it comes from a direct email server or because the web-form cannot ascertain the language), the Language Classification model classifies the language.

• The content analyzer model (root category configured in OPM) and language are determined.

6. Depending on the confidence level, Genesys takes one of the following actions:

• Sends an automated response to the consumer.

• Sends a suggested response to a live agent for their review.

• Sends the message to an agent allowing them to manually select a standard response. Optionally, responses can contain links to Knowledge Center for related content (requires Knowledge Center).

7. If the confidence level falls below the auto-response threshold, the system sends the email interaction for distribution to an agent.

8. If the confidence level exceeds the threshold, the system sends the automated response to the consumer, ideally using the original To: address as the From: address, enabling the consumer to respond easily.

9. Genesys stores the response in the contact history.

10. If the incoming email is a reply to a previously sent response, the message is routed directly to an agent, bypassing the review steps 5 and 6.

11. The agent receives the customer message (with or without a suggested response) and reviews any response for accuracy and relevance.

12. The agent can include the suggested response in their reply. If a suggested response is not available, the agent creates the response and sends it to the customer. If no reply is needed, he finishes the interaction by simply entering “Mark Done”.

13. The agent records the outcome of the interaction for reporting purposes.

14. Genesys stores the response in the contact history.

1. The customer requests to chat with a live agent via the web page.
2. Customer enters his data via a registration window. The data he can enter are: Last name, first name, nickname, subject and e-mail address.
3. Genesys uses the subject to determine the parameters for routing of the chat request (see chapter “Distribution logic”).
4. Genesys will check if last and first name is available from the customer
   • If the customer has not provided the information on first and last name the chat session will not be associated to any contact and no transcript will be saved or e-mailed to the customer.
5. If the customer has entered his e-mail address, Genesys will search for the customer in the contact history. If no contact with the same e-mail address is available, Genesys will create a new contact. The current chat session will be associated to this contact and the chat transcript will be stored under this contact.
6. The chat window will pop-up.
7. Genesys checks if agents are logged in for the requested subject.
   • If no agents are logged in at all for the service chat is disconnected and customer is getting a disconnect message.
8. If agents are logged in for the service, routing takes place.
9. The customer gets a welcome message from Genesys system. Welcome text may depend on the subject.
10. Genesys will search for an available chat agent. If no agent is available the chat interaction will be queued (see chapter “Distribution Logic” for the queuing logic)
    • until an agent becomes available. Comfort messages may be sent to the customer during wait time
    • customer ends the chat session (the business flow ends)
    • final timeout is reached, chat is ended and the customer is informed (the business flow ends)
11. When the chat request is routed to an agent, he can either accept or ignore the chat interaction. If he does not accept the interaction, Genesys will attempt to route to another agent after a specific time out. The first agent will be set to not ready (RONA). Continue at step 9.
12. If he accepts, the chat session between the agent and the customer is established. The agent can use standard responses based on the subject for the chat interaction with the customer.
13. When the chat session is finished the agent can set a disposition code to register the outcome of the chat for reporting purposes.
14. If the customer has provided his e-mail address during the registration process, he will receive a transcript of the chat session via e-mail (optional).

1. The user searches in Twitter/Facebook for the company's handles. User will post/tweet to the attention of the company, by posing a customer care issue.
2. User will post/tweet to the attention of the company, by posing a customer care issue.
3. Genesys monitors the Twitter/Facebook handles via predefined events and filters the message using keywords to determine actionability.
4. Genesys verifies if a corresponding contact already exists in Genesys Contact History. The customer will be identified in the contact history by his Facebook / Twitter handle (if available)
   • 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.
5. Genesys verifies if the day is a normal operational day. If not, a special day message can be sent stating that the message will be answered once the service is back online. The special day message can be sent either publicly or in private mode.
6. Genesys has the ability to determine if the operating hours of the service match the current time and day. If not, a standard message will be sent in response stating that the message will be answered once the service is back online. This message can be sent either publicly or in private mode.
7. In addition, it is possible to define an emergency message that will be sent once the emergency process is activated. If the emergency setup is invoked, then the system can answer with some emergency message either publicly or in private mode.
8. Genesys will search for an available agent with the correct skills.
   • If an agent is available, the interaction is routed to an agent.
   • If no agent is available, the interaction is queued until an agent becomes available
9. The interaction is sent to the agent for appropriate response.
10. The agent will decide if the interaction requires private comments.
    • If no private answer is required, he will reply via the company facebook page or company's twitter handle
    • If private messaging is required, the interaction will be moved out of the public comment space and will be dealt with via private messaging (Twitter DM/FB messenger. See separate flow for FB messenger)
      • Best practice for the agent is to respond to a public message with a public response, indicating that the conversation might be moved to private.
    • The agent also has the ability to simply “like” the user comment, if this was considered as positive and no specific answer required.
    • Otherwise, no further action is taken.
11. When the interaction is finished the agent can set a disposition code to register the outcome for reporting purposes.

Business Flow Description – Reply with Facebook Messenger

1. User will send a facebook message to the company (e.g. after having been asked by an agent to connect privately).
2. The message will be stored with the customer contact in Genesys contact history
3. Genesys verifies if the day is a normal operational day. If not, a special day message can be sent stating that the message will be answered once the service is back online. The special day message will be sent via facebook messenger.
4. Genesys has the ability to determine if the operating hours of the service match the current time and day. If not, a standard message will be sent in response stating that the message will be answered once the service is back online. This message will be sent via facebook messenger.
5. In addition, it is possible to define an emergency message that will be sent once the emergency process is activated. If the emergency setup is invoked, then the system can answer with some emergency message via facebook messenger.
6. Genesys will search for an available agent with the correct skills.
   • If an agent is available, the interaction is routed to an agent.
   • If no agent is available, the interaction is queued until an agent becomes available
7. The interaction is sent to the agent for appropriate response.
8. A Facebook chat session is established between the customer and the agent.
9. When the interaction is finished the agent can set a disposition code to register the outcome for reporting purposes.

1. The customer contacts the company via e-mail, chat or SMS
2. Genesys verifies if the customer can be identified in context services (Reference: BL1)
   1. Identifying information is:
      1. E-mail address for e-mail and chat
      2. Phone number for SMS
3. If the identifying information does not match an entry in context services, a new contact will be created. Context from the interaction and customer journey will be attached to this contact. For chat: If the customer does not provide an e-mail address, he will be handled as anonymous customer and no contact / journey will be created.
4. The interaction is handled as described in the underlying use cases for chat, e-mail or SMS
5. If the customer could be identified in context services, Genesys will check if personalized treatment/handling of the customer interaction is required using the available information in the database and the configured business rules (Reference: BL2).
6. Genesys updates the contact with context information from the interaction and the customer Journey. The interaction is handled as described in the underlying use cases for chat, e-mail or SMS.
7. Genesys updates the contact with context information from the interaction and the customer Journey (Reference: BL3). Genesys will modify the following based on the configured business rules:
   • Automated reply message (personalized messaging)
   • Required skill / agent to handle the interaction
   • Interaction priority
8. The flow will continue as described in the underlying use cases for chat, e-mail or SMS with the modified parameters as described above.

1. A customer is browsing the company's website or mobile site and requires help. The customer decides to call the contact center and clicks the “ClickToCall” button. Optionally, the customer can click a Channel Selector Widget that shows available channels. If Estimated Wait Time is above the configurable threshold, the ClickToCall button is not accessible.
2. ClickToCall Widget displays the Estimated Wait Time, and the customer is prompted to enter their phone number (mandatory) and optional contact attributes such as Name and Email.
3. The website retrieves a dynamic phone number related to the current web page and displays that to the customer.
4. The customer manually dials the number (or could be prompted to dial the number using click-to-call in a mobile browser), and a call into the contact center is established.
5. Depending on the configured method for matching the interaction, one of the following occurs:
   • DNIS Pool: The user is placed into a queue.
   • Access Code: The website displays an access code and Genesys prompts the caller to enter the access code while on the phone call. If the customer does not enter the correct code after multiple attempts, a corresponding message is played and the call is disconnected. Note: this approach has licensing and development requirements.
6. The call is queued within the Genesys system according to the distribution logic described below and delivered to agents with the skill corresponding to the requested subject.
   • If the agent accepts the call, the call is established and the following information is displayed in the agent desktop: Subject based on DNIS, Customer ID, First Name, and Last Name (as available).
   • If the agent does not accept the call, the call is sent back to the queue and the agent is set to not ready (RONA – redirect on no answer).
   • After the call is finished, the agent sets a disposition code to record the call outcome for reporting purposes.

1. A customer is browsing the company's mobile application and requires help. The customer decides to call the contact center and clicks the “ClickToCall” button. The mobile application and related functionality is not within the scope of this use case, but will be provided by the company. Genesys can provide sample applications for iOS and Android.
2. The application retrieves the expected wait time for an agent with skills corresponding to the page and determines whether the time is within the acceptable threshold. If the wait time is above the configured threshold, the app informs the customer and offers to notify him via push notification once an agent becomes available. For customers who do not have push notifications enabled, it is recommended to offer them the ability to activate push notifications for improved service. This functionality is within the application logic and not provided by Genesys.
   • If the customer does not want to wait to be notified, the call to the contact center is established from his mobile device.
   • If the customer agrees to be notified, a push notification is sent to the customer when an agent becomes available. If the customer declines the push notification, the flow ends.
3. The mobile app retrieves the customer details, then establishes a call from the customer’s mobile device to the contact center.
4. The call is queued within the Genesys system according to the distribution logic described below and delivered to an agent with the skill corresponding to the requested subject.
   • If the agent accepts the call, the call is established, and the following information is displayed in the agent desktop: Subject based on DNIS, Customer ID, First Name, and Last Name (as available), plus a new tab for Mobile Details, including a map with the customer’s current location.
   • If the agent does not accept the call, the call is sent back to the queue and the agent is set to not ready (RONA – redirect on no answer).
5. After the call is finished, the agent sets a disposition code to record the call outcome for reporting purposes.

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 his 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 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 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 he 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 will be connected to an agent.” The customer can confirm the callback by pressing “1”, and he will be 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 he still does not accept the call, the request is cancelled.
9. After the conversation between the agent and the customer, the agent can classify the call for reporting purposes via his agent workspace.

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 his 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 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 voice mail, 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 he still does not accept the call, the request is cancelled.
9. After the conversation between the agent and the customer, the agent can classify the call for reporting purposes via his agent workspace.

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, only the customer can initiate the co-browse session.
   • Call only: A session ID is displayed to the customer if he/she clicks the co-browse link in the Assistance/Channel Selector Widget. This session ID is needed to join the agent desktop with the correct browser session. The customer gives this session ID to the agent over the phone. The agent enters the session ID into the agent desktop to start the co-browse session.
   • Chat only: The customer clicks the three-dots icon on the chat widget and selects "Start Co-browse".
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 web page, click buttons, or navigate the customer's browser.
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 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 web page. Sensitive Data can be masked before presenting to the agent, and agent controls (the ability to fill certain fields or submit forms) can be blocked through instrumentation. The customer can revoke the Write Mode at any time, returning the agent to Pointer Mode.
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.

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

1. A customer sends an SMS to a company phone number. The SMS message is captured from a Company SMS center to be handled by agents.
2. Genesys is integrated to the SMS center via an SMS Gateway and will recieve the messages.
3. The new SMS is captured by Genesys including the customer's phone number as meta-data.
4. Genesys verifies if the corresponding user already exists as a contact within the Genesys Universal Contact History (by phone number). If the contact does not exist yet, Genesys creates the contact. The SMS message text as well as any answer by the agent is attached to the contact.
5. The system will verify if the customer's phone number is on the blacklist (see chapter “Blacklist”). SMS from blacklisted phone numbers will not be distributed to agents 6. Genesys analyzes the content to classify the SMS (see section “SMS message Categorization ”)
6. The system sends out a receipt acknowledgement SMS to the customer with a predefined template.
7. Once an agent with the requested skill is available, the SMS is routed to the agent's workspace application with screen pop showing information on the SMS category. Any available contact information from the Genesys Contact History (e.g. customer name) and previous contact history is also displayed.
8. Once the agent reads the SMS, he or she needs to decide if a reply is needed.
   • If no reply is needed, the agent marks the interaction as done.
   • If a reply is needed, the Agent creates an outbound reply SMS, potentially using a standard response template.
9. The agent sets a disposition code to mark the business outcome for reporting purposes.
   

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 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. (BL3)
6. The customer's response is then sent to a third-party NLU engine via API. [BL1-BL4]
   • If intent and entities are returned, the conversation moves to the correct point in the interaction flow, which could be within one of the following sub-flows (or microapps):
     • Identification & 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?" [BL2-BL3]
   • If the customer responds “yes”, they're brought back to Step 5: "How may I help you?”.
   • If the customer responds “no”, the chatbot decides whether or not to offer them a survey (see step 8).
   • If the customer responds with a more advanced answer, the response is sent to a third-party NLU engine via API to determine intent and entities for further processing.
8. Customer information and/or context is retrieved to determine whether to offer a survey. [BL5]
   
   • If a survey is to be offered, the chatbot continues to the next step.
   • 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 continue to the final step and are shown a goodbye message.
10. The survey is executed. The survey questions are configurable by the customer on a business-as-usual basis and therefore no dialog flow is defined here. This dialog uses the Genesys Intelligent Automation Questionnaire Builder microapp.
    • The chatbot presents a goodbye message and ends the chat.
      

• If the brand was pre-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 company purchases Genesys Messaging for WhatsApp (including Hosting Fees and Incidental sellable item) 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 company 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.
• For Facebook Messenger there is no specific approval required. The steps for purchasing and going live with Facebook Messenger are the same as for WhatsApp.

1. Apple Business Chat: 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. Facebook Messenger: the customer can initiate a Messenger Conversation through the official Facebook Page of the company)
2. Apple Business Chat: The customer clicks the chat message icon, and sends an initial message to begin the conversation. Facebook Messenger: The customer clicks on the "Send Message" icon on the Facebook official page.
3. The Genesys system checks to see if it can recognize the customer.
4. For brand new interactions, Apple passes an opaque customer ID to protect the customer's privacy until they are ready to share more information with the company. WhatsApp passes the phone number of the customer to help identify who initiated the conversation. Facebook passes a new PageScoped ID which is unique for a user, for a 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 Engage on premises.
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. For WhatsApp, Highly Structured Message templates (HSMs) can be sent to the customer (see below). For Facebook Messenger, Rich Media elements include Generic, Carousel, Media, and Button. For Apple Business Chat, additional rich media elements can be used by the agent:
   • List Picker - to select one or more options from a list
   • Date Picker - to make an appointment
   • Apple Pay - to complete a transaction
   • Deep Linking into company app for customer authentication purposes, invoking other capabilities already within the app, or for other reasons
10. Customer and agent interact via messaging service and after conversation is complete, agent dispositions the interaction.

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

• Using these interaction types can save time for the agent and reduce errors from the customer. Agents can choose these options from the standard response library so they don't have to assemble the pick lists on the fly.
• After the conversation between the agent and the customer, the agent can classify the chat for reporting purposes via the agent workspace.

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

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

1. A voice interaction is initiated (reactive or proactive) on the voice channel.
2. The customer hears a standard welcome message from the voicebot.
3. Customer information and/or context is retrieved from:
   • Customer profile information 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 sub-flows.
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."
   • Fallback 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 or not to offer them a survey (see the next step). If the customer responds with a more advanced answer NLU Engine determines intent and entities for further processing.
9. Customer information and/or context is retrieved from the following sources to determine whether to offer a survey which is available within Genesys Intelligent Automation only (steps 8-10):
   • Customer profile information in UCS
   • Genesys User Data
   • API call to third-party data source
   • Logic defined in Intelligent Automation
   • If a survey is to be offered, the voicebot continues to the next step.
   • If no survey is to be offered, the voicebot shows a goodbye message and ends
10. The voicebot asks the customer:"Would you like to participate in our survey?"
    • If the customer answers something like "yes", then they continue to the next step and engage in a survey.
    • If the customer answers something like "no", then they shown a goodbye message and the voicebot ends.
11. Optional: If the survey results meet a certain criteria based on the configured evaluation parameters, a specific action can be taken. For example, if the customer provides a negative response, they can be routed to a live agent.