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.
The ICC Application defines certain variables in the top level interface and other variables at localized lower level interfaces. ICC utilizes the function a!localVariables() to decrease lines of SAIL and increase developer productivity. Using this function, designers can add variables to interfaces based on which other interfaces they need to reference. Top level interface variables affect multiple lower level interfaces such as the agent dashboard and telephony component. Lower level interface variables affect only smaller components such as a single grid.
Using a!refreshVariable() designers can now configure variables to refresh when the value of another variable changes. In ICC this is seen through the use of the variable local!taskCompleteRefresh
There are a multitude of SAIL comments included, helping designers understand the intent of each item.
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. Many local variables defined here utilize a!refreshVariable() which will refresh the value of each variable when other, specified local variables change. 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 rule inputs. 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 ri!intent and ri!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 ri!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.
Different interfaces are conditionally displayed depending on the state of the interaction. The three main states are; Awaiting interaction, verifying a customer, and engaged in interaction. The below images highlight which interfaces are displayed during these states.
Based on the above image, the interfaces ICC_CP_offCallMargin and ICC_CP_agentOffConference are displayed when an agent is awaiting an interaction.
Based on the above image, the interfaces ICC_CP_onCallLayouts, ICC_activeInteractionPrompter, ICC_CP_confirmIdentityOfKnownIncomingNumber, and ICC_CP_verificationCheckForExistingContact are displayed when an agent must verify the customer.
Based on the above image, the interfaces ICC_CP_onCallLayouts, ICC_activeInteractionPrompter, and ICC_CP_fullCustomerView are displayed after verification, when the agent can view customer information.
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.