Quite a while ago I was introduced to the theory of Failure Demand. Failure Demand has been defined by System Thinker John Seddon as “demand caused by a failure to do something or do something right for the customer“. It is probably a Customer Services department of a company that can relate to it the most e.g. through Customers with repeat calls, because their problem has not been solved, despite the promise made. I agree with Tripp Babbitt, that failure demand can cause between 25 % en 75 % of Customer services work. In itself this is not strange (it is what you have Customer services for), yet I also think that the majority of failure demand can be prevented. How? I will address this in a second post on this theme, next week.
In this post I would like to focus on the implications of changing the definition of Failure Demand and, by doing so, broadening the scope and application of the principle.
Failure Demand Redefined
Coming from a Customer services background and with extensive personal experience in analyzing root-causes for failure demand (use of terminology in hindsight by the way) I came to think that Failure Demand, as a concept, can have a much broader impact and applicability, if we change the definition to what it really is:
Failure Demand is the consequential act, or non-act, of a Customer when his desired outcomes are not met.
Why is it important to redefine Failure Demand
For me, the importance of redefining Failure Demand lies in the following: I believe it is important that there is some kind of general accepted vocabulary that can be used across industries and disciplines. If we are ever to establish good collaboration between company silo’s it is needed that we all understand what we are talking about. As you might already know I believe collaboration (and its superlative “co-creation”) is at the center of a Customer centric strategy. Such a strategy even requires collaboration to extend outside the company with Customers and partners.
The traditional definition of Failure Demand makes a good case of tackling the consequences of a failure to act or a failure in acting by a company on its own work. I believe it is a powerful concept from that angle. Taken from the angle of putting in place a Customer centric strategy, like Social CRM, designing great Customer (Service) experiences and Innovation, the “traditional” definition falls short.
Implications of Failure Demand for Service (Experience) Design and Innovation
Service (Experience) Design and Innovation should focus around Customer’s needs and desired outcomes. In essence this is what putting Customer needs at the center of your Business Strategy is about.
I believe it is important for both Service (Experience) Designers and product/service Innovators, as much as it is important for Business Process Engineers, to understand that their insights will be enhanced when starting their approach from an outcome perspective and that they can also learn a great deal from understanding Failure Demand in their own organizations and from their own products and services. Furthermore I believe all functions mentioned in this blog-post should collaborate closely to really address the issue. It stretches far beyond Customer Services and the back offices. Analysis of Failure Demand, even in the “traditional” definition, is probably a very good first step for such a collaborative venture to improve or innovate the Customer experience. At the same time, understanding where your products and/or services fail to do the job that Customers want to get done, will help you best understanding where you need to focus your improvement or innovation efforts.
Extending to the above and my proposed definition, Failure Demand can even be regarded as a failure in Customer demand from an economic perspective: lack of (repeat) sales and revenue. All as a consequence of not meeting desired outcomes. From this perspective failure demand enters the world of marketeers and strategic business development too. A perspective well worth a try if your short of demand in current economic times. And who isn’t?
Failure Demand, as a concept, provides great insight in the inability of the Customer experience (design) to provide for a Customer’s desired outcome(s). Failure Demand cannot only explain the level of extra work to be done as a consequence of failures by the own organization, it can be a powerful concept that contributes to the field of Service (Experience) Design and Innovation. Failure Demand can well be the starting point for Outcome Driven Collaboration.
I will blog on my approach towards failure demand analysis next week, to further outline that perspective. In the meantime let me know what you think. How could you apply Failure Demand in your work?
Pingback: Managing for a Sustainable Pace
Pingback: Why the military must(n’t) invade our schools « Keeping Ahead of the Oil Curve
Pingback: Reading EXCLUSIVE: Social CRM Vendors Don’t Walk The Talk by Jeremiah Owyang, partner, Altimeter Group « Fredzimny's Blog
You announced to blog on your approach towards failure demand analysis. Did I miss this piece? I haven’t found it on this blog, or haven’t you published it yet? I’d be interested in it.
It’s your blog. I find irony that only yesterday you were prodding the conversation for attention.
However, I won’t publicly post that . . .
I see no solid basis for Mr. Hill’s hyperbole and will defend when prompted. He has no fact and this isn’t the first time he has done this.
You are more than welcome to defend the ideas of Mr. Seddon and your own. You are also more than welcome to explain why the ideas of Graham, or the ideas from the ones he cites, are not as great as yours. But,
I sincerely have a problem with your approach to the discussion. Attacks on a persons credibility are really not acceptable in general and certainly not on my platform.
This platform is about being an open space for people to discuss ideas, experiences and thoughts. They me even be rants about these ideas, experiences and thoughts. I cannot accept rants on a person though.
Feel free to stop by anytime if you have good arguments why your ideas are better than anyone else’s on this platform. I urge you to stay away from the discussion whenever you feel the need to take or make things personal.
I’m sorry to have to say this here.
Thanks for your comment and pulling from one of our websites. It is more than Taiichi Ohno. It is also Deming, Ackoff, Argyris, etc. The difference is the learning that is taking place with this method that separates it from the rest. John Seddon has advanced the learning by application and studying systems.
I have seen little evidence of this “vast experience” you speak of and from Graham’s writing I would have to say there are gaps in his experience, but he continues to fill in these gaps with conjecture. It is as Deming says “experience by itself teaches nothing.”
I’m of the opinion that it is very much o.k. to challenge ones ideas, thoughts and write-ups.
I would appreciate it if you could refrain from commenting on the persons credibility and focus on the credibility of the ideas. That’s what this platform is all about.
Thx for cooperating.
I think that you will find Graham is a doer who has vast experience of what you mention your methid is founded on : “The Vanguard Method© includes a translation of Taiichi Ohno’s ideas behind the Toyota Production System for service organizations. Service is different to manufacturing. In simple terms there is inherently greater variety in customer demand, hence the need to design to absorb that variety. We recommend that service organizations avoid the ‘tools’ developed for ‘lean manufacturing’ as they don’t apply well in service organizations”
Always a pleasure to hear from Graham, he never disappoints with his generalizations. He does continue to ruin the name of my favorite race car driver though.
Comments by Mr. Hill are often devoid of fact, so I will just say that we must have successfully eradicated failure demand in the 1980s and that we have all been able to move on to bigger and better things. . . not.
You will find better folks around contact center expertise, true. The issue is that the contact center is part of a broader system, something many fail to understand that attempt to optimize these centers. We need to understand that the functional separation of work into specialties creates sub-optimization.
Follow whomever you like but I would encourage anyone to understand before spouting. Knowledge of the method John Seddon promotes requires doing not reading.
Seddon’s ‘Failure Demand’ is by no means new or original thinking. It has been with us in the tools I and many others learned decades ago when I was involved in service quality work in the 1980s. And there are far more erudite – and far more positive – thinkers about the basic idea of removing things that create failure during contacts with customers.
From a call-centre perspective, easily the best thinkers are Bill Price of Driva Solutions whose book ‘The Best Service is No Service” is a must read and Peter Massey of Budd who collaborates extensively with Bill Price. I suggest you look to Bill and Peter for thought leadership rather than Seddon.
I’m a big fan of Bill Price. His view on the value of the Contact Center for the company is much mine, mainly because he takes a true outside-in approach, whereas Seddon is highly focused on the inside.
As promised I will write up my approach towards all this, sometime this week. I think you will recognize who’s leading my thoughts ;-)
Thx for stopping by and taking the time to comment.
Thanks for the reference Wim. Let’s be careful not to start programs to stop failure demand. The important change we need to have occurr is the fundamental thinking problem behind the design and management of work.
Command and control thinking has dominated organizations for far too long at great expense.
It’s all about Customer Demand, ultimately, isn’t it? ; ) Failure Demand is(or should be) in reference and relation to Customer Demands(or Desired Outcomes). We can’t define a “Failure” unless we know what success is.
I have no issue with calling it FD or renaming it. What’s important, as you and Scott agreed, is that we extend the concept into the entire enterprise.
Like Russ, I’ll need to do some more reading on FD, but conceptually, at least the way you frame it, it seems a no-brainer.
Who does not have a wealth of historical information from customers already, within their customer service/contact center? Mining this becomes an obvious place to start, n’cest pas?
Where I have a problem with the concept is with the title – Failure Demand. If the idea is to find the right words to help break down the silos and foster collaboration within the organization for the benefit of the customer, I think the words “Failure Demand” lacks that “marketing punch”, “MBA buzzword jargon”, or whatever you want to call it that gets people to rally around the concept. Get idea, but in conjures up the wrong image immediately – my mind goes to six-sigma, process re-engineering…..
I dislike the fact that (mindless) sound-byte buzzwords/catch phrases are important, but I thinks that’s human nature.
I, too, am on the perpetual journey to make organizations feel passionate about their customers.
A no-brainer indeed, at least for the ones commenting here, and likely too for lots of other Customer Services experts. In my experience though, this no-brain-needed-thinking is not widely applied.
I did my share of projects and ran several Customer Services departments (as an outsourcing provider). When addressing the “issue” it never really took off. I only had the chance to take “it” on in two projects so far. And it was not until this crisis, that I finally got to do a huge “failure demand” analysis project for one of the major Dutch companies in financial services. Great projects and great outcomes. But implementation of the improvements is certainly not a “cookie”, even though the results of the analysis are usually widely accepted and a need for change is often felt throughout the company.
I don’t think this has a lot to do with terminology. Everyone wants to do good things for the Customer. When it comes to change, there is a whole new can of worms one needs to eat..
Nevertheless, like you mention: Failure Demand has a very negative connotation, I agree. So, what can we come up with?
Thx for reading and commenting.
Hi Wim, (and other readers!)
I am about to undertake failure demand analysis for one area of a Call Centre.
I feel that once having designed a measurement system that is reliable, repeatable etc. the real challenge will be translating data collected into action, without treating each instance of FD as if it were special cause variation and hence fire-fighting, rather than prioritising further areas/processes for improvement.
Do you have any tips/tools/techniques for getting from measurement of FD eg by “defect” type (eg failed fix), transaction type (eg. Telephone, email etc) and customer, to high level identification of the process/sub-process/process step which has created it (other than drilling down in every case).?
To put this in an open-ended way, how did you move to action planning and prioritisation from FD analysis, in your own project?
Thanks for your help
Sorry to hear that Haim.. I was hoping to be important of course ;-)
No, really… I agree with all your saying. I do have to add though that I do not regard myself as “system thinker”. Not because I think there is no value in it, but mainly because I think there is more value for me in combining different kinds of “thinking”. Like there are “design thinking”, “social business thinking”, “lean thinking” etc etc..
I like to regard myself an “independent thinker”, who is passionate about Customers.
Thx for your additional explanation.
Wim – I agree there is value in multiple disciplines and in bringing them into a single discussion, otherwise we all become part of the orthodoxy of a single school of thought, and that’s really no fun at all.
Wim – Thanks for a very important post. From my experience in enterprise software, failure demand tends to be costlier to the service organization than normal demand, both short term in the investment required and longer term, in lost business and credibility. I am wondering what your experience is?
Thanks for dropping by. I’m happy you liked the post, just not sure why you feel this to be a “very important” post? Could you be more specific?
… ok, so it is not important. I lied.
Seriously though, this post highlights two topics that I believe are key to success in a service organization:
Firstly the need for robust quality system, reducing failures and the resulting failure demand, resulting in cost savings, customer satisfaction and ability to have a positive dialog with the customer to create value.
Secondly, the need to take service and contact center discussions out of the single-minded focus on individual activities and their representative metrics, into systems thinking and the understanding of the relationship between different activities is important.
Examples are plenty for these situations, I am sure the readers have a few of their own as well.
I’ll have to do more reading on “Failure Demand”, specifically(thanks for the links above), but am familiar with Root-Cause Analysis techniques, especially as applied to Technical Support(ie IT incidents). See ITIL-based Problem Management and Continual Process Improvement for more info.
I have also seen such analysis most often applied in the context of optimizing the service delivery process. For example, driving down the number of calls. And, true, this in itself can and does result in increased customer AND employee satisfaction.
But, it’s really a shame that the insights that FD and RC analysis provide are kept there. As you describe above, the benefits of FD and RCA extend and should extend beyond contact center process optimization. Contact Centers are, IMO, your richest source of customer feedback. FD and RC analysis as a component of feedback analysis MUST be integrated back into the entire business: the Sales process, the Marketing process and, as you discuss, the Experience Design processes, including Product Development and R&D. This is the collaboration across silos that you discuss.
They say that we learn most from our failures. Well, some very high, near-99% of contacts to the contact center are about something failing. Customers are telling us what they need and want, where our products fall short, what would make them buy again/more, etc. We mustn’t limit these insights to the Contact Center.
Looking forward to next post, Wim.
Great to see you here too! Thx for reading and a great comment, that could have been straight from my own heart.
To avoid any disappointments next week: approaches for Failure Demand and Root-Cause analysis are likely to have many similarities.. Nevertheless I think it is good to share the story. Judging by the (increasing) size of many Contact Centers, there are bound to be some people who can benefit.
Thx again & looking forward to next week too.