Build a journey map - Salesforce Tutorial

- [Instructor] So now that we've gone through that real-world example of journey-mapping, and that really rough journey map of My Urgent Care process, let's bring this into a more technical aspect. Let's go back to this example that we've been using that we'll use throughout the course of having a simple service cloud implementation. So, what we are going to journey map here is the process of the customer going through customer service. And what we're going to be doing, is we're going to be making the different blocks of hey, this is the task, this is what's in between the task, and this is how things are going. So let's start off with a couple different things. And I'm using ClickUp. There are a bunch of different softwares that you can use to document this. I'm using, it's called Whiteboard. I don't want to confuse this with whiteboarding as an elicitation technique, which is more like brainstorming. This is just what the feature's called. You can use different softwares. I know Lucid, or Lucidchart, they have some softwares. There are many of them. This is just the one that I have access to, and I'm comfortable using. So, we are going to bring in a block here, and we can type in here. So, I'm going to say, "Customer has issue" here, okay? And then let's see, what is it, the next one. We're going to bring in another one. Customer creates, contacts company, let's say contacts company. Now, you can do this on paper if you would like, as well, if you want to follow along. You could also get a lot of different practice with creating these if you just journey map out your process at different stores, at different companies, maybe in the drive-through line to get your Starbucks in the morning. That's something that you could do as well. But I'm just doing this one as a practice walkthrough with you, so you can get a little bit more familiar with it. So, we have "customer has issue," "customer contacts company." Then let's see, drag this, "Support agent gets assigned." And, let's see, here, "Support agent communicates with customer." And hopefully this isn't too confusing, but I'm going to drag this one down, so we don't have to go back and forth. So after the customer, they, I'm going to say ping pong back and forth. "Ping pong with customer." Okay. And then after the ping pong with customer, "Support agent works to solve problem." Okay, and then, "Support agent delivers solution" to the customer. And then finally, we're going to have this be "Support agent closes out ticket." Now there could be multiple different processes here for journey mapping like we talked before. One that's coming to mind that we could also journey map is if the customer does not respond, or what is the process for, hey, this hasn't been answered, maybe we escalate some tickets. What happens if it's been open for a week, and no support agent has been contacted? But this one is just going to be the typical journey that we are going to work through. So now that we have kind of the basic blocks out here, I want to start to connect it with some information. So customer has issue. Okay, let's see if I can get this. There we go. Okay, we're just going to connect all these guys here. And then we'll add in some text in between as well. So this might take a little time. Feel free to skip between these, if you feel so inclined. Okay, two more. Okay, so that's kind of a rough journey map. So now that we have these different blocks out here of what we're doing, we can enter in text of what happens in between all of these stages. And that's where personally, I've seen a lot of different things happen to where we can improve business processes. So if we go over here to this text area, we could enter in that customer gets frustrated here, or customer works to find their own solution. Let's just say "customer to website." So they go to the website. It's a little tricky with, okay, and formatting is not the best. But what I could do here is spell correctly and do that. So now that we have customer website, let's go to this next one. So customer contacts company. So that could be through whatever means. So email support email. And we could have sub-processes here, but they're going to email the support email in this scenario when a support agent gets assigned. So now let's go to the next one to where we're going from the support agent gets assigned, the support agent communicates with customer. So for the customer, it would be customer waits. And however long the processes from a support agent getting assigned to the support agent communicating with the customer. So if we're taking a bad scenario, we could say customer waits five days. And that is pretty big bummer right there. There are things that I'm thinking about now, if I'm journey mapping this, that the customer could get really frustrated. We, from a technical standpoint, we could have different things that we could fix, like an auto response saying, "Hey, thank you so much, here's your ticket number. This is how many days, or the average time to email back is." If that's something that your client wants to be transparent on. Or you could say, "Hey, the average, however many days, is how long to get back to you, or the amount of time that gets back to you." So the customer waits five days, support agent communicates with customer, and then ping ponging with the customer. Let's say could, this is when the support agent discovers issues. Okay, let's move this over. And it could be that the client isn't quite sure what is wrong, and so they just say, "Hey, this is an issue I'm having." So the support agent may not have all the information. So the next one is going to be going from ping ponging to works to solve the issue. So support agent works with other departments, okay? And that could be there. Again, if I'm thinking from a business analyst standpoint, let's look into that process a little bit further to see if there's something that the client wants to improve upon when they're working with other departments to solve a solution. So maybe we could say, "Hey, let's move this ticket with information over to the IT department, if it's something that they're having an issue there, or with the product department, or with the delivery department." So then they can work on delivering a solution and then those individual departments can give their feedback. But we're not solutioning that quite yet. We are just solutioning the journey map. Next we're going from support agent works to solve the problem, support agent delivers, hopefully with SLA. Okay, and then I'll move that over. And an SLA is a service level agreement. So this is essentially what a goal is going to be for your support agents to close a ticket. So let's say we have, if it's a level three priority, and the difficulty is at a level two to solve, then with those parameters, we, as company, would like to deliver a solution within two business days. That's what the SLA essentially would say. Like, "Hey, we want this to be closed out within a certain number of business days." And then let's say the support agent closes out a ticket, waits to hear from, waits to hear from customer before closing out the ticket. And again, you may have certain processes that go along from here that we could add in as some more details in between this journey map of like, Hey, after three days of we've delivered the solution, then we're going to close out this ticket and say, we haven't heard back, we assume things are fine, please email back if the solution is not delivered. So this is going to be a really rough version of a journey map when you're working with a customer. And again, it's a great elicitation technique. You heard me say like, "Hey, this is where we could draw out some requirements of saying, 'Hey, we would really like to have an auto response to help our customers understand the SLAs, to help them understand, hey, this is your ticket number. You can email us back if you're really having issues. You could call us if you're having issues.'" And this gives you some information as the customer, working with other departments, how do we ping pong back and forth with other departments? Again, really great way to do elicitation techniques.