Modifying Agent Dashboard

Introduction

The Agent Dashboard provides a unified customer view alongside communication controls to the agent. This page will describe how to integrate your records and processes into the ICC Application, as well as provide some guidelines for extending certain capabilities. If you would like more information on the capabilities of the Agent Dashboard, refer to the user guide.

Agent Dashboard Design Overview

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.

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 configure variables to refresh either when the value of another variable changes, or upon a timed refresh. In ICC this is seen through the use of the variable local!taskCompleteRefresh. For more information on how local variables are used in Appian, refer to the Local Variables page.

Top Level Interface

The ICC_RP_mainAgentDashboard object is the top-level interface and starting point for the Agent Dashboard. This interface serves a couple primary functions:

  1. Declares all local variables that need to be passed to lower level interfaces.
  2. Establishes which variables refresh 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

This interface is useful as a starting point when needing to navigate to a specific portion of the Agent Dashboard. The following sections will describe important interfaces to consider when modifying the Agent Dashboard.

Agent Landing Page

When the agent first pulls up the agent dashboard, they will see their landing page, which is defined by the ICC_CP_agentOffConferenceStats object. This interface has two primary sections.

Statistics

The ICC Application pulls back certain metrics and relevant queue statistics that are specific to the agent by default. These metrics can be modified if so desired, but are are designed to work out of the box.

Main Content

In the ICC_CP_agentOffConferenceStats interface, the section titled Recommended Training For You is a placeholder for you to provide your own custom landing page for your end users. This section is meant to be modified to replace this content with the relevant information you want your agents to see.

Using Your Own Customer Record

The ICC App comes with an out of the box customer record and associated data entities, which are used for identification, verification, and displaying customer information on the Agent Dashboard. This record is meant to be replaced with your own customer record, which is explained in the following subsections.

Screen Pop and Customer Identification

When an agent receives an interaction, the Agent Dashboard will update to identify that customer. If the interaction is via phone or SMS, the dashboard will try to match that phone number with the customer information. If there is exactly one match, the dashboard will proceed to customer verification, which is described in the next section. However, if there is no match, or more than one match, then the dashboard will display a search form to the agent to identify the customer. To use your own record for customer identification, follow the steps below.

  1. Open up the ICC_QE_getContact rule.
  2. Modify the a!queryEntity in local!queryDatasubset to query whatever entity represents your customer record.
  3. Modify the a!queryLogicalExpression in local!phoneExpression to match whatever phone number field(s) you would like to query.
    • The phone number is expected to be stored in the database in an E.164 format.
  4. If your primary key field is not named "id", then replace the id field in the a!queryFilter expressions with your primary key.
  5. Modify the search grid in the ICC_CP_searchForAndSelectContact interface with a search grid specific to your record, making sure to retain the saveInto values.
  6. Replace the ICC_QE_searchAllContactsOnDash rule with a search specific to your customer record, returning the matching customer records.
    • The search rule input represents the value that is searched.
  7. Modify the ICC_CP_contactInformationSections and ICC_CP_enterAddressForNewContact interfaces with your custom record fields you would want the agent to fill in when creating a new customer.
  8. Modify the button widgets in the ICC_CP_createOrUpdateContactButtons interface with any verification logic needed, making sure to preserve all of the saveInto logic.
  9. Open up the ICC Create Contact process model and replace the Write Primary Address and Write Contact write to data store nodes with writes to your customer table(s).

Customer Verification

After the customer has been identified, they must also be verified. The following subsections describe modifications that need to be made to customize the customer verification interface, as well as what is needed to pass in verification information through IVR or virtual agent.

Agent Interface for Verification

  1. Open the ICC_CP_verificationCheckForExistingContact interface.
  2. Modify, add, or delete any card layouts that correspond to a verification field in the interface.
    • Notice that the verification fields are defined from the ri!contact rule input, which represents the customer.
  3. Modify the disabled fields on the button widgets at the bottom of the interface to adjust the conditions in which the agent is able to continue after successful verification.

Verification Through IVR or Virtual Agent

Customer verification is also something that can be passed to the Agent Dashboard through the IVR or virtual agent systems. When the Agent Dashboard parses through the call or SMS data that is provided from the telephony provider, it looks for the following attribute key value pair.

1
identity_verification = passed

As long as this value is set, and the phone number of the customer matches a field in the database, then the Agent Dashboard will recognize that the caller has been successfully verified.

Displaying Your Customer Record

Once a customer has been verified, then the agent will see the customer's full profile. This includes at least one view from the customer record. By default, the ICC Application will show the summary view of the out of the box customer record. However, if you would like to use a different customer record, you can follow the steps below.

  1. Navigate to the ICC_CP_customerRecordViewField interface.
  2. Modify the parameters in fn!recordViewField.
    • Point cons!ICC_RT_CUSTOMER to your customer record.
    • Modify the view parameter to the view you would like to display.

Adding in Additional Records

If you would like to add additional records or record views to the Agent Dashboard, you can do so by using the fn!recordViewField component. Note the following important parameters for this component:

  • recordType - The URL stub of the record type.
  • identifier - Identifier of the displayed record view.
  • view - The URL of the view to display for the record.
  • onSubmit - One or more variables that are updated when a related action is submitted. The value to be saved is a dictionary representing the record instance that is loaded.

Adding to the Interaction Log

In the ICC App, certain actions the agent takes are automatically logged to the database, as well as displayed in the Interaction Log portion of the Agent Dashboard. These log entries can be viewed at any time from the interaction record, creating an audit trail of what happened during the interaction.

To add another entry to the interaction log, you will need to write into the ICC_INTERACTION_LOG_ENTRY table. Furthermore, if you would like the log entry to display to the agent, you will need to append the entire entry to the interactionLogs local variable. See below for an example of this, which can be re-used with some small modifications as listed below and highlighted in the example. Note that you will need to pass in the interaction and interactionLogs local variables in the interface that is writing this.

  • details is the activity log entry message.
  • type is an optional parameter that will define the type of entry.
    • This is a foreign key to the ICC_REFERENCE table.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
a!writeToDataStoreEntity(
  dataStoreEntity: cons!ICC_ENT_INTERACTION_LOG_ENTRY,
  valueToStore: 'type!{urn:com:appian:types:ICC}ICC_InteractionLogEntry'(
    status: null,
    source: cons!ICC_VAL_ILE_SOURCE_APPIAN,
    externalChannelSid: ri!interaction.externalChannelSid,
    externalTaskSid: ri!interaction.externalTaskSid,
    createdBy: loggedInUser(),
    createdOn: now(),
    internalOnly: false,
    deleted: false,
    relativeOrder: (length(ri!interactionLogs)+1),
    interactionId: index(ri!interaction,"id",null),
    caseId: index(ri!interaction,"caseId",null),
    contactId: index(ri!interaction,"contactId",null),
    user: loggedInUser(),
!   details: cons!ICC_VAL_VERIFICATION_LOG_MESSAGE,
    sentimentScore: null,
!   type: cons!ICC_VAL_ILE_TYPE_IDENTITY_VERIFIED
  ),
  onSuccess: {
    a!save(ri!interactionLogs,append(ri!interactionLogs,fv!storedValues))
  }
)

Modifying Interaction Reasons

When an agent wraps up a call, they can choose the Interaction Reason. By default, they can choose from Update Customer Info, General Questions, Status Inquiry, or Other.

Interaction reason

These values are stored in the ICC_CALL_REASON table. Below are descriptions for each column in the table.

  • ID: The primary key.
  • NAME: Name of the interaction reason.
  • DELETED: Determines if the value will display or not. Valid values: 1, 0. If set to 0 the value will display; if set to 1 the value will not display.

You can modify the existing values by simply changing the NAME column.

You can also add an interaction reason by adding a row to the reference data table with a new ID, a new NAME, and a DELETE value of 0.

Modifying Customer Profile

When a customer has been verified, the customer profile card will display on the left hand side of the Agent Dashboard.

agent_customer_profile_small.png

To change the contents of this card, you can modify the ICC_CP_currentCustomerProfile interface.

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. By changing these values in other interfaces and passing them as rule inputs here, the designer can customize the recommended responses that an Agent sees at any point in the interaction. Additional variables can be passed in as rule inputs, and conditional logic can be added to each of the choose choices here to display different recommended responses.

In addition to displaying recommended responses based on the state of local variables, responses can also be controlled through agent assist capabilities using Dialogflow, as described in the section below.

Modifying Agent Assist Responses

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 ICC App, Agent Assist can do things like recommend a specific response to the agent when a certain intent is recognized from the customer. 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.

    dialogflow_intent.png

  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.
  6. Open the Intelligent Contact Center App in Appian to configure Agent Assist.
  7. 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.
  8. Open the ICC Artificial Intelligence Module App.
  9. 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