Do you think people with a background in processes are the best at customer journey mapping?
My favorite part of the job, whether focused on those abstract things we call "processes" or focused on the customer or just on the 'things we do' - is to go to the whiteboard with as many of the constituent groups as possible. Inevitably, going back to the days of DFDs, there will be places where the arguments erupt. There are people in all groups who know what should happen and others who know what does happen. There are multiple groups who have their separate dates for any given milestone that actually have different meanings to different people. This is the messy arena of customer facing work. I love it. The customer journey will be a part of that, hence Emiel's response is good for it. But, to nail down the exceptions takes a village.
It is NOT important that someone with a background in process does the customer mapping journey.
The fundamental difference between internal process mapping and customer journey mapping is that the level of detail is likely to be less in the case of the latter.
At one end of the customer journey, we have a customer who buys a product like an air conditioner, takes out annual maintenance and unless issues arise (warranty, bad service), there is little contact needed. At the other end of the scale we have e.g. job shop operations where there can be a need for customer contact on a daily basis in the early stages of custom manufacturing.
The best resource for development of internal process maps is a facilitator whereas the best resource for development of customer journey maps is a customer relations specialist.
Well... I always "map processes with the end in mind". And the end in my capturing exercises always mean: A happy customer, no exception.
Efficiency gains are a derivate and never a goal. So... the customer drives the journey, and the process guy facilitates. In other words, drives or captures the WHY...
If you want to pave the cowpath, by all means then let end-users map the customer journey. At best you'll get a new cowpath.
On the other hand, if you want your process to fail, have IT do it all by themselves. You'll get a nice road but no cows.
So we are between the proverbial "rock and a hard place" (and being unfair to both end-users and IT).
Our answer comes when we ask "What does 'map' mean?" We actually want to map but then go beyond "as-is" to "rationalization" and "innovation". And that means the special skills of the process technology-savvy business analyst who also is a domain expert. The analyst works with both IT and end-users. And provides insight and leadership in dialogue with business. And sometimes business people even do their own analysis (because it's a "role", not a job description). And everyone contributes.
The analyst knows both sides of the house but (and this is important, because it means that coders and programmers do not play a big role in business process automation) the technology now permits business and analyst to focus most of their attention on business semantics.
All you need to do a customer journey mapping is a little bit of common sense.
And that is not, statistically speaking, residing more with people with background in processes.
As John mentioned “house”, I will use the example of house architecting.
Before talking to an architect, a person or a family must be clear about why they want to build a house and how this house will fit their life, e.g. do they plan to have kids? do they expect a lot of long-stay visitors? do them plan to move to another place?, etc. Of course, some people contact an architect before answering to these questions thus wasting their money and taking a huge risk (a good architect will ask them these questions and a bad architect will offer a solution which may be not suitable for them, e.g. by asking how many floors they want).
So, the mapping of customer journey is about anticipation (by a good process architect, of course). See variant 5 from the ref1 about multiple scenarios.
Is it important that they DO the mapping? No.
Is it important they they PARTICIPATE in the (facilitated) process of mapping? Yeah. Otherwise, entropy will set in hard and fast when that information is transferred to the application team for implementation.
Isn't this exactly what the discipline around service design does - with a strong focus on user experience? In that case it's not "anyone" that can do it - as you need someone really good on user experience to re-think customer experiences in various stages (see Wikipedia link). The codification after the thought process is of course, easily done.
Wikipedia has an article about it, but in the references we wrote a little bit about that too - and partnered with a bunch of people in that area. They look at the customer experience more holistically before diving into the weeds of process mapping.
Excellent example of a situation where a facilitator is not going to help.
The key to "service design" is to log and tally all service tickets and then up to the service provider to decide whether they direct customers to an FAQ database or let them private chat.
I am not a fan of FAQ databases where my response to "Did you find what you were looking for?" is NO !, 99.999% of the time.
For me, 'service design" is more of a data mining exercise as it is extremely difficult to anticipate service calls for what designers feel are the most elementary capabilities of a product.
Who would think, for example (unless you are a driving instructor) to tell a new driver of an automatic car, that they need to use the same foot for the gas and the brake (as opposed to trying to use both feet) i.e. "Whenever I stop the car, the engine makes a funny noise" ?
Process thinking and collaboration thinking is an helpfull skill to capture the complete "journey" of the customer in the product or service offer you have.