It all depends on what you are using the tools for. The blueprint should describe in detail all processes that happen within the organization. A customer journey map shows the jobs a customer needs to do while trying to reach a certain end goal.
If the journey map dives "under water" and describes the supporting processes within the organization you can connect the two.
What do you think?
It clarifies both. Thanks. I'm trying to implement this method in our office in Montreal, Canada (adviso.ca, a web strategy firm).
If I could rephrase it correctly, CJM could be seen as Use Case based on experience cycle (i found it on Dubberly blog from DDO and I found it more relevant than Sales Cycle).
Blue Printing is a mapping of all business processes impacted by the journey. Both tools have to be used together. What do you think of alignment diagrams where you have both tools on the same image?
We use personas a lot and then we scoped their flow with use case. I'm trying to find a way to merge personas, CJM and Blue printing. Is it realistic or pure utopia? Moreover, we are a web strategy firm we can only on web related processes.
Check out some of our past work on UX Swimlanes at my former company
(And the reason to check is that they combine storyboard / user / business / technical process flow with personas, requirements, and use case cross-references. Do not see alignment diagrams managing that...though they are great for other things.)
It's not an utopia to merge. I think they have to be merged at some point.
And I would suggest to just keep on changing your tools. (Re)designing the tool is an important part of the process while trying to find the right questions to ask and understanding the issue :-)
Sometimes we talk about "blueprinting the journey map"...a blueprint defines implementation detail about what an organization needs to do to support the customer journey (front stage / backstage / support - or business + technical process / procedures), and as you observed the two are structured along the same sequence of actions.
I often think of a blueprint as an extension of a journey map, with additional layers that show how we as an organization support that journey.
Exactly. It is clearer now. Thanks for your help
I think, the difference lies in the perspective. If the service blueprint describes a service inside-out (How does it work?), the CJ map describes it outside in (How is the service perceived?).
Todd and Chris from Adaptive Path make a good point in their presentation at MX conference. Have a look:
I just saw Chris Risdon speak at the MidwestUX conference (http://2012.midwestuxconference.com/) this past weekend. I would agree with the approach is the best summary of the difference between Service Blueprints and Customer Journeys.Thanks for posting this!
I agree with Arne. It entirely depends upon the use the tools are being put too. If you only want to get an outside-in view of the customer experience then a customer journey map might be sufficient. If you want to look at how the organisation works to deliver the touchpoints from the inside-out, then service blueprints might be enough.
But I also agree with Jess too. The sweet spot is often combining the two (and other tools) to get a more coherent, joined-up view of how the customer experience as a whole works. It is of little use knowing what the customer journey looks like in detail, if you can't pull all the organisational levers required to make it profitably better. And it is of little use knowing how to improve service delivery, (to use a goods-dominant logic term), if that results in customer disatisfaction.
Note: Check out Any Polaine's Blueprint+ if you want a great hybrid approach incorporating the best of both tools.
Having said that, neither Arne nor Jess go far enough. Customer journey mapping and service blueprinting need to be connected to more robust models of how organisations, their partners and their customers co-create value together during the customer journey. That probably requires that Service Designers have at least a passing familarity with Business Operating Models that show how the organisation as a whole creates value and Service Oriented Architectures that show how internal services create the platforms that enable customers to co-create value for themselves.
This is an inevitable part of the professionalisation of the service design discipline. It is part of the expansion of service design from the ephemera of designing the customer experience, to the nuts and bolts of designing how organisation can enable the customer to co-create their own experience. It is part of the move from Design to Service Science, Managament, Engineering and Design.
Thanks Graham. I like Polain approch which is creating a new canvas intergrating CJM and blueprint, but we can't see internal process between business unit. I've red that Alignment models could be used to merge efficiently those 2.
I assume that when you talk about Alignment Models you mean something like those described in Kalbach & Kahn's article on Locating Value with Alignment Diagrams. Whilst the article is interesting, the Alignment Diagrams it descibes are still a bit too superficial to be of much use to real organisations. It's one thing to map out the customer journey, or even the underlying business processes, but it is another entirely to define all the complementary capabilities that play in a role in the Business Operating Model within which the customer's journey is enabled.
Part of the problem is that most service designers don't really understand business; in the same way that most businessmen don't really understand design. This is only natural, reflecting as it does a different underlying philosophy about how to organise 'business', and in some cases, even the business of business.
If we are to bridge the gap between designers' representations of the outside-in customer journey and the experience they perceive from undertaking it, and businessmen's representation of how the business operates, we are going to have to look to newer systemic models that can show the different parts of the business, how they operate together and how that delivers the value business is looking for. Alignment Diagrams are not going to make the cut.
For my own work in service, experience and capability innovation I have experimented with tools drawn from Toyota's implementation of Hosjin Kanri, from Ulwick/Christensen's Customer Jobs, from Allee/den Ouden's Value Networks, from IBM's Component Business Model and SOMA, and more recently, from Yu's I* Framework. All bring different perspectives that together form the backbone of a robust alignment model. One that services the needs of designers looking from the outside-in and businessmen looking from the inside-out.
It is an interesting journey.