Within Omnichannel, we have the ability to route conversations based on different factors. At this point in time, there’s Skill-Based routing (covered at https://thecrm.ninja/omnichannel-for-dynamics-365-skills-part-ii/), and Workstream routing (covered at https://thecrm.ninja/omnichannel-pre-survey-responses-routing/).
Routing is used to send customer interactions to specific queues, in order to have them handled by the agents best suited. This could be based on the language that the customer is using, the query that the customer has (involving pre-chat survey questions), etc.
The way that this is done (included in the previous articles) is by selecting the details that we want to use. This could be the contact (when recognised as a record in the system), pre-chat survey responses, or several other options.
However, to date we’ve only been able to use fields/variables from the chat session itself. It’s not been possible to connect to other data that we’re holding within the system, and use that for routing. We’ve only been able to use items that are directly linked to the conversation:
- Account
- Case
- Contact
- Context Variable
- Live Chat Context
So if we had identified the customer as existing in the system already, we weren’t able to query related records to them, eg accounts etc. That’s all changed now though – we are now able to do this!
Let’s see an example of this. We have a customer, and we know from within Dynamics 365 that his company is a VERY large customer of ours. They spend a great deal on our products every year, and as a result, we want to route any interactions with them to a special VIP queue. Previously we were unable to do this, unless we somehow set a flag on the contact record to display this.
What we’re now able to do is go and get values from the linked account record, and use these as the routing variables within the workstream:
We can add multiple rows here, all connecting different parts of the data.
Note: The only caveat is that the entity needs to be linked to one of the Omnichannel items (which are listed above). We can’t daisy-chain non-related entities, eg Contact-Account-Invoices
These can obviously be put together in groups, to satisfy more complicated conditions, using AND/OR conditions. With this, we can therefore address very specific scenarios, tying together conditions across multiple entities.
Even nicer, we’re not restricted by the relationship type. We therefore can select an entity that’s related to the primary Omnichannel entities as:
- One to Many
- Many to One
- Many to Many
With this being in place, we’re now really able to ‘fine tune’ how we can route customer interactions, and set up specific places for them to be directed to. Through this, we can identify & serve identified sectors of our customers in different ways, as we feel is best appropriate.
This is also applicable to skill attachment routing, where the same level of functionality is provided.
So with this in mind, how would YOU think that you would go ahead and use this? Leave a note in the comments below!
