The Agent Dashboard is the heart and soul of ICC. This is where the Twilio field is integrated into an interface to provide all of the necessary views and actions that an Agent needs. This is also where many of the tie-ins to Google Dialogflow for AI are integrated.
To understand the details of the Agent Dashboard, it is important to know that this interface is designed using in-page navigation. Unlike chained forms in a process model, in-page navigation is driven entirely by SAIL and what the end user sees is strictly controlled through local variables. For purposes of organization, readability, reusability and concurrent development, the SAIL code for the dashboard is split up into many interface objects. Interfaces are then nested to create a logical structure of navigation.
Designing an application with in-page navigation presents some unique challenges. These following sections will help you understand important concepts of how the Agent Dashboard is built and how to customize the interface.
Local variables need to be defined purposefully with in-page navigation. "Load" variables cannot always be used in deeply nested rules because higher level interfaces cannot directly change the values of those variables. "With" variables will reset back to their initial definition on variable changes from higher level interfaces when their definition depends on variables from higher level interfaces. While this is helpful, having too many with variables reloading constantly will impact performance. A common design with in-page navigation is to include most local variables in the highest level interface and pass them down as rule inputs. This way the designer can control when variables change given different actions on a page with confidence that the variable will update in all of the other interfaces that reference it. To prevent a large number of rule inputs, local variables of primitive types can be defined inside a dictionary. The design can then pass the dictionary down as a rule input of type "Any Type". However, it is not recommended to store a list of CDTs within a dictionary.
The ICC Application stores a variety of parameters in the local!stateVariables dictionary. These variables are the backbone of the Agent Dashboard structure. These perform a variety of functions, including controlling the state of the interface and storing information regarding the interaction. Please note that modifications to this local variable may cause errors to the out of the box functionality of Agent Dashboard.
There are a multitude of SAIL comments in the rule input that defines this local variable, helping designers understand the intent of each item.
The ICC Application also contains the local!customVariables dictionary. In the ICC Sample Application, this is used to store all local variables that are related to the credit card use case. In the default application, this is left empty. It is recommended that this dictionary be used to store all of the variables needed when defining your custom use case.
This section will walk through the structure of the Agent Dashboard, starting with the highest-level interface.
The 'ICC_RP_mainAgentDashboard' object is the top-level interface and starting point for the Agent Dashboard. This interface serves two primary functions:
As described in the Local Variables section, any variables that are needed in both the Twilio field and in the remainder of the Agent Dashboard need to be defined here. These variables are then passed as rule input references to other interfaces.
The main interfaces to consider when modifying the ICC App are described below.
Navigating from the 'ICC_RP_mainAgentDashboard' to 'ICC_CP_connectionPanel' to 'ICC_CP_twilioField' brings you to the interface for the field. The Twilio field consists of a multitude of parameters which are used to define the functionality of the component, connections to Twilio, and various saves under certain conditions. These saves are critical for the rest of the application, and are described in more detail below.
This save gets called once a task in Twilio reaches the Appian user in the Agent Dashboard. This is the initial "screenpop" that the agent sees, as it kicks off the rest of the application and begins the verification process.
This parameter is also used to allow for graceful behavior if the screen is ever refreshed while on a call. In order to do this, we call "ICC_QE_doesTaskExist" and if the length is greater than 0, we query the database for that task. This data includes interaction logs which tells us what page the agent was on prior to refresh. If the agent has not verified the contact's identity, we bring the agent to the verification steps. If a contact's information has been verified, we query the contact's information and bring the agent to the standard customer view.
During a chat or SMS interaction, this save gets called every time a new message is sent or received by the agent. In addition to saving the new messages into the interaction log, there are two other functions that happen:
This save gets called when the agent ends an interaction and enters the wrap-up phase. In the ICC App, this fires off a process model which closes the interaction and for chat/sms, writes each message to the database as an interaction log.
This save gets called when an agents finishes their wrap-up phase. In the ICC App, local variables are reset and the updated list of recent interactions is pulled from the database.
The 'ICC_CP_leftColumn' interface is for all of the UI components on the left side of the agent dashboard below the Twilio component. Depending on whether an agent is on a live interaction or not, different child interfaces are rendered.
The 'ICC_CP_offCallMargin' interface displays the list of recent interactions the agent has had. This can be customized to display any other navigational element an agent might need when not on a live interaction.
The 'ICC_CP_onCallLayouts' interface renders the following elements when an agent is on a live interaction:
The 'ICC_CP_agentDash' interface contains everything to the right of the Twilio component and left sidebar. This is the main content of the Agent Dashboard and is the most dynamic. Similar to "ICC_CP_leftColumn", it has two child interfaces depending on whether an agent is on an interaction or not.
The 'agentOffConference' is the agent "landing page" that they will see upon initial rendering of the Agent Dashboard. For the ICC App, this contains several sections:
The default view renders various statistics an Agent may want to see throughout the course of the day as well as links.
Displays the interaction record interface when a recent interaction is selected from the 'ICC_CP_leftColumn'.
The 'ICC_CP_activeConferenceInterface' is the main interface that is loaded when an agent is on a live interaction. Of the many elements of this interface, the most important parts are described below.
The 'ICC_CP_activeInteractionRecommendedResponse' interface controls the recommended response that the agent sees at the top of the screen. What is rendered here is determined by the state of local variables. The 'ICC_UT_decideRecommendedResponse' rule input returns the appropriate response given the stateVariables dictionary. For example, the ICC App uses the following variables as guides for the rule input to display different responses:
By changing these values in other interfaces, the designer can customize the recommended responses that an Agent sees at any point in the interaction.
The 'ICC_CP_AI_recommendedActions' interface controls the recommended action capability to provide the agent a navigation action when appropriate. Similar to the recommended response, a button will render only under certain conditions as defined in stateVariables.intent and stateVariables.contactIsVerified. Depending on the intent that is recognized, a button will become visible to navigate the agent to a specific screen. The button navigation is really just a list of saves for certain local variables that control the state of the interface. An example is provided below for a specific Agent Assist action:
If stateVariables.intent = updateContact, then a button will be rendered to Update Contact Info. If the button is clicked, the following local variables are updated, which will navigate the agent to the customer record view to update their contact information.
Additionally, certain queries are run to update other local variables to display the customer's information.
For details on how to modify Agent Assist with Dialogflow, please refer to the section below.
The 'ICC_CP_confirmIdentityOfKnownIncomingNumber' interface is the customer verification screen if the phone number of the customer (voice/SMS) is recognized from the customer record.
Please note the phone number must be stored in the 'ICC_CONTACT' table in the following format to be properly matched by default in the app: +(country code)(phone number). For example, for US phone numbers, the syntax would be: +11234567890.
The 'ICC_CP_searchForAndSelectContact' interface is rendered if the phone number that of the customer (voice/SMS) is not recognized from the customer record. This brings the agent to the customer search interface.
The 'ICC_CP_fullCustomerView' is the full customer view after a customer has been verified. This interface serves as the main navigational interface for viewing a customer's record, cases, interactions, etc. This page can be customized to display any relevant information an agent would want to see about a customer, as well as any actions an agent would want to take.
As a designer, you would want to consider making local variable updates to trigger updates to recommended responses as well as the activity log from here. Recommended response logic can be found in the 'ICC_UT_decideRecommendedResponse' rule input, while appending another entry to the interactionLogs local variable will update the activity log on the left column.
Agent assist is powered by Dialogflow and consists of an “agent” and a list of intents. Dialogflow uses intents to categorize a user's intentions. Intents have Training Phrases, which are examples of what a user might say to your agent.
The ICC app utilizes intents to suggest things to the agents as phrases are given by the customer, this is called Agent Assist. In the app Agent Assist can do things like offer a direct link to the dispute a credit card transaction if the customer says they are having an issue with a card transaction. For more information see the intents documentation.
As you develop your ICC app further you can add additional intents to allow the Agent Assist to cover more areas. To do this, first create a new intent.
Once a new intent is configured the ICC dashboard needs to know what to do with the new intent response. To configure Agent Assist, open the Intelligent Contact Center App.
