<translate>= Using Zendesk Integration Scenario Blocks = A scenario is a script that defines the logic of automated processing of interactions satisfying some specific criteria (e.g., inbound interactions arriving at a specific access point). In Bright Pattern Contact Center software, scenarios are used to map out the sequence of actions that may occur during an interaction (voice, chat, SMS, etc.), with all the possible options, exits, prompts, and so forth, that could be presented to a user or customer.
Scenarios are built and defined in the Bright Pattern Contact Center Scenario Builder application, which is available via the Bright Pattern Contact Center Administrator application. You can create your own scenario from scratch, or you can use a template scenario (easier) and then customize it to suit your needs. Scenarios are constructed using "blocks," which you can learn about in more detail in the Scenario Builder Reference Guide.
For the purpose of this Zendesk Integration Guide, let's consider the integration scenario blocks that could be used in a simple scenario involving look-ups to recognize the customer and screen-pop of the customer's Zendesk data.
Zendesk Scenario Building Notes
When building your Zendesk scenario, note the following:
- The Zendesk scenario blocks function the same whether they are used in voice or chat scenarios.
- Zendesk scenario blocks work best when configured with other Zendesk scenario blocks, either in pairs or in a series. For example, if you want to search your Zendesk account for a customer’s contact information, then pop the contact information search results to the agent, your scenario would need both the Zendesk Search block and Zendesk Screen Pop block.
- Using the Zendesk Screen Pop block, you can make the scenario pop a new ticket every time the customer calls/chats, but you don’t have to do it that way. It may be enough to pop the customer’s contact info so you don’t have so many tickets.
Example Voice Scenario
What follows is the sequence of actions that could occur in a basic voice scenario flow.
Click the following link to download a version of this Zendesk voice scenario example.
File:App Zendesk Search and Pop (Voice).zip
Action 1: An inbound call comes in, and the customer is prompted for information.
A customer calls Bright Pattern Support. (For simplicity, service hours verification is omitted, and agent skill requirements are identified by the dialed number.) The customer is greeted with a Collect Digits block with the following prompt: Welcome to Bright Pattern support. If you are calling about an existing case and have the case number, please enter it now followed by the pound sign. Otherwise please remain on the line.
Action 2: The customer does not enter a case number, so the scenario identifies the customer by caller ID.
If the customer does not enter any digits, a Zendesk Search block is used to recognize the customer by ANI (Caller ID).
Action 3: The customer's data is pulled from Zendesk data and popped to the agent.
If the customer record is found, a Zendesk Screen Pop block is used to pop the customer record into the Zendesk application of the agent that will receive the call. The call is then sent to the service queue.
Action 4: The scenario looks up case/ticket data.
If the ticket number is entered, a Zendesk Search block is used to look up the ticket information.
Action 5: The customer is directed to a menu.
A Menu block is then used with the following prompt: Thank you. We have found the ticket with subject $(zdTicket.subject). For the status of this ticket, press 1. For any other inquiries, press 2 or stay on the line.
Action 6: A prompt regarding ticket status is played to the customer.
If the self-service is selected, a Play Prompt block is used to inform the customer about the current ticket status: The current status of this ticket is $(zdTicket.status). Thank you for your inquiry. Goodbye. The call is then marked as self-served and released.
Action 7: The customer's ticket/case information is popped to the agent.
If the customer needs the agent's help, a Zendesk Screen Pop block is used to pop the ticket to the Zendesk application of the agent who will receive the call. The call is then sent to the service queue.
The Complete Voice Scenario
The diagram shown illustrates what a complete scenario looks like when designed in the Scenario Builder application.
Example Chat Scenario
The following is an example of the sequence of actions that could occur in a basic chat scenario flow.
Click the following link to download an annotated version of this Zendesk chat scenario example.
Zendesk Create and Pop User (Chat)
Action 1 (Optional): A customer fills out a pre-chat form with their first name, last name, email address, and a brief message; the brief message should go to the agent.
Using an If block, the scenario searches the pre-chat form to see if the message field is empty or not. Then, if the field is not empty, the Set Variable block is told to treat what was entered in the field as a chat message; this is done by resetting the value to item.newMessage.
While it is not necessary to include a message field on a pre-chat form, you may find it useful for your agents, as well as for reporting purposes.
Action 2: The scenario searches for matching customer information in Zendesk.
Next, using a Zendesk Search block, the scenario searches in your Zendesk account for customer information entered on the pre-chat form. In this instance, the block will search in Zendesk for a customer whose email address matches the one entered in the pre-chat form’s email field; the results are returned to the variable entered in the Recordset name field.
Action 3: The customer information from the Zendesk search is configured to pop to the agent.
If the search for a matching customer email address is successful, you will want the search results to pop on the agent’s screen. This is done with the Zendesk Screen Pop block. In this example, the variable from the Recordset name field in the Zendesk Search block is used to pop the ID of the user (i.e., customer) to the agent. Note that if you want this information to pop, check the box Pop screen upon answer.
Action 4: The scenario finds an agent available to take the chat and pop the Zendesk search information to.
Next, the scenario searches for an available agent to receive the chat and the Zendesk search information using the Find Agent block. Note that this block is useful for skill-based routing. In this example, no settings are configured, so the interaction will be routed to the first available agent.
Action 5: The agent is connected to the chat with the customer.
After finding an available agent, the scenario uses the Connect Chat block to connect the agent to the customer. It is at this time that the information from the Zendesk Search block is popped to the agent. Note that in this example no additional settings are configured.
As a general reminder, the Find Agent block and Connect Chat block (or Connect Call block, if in a voice scenario) are meant to work together. That is, these blocks should be arranged in a scenario with no other blocks between them.
The following image is what the agent sees in Zendesk when the chat is connected and the screen pops with the customer's information.
Action 6: The scenario ends.
Finally, when either the agent or the customer ends the chat, the scenario will end; this is defined by using the Exit block. Bright Pattern generally recommends to always terminate a scenario or scenario branch that should not continue with an Exit and not rely on the customer to do so. That is, it is good practice to end scenarios and conditional exists because you always want to know what your scenario will do in any given situation. An Exit block will forcibly terminate the scenario wherever it is used.
The Complete Chat Scenario
The diagram shown illustrates what a complete scenario looks like when designed in the Scenario Builder application.
For more information about scenarios, refer to the Scenario Builder Reference Guide.
</translate>