This issue has lots of pictures! It’s also a two-parter. We’ll introduce what it means to “walk back the customer journey” this week and continue that theme next week.
Not everyone has the title Chief Customer Officer. If you’ve read the last two newsletter on The Simple Customer Journey Map and Priority Touchpoints, you may get the sense that “gee, Ben, this is nice and all, but I can barely get other teams to take customer experience seriously, let alone get everyone in the room to talk about naming journey stages—how am I supposed to actually use this stuff??” (hopefully not where you work!).
Even if your situation isn’t that extreme, it’s still a fair point. A lot of talk about journey mapping is done with the assumption that you’re approaching it from the top-down with all departments represented. You can do customer journey mapping within a single department, but it’s not as effective as having representatives from every stage of the customer’s journey in the room.
What if you don’t have a canonical customer journey map at your company? Is the customer journey still useful? Absolutely. As you discover problems at particular touchpoints, you can use those problems to “walk back the customer journey” and discover ways that you could have prevented the problem touchpoint from occurring by delivering a better experience earlier in the process. Let’s take a look.
Photo by Hugues de BUYER-MIMEURE on Unsplash
A Problem at Renewal Time
Here’s a story¹:
“We’ve got a problem. E-comm Co. is threatening not to renew their FullStory contract if we can’t address their performance concerns.”
“What performance concerns? We’ve been live on their site for a year and everything has been fine.”
“They ran a Google Lighthouse report and they’re saying we’re slowing them down.”
“Okay, right—I’ll get an engineer on this ASAP.”
Now, any code you add to your site will have a performance cost, even if it is imperceptible to the user. But “imperceptible to the user” might not matter. If Google Lighthouse—the performance profiling tool that has the world’s largest search engine in its name—shows some murky numbers and says you’re slow, and if this causes a problem for your customer—even if you have a very reasonable explanation for the numbers!—your customer’s problem is now your problem.
Probably the worst way to experience this problem—aside from the customer not renewing—is having to do a fire drill with the engineering team to save the customer. Fire drills are expensive. Engineers and other team members have to interrupt what they’re doing to do research, write emails, and get on calls. Even if the end result is “everything is by design; the numbers in the report aren’t providing a complete picture; here’s why”, it’s still not good that you got to that point in the first place.
How can we prevent this issue from happening again by doing a better job of setting expectations? Let’s walk back the customer journey from the point where we first saw the problem.
Walking Back the Customer Journey
Once we write down the problem, the current stage, and the action we took, we want to “walk back” (to the left, if we’re writing it down) to ask how we might have prevented the problem and/or unwanted action from occurring. What can we do to prevent “fire drill for the engineering team?”
If the problem is a matter of setting expectations, perhaps we write a knowledge base article so customers can research and understand numbers in a Lighthouse report. In addition, we might do some proactive outreach to key customers who we believe may see unfavorable numbers in a Lighthouse report so we can review it with them ahead of time. But proactive outreach can be time consuming. How might we prevent that step earlier in the customer journey?
Onboarding is a critical stage in the customer journey where you have the customer’s attention and can set them up for success. By covering site performance with a dedicated training session, we’re able to set expectations and prevent unwanted surprises later on. That’s great, but how might we cover this even earlier?
At the purchase stage, we might add language to the contract that explains agreed-upon service levels (SLAs) for script performance, detailing exactly how it works and what customers can expect. Granted, you don’t update the terms of your contract for just anything, but it’s worth considering for key areas of your product where it’s critical that expectations be set clearly.
Walking back one step further to the evaluation stage, we can add a product demo dedicated to script performance. We might cover popular performance profiling tools in depth, walking through each one in detail. This way, by the time the team has signed the contract, they’re fully aware of how FullStory affects site performance. This could eliminate the need for or shorten the length of a training session at the onboarding stage.
At this point, we’ve walked almost to the beginning of the customer journey (we’ve left out the “awareness” stage in this example). If we implement all of the proposed actions at the earlier stages in the customer journey, the customer isn’t going to be surprised by script performance. As a result, this should increase the probability of renewal and reduce the risk of unnecessary fire drills.
Walking back the customer journey is going to highlight what you can do at each stage to set better expectations and hopefully prevent pain for both the customer and your team. Would it be helpful if you had named journey stages and a canonical customer journey map (as discussed here) to provide a shared one-company perspective of the customer? Sure, but it’s not strictly necessary. You’ve got everything you need to start walking back the customer journey to better set expectations.
But what if, despite your best efforts to set expectations, you’re just not able to meet the (prospective) customer’s needs? Next week we’ll look at the difference between setting and meeting expectations and how that distinction can affect your process as you walk back the customer journey.
This isn’t based on a specific interaction with a customer, but I’ve seen various aspects of this story in various interactions doing customer support at FullStory. I’ve pieced together those stories to simplify the narrative for this newsletter.