Within Microsoft’s Omnichannel for Customer Service we can enable post-call surveys. I recently published a post explaining this feature. In this second related post I will explain how I have enhanced my post voice call surveys.

You can read my original post here. (You might need to read that post before digesting this one!)

In my original post I explained how we can use a Copilot Studio BOT (aka PVA BOT) to gather customer views at the end of a telephone conversation. That is great but when we want to review the survey results the out of the box approach would be to use the “Analytics” option in Copilot Studio. Usefully, there is an option to allow us to download data about the sessions into Excel. But it limits us to data created in the last 28 days.

And what if I wanted a dashboard in Dynamics 365 showing the recent survey results by agent etc. In this post I will explain the approach I’ve taken to get the survey BOT to store results in the Dataverse. (And therefore, give me the ability to create a multitude of “reports”.)

The principle here is straight forward! From within my survey BOT I’ll need to trigger a Power Automate that will add a row into the Dataverse. Simples!

Except I did hit a small challenge …. Each of my survey records would be linked to the conversation. And to make reporting easier I wanted to also add details of the agent who took the call. I always knew this might not always be 100% accurate! As one call could be passed from agent to agent. But as the majority of the time each customer would speak to one agent, I was happy to accept a small compromise on that.

But things were more complex than that!! To explain … on the conversation records we have a field called “Primary agent” (As shown below). I had thought I’d just grab the value of this field and add it into my survey record. But this field seems to hold the name of the last agent in the conversation. When we are using a post call survey the last agent is always the Copilot Studio BOT.

So, I decided my Flow would need to find the agent who accepted the call. This will be the first human agent in the conversation, which for my purposes would be close enough to the actual “primary” agent.

I will detail my change below, the steps involved are …

Step One – Create a Dataverse Table

My first task was to create a Dataverse table to hold my survey responses. As my survey simply involved two questions it wasn’t a complex table. I just needed text columns that would hold the responses given to the BOT.

My table also had two lookups. One to the conversation and another to the primary agent. (As mentioned above this would be the agent who first accepted the call.) Meaning my conversation lookup will be to the “conversation” table, known as “msdyn_ocliveworkitem”. And my primary agent would be a lookup to the systemuser table.

Note: I am going to assume you know how to create a table in Power Apps!

I’ve shown the columns from my table below.

Once I’d created my table, I tweaked my views and created a simple chart. You could obviously extend this concept … you’d maybe add more columns and create a “wonderfully well presented” PowerBI report etc.

Step Two – Create a Power Automate Flow
From within my survey BOT I used the “Call an action” option and selected “Create a flow”. This gave me a flow with a trigger of “When Power Virtual Agents calls a flow”.

The first thing I did in my Flow was to add three parameters. “ConversationGUID”, “HowDidWeDo” and “Why”. All of these would be strings that I would pass in from my Copilot Studio BOT.

Next, I added a simple “Get a row by ID” action which would take the ConversationGUID parameter and read the conversation record.

I now needed to consider the challenge that the active agent field in the conversation will be the survey BOT and not the human. So I started off by initializing a variable called “AgentGUID”. I set its value to the active agent from the conversation. (I knew this would typically be wrong but I wanted to ensure it always contained something!)

I now have a “list rows” action. This is looking for rows within the “Sessions” table.

Tip:
In my instance I had two tables called “Sessions”. Make sure you select the table called “msdyn_ocsessions”. (Maybe try using the “Code View” option as here you will see the entityName.

I then filtered the rows with “_msdyn_liveworkitemid_value” being equal to the ID of the conversation I’d returned. And also, the “msdyn_agentacceptedon” field not being blank. So I am looking for the session in which an agent accepted the conversation. I limited the row count to 1. As if multiple rows existed, I would only take the first one.

I could now use an apply to each (on the one row returned), in which I set a varvale equal to the owner of the session record. Which I could to be the agent who accepted the session.

My final action was an “Add a new row action”. This was used to create a row in my custom survey table. I’d called my table “Voice Surveys”. I set the name field to match the name of the conversation record.

I then linked my conversation field to the conversation. (Note plural name being “msdyn_ocliveworkitems”. And my primary agent field was a lookup to “systemusers” with the GUID being the variable I’d defined.

My final step was to set the responses to my survey questions to be based on the variables passed into the Flow.

Step Three – Alter my Survey Copilot Studio BOT
In my survey BOT I already has a question and condition based on the user saying “Amazing”, “Great” or “Poor”.

Notice the I repeated my Power Automate trigger in each “leg” of my condition. I did this as the “Why” field would only be supplied if the customer said they’d had a poor experience. So on “Great” and “Amazing” I simply added “Not Required” for my reason why. But on “Poor” I passed the result of my “why” question.

The conversationGUID was set to the variable “bow_msdyn_Conversationid”.

And “HowDidWeDO” was linked to the question response of “Amazing”, “Great” or “Poor”.

You may decide to pass different values! As your survey will no doubt contain different questions to mine. But hopefully you can see that I am passing the GUID of the conversation plus whatever data the BOT has collected.

Conclusion

So, I now had a table in my Dataverse that will contain my survey responses.

I admit for my test I didn’t create the best looking chart / dashboard in the world. But you can see that from within my application I could list the survey results and see the primary agent for each. (I’m sure you can create something much more effective than I’ve done in this example!)

Hopefully this post has given you some ideas on how you might want to store voice survey results. And also given a few tips on challenges you may need to overcome. Enjoy!

Leave a comment

Trending

Website Powered by WordPress.com.