Omni Flows Pilot Spoiler Alert [3/3]
Hello again! If you’re coming from the previous article on OmniFlow Pilot Skill Based Routing: Thank You! If not, you might consider checking that article out as well as the previous one. Or watch our video summaries for both on Queue Based Routing and Skill Based Routing to catch up and understand where we’re coming from.
What are we doing here? Well, I’m taking you for a quick spin and showing you some of the things we’re bringing forward in our Omnichannel+Flow Pilot which I am showcasing specifically for Salesforce Chat.
Important mention: What I’ll show you here belongs to the road-map and pilot capabilities realms which means that Salesforce’s Forward Looking Statements and Safe Harbor applies from now onwards and as you go about reading this, the previous and first related stories as well. This story is the last of a series of 3 article-guidelines in which I will present this compelling project.
VIDEO SUMMARY [~9min]
DIRECT TO AGENT ROUTING: BUILD ON TOP OF FLOW CREATED IN PREVIOUS ARTICLE
Now let’s add a different decision node, up at the front of the existing “Add Chat Skill” requirement action as shown below. And, we’re going to check if the customer has a preferred agent. This could be because you wanted to go to the agent that the customer spoke to last or it could be because there’s a 1 to 1 account relationship policy at your company. Whatever business criteria you like, we could choose to route directly to a specific agent.
Look a the Contact and see whether or not there’s a ‘preferred agent’. Let’s create a decision that defines if we need to route to a specific user or not. Drag and drop a “Route Work” action and call it “Route to Preferred Agent”. Define input variable as we’ve done in the previous 2 articles. Go back to that documentation if this does not sound familiar to you.
Now, Routing type is to a user. Which means that instead of doing queue or skills we are going to select Route To: agent. We could type a particular agent’s name like myself, but that wouldn’t make it very dynamic. For that, we can pass in a variable and make it dynamic indeed. Here is where we would configure this to be contact’s “preferred agent” look-up field [that we created in the very first article and video].
From there we can specify whether if this is required: it will only go to this agent or not. And after that point you can also define a back-up queue. If you haven’t marked it to be required it will fall back to the back up queue.
We have a Directo To Agent Path as well as our Skill Based Routing Path created earlier. Nice work! And that was our direct to agent example.
MORE WITH FLOWS GIVEN ITS NATURE & BEAUTY
What happens if you wanted to make changes to your business process as you’re going through the Flows we’ve been creating? Let’s say for example that you’d want to update the case setting its priority based on the context provided by the customer on the pre chat form. Well, you’d check that condition, then update the case and go from there.
The point being here, that if you want to do custom logic as you go through this, that’s where the entire power of the flow builder comes in and allows you to take things to higher grounds 😎 Finally you may ask your self if the case is linked here? And the answer in this instance is yes! The case is auto created and linked at this point. This is a simple example for it.
In the future for the New Chat on the NEW Conversational Platform: the idea is going to be that you decide what objects you want to link-to. And everything will be created inside the flow via bundled-actions similar to ‘route work’ and ‘add skill requirement’ but for functions like ‘Channel-Object-Linking’ and more!
MORE FUTURE HIGHLIGHTS, VISION & IDEAS
A few other things that we’d love to be able to do here.
Add Screen Pop Action: added to left hand-side, it will allow you to decide what information to pop to the agent leveraging customer context and information on Flows.
If customers are coming-in and asking about an order, then let’s pop the order for agents when the work gets delivered to them.
Whereas if they’re calling about an existing case, let’s open that existing case for the agent. The key thing is that we’re going to allow you to open up on the agent screen the records that you choose based upon what ever logic you want inside the flow.
Add an Availability Check action: so that you can check for example whether an agent is online or a queue is full before routing anything into it.
And finally, we’re looking of course at adding an Einstein Classification action so that you can use AI to work with what a Chat, Phone, or Email… is about and take that information to drive processes from there.
Lots of cool things potentially coming up. And I am very excited to be able to collaborate as a PM here as well!
IN A NUTSHELL
This is the last of a series of 3 articles. In it, we walked through the new OmniFlow Pilot capability and created a Direct To Agent Routing scenario leveraging both Route Work (route to agent) and Add Skill Requirement actions. We also added additional business logic to it. Finally I shared some future highlights with regards to the direction we are taking things from here. All articles shared here talk about pilots and road map. And Safe Harbor applies for all. Feel free to go to the other first two articles on Queue Based Routing as welll as Skill Based Routing for Omni+Flow. Thank you!
Important: Salesforce provides Omni+Flow to selected customers through a pilot program that requires agreement to specific terms and conditions. Omni+Flow isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. Salesforce can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available Salesforce products and features.
Have questions? Feel free to reach out. Let’s connect on Twitter. I’ll answer DMs faster than emails. @lecharleslozano
