Walk Up Experience - Interaction Management

#Interactions , #London Release , #Interactions

Andrew Barnes

4 minute read

Walk-up Experience

Walk-up Experience

We are continuing with our Walk-up Experience example from two weeks ago to feature another platform capability added in London. The Walk-up Experience plugin is the first plugin I am aware of that uses Interactions. This is why we are going to be using it as our example to help explain Interaction Management.

Interaction Management

ServiceNow has long had a Service Desk Call plugin that in some ways is the spiritual predecessor to Interaction Management. It enabled the recording of a call with a customer, even prior to knowing what type of interaction you would have with the user. You might end up making the call an Incident, or a Service Request, or solving the issue directly. For phone calls, this process works great. Where it starts to show its limitations is around all of the other contact points and methods we can have with users. Chats, Physical walk-up, Virtual Agents, and other possible interactions types are not required and limited to be one at a time engagements. Thus enters Interactions.

Interaction Management at its core looks to add flexibility and centralization of communication channels to and in the platform. It does this by installing some new tables and roles. The base table is Interaction. This table is where the customer interactions are stored and then routed. Each interaction record is fairly lightweight. It contains the user, a short description, state, queue, and channel. This allows us to decouple our interactions and processes from particular areas in the platform which gives you the developer more flexibility.

Let’s take a look at channel first. A channel, in this case, is walk-up. The other channel available in London is chat. This channel defines the states an interaction goes through. This is where the last blog post and todays post are tied together. The walk-up channel uses extension points to define their states and transitions. Allowing them to be enhanced without edited the script in the channel definition.

InteractionStateModel

The channel enabled in Interactions via defining a connector. The connector is the collection of scripts that define what the states for that channel do. This is a fully scripted process using standard ServiceNow scripting. The movement between states is controlled via UI actions or business rules. Routing is also handled via business rules and assignment rules.

(function interactionAssigned(interaction) {
	try{
		new sn_walkup.ExtPointUtil().loadExtension("NotificationFacade").sendAssignedAndThresholdNotification(interaction);
	} catch(err){
		gs.info(err);
	}
})(interaction);

Above is the script for what the walk-up connector defines what is done on the state of assigned. You can see the use of the ExtPointUtil to load an extension point which we covered previously. This then looks for all the extension implementations and finds this function and uses it which you can see below. This allows a developer the opportunity to create a different implementation with a higher order to adjust the functionality without modifying the OOB records or have impacts for upgrading.

sendAssignedAndThresholdNotification: function (interaction) {

	if (this._isNil(interaction))
		throw this.ERR.INTERACTION_INVALID;

	gs.eventQueue(this.ASSIGNED, 
				  this._getInteractionGlideRecord(interaction), 
				  this._getRecipient(interaction));

	var thresholdInteraction = this._getThresholdInteraction(interaction);
	if (thresholdInteraction)
		this._sendThresholdNotification(thresholdInteraction);
},

Queues are where these interactions can start coming together. Interactions will be routed to a queue depending on the rules that it matches as defined by your matching rule records. Each queue can have its own schedule and other defining attributes that are appropriate for the process it is supporting. Agents can pick up the next queued interaction via a UI action as seen below.

Take Next Interaction

This process will be quite changed as Agent Workspaces are adopted and utilized in the future. The agent will have their workspace open and set themselves available for a queue. This will allow them to be pushed work items, or for them to grab the next user interaction and engage with that user in a tab on the agents’ workspace. They might be helping multiple users at once with this method.

Agent Workspace Queue

Interactions can be transferred between queues and agents. An agent can then take the interactions and create other record types and associate them to the interaction. This could be an HR Case, an IT Incident, or a Service Request.

This new functionality will enable developers and administrators the ability to centralize communication channel management, thus simplifying our processes and allowing for consistency and flexibility across the platform.

Comments