Customer success has become an interesting topic for software vendors and systems integrators, alike. I am thinking about this topic for a while now and now bring my thoughts to virtual paper after Jon Reed pinged me about it and after reading Josh Greenbaum’s very readable post about “customer successing”. By the way, Jon called software vendors to attention and to deliver proof points in a great article, too.

So, call me a copycat 😉.

The customer success movement

In the past years enterprise software vendors and consultancies alike, have increasingly established customer success teams as part of their organizations. One can almost call it a movement. And it is a laudable endeavor to work on ensuring the customers’ success.

However, when looking closer at the reasons for their establishment and their charters, it becomes quite obvious that many of these customer success teams are set up as a reaction to failing implementation projects or, even worse, as a vehicle for selling further services to customer companies.

Consequently, metrics that are used for measuring the success of the customer success teams are based around project metrics. Have implementation projects been on time, in budget, and delivered quality results, means they have been successful.

Don’t get me wrong: there is nothing wrong with attempting to improve project success and to generate additional sales. There are still woefully many projects that do not get implemented within the allotted budget and time, and in sufficient quality. Additionally, one can argue that only happy customers do follow-up purchases; and customers are happy because the earlier projects succeeded.

I get it. Seriously. I am a consultant, too.

Many vendors, often even systems integrators, are also positioning people in a role named customer success partner or similarly in their customers organizations. Oftentimes without charge. The role of these persons is typically to ensure the successful usage of the vendor’s products by, amongst other things, ongoingly providing the customer with information.

Information about the vendor’s products.

But there is a catch. Actually, three of them. At least.

The first one is quite generic. A customer success team that is part of a business that does not define its own success as a result of making its customers successful, can only work with an inside-out view. It simply cannot look deep enough into the customer’s needs and desires because there is always the lens of the own solution set to limit the view.

The second catch is quite specific. It lies within the term of project success itself. The common interpretation of a successful project is that it was completed in time, on budget, and in quality. This is a flawed interpretation. Project scope, more often than not, gets changed in the course of the project and more often than not, items were descoped in order to stay in budget. Sometimes, a project that is an abject failure using these metrics, is a huge success for the business. Project success is therefore independent from customer success. Success, measured by project metrics, is not equivalent to success for the customer; the projects being counted as a success using these metrics or not.

Additionally, project success can certainly not be gauged directly after go-live. Instead, the success of a project implementation can only get evaluated over time by using its outcome. Only by using the result of the implementation, can value be created. At go-live, there is merely potential value. The use of the implemented solution needs to lead to at least the intended benefits to call it a success.

To determine the created value, it needs information that neither the software vendor, nor the implementation partner have. This means, that they are also not the right entities to measure customer success.

A customer success partner sounds like a good idea. And it can be. But then, these persons, even if provided by a vendor without charge, are employees of the vendor; they are typically charged with ensuring the successful usage of the vendor’s software and to make sure that the customer uses more of it. And no, they typically do not work on a commission basis.

While this is laudable, customers might be more successful when using another vendor’s software. Now, a part of the role of customer success partners is exactly to avoid purchasing from another vendor. Their positioning follows an inside-out thinking, as opposed to an outside-in thinking. I do not argue that these roles are useless, on the contrary, just that they cannot systematically have the best interest of the customer at heart.

Why? Because it creates a potential conflict of interest.

And it only goes on from there.

Customer success is not only determined by successful execution of projects, but also by many topics that surround them. Many of these cannot be influenced by a software vendor or an SI. Where technology comes into play, customer success is impacted long before a project starts and long after it ended.

And customer success is not only defined by financial results but also by still less tangible ones like customer experience, although customer experience can be brought into financial metrics, too. This was the topic of a CXChangersTalk between Peter Pirner and me.

I argue that customer success already starts when the customer identifies a need and starts to reach out for solutions. Successfully finding solution candidates with low effort, successfully establishing the right KPIs to measure progress, successfully setting up a business case to explore the value of solving the issue at hand, successfully defining the right user stories to address, successfully performing a selection of vendor and implementation partner, successfully ending contract negotiations with both, vendor and SI, successfully selecting the right team members to work on a project … the list goes on and on, not even talking about transparent pricing models that are tied to customer success. Spoiler: Per user licenses and pay per use are not; they are just the translation of on premise models into the SaaS world.

These are some of the customer success related topics that vendors and SIs barely address – or not at all. Admittedly, some of them can’t be addressed by them.

The story goes on after the completion of a project. How easy is it to get effective and efficient support? How transparent and reliable are roadmaps? In how far does the chosen vendor deliver additional value with regular software updates? What does it take for the customer to take advantage of this additional value? How does contract renewal or its amending work? And how easy is it to integrate or even migrate to another vendor?

All these, and more, questions have implications on customer success, on monetary and customer experience scales. Few of these questions can be addressed by customer success partners, some could be, but usually aren’t.

How customer success can be addressed

As you might guess by now, I am of the opinion that customer success can only partly be addressed by a software vendor itself. The possibility, or even the smell of a conflict of interest is too big. After all, a company is obliged to its shareholders to be profitable, even more so, if it is a publicly traded one.

The situation might be different if it is a privately held company and its owners vow to consider corporate success a consequence of making their customers successful. But even then, there are some boundaries like profitability and a bias for the own product line.

The solution lies in the buyer company having a clear definition of what “success” in IT means that is supported by a clear set of KPIs. This definition, and correspondingly the KPIs, need to support the whole corporate value chain, including all supporting processes. It also needs to be part of and support the corporate strategy.

These KPIs need to be monitored over time and their values need to be discernible by stage in the value chain, project/program and vendor/partner.

Doing this is not an easy exercise. It is also an exercise that cannot be completed or done with the help of a single software vendor or implementation partner. If at all, it needs the help of an independent partner who has no stakes in any IT project.

Having this set of KPIs helps in identifying the strengths and weaknesses of engagements over time and therefore gives clear indications about where an improvement might be necessary.

Why “might”, you ask?

Because an improvement in a KPI is not necessarily worth the effort.

Ideally, all KPIs are also collected and used across companies and industries. This way, one can learn from other companies of the own industry and even across industries. This way, all parties, enterprise vendors, consultancies, and buyers can benefit.

Latest this does not work without the help of an unbiased observer as a trusted partner.

An interesting question is why a system like this doesn’t have big traction, as it creates benefit for all involved parties, not in the least for the buyers, who otherwise need to trust first and measure achievement vs. promise only later.

As the minimum, all partners need to trustfully cooperate as a team with the intention of maximizing value for the customer.

How to get there? What do you think?