Resolved
4 votes

Do you think people with a background in processes are the best at customer journey mapping?

Tuesday, July 19 2016, 09:07 AM
Share this post:
Responses (16)
  • Accepted Answer

    Tuesday, July 19 2016, 09:13 AM - #Permalink
    Resolved
    7 votes

    I always let the customer do it.

    • Patrick Lujan
      more than a month ago
      But is anybody holding their hand(s), helping them, facilitating, eliciting? If not, I think you get the "cowpath" from John Morris below. @alecsharp's "handoff diagrams" come to mind with an occasional, well-timed "why" interjected.
    • Emiel Kelly
      more than a month ago
      Patrick,

      As always it was with a little sarcasm. But, wouldn't it be weird that a company maps a customer journey without the customer speak up?

      I am assuming now that we talk about the as-is customer journey ("dear customer how do you experience the way we deal with you?)

      Having said that, asking the customer how he would like to be dealt with, brings us easily to a to-be customer journey.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 09:22 AM - #Permalink
    Resolved
    6 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 09:46 AM - #Permalink
    Resolved
    4 votes

    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.

    • Emiel Kelly
      more than a month ago
      To me the customer and the executor are all stakeholders in the same process, so some process background (not the same as "good in processs mapping") would be helpful, I think
    • Emiel Kelly
      more than a month ago
      And even sometimes the customer does the execution himself for a large part.

      Customer Journey: All the effort a customer has to take, so we can execute our processes.
    • karl walter keirstead
      more than a month ago
      Helpful, to have some process background, yes. Not important though if you can send out a facilitator, at least to start things off. You can facilitate at a distance using Webex or GoToMeeting but for any mission critical project, it is best to appear on site for 1-2 days.

      And, yes, as well, for "the customer does the execution himself" - however, we tread easily in healthcare (no inreach option), because some patients would upload 50 inquiries per day and seriously reduce the doctor's productivity.

      Re outreach, given the near impossibility of hard-coding outreach, we accommodate outreach to a customer at a portal from ANY BPM step or ad hoc step.

      One home healthcare services delivery agency has staff who work exclusively in the field - the software posts their daily schedule (2-5 visits per day) - they type in progress notes and upload.

      Time is of the essence because one staff member can come in as another leaves - the incoming staff member needs the progress note from minutes ago for continuity of service purposes.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 09:54 AM - #Permalink
    Resolved
    4 votes

    It may not make a difference in mapping their journey, but it can be helpful if you want to improve that process. They may see things that you can't because you are too close to it.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 09:54 AM - #Permalink
    Resolved
    5 votes
    I think it's important to have background in processes for two reasons:
    1) Because the Costumer Journey Mapping translates into a process, it is necessary to have knowledge to convert and sort customer contact points with the company in a sequence of activities and decisions, such as a process, which should be modeled on the basis of rules to identify patterns behavior. Otherwise, I do not think that's possible to identify the potential pursued, i.e., to know the patterns of customers behavior in order to provide them with the best offer and increase revenues;
    2) Consideration should be someone with knowledge of the internal processes which respond to customer interactions, in order to facilitate the optimization of alignment between customer preferences and responses that the company can offer.
    • karl walter keirstead
      more than a month ago
      It seems pointless to try to anticipate all manner of customer contact (reach in and reach out) and set up touch points plan side.

      Given there will be no end to a need for on-demand reach out or reach in ,why not just make the run time environment capable of accommodating reach out/reach in at any point along the corporate Case timeline?

      Nothing wrong with data mining to identify high-frequency in/out transactions and update process maps to include these
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 11:00 AM - #Permalink
    Resolved
    6 votes

    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...

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 11:38 AM - #Permalink
    Resolved
    7 votes

    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. 

    • John Morris
      more than a month ago
      In the context of the question, it's worthwhile to compare business process management automation to accounting.

      There are accounting roles ranging from fully accredited accountants (both external and internal) all the way to bookkeepers. But all business people understand accounting and finance fundamentals, in varying degrees.

      How does this model of accounting roles compare to what is needed to realize the promise of business automation technology?

      My prediction: In the future a similar set of roles will also characterize the technology of business automation. And the technology to which we are referring goes beyond business process to also include business rules, business information (i.e. data) and business analytics technologies, all collectively known as the technologies of business semantics.

      There will be both strategic and tactical technology specialists (consultants and business analysts), there will be domain specialists (business analysts), and all business people will know these technologies -- AND HOW THEY APPLY SPECIFICALLY TO THEIR BUSINESS -- in varying degrees.

      Commodity semantic technology functions will be either open source or bought off-the-shelf (COTS); but unique semantics or differentiation will be achieved by hands-on specification and evolution of semantic artifacts performed directly by business people and business analysts. Just as business people and divisional accountants manage accounting today. (And of course the question of governance and fraud is never far away...)

      Oh -- and accounting and business semantic technologies will "eventually" collide too . . .
    • Emiel Kelly
      more than a month ago
      John,

      Looks like you look completely different at what a customer journey is. To me it is "emiel wants an insurance an what does he have to suffer untill he is insured? "

      It looks like you see it as something like letting the end users design their own app in a bpm system
    • John Morris
      more than a month ago
      Hi Emiel. We could try and define more precise terminology I guess. I'm using "end-user" as a proxy for "vendor business staff", especially non-IT staff. And the "suffering subject actor" of any given customer journey instance is "a customer".

      I'm for business "designing and evolving business processes" certainly. Should customers have options, thus de facto enriching their customer journey? By all means, if practical and if it makes business sense.
    • Emiel Kelly
      more than a month ago
      John,

      That's indeed another vision on customer journey. To me it's journeys like

      - emiel goes shopping at walmart

      - emiel buys a new motorcycle

      - emiel buys a book at amazon

      - emiel buys Chinese rubbish at Alibaba


      (Emiel is the customer in these cases)
    • John Morris
      more than a month ago
      Emiel,

      All good journeys, for sure! And on these journeys you are the "animated red dot" moving along the in-flight BPMN-based process model diagram (designed together by a business analyst and merchandising manager).

      I only wish I had your budget! : )

      John
    • Emiel Kelly
      more than a month ago
      ;-)
    • Emiel Kelly
      more than a month ago
      Or "Emiel wants to build a house"


      (read on)
    • E Scott Menter
      more than a month ago
      +1 for "nice road, no cows".
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, July 19 2016, 12:28 PM - #Permalink
    Resolved
    4 votes

    Does a one-legged duck swim in circles....

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 01:53 PM - #Permalink
    Resolved
    5 votes

    Give me a good facilitator who can elicit any day.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 02:28 PM - #Permalink
    Resolved
    5 votes

    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.

    • John Morris
      more than a month ago
      The act of performing a "customer journey map" quickly becomes reified (OK, why did I have to use that word?) as THE customer journey map. Or how about "cast in stone"?

      One needs a little theory beyond common sense in order to break through from the cowpath. Why isn't software better than it is? For many reasons, but of relevance here because sometimes common sense isn't so sensible. Examples abound. : )
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 04:00 PM - #Permalink
    Resolved
    4 votes

    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.

    Thanks,
    AS

    • John Morris
      more than a month ago
      "Anticipation" is such a nice word. And gets to the positive hopes associated with sales too!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 19 2016, 07:53 PM - #Permalink
    Resolved
    4 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 20 2016, 11:08 AM - #Permalink
    Resolved
    3 votes

    No an easy skill to quickly learn more important being a good listener and communicator?

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 21 2016, 11:43 AM - #Permalink
    Resolved
    2 votes

    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.

    • John Morris
      more than a month ago
      "The codification after the thought process is of course, easily done."

      So is pouring concrete . . .

      . . . which characterizes the inevitable if one is not working with a modern BPM platform. (And if the platform isn't "modern", then codification itself to the back-end is itself a real challenge.)

      If I misunderstood your comment Amit, I'm happy to correct myself! : )
    • Amit Kothari
      more than a month ago
      Totally agree, John. In this metaphor, we're talking about concrete that's neither level not flexible for changes after plumbing and codification is in place. Nor does concrete have any soft spots that "give" easily without stubbornly refusing to budge :)

      Fortunately, for modern cloud platforms, integration-as-a-service is now a commodity. For old-school legacy and on-premise - well, good luck!
    • John Morris
      more than a month ago
      Integration-as-a-service all too easily ends up in h*ll. API h*ll and data management h*ll. IFTTT or Zapier or more robust alternatives, it doesn't matter. They aren't ("yet"?) scaleable in multiple important dimensions (transaction volume, security, semantic richness, manageability). This lack of scaleability might not matter if you are tracking large volumes of sensors communicating only every 15 minutes, and where you don't care about losing a certain percentage of messages. But I'm not convinced that ideas + code + APIs lead to anywhere else than a sea of concrete. : )

      The challenge for humans is ultimately semantic richness, and to manage the semantic richness of reality one needs technologies where domain semantics are first class citizens of that technology. That means the irreducibly complementary technologies of business process, business rules, business analytics and business data. And UX, etc.
    • Amit Kothari
      more than a month ago
      John - I would have to disagree with you there. We cannot live without Zapier in our business. It automates away a ton of things and is incredibly flexible, since you can change any integration at any time in just 4 clicks. Old-school integration is currently being re-defined by apps like Zapier, and we're going long on that future. Zapier has many millions of users (many of them paid) and they're growing because it actually works. In our company, the least techie people use it and love it.

      I don't know what "semantic richness" means in terms of getting work done and easing hooks between apps. Could you elaborate?

      Amit
    • John Morris
      more than a month ago
      Hi Amit,

      Integration-as-a-Service is certainly a welcome topic and as you point out a lot can be done already (in just a few years too since becoming more widespread).

      As for business semantics, you can find lots of lengthy definitions around, including in even already Wikipedia (although my use of the phrase is more general than this definition):

      https://en.wikipedia.org/wiki/Business_semantics_management

      How about "a common formal language of the work of business, specifically where the irreducible concepts of work, particularly business process, business rules, business data, business narrative and business models are first class citizens of that language"?

      Note "formal", which implies "usable in software". One could argue that all software is already doing these things. Business semantics just makes our goal explicit.

      Note "common" which refers to the chaos of meaning between conflicting meta data between and even in business systems.

      A synonym could be perhaps "formal business language". COBOL was probably intended to be this (i.e. COBOL being an acronym for "common business oriented language".) But the computer science wasn't mature enough during COBOL's heyday to enable direct business semantics.

      Why bother?

      Because being able to work directly with business semantics is enormously beneficial to business people.

      The payoff is that as software gets smarter, business people can work directly from idea to new business tool. It's what we do already in accounting for a long time.

      There's so much today about "agility". Agility only is possible if you can build out your ideas in "agile-time".
    • Amit Kothari
      more than a month ago
      John - agreed, but the devil is in actually "doing" this.

      That's what we've done - we've built something that actually "does this" in a way that anyone can understand and use, since I would guess that 99.9% of people don't know what "business semantics" means.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 21 2016, 12:05 PM - #Permalink
    Resolved
    2 votes

    @Amit

    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" ?

     

    • Amit Kothari
      more than a month ago
      Hey Karl, good points.

      I must admit I am not a service design practitioner - I dream about amazing products and user experience when I sleep at night! I did post this question however which had interesting responses in the one of the largest Service Design communities on LinkedIn:

      https://www.linkedin.com/groups/1856454/1856454-6158304918227734531

      They would perhaps engage better with the comparison.

      Hope it helps!
      Amit
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 26 2016, 06:43 AM - #Permalink
    Resolved
    2 votes

    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.

    • David Chassels
      more than a month ago
      Indeed but a very easy skill to pick up apprentice accountants were doing it in the 70s ....nothing new!
    • John Morris
      more than a month ago
      +1 reference by Mr. Chassels to accounting practices in the 70s.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
29/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
223 Replies
29/09/2016
Bogdan Nafornita
210 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016