Modifying Agent Dashboard

The Agent Dashboard is the heart and soul of ICC. This is where the communication 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.

ICC Variables

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.

/icc/declare state variables

Interface Structure

This section will walk through the structure of the Agent Dashboard, starting with the highest-level interface.

Top 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:

  1. Declares all local variables that need to be passed to lower level interfaces
  2. Establishes which variables display refresh behavior when telephony interactions end
  3. Defines the layout and calls rule inputs for lower-level interfaces
    • ICC_CP_connectionPanel
    • ICC_CP_leftColumn
    • ICC_CP_agentDash

As described in the Local Variables section, any variables that are needed in multiple branches of lower level interfaces 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.

Connection Panel

Navigating to ICC_CP_connectionPanel brings you to the connection panel that is used for live communications. This includes the box layout surrounding the availability and call controls, as well as the communication component itself. If you wish to add any auxiliary text or notifications surrounding the call controls, you can do so here.

If the ICC_ENV_USE_TWILIO_TOGGLE constant is set to true, then the Twilio field will render. Otherwise, the Genesys field will render. Important information for both are provided below.

Twilio Field

Navigating to ICC_CP_twilioField brings you to the interface for the Twilio component. This interface contains both the mock Twilio component, as well as the live Twilio field component.

The mock component renders Appian buttons in place of Twilio communication events. It can be rendered if the ICC_VAL_DEV_ENVIRONMENT constant is true and the user is a part of the ICC Mock Testing Users group. The mock component is meant to be used for development purposes, abstracting the Twilio connection and replacing live communication events with buttons. This is useful when wanting to build out the rest of the interface without going through live telephony or chat while developing or testing.

The Twilio field itself 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 save events are critical for the rest of the application. The behavior of the save events as provided out of the box is described below.

onTaskReserve

This save event occurs for voice calls when the autoAnswer parameter is set to false, and the click to answer dialog displays for the agent. It updates the incomingCall local variable, which is used to update the box layout.

onTaskDismiss

This save event occurs for voice calls when the agent is on the click to answer dialog, and the incoming call is either rejected or times out. It updates the incomingCall local variable, which is used to update the box layout.

onTaskLoad

This save event occurs 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.

onNewChatMessage

During a chat or SMS interaction, this save occurs 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:

  • New message is sent to the AI service (if enabled) for intent analysis
  • Sentiment analysis is run on the newly received message
onTransfer

This save event occurs when the agent clicks "Transfer", initiating a blind transfer. The agent is subsequently brought to the wrap-up interface in the component, bypassing the onCommunicationComplete event. This event triggers an activity log entry for the transfer, as well as database writes for interaction data.

onConsultStart

This save event occurs when the agent clicks "Consult", initiating a warm transfer. This event triggers an activity log entry for the consult, as well as database writes for interaction data.

onConsultReturn

This save event occurs when the agent is on the consult screen and clicks "Back to Caller", ending the consult and returning to the caller. This event triggers an activity log entry for the consult, as well as database writes for interaction data.

onConsultTransfer

This save event occurs when the agent is on the consult screen and clicks "Transfer", ending the consult and transferring the call. The agent is subsequently brought to the wrap-up interface in the component, bypassing the onCommunicationComplete event. This event triggers an activity log entry for the consult, as well as database writes for interaction data.

onConference

This save event occurs when the agent clicks "Conference", initiating a conference call. This event triggers an activity log entry for the consult, as well as database writes for interaction data.

onCommunicationComplete

This save event occurs when the agent ends an interaction and enters the wrap-up phase. This event triggers database writes for interaction data. It also updates the onCommunicationCompleteRefresh local variable, triggering other local variables updates on other interfaces.

onTaskComplete

This save event occurs when an agents finishes their wrap-up phase. This event fires off a process model that closes the interaction. It also updates the taskCompleteRefresh local variable, triggering other local variables to reset on other interfaces in preparation for the next interaction.

Genesys Field

Navigating to ICC_CP_genesysField brings you to the interface for the Genesys Voice PureEngage component.

The Genesys field itself consists of a multitude of parameters which are used to define the functionality of the component, connections to Genesys, and various saves under certain conditions. These save events are critical for the rest of the application. The behavior of the save events as provided out of the box is described below.

onCallLoad

This save event occurs once a call in Genesys 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.

onCallComplete

This save event occurs when the agent ends a call and enters the wrap-up phase. This event triggers database writes for interaction data. It also updates the onCommunicationCompleteRefresh local variable, triggering other local variables updates on other interfaces.

afterWorkComplete

This save event occurs when an agents finishes their wrap-up phase. This event fires off a process model that closes the interaction. It also updates the taskCompleteRefresh local variable, triggering other local variables to reset on other interfaces in preparation for the next interaction.

onConsultLoad

This save event occurs when the agent clicks "Consult", initiating a warm transfer. This event triggers an activity log entry for the consult, as well as database writes for interaction data.

onConsultComplete

This save event occurs when the agent is on the consult screen and clicks "Transfer" or "Return to Caller", ending the consult call. The agent is subsequently brought back to the active call screen or to the wrap-up interface in the component, bypassing the onCallComplete event. This event triggers an activity log entry for the consult, as well as database writes for interaction data.

onTransferInitiate

This save event occurs when the agent clicks Transfer, initiating a blind transfer. This event triggers an activity log entry for the transfer, as well as database writes for interaction data.

Left Column

The ICC_CP_leftColumn interface is for all of the UI components on the left side of the agent dashboard below the communications component. Depending on whether an agent is on a live interaction or not, different child interfaces are rendered.

Off Interaction

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.

On Interaction

The ICC_CP_onCallLayouts interface renders the following elements when an agent is on a live interaction:

  • Activity Log (ICC_CP_currentCallLog) - a running list of events that have happened during the interaction
    • Displays elements of local!interactionLogsVA (virtual agent activities) and local!interactionLogs (live agent activities)
  • Agent Notes (ICC_CP_currentInteractionNotes) - notes the agent took during the interaction
    • Displays elements of local!interactionNotes

Main Content

The ICC_CP_agentDash interface contains everything to the right of the communications 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.

Off Interaction

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:

Default View

The default view renders various statistics an Agent may want to see throughout the course of the day as well as links.

  • Agent Daily Stats
    • Agent's number of interactions and average handle time for this day
  • Queue Stats
    • Various statistics for the queue(s) that an agent is assigned to
  • Recommended Trainings
    • Links to example training sites

When using the Genesys PureEngage component, the agent daily stats and queue stats expect the Genesys PureEngage environment has ElasticSearch installed. ElasticSearch is an optional part of the Genesys PureEngage installation process.

Interaction View

Displays the interaction record interface when a recent interaction is selected from the ICC_CP_leftColumn.

On Interaction

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:

  • ri!contactIsIdentified
  • ri!contactIsVerified
  • ri!intent

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.

  • ri!showCustomerProfile
  • ri!editContactInfo

Additionally, certain queries are run to update other local variables to display the customer's information.

  • ri!contactAddress
  • (only in Sample Application) ri!ccContactAdditionalDetail

For details on how to modify Agent Assist with Dialogflow, please refer to the section below.

Customer Identity Confirmation

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 E.164 format to be properly matched in the app. 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.

Full Customer View

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.

Interaction State

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.

Awaiting Interaction

/icc/off_call

Based on the above image, the interfaces ICC_CP_offCallMargin and ICC_CP_agentOffConference are displayed when an agent is awaiting an interaction.

Verifying a Customer

/icc/on_verification

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.

Engaged in Interaction

/icc/on_call

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.

Modifying Agent Assist

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.

  1. Click on the + next to Intents in the left menu.
  2. Add the name name into the Intent name text field.
  3. In the Training Phrases section, click on the text field and enter the phrases a customer would give to initiate this intent, pressing enter after each entry.
    • For example:
      • What is your name?
      • Do you have a name?
      • name
  4. In the Responses section, click on the text field and enter the appropriate response
  5. Click the Save button

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.

  1. Open the decision object ICC_UT_intentRecommendationOutput
    • Add the new intent as a new row in the decision table
    • Set the output as n, where n is the number of input rows
    • Be sure to update the Else row to n+1 where n is the number of input rows
  2. Open the ICC Artificial Intelligence Module App
  3. Open the expression rule ICC_CP_AI_recommendedActions
    • In the button widget there is a choose() function
      • Add a new parameter to the choose() function that is the name of the intent (it does not have to match exactly the name of the intent in the decision table)
      • In this new parameter add any logic that needs to be done to calculate the suggested response
    • Once configured the button will now update appropriately to display the new suggested response
FEEDBACK