Attention Customers: You’re Responsible for Vendors’ Customer Success Efforts Too. With Proof Points

I admit I’m shamelessly drafting on Jon Reed’s excellent post on customer success proof points by posting this a little ahead of my original schedule, but the timeliness was too good to ignore. The fact that we were both working on this issue from slightly different perspectives was also too good not to acknowledge and draft on.

Jon’s post rightfully takes vendors to task for touting a concept – customer success – mostly as a marketing check-the-box effort. Like greenwashing (McKinsey is catching some flack over this from its own employees on this topic) and other forms of virtue signaling (diversity and “stakeholder capitalism” programs come to mind as well), it’s a tempting feel-good move that marketers love because it allows them to show how far they’ve come from the bad old days of customer failure. Whatever that is, it’s over now, right? So let’s add customer success to a few execs’ job titles, wash our hands of that benighted era, and move self-righteously towards the glory of customer success.

Whatever that is.

Which is the existential problem with the concept: how do you actually measure customer success, and by extension, customer failure? Believe me, it’s much harder than it looks, and certainly doesn’t happen because you now people whose job titles include these words. The old measures of “on time and on budget” never worked very well – lots of patients died on the operating table despite a “successful” implementation. And lots of declarations of success are really what I call Bad Practice Repair, a phrase I used back in the ‘90s in response to the Business Process Reengineering hype that kickstarted the modern enterprise software market. Too many BPR projects back then turned out to be mostly about overcoming egregious technical and process errors. Relatively few, by contrast, were about overcoming technical or process debt and truly re-engineering an improved process.

Calling those bad practice repair projects “successful” was like staunching a self-inflicted wound and calling it self-care. It’s as true today as it was 30 years ago: success needs to be a little more than “base line” survival to justify the zillions of dollars customers spend on tech in the hope they’ll be successful at what turns out to be more a false promise than anyone would like to admit.

“Successful” go-lives were always another false metric of customer success. Going live is only the beginning of a long journey to achieving the goals, and hence the value, that was intended when the contract was signed. In fact, counting go-lives is a truly false metric that perpetuates the notion that the vendor’s job is “done,” and the success box is checked, when the customer begins using the new system. It’s a metric made for facile financial analysis and simplistic industry benchmarking, and is emblematic of an earlier age – which we unfortunately still live in – when selling software, and appeasing a Wall Street monster that rewards sales growth above anything else, was the real raison-d-être of enterprise software sales and marketing efforts.

So when Jon took a much-needed swipe at vendor customer success programs (again), and offered up some suggestions as to how vendors could do a better job, it was time to take a swipe at another party in desperate need of some prodding on the issue of customer success: the customers themselves. Customers are often equal partners in what I call a “culture of mediocrity” that dominates our industry, a culture that has normalized failure and mediocrity as just the price of doing business. Sad but true.

Which brings us to my favorite aphorism about customer failure:

It takes all three parties to really screw up a project: the vendor, the service provider, and the customer.

And my favorite aphorism about customer success:

Customer success requires the active participation of all three parties: the vendor, the service provider, and the customer.

With these aphorisms in mind, it’s time that customers get a little tough love too. Jon has his list of to-dos for the vendors, here’s my Eleven Customer Success Proof Points – for customers. (In ascending order, sorry. I was never much of a Letterman fan.)  

1. Work with vendors that publish their customer success criteria alongside data on how well the vendor is doing against those criteria. Jon’s embedded benchmarking by industry and job role should be part of this. Embrace vendors that embrace self-criticism and reward the ones that do a good job by actually proving they’re trying to do a better job.
2. Insist on transparent pricing – really transparent pricing – from your vendors. This is an obvious riff on several of Jon’s points, as is point #3 below. A vendor that markets itself to you as a “partner” shouldn’t be playing games with pricing. Too many complex product BOMs make it really hard for customers to know what they’re actually buying. This is deliberate, and should be stopped. By you. By not enabling this anymore.
3. Insist on simplified contracting and real contracting oversight. Another “only you can prevent this” problem. Why do business with a company that relies on hidden gotchas that are intended to extract some unanticipated lucre from you? If your vendor’s business model makes their legal team the absolute ruler of the contract T&Cs, and not their customer success team, find another vendor. While we’re at it, if there’s a gag order in the contract preventing you from disclosing problems with your projects, don’t sign. The only vendor I know that requires this has to – otherwise their self-reported customer satisfaction score would be regularly revealed to be the blatant lie that it is.
4. Refuse to participate in quota-driven sales efforts and don’t succumb to end of quarter discount pressure. We all need to stop making the industry look like Tricky Dick’s Used Car Emporium, and that means customers have to stop enabling this behavior. It’s actually good for your budget: Those discounts and other end of quarter field-sales shenanigans actually don’t really save you money anyway. Paying a discount on something you don’t need in order to get something you do need rarely pays off in the end. Unless accumulating shelfware has any relevance to your company’s business.
5. Be sure the service and support package from your vendor meets your needs, not theirs. Customer success is hugely dependent on service and support, particularly if we agree that go-live isn’t the true measure of success. Vendors should provide careful analysis on what kind of support works for your company, and why. This should be a data-driven conversation, not just a set of pretty PowerPoints. It turns out that the less-than-sexy service and support side of the contract is super-critical, so don’t skimp on this part of the process.
6. Use objective, third-party analysis of projects that is publicly accessible, even if it also forces you to rate yourself. As Jon already mentioned, I do have a dog in this fight, ProQ. There’s also a Raven you can put in your corner – Raven Intelligence has great data on implementation success and failure from actual, verified customers who fill out post-implementation reviews on the Raven site. ProQ takes a slightly different perspective by measuring teamwork as a project is underway. Either way it turns out that vendors’ reticence to publish real data on their own success criteria (see #1 above) is unfortunately matched by most customers’ reticence to look in the mirror and see that they too may be part of the problem of project failure. Which means by embracing real transparency – and the potentially painful accountability that comes with it – customers can be part of what guarantees their own success. Imagine that.
7. Work with vendors that promote partner success and punish partner failure. The two “it takes three parties” aphorisms above mention the role of partners, and to be honest they’re often more responsible for project success than vendors and customers. Partners are what I call the “adult supervision” – the party that is supposedly the most qualified to actually execute on the customer’s plan to gain business value from the vendor’s product. Unfortunately, most vendors’ partner programs are geared towards the success of the vendor, not the partner and certainly not the customer. Unless the partner is a global SI. When it comes to this class of partner, most vendors won’t confront the GSIs for fear of upsetting the gravy train – regardless of the fact that the vast majority of project failures are the fault of partners, all too many of which are GSIs. Customers can and should insist that the vendors curtail the excesses of these partners, so a corollary of this point is that customers, whenever possible, should work with boutique SIs or directly with the vendor’s own services teem. (Think I’m exaggerating the problem? Trying searching the name of your favorite GSI and the terms “project failure” and see what comes up.)
8. Make sure your projects have senior sponsorship and the right people on the job. These last four are all tried-and-true, well-known truisms that have been around forever, but bear mentioning nonetheless. No one wants the SI to sell the A team and deliver the B team, and customers shouldn’t do this either. If the project isn’t important enough to put your good people on, maybe you need to rethink why you’re doing the project.
9. Do not attempt anything transformative without working from start to finish with the stakeholders impacted by that transformation. Technology is the easy part, it’s those damn humans that always get in the way of success. (Another aphorism, BTW.) Keep that in mind when your users are up in arms over the new system and/or your new software is actually making life harder for everyone other than the project sponsor. So you stuck to the project plan and delivered, without widespread and relatively enthusiastic user acceptance, everyone just wasted their time and money.
10. Don’t cut corners around training. If you really need me to explain this please stop reading now. Actually, if you’re still reading you probably get this and know that training is always the first thing to get cut from a budget gone astray, and a lack of training is a good reason why we can’t measure success at go-live: if you go live and your users aren’t well-trained, it’s pretty much a guarantee the project will fail to deliver its intended value.
11. Get help. There’s a lot of moving parts to making sure you’re as successful as possible, and as good as you are at your job, it really helps to have outside help in the form of a consultant who can make sure all the I’s are dotted and t’s crossed. Every good writer needs a copy-editor to provide that outside/in perspective, and every good IT project needs someone in a similar role.

Actually, there’s a twelfth proof point, which sort of goes without saying:

12. Only do business with a vendor that has read Jon’s post on customer success proof points.

Does this get us closer to a set of metrics to truly measure customer success? It’s a start. I think Jon’s points about burying NPS is job # 1, this data point means nothing to anyone anymore. On the other hand, the work Coupa is doing in benchmarking the value their customers are getting is just amazing. When this kind of data is coupled with objective third party data, the result should be a huge benefit for customers and a huge anchor for competitive positioning on the part of the vendors and partners that have embraced these kinds of measures.

I also like what Jon said about a bill of rights, maturity models, and risk dashboards: all of these ideas have the ability to become the basis for the kind of metrics the industry needs. Infor’s Bill of Rights has some very easy-to-quantify components, such as data security, availability, pricing transparency, support turnaround times, and others. As the cloud provides enormous amount of telemetry and metadata, creating and reporting these metrics should be pretty easy – at least from a technical side. Pushing for partners to sign on to being measured will be hard, but if customers insist that their engagements with SIs depend on transparency, then eventually the SIs will be forced to comply. It will probably start with the boutique SIs leading the charge – their overall success rates are typically much much higher by virtue of the fact that they can’t ride their brands through failure after failure like the GSIs.

Finally, while it’s relatively easy to insist that your vendors behave appropriately, the truth is that customers have an obligation to work a little harder than they have in the past to hold up their end of the opportunity described in Aphorism #8. We all would like our experiences as customers to be as good as possible, but like many things in life, just because you’re paying the bill doesn’t mean you don’t have work to do. My experiences with ProQ have shown me that customers are as scared of transparency and accountability as vendors and SIs, even though at the end of the day the cost of failure is a burden mostly carried by the customer. Those consequences are more dangerous to customers’ business continuity and successful business transformation than anyone would like to admit.

Like everything in life, you tend to get out what you put in. Customer success is ultimately the customer’s responsibility – it may be a job title in the software industry, but customer success really is a do-or-die issue for the folks who matter. Customers just need to act on that responsibility, and don’t worry if you step on a few vendor or SI toes along the way. It’s good for them, and the good ones know it. Or will soon, once Jon and I are done with them.