Mapping services (part 2):
As a short recap: a business' service environment consists of dedicated customer journeys which are experienced in a linear fashion by their customers. Part 1 of this article introduces the basic concept of experience paths and customer journey mapping. This second part is about touchpoints.
It is very important to understand the variety in touchpoints and what role each touchpoint plays for a customer experience; how different journeys can come across the same touchpoints, and how different touchpoints are encountered along different experience paths.
What are touchpoints?
For businesses, it is important that customer experiences are orchestrated around particular places where the customer interaction happens. The term “places” is not to be taken literally here - other common terms used are “customer interfaces”, or “touchpoints”. A touchpoint can be a company’s website, a cutout voucher for a campaign offer in a newspaper, or a cost-free phone number customers can call. It can as well be an in-shop counter where an order is taken, or a table menu that is handed to you in a restaurant by the head waiter.
Fig. 1 shows such a variety of touchpoints across the customer experience sequence for delivery orders and takeout orders in a pizza restaurant. As we can see: a touchpoint map helps to illuminate the crystallisation and interaction points for different customer service experiences. In our initial drawing, we have common elements (all pizzas need to be baked and packaged, regardless of them being taken away or being delivered), and we have other elements specific to particular experiences: the display menu is mounted to the wall in the shop room, but there usually are as well printed leaflet menus available on the counter in the shop room.
So: a touchpoint map does not only depict to which experience a particular touchpoint belongs, but it allows as well to show that there is a functional equivalence between “a leaflet menu” and a “display menu”.
The front door may not be the most obvious thing you would expect in a touchpoint map, but if you ever found yourself standing in front of a closed pizza place in a suburban setting, looking at the front door for the opening hours to understand whether you came outside business hours or whether the place was closed for good, you will admit its importance.
In that context, we as well may argue that shop illumination, signage and outdoor seating should be added to the touchpoint map as well to signify that the pizza restaurant is, in fact, open. Touchpoints are specific in their function for the experience, but not necessarily exclusive. The information architect Andrea Resmini notes: “Individual points of interaction within a channel configure touchpoints. Touchpoints allow actors to receive, produce, co-produce, or modify information.” (here)
It’s fair to say there are many other information sources that customers could employ for finding out about whether a pizza restaurant is open right now: the pizzeria’s website may list business hours, Google Maps or Facebook may have that information as well, your downstairs neighbour may have told you she’s been to the place a few weeks ago, or you may try to find the pizzeria’s phone number online or in the yellow pages.
Which reminds us: Fig. 1 doesn’t even show the phone line as yet another touchpoint.
If you’ve read the first article in this series, you probably recall that we indeed started our mapping exercise from observing customers who have visited the physical shop room. We didn’t even consider ordering by phone as part of an experience path until now.
Let’s fix that.
Adding/revising touchpoints
First, we need to identify where in the experience path the touchpoint is located. For our example, the phone line appears at roughly the same spot as the counter (as this is the place where the in-shop orders are taken). But another thing is important when reconstructing the journey for orders placed by phone: the leaflet menu that in-shop customers can pick up in the shop needs to already be present at a customer’s home when she makes the phone call for the order. For orders by phone, the leaflet menu usually is the primary source of the collated information about phone number, opening times, and delivery times. With this in mind, the position of this particular touchpoint (only within this specific experience path) has to change in our map, as shown below:
Fig. 3 shows the complete experience path for the delivery order placed by phone, or made in-store (the takeout order path has been kept for reference). Not only has the position for the leaflet menu changed in the experience path - the leaflet menu as well serves a different purpose for this experience than the display menu would in the store: besides containing the list of dishes, it informs the customer about the phone number and the available pizza ordering/delivery options in one place. So it is fair to say that the leaflet menu marks the entrance point for the delivery order experience via the phone. Similar as in the shop, the menu is studied as a prerequisite for making the order.
With the calling-in experience path drawn out this way, two optimisation questions for the business owner can be framed:
First, who in the store shall answer the phone? The counter staff, who might be busy with taking in-shop orders? Or the pizza bakers, as they are the ones working based on the orders? From the optimisation perspective, both options are equally valid. However: this decision cannot be made without looking at parallel uses of the phone line: Are there other experience paths for which the telephone may be a valid touchpoint , such as “reserving a table”, if the restaurant offers a dining-in experience? Does the pizza restaurant offer pasta dishes as well so that the pizza bakers answering the phone would have to act as secretaries for their lasagna-baking colleagues in the kitchen? We can’t decide on a touchpoint without knowing which other experience paths are coming across this same touchpoint.
Second: by the time the phone line is manned, a sufficient amount of leaflet menus already needs to have been delivered to the post boxes of the residents in the delivery area. In Finland, this may pose an interesting challenge: It has become quite common to refuse the reception of marketing material, brochures and leaflets in the post box by placing a “no advertisement” sticker on its lid. To these households, the pizza menu leaflets cannot be delivered. If 3.000 households are located in the delivery area, but more than 1.500 have one of those “no advertisement“ stickers on their post box, the amount of available customers is significantly reduced, and the whole business case calculation for the restaurant’s delivery business may be in jeopardy. No touchpoint exists in isolation, and for a touchpoint to work well, preceding and neighbouring actions need to be considered.
A touchpoint map: A backbone for adding/optimising touchpoints
As we can see: adding and optimising touchpoints is far from being trivial. Admittedly, our example was simple (and deliberately so). But what started as a relatively simple depiction of a random sample of observed customer service experiences is the baseline of gaining a systematic understanding on how to shape and how to improve a customer service experience from start to end.
Complexity in these depictions adds up as more details are added, and there literally are no limits to it - the more complex and varied the different customer experience paths are, the more detailed the touchpoint map can get.
Improving the experience at any given touchpoint involves different perspectives around the question: what goes wrong at a touchpoint, and why? Having a good understanding of the experience paths and the touchpoints involved takes the guesswork out of the orchestration of customer experiences. Preventive actions happen before, corrective actions happen after something went wrong. A preventive action can happen at another touchpoint, and can offer a valid improvement in how customer’s affairs are handled.
Having a precise record of where in the experience things are amiss allows us to apply corrections and improvements where they matter most. In other words: not only the touchpoints themselves need to be considered, but as well the experience contexts in which they play a role.
Imagine a customer going through the entire experience of wanting to order a bunch of pizzas for the family on his way home from work. Assume the customer knows the favourite pizza for everyone in the family by heart, he may still be taken aback by discovering that none of his credit cards are accepted in this pizza restaurant when trying to pay for his order. Certainly a disappointing experience. For good reasons, some shops and restaurants are trying to mend that by clearly displaying logos of accepted payment methods at the counter / cashier, or already on their front door.
Businesses are - necessarily so - interested in smooth product/service delivery. So: quite many touchpoint mapping initiatives strive for identifying bottlenecks and shortcomings in the customer service experience. And quite some of them are envisioning a truly seamless customer journey, describing handover protocols, roles and responsibilities, reasons for contacting, and so on. Let’s not forget: most of these initiatives start strictly from a fulfilment perspective, and thus have to simplify and aggregate customer wishes as well as to limit the degree of customising the product and service offering to be economically viable. As a result, the underlying customer experience scenarios become very prescriptive by nature.
My contention is: Especially with the advent of multi-channel- or omni-channel experience spaces, this focus on the fulfilment paradigm just may prove too narrow in scope.
The next instalment of the article series will shed more light on the topic of how we should be building digital experience spaces in multi-channel environments.
