Not all times you will want to provide live chat opportunities for a customer to a real person. Self Service is huge when it comes to serving a customer on their terms, at the time and method that suits them, whilst keeping more specific 1:1 interactions for more complicated questions, issues or concerns to staff. This post covers how to get started with connecting a Power Virtual Agent together with Omni Channel Engagement to make this scenario possible!

This post aims to give you a short guide on setting Power Virtual Agent to be connected with Omni Channel Engagement. The setup starts in Power Virtual Agent with connecting Omni Channel, then moves on to just modifying the topic to include the escalation trigger. It then covers configuring the bot in Omni Channel with the Queue and routing rules to provide an experience of initial self service and escalation capabilities to a real omni channel user.

Lets just talk a moment about the customer experience your aiming for when connecting Power Virtual Agent to Omni Channel Engagement

Bot to Real Agent Customer Experience

Understanding how the user would experience this bot to human interaction is critical to be able to set it up. Lets begin.

A user would interact with the same widget you create from Omni Channel Engagement (and not the widget from Power Virtual Agents). This means your styling and any other configuration you have made, such as downloading transcripts or pre-chat questions would still be applicable.

The difference being is when the customer starts the conversation by opening the widget, they start the conversation with the Virtual Agent rather than a human being, as you can see in the screenshot below.

There will be a point in the topic and conversation flow you’ll want to transfer to a real person. This needs to be authored into the business logic, which will be covered in the second session of this post. In the screenshot below, the store hours topic was modified to include an escalation path.

When the conditions are met for transfer, a real user in Omni Channel gets routed the customer’s session just as if they started a new request without a bot. This time it is seen as an escalation from bot, so the agent knows exactly what they are accepting.

 

From a customer’s standpoint, they can see this escalation in the same way as if this was a transfer request from another user. They get to see the ‘An agent will be with you in a moment’ notification and then who has joined (by accepting) the conversation, as shown below.

The user will get the full transcript of what the bot and the customer have discussed visible in the Chat Pane. In the Power Virtual Agent trigger, a variable can also be included for more contextual information. In the screenshot below I mistyped the context phrase (should be va_LastPhrase) and so this was put literally rather than the data contained in the expecting variable.

 

Then the conversation flows between the customer and the agent in the same way any other conversation does using Omni Channel Engagement until it comes to a close.

For perspective, in the Supervisor Dashboard, when the Virtual Agent has started a conversation, without a human being in scope, this conversation can be seen in this dashboard where the ‘Active Agent’ is the Virtual Agent and can be monitored by the Supervisor.

This has covered the expected behaviour from a customers perspective. Starting from the Virtual Agent experience and escalating to a real human being using Omni Channel Engagement. This next section will cover how to set this up.

How to setup Power Virtual Agent with Omni Channel Engagement for transferring

Navigate to the settings in Power Virtual Agent (top right screen of the maker experience for PVA) and click ‘Transfer to Agent’. You’ll be prompted to select either Omni Channel or a Custom service provider. This blog post only covers Omni Channel Engagement and a pre-requisite is you’ll need the Omni Channel Engagement app installed in the same tenant as the Virtual Agent your working with.

Select Dynamics 365 Omni Channel for Customer Service.

It will ask you to setup an application registration with Azure if one doesn’t exist. Follow the link in step 1 on the prompt and it’ll open the exact place you need to make the App Registration. Once completed copy and paste the Application ID. (Reading the Terms and Conditions, especially about transferring data).

You can see in the screenshot below the experience of Registering an Application in Azure. I kept everything as the defaults and left the Redirect URI blank.

 

Once this has been copied into the Application ID click next and choose your environment. Choose the environment you have Omni Channel Engagement configured for.

Almost finished with the setup in Power Virtual Agents but before you leave, you need to configure the transfer to agent action. You can put this where you require it – a few recommendations would be to modify the system ‘Escalate’ topic and also review other topics where you need to hand over to an agent naturally. An example is below where I modified a sample topic with an added question – ‘Did you want any assistance?’ with a Yes/No answer and as a follow up you have access to ‘End Conversation > Transfer to Agent’. The customer would then select this option when they want to initiate the transfer from Bot to then a request for a real person to pick up a proposed session in Omni Channel Engagement.

 

You can add Context Phrases in the ‘Transfer to Agent’ action which are covered in the next section and are directly linked to the context variables that can be used to get the data when routing to the real user in Omni Channel.

Setting up the Bot in Omni Channel Engagement

The second step of the process is configuring the experience in Omni Channel Engagement.

Open Omni Channel Engagement after configuring the connection from Power Virtual Agents and you’ll see the Bot under the ‘Bot’ section in the Omni Channel Engagement App.

 

Open this record and associate the Queue you want the bot to monitor.

Now the next step is to navigate to your Chat Workstream where you want your Bot to be routed through. Select Context Variable. Power Virtual Agent sends a number of variables over in the transfer process which we can utilise when routing the query to a human agent. We want to use one of these – va_Scope but you don’t have to use this specific one, you can use any number of these based on your requirement.

A list of the available context variables are below along with the type of data that could be found in them. This is an example based on a real escalation between my bot and a user in Omni Channel which you can see in the screenshots within this post. In the variable va_Scope it simply has ‘bot’ in it with it being transferred from a bot, or else it would be empty where a transaction wasn’t transferred from a bot and didn’t touch the Power Virtual Agent interface.

Now finally, we want to use this va_Scope context variable to monitor all interactions first and then escalate to an agent. We need to use this context variable that will either have ‘bot’ in it, or not, to determine that. The bot should pick up any sessions which do NOT have ‘bot’ in the va_scope context variable (ALL of them for this Queue) but then when the va_scope variable DOES have ‘bot’ then it should route it to a real agent. This is configured using routing rule items in the workstream.

You will need to configure one rule for each scenario which can be seen below, using the conditions of the context variable ‘va_Scope’ added in the previous step to either equal ‘bot’ or to not have data at all.

 

The second rule item for not containing data is shown below.

 

Wait for approx 15 minutes for your configuration changes to take place and then open the website where your Omni Channel widget is hosted and trigger your condition to see this in action!