Are you a Customer Success leader? Do everything you can to remove barriers in the way of your CSM’s so they have only one thing to focus on: Customer Success
Are you a Customer Success leader? Do everything you can to remove barriers in the way of your CSM’s so they have only one thing to focus on: Customer Success
I captured a few simple points in a video a few weeks back in a flash of contemplation (hence thought rocket). Other than capture and share it here I wanted to elaborate a little. First the video:
The first thing to say is that customer success is not an isolated event or activity and this video and its content should not be taken to mean that.
Customer success is a series of purposeful activities or events which over time lead to the customer achieving their intended outcomes.
That is my super simple definition specifically as context for this post.
The 5 points captured in the video are merely outcomes that can be captured at any given time and may characterise a single moment of success. There could be many others. These are my top five. These and the others happening repeatedly over time would constitute long term customer success. This would be the true customer success.
So now onto a wee bit of elaboration on each of the 5 points because this is a thought rocket after all and I don’t want to over think it.
Probably the most important thing about any short or long term success is that a business outcome is achieved. Of course the ideal is that it is positive and satisfies the customer but I would also say that it should be the result of purposeful intent. That means you achieved what you set out to achieve. Unintended outcomes can happen and you can even allow for those and they can be of greater consequence. But better would be those that were achieved as a result of purposeful cause and effect planning because this can lead to repeat-ability.
Being able to capture a success in a way that it inspires greater use, adoption, success and value creation is best. Not all successes can be made into a great story. Stories are what capture the imagination and drive greater momentum but the detail of that is for another post.
If the success can be reapplied in the same area (team or department say) or ideally even more broadly (another team or even department or company) then so much the better. This again drives further use, adoption and success and is fundamentally a scale lever.
The ability to quantify or qualify the success in some way greatly increases the value of the success. Nothing succeeds like tangible, measurable success. Especially if it fits in with predefined targets you intended to achieve and then you blow them out the water. I’m talking KPI’s baby 🎯 😁
If it succeeds in changing behaviour and sticks then so much the better. Most customer success efforts are oriented around driving a change in behaviour so that different outcomes are achieved. This is most often the promise of the new technology being sold, implemented and adopted. So this becomes “très importante”.
What else, what have I missed, what would be your top 5 – let me know in a comment if you dare 😜
Customer success teams were put in place in technology SaaS and subscription companies to ensure that customers are successful in their use of the technology they invested in. They have become a core part of ensuring the customer derives long-term value and ultimately stays with the vendor (in other words renews the subscription).
But has the vendor and customer become too reliant on them?
I am a customer success manager. Far be it for me to be talking myself out of a job. But actually that is the point. If I could get to it (that point) I would have done my job I think.
Especially with technology products you would think that the technology itself would play a major role in helping users use it and get value out of it. And with the advent of AI, machine learning and automation, even more so.
Enterprise technology is quite a different beast though. The complexity of organisations means that technology use and adoption is not straightforward. It’s dependent on many environmental factors. Like culture, organisational complexity and maturity, etc.
Factors that technology is not good at dealing with but humans are. These have to be factored in, so to speak, in terms of how you ensure use and value creation of a technology in an organisational context. So I don’t see human effort going away anytime soon.
Still, lets look at how technology can and should help to alleviate burdensome tasks best left to machines.
In my mind, a lot of the help technology provides is ultimately geared towards the user being able to self help or serve. And its not just about the end user but also those responsible for end user adoption – the people customer success managers typically work with. I’ll call them adoption managers for sake of clarity. They are typically the ones served by Customer Success Managers most directly but as you will see in the next section, I certainly am driven to make them as self sufficient as possible too.
By this I mean two things:
The origins of the idea and also current manual efforts are documented in this post I shared on LinkedIn: Co-owning success with Office 365 customers
Validation has come from winning the hackathon awards (at the global level we won in a field of over 24 000 competitors and 5 000 entries). We also received solid validation from customers we are working with on the current manual efforts mentioned and all new customers we introduce it to.
So it seems there is appetite for this gap in the market. You can watch a very short demo of what we pitched and won with and answer 3 short questions in a follow up survey here if you like – it would help with further validation.
The future of customer service is about giving customers more control and better access to operations, so they can build their own experiences in real time. To do this, in addition to investing and moving customer service to cloud-based operations, they focus in on how to work better with automation.
I am totally in agreement with this as I wrote in this post: The Future of Customer Success is Not Human. Even though the context of the study above covers customer service trends which is very different to customer success, it is still broadly applicable. The domain is the same.
I think these activities are going to continue to expand in use and value, especially to alleviate customer success manager efforts where they are overloaded and too much is expected of them and where bureaucracy has crept in.
In the post where I wrote that the future of customer success is not human, I quoted a study on bureaucracy. It has customer service, in which again I would suggest customer success falls, at the top of the rankings of roles and fields where bureaucracy has crept in (list of rankings pasted again here). Being a practitioner I would concur with that and the point I made then and again now is that technology can help avoid this.
Of course a large portion of the problem stems from overzealous management ptractices which is not something technology can help with. But by and learge I see it as a valuable counterbalance.
Assuming that technology can take up a lot of slack and reduce bureaucracy, what does this leave the customer success manager and those responsible for adoption to do?
Well it will be to focus on those intractable problems that I mentioned earlier technology will not be able to help us with and will become increasingly needed. Thorny problems and challenges that can be overcome to improve the customer experience. Those that require and will take imagination, creativity and innovation and will focus on the challenging art of managing people.
I have two separate posts on these topics that elaborate on that if interested.
Choose it, don’t let it choose you.
Engage in the process of engaging.
Don’t just say yes to what is thrown at you from team mates, bosses, customers, random approaches from the web and social media.
Be discriminating or become a generalist. Be focused or fail, as in Warren Buffet’s 5/25 Rule
Arrogant you might think but being a slave to whim serves nobody well.
Work is everywhere but you need to hire the right work.
To become a master of your work, you need to turn things around, you need to reverse roles in the working relationship.
You do not need work that does not serve your specialism, help you grow or that will detract from you achieving your outcomes or helping others achieve theirs.
You are happy to help those that know what they want and are interested in becoming a beneficiary of your talents according to your rules of engagement.
You are the specialist, if even to just the people who are less experienced than you. They are currently unable to get to their desired destination by themselves; otherwise, they would already be there.
If you’re going to responsibly take care of them and the job to be done, you need to be in control.
This happens through a conversation, which has several parts:
What problem needs solving, what outcome needs achieving. Get to the root of the challenge. Every time they lay out a problem or goal, ask yourself why. What’s the heart of the situation? Don’t rule out emotion, it’s not all logic and they aren’t logical until it comes time to justify a close.
You cannot just look at this in terms of your capability to provide a solution, you need to look at this in terms of productivity. Do you have the time, would you do a good job compared to other options, what influence do the strategic and growth drivers bring, etc. Add any criteria you want but prioritise. If the answer is no, respectfully decline. If yes, move on.
How good can this possibly be? In your experience, what should this look like? Paint that picture for them, the one that replaces their pain with a better situation. By asking yourself what could be at the heart of their issue, you’re able to address that here as well.
Note, I did not say to solve their problems. That is part of an execution effort you and they will have to invest time, effort and possibly money into. It is to be determined at a later stage. Articulate which points need to be fixed in order to provide the solution and bring their alternate reality to life.
Everyone feels like their problem is big and unique until they hear about others you’ve worked with who are on the journey with your solutions making progress. People need social validation through peers. Connect people on reference calls. This requires you to build customer advocates with activities and programs.
A simple question creates a fork in the road. “Would you like help with this approach I’ve suggested?” Ask it, and then wait for the answer. A non answer or a no is perfectly acceptable and allows all concerned to move forward. An unequivocal yes requires more work. That is for another post.
Features and functions are easy to obsess over. They are tangible. You can click a button and it does something. Or not, at least not what you expect. And you can obsess about why not and what it should be doing.
I’ve been included in countless enterprise technology adoption programs and find this the most focused on area. This and plans. Plans are also easy to obsess over. You can move dates, tasks, people responsible, etc. Again this is a tangible area of activity, or seemingly so.
It’s the the difference between deep work and shallow work that Cal Newport covers in his book Deep Work: Rules for Focused Success in a Distracted World.
In my view the feature and function work and also the planning work is shallow work. Which is not to say it’s unnecessary. It must be done and is critical for success. But it plays a small part. Currently the majority of the effort sits here and accounts for a small part of success in my humble opinion. It should be the other way round.
Deep work is the human behaviour work. Thinking how to change it. The strategic work that takes you out of the shallows and the weeds. The creative, imaginative work that forces you to think about where you are going.
Its easy to see why the feature, function and plan work is the work that dominates. You can easily avoid confrontation on difficult people work when there is a plethora of functions to play with or talk about. You can spend endless hours discussing why something does or doesn’t do something or even playing with it.
Questioning why you are doing something that may not be working or taking responsibility and hard decisions for needed changes. Understanding misalignment to a broader purpose. This is impossible when your head is stuck in the nuts and bolts of features and functions.
The Lean Startup isn’t just about how to create a more successful entrepreneurial business. It’s about what we can learn from those businesses to improve virtually everything we do. I imagine Lean Startup principles applied to government programs, to healthcare, and to solving the world’s great problems. It’s ultimately an answer to the question ‘How can we learn more quickly what works, and discard what doesn’t?
What Tim O’Reilly, CEO O’Reilly Media, said above pretty much sums up what I am trying to do here: apply the methodology to a great challenge I face daily in my role in customer success – successful enterprise technology adoption. To find out more about the core methodology you can head on over to www.leanstartup.com.
The methodology has been highly successful in its application with startups but far more broadly now too as Tim O’Reilly suggests. I’ve been thinking about it a while and captured how I wanted to apply it very briefly and simply in a customer success management primer I put together on SlideShare. I’ve added the relevant bit as a diagram above.
It’s not unlike what the co-founder of Percolate where I currently work has suggested in this article: Noah Brier’s Three Rules For Leveraging New Technologies. There’s no specific reference to the lean startup methodology but you should see the similarities and they are based on the lean startup methodology’s heavy reliance on software engineering approaches which Noah Brier does reference.
I’ve been applying the approach loosely with the customer success planning and execution work I have been doing with customers and now felt it time to capture that in a little more detail. That is what this post is about. It’s also in the context of my most recent work which is marketing, as in Noah Brier’s post, but I believe it can be applied widely for most enterprise technology platforms. It also chimes with earlier thinking I’ve done which seemed to resonate at the time: Why leaders of digital initiatives inside organisations need to think like start-ups.
This approach I am taking is in direct contrast to previous approaches to technology adoption. Enterprise technology platforms used to be highly configurable and customisable and were often planned and prepared for launch far in advance of launch dates. They would exist in this form for years afterwards until a new version was ready for re-launch. This was tied in, to a large degree, to a vendor’s approach who would plan new features and functions years in advance before releasing a new version. Now with SaaS (Software as a Service) that has all changed.
Customers no longer get to change the platform to the degree they used to and vendors have vastly reduced development cycles to ship new features more frequently, sometimes as often as weekly. However, most often these are tested with a handful of BETA customers and then shipped when ready on a quarterly basis.
With new features coming this frequently and with the lack of customisation and configurability, it doesn’t make sense to plan too far in advance. A far more iterative and experimental approach is called for.
This approach supports customer and end user success with the use of their enterprise technology platform. So those chiefly responsible for the platform’s success as well the users of it. It combines what has worked well with many global customers in my experience and incorporates lean startup methodology. It’s based on the view that success cannot be achieved by chance but needs a good design which is measurable, executable and iterative.
It targets key outcomes including measures of success (KPI’s), plans the necessary activities and resources required to succeed and reviews progress periodically that allows for course correction or continuation of successful activities. I simplified the steps from the Lean Startup methodology for my purposes to three.
Note that this model is narrowly focused on planning and execution activities and does not take into consideration some critical supporting activities. Things like a champion network, an online support environment, etc. I’ve written about all of these to some degree or other under the customer-success tag so follow the link to find out more.
Generally there is a phase of work prior to the success management cycle starting that includes getting the platform ready for launch. This would include things like configuration of the system, setting up workflows and permissions/ roles, access and security settings, provisioning of users, etc. These technology, governance, authentication, legal, support and security considerations have to be mapped out and delivered in accordance with the organisations policies, most often managed through IT. This would ideally be followed by a successful launch of the platform which I’ve written about here: Launch like a boss – bringing consumer startup practice to your enterprise technology platform
The success management cycle would ideally have been been planned ahead of launch as part of the implementation planning, e.g. the initial uses cases and workflows you launch with form part of a longer term success vision and planning cycle.
In some cases, a customer will have launched and have been using the platform for many months, even years, without a robust success methodology in place. In this case you would have to take stock of where successful (or not) platform usage is and work from there. It may require a platform relaunch. At best, there are some successful uses of the system in place already and you want to take these to the next level.
NOTE: When starting with your first success cycle, be aware of any preceding activities like an implementation or onboarding phase with all that it set out to achieve. This can be used as a baseline for the use cases and measures in your initial success cycle.
Over time, with successive quarters and years of use, you would expect an organisation to become more and more proficient in its use of a technology platform and that value outcomes will also increase over time – see diagram.
And if you expect that all users will be equal in their stages of maturity well you are likely to be disappointed which is why you might want to break maturity levels up between your users and segments of users – see next diagram.
Also, there is likely never to be an end to the overall maturity path as new features are added to the platform and new users come and go.
An approach to managing maturity levels between different users and /or segments of users is not critical to the success methodology. But if you are dealing with a great many users in a large organisation with many different geographical or vertical segments, you may want to consider it.
The diagram above is pretty self explanatory and hopefully its clear how you might be able to work with something like this. You really want to keep it as simple as possible because you don’t want to add complexity especially where the organisation or technology already is.
Which leads me neatly to a final point. This whole methodology, like the lean startup approach, is very simple and experimental. That is the beauty of it and the reason for its effectiveness. Good luck using it and if you have feedback about what works or doesn’t or any improvements, please do let me know in a comment.
I work in customer success in the enterprise technology space and have written several posts on the activities required for the role – find them under the customer-success tag. This one is about the use case which I see as the currency of customer success management.
A use case is a set of interactions between a user and a system to attain a particular result or function and is often represented by a process or work flow. Use cases should ultimately be geared towards delivering a business solution.
A solution is designed to integrate multiple facets of a company’s business through interchange of info and processes and should produce outcomes that achieve business goals.
Use cases / solutions can be captured to show the value a platform is providing to the business. It can also be used to share amongst users to support further use and value creation across different parts of the business. See more on this at the end of the post.
Each use case should have its own measure of success and can be broken down into 4 parts which could easily be captured in a single page or slide document template:
As far as possible have a method that is simple, quantifiable and results should be taken as representative. You could start with a simple spreadsheet for collecting and managing a use case pipeline. Apply a selection criteria that will allow for quick shortlisting. From a shortlist you could (but don’t have to) use an online survey to get feedback on priority and demonstrable value.
Criteria used for selection (score 2/3 to be progressed or selected)
Pre-existing use cases will only need to be captured and tracked so you have a record of them and so that you can share them. The management ends there until you get to the point of sharing or communicating them. Clearly these types of use case will only exist where the platform has been used for some time. When you are launching a platform for the first time, all uses cases will need to be planned and executed.
In the case of a new platform launch, ask the vendor if they have any from other customers that can be used as a baseline. When a platform has been around for a while but you are only starting the work of managing use cases at a late stage, ideally you are able to identify as many pre-existing use cases as possible.
Pre-existing use cases (I call them serendipitous use cases :) have come about spontaneously and hopefully reflect a natural use of the platform. They are unforced or not mandated and as such they are the purest form of a use case. These type of use case are like gold. When I manage business value workshops with customers in which identifying uses cases is big part (see diagram), I dedicate a separate session for these.
Analyse responses from surveys if you have used them or manually evaluate each use case and select the ones that have scored highest in terms of priority. Next identify a person who will help drive their development. Progress with the development of the top 3 or 4 use cases. Finalise the use case format/template mentioned at the beginning, ready for distribution and work closely with use case leaders and users. On this last point, the more complex the technology, use case or organisation, the more you will likely need an owner and team of people supporting it.
This should be done over a short period of time but that also depends on the complexity of the organisation, technology and/or use case. I suggest roughly a three month period. In this time users should be trained on the use case and supported in getting up and running where needed. Progress should be followed pretty closely and ongoing support provided where possible. At the end, determine where the goals for the use case have been achieved. If it does perfectly then you could adopt this in future uses as is. If not you may need to tweak and iterate further on the use case in a second, quarterly cycle. You may, at worst, need to discard it. If the former case, you can then go on to share it.
A critical aspect of achieving success (and ultimately in my business that means driving adoption of a technology platform) is capturing the essence of the value it delivered in an easy to understand, simple and ideally visual way and then sharing or communicating it. This is also fundamentally important for those responsible for the platform in the business and who have paid for it and must ultimately justify its value and ROI.
It is by capturing successes through use cases and sharing them that you perpetuate success. Users in the organisation not using the system yet see how others who are using it and are inspired to use it in similar or even better ways. It becomes a self fulfilling and virtuous circle of success.
The diagram you see here could be a simple way of capturing the outcomes of a successful use case delivered over a period of time. It is fairly self explanatory. The key thing about it is that the easier you make it to share the better. An image file is likely to be the best way to do that. You could even go so far as to share a template with use case owners or the general population of users so they can capture their own unplanned or serendipitous use cases and then go on to share them.
I mentor startups that go through Microsoft Accelerator’s London program. Because of recent experience I focus on customer success management practices and enterprise software startups, but not exclusively. I recently joined a startup (again) and here too I’m helping with building out a customer success practice.
In all cases what often comes up is the importance of an online presence to deal with various elements of customer success. So I thought I would capture what I have recently been communicating as important and that is the purpose of this post. If you are not sure about what customer success is, I’ve written a simple primer on SlideShare.
To clarify what I mean by online presence, this doesn’t just mean a website with some documentation. This could be a basic starting point but there are many more considerations. I’ve broken these out into sections in this post, explained each and tried to give examples from companies who I know do it well.
The purpose of a good online presence would be to educate, support and add value to the way the customer uses products and services. As an extension of a company’s support, service and customer success department it’s intended to scale those efforts. If done really well it will enhance the customer experience, build an army of customer advocates and ultimately drive loyalty.
This goes a step beyond basic product information that would be well served by a good document library. Incorporating rich media like a video series and even going as far as incorporating a certification program could really enhance a learning program. Pixelmator does an awesome video tutorial series.
Education doesn’t just have to be delivered on the site itself. Offer a webinar series where customers can sign up and attend predetermined sessions with other customers. These would be delivered using screensharing, chat and audio/video software. This could be added to a formal training program as a way to top up and refresh learning.
A webinar series needs a team to run regular sessions that customers can get a calendar view of from a page on your site, sign up for and drop in to. If you have a global customer base, stagger the times to cover all time zones.
This is the dark horse of a well delivered customer success presence. Not easy to deliver well, it takes serious and authentic effort. If achieved it can deliver substantial benefits:
Salesforce have done an amazing job with this incorporating their own community platform on the back of their success site.
On the risk side, you may have customers mounting an insurrection if things go wrong or they don’t quite appreciate a new product release. Having a good community management contingency plan in place is critical. The Community Roundtable has an excellent Community Manager Handbook if you want to develop this further.
This is a fairly obvious area and the cornerstone of any attempt to help customers. Mostly a case of helping them with problems they are experiencing with your product or service, it’s often a question of turning a negative situation into a positive one. But that is a golden opportunity to enhance the customers experience if done well.
In an enterprise environment with a complex product or service that’s especially tricky. Support for the enterprise may have to take many different user types into consideration like the end-user, someone who acts on their behalf, an IT help desk for instance, etc.
A means to log issues and track responses would be table stakes but even this is not done well by many, if at all. In my view this is best done on a site (main site and/or a support or success site and also “in app” ideally) and personalised to the individual so he or she can track progress and responses, rather than via email. Other things to think about (and check out Code School who does a great job with many of its activities):
Again this is a really basic area that should be relatively easy to do well. Surprisingly many companies don’t.
You should at the very least have a well laid out and searchable or filterable document area on your site. The structure should be intuitive in relation to your product and service or offering. You could go further and structure the content for user type or proficiency level.
In addition to this there are some really basic things you can do to enhance the experience. For instance, you can incorporate rich media like video but if you want to keep that to a learning section, you could simply include gifs which are simple, animated images.
Percolate where I currently work does a really good job of this in my view.
If you have decided to expose your thinking about the future direction of your product (this is something more specific to product features than service elements) you can make this a compelling part of your efforts. This is also most often a consideration with complex enterprise software products where future enhancements might impact on a customers operations. It’s of special interest to those responsible for the platforms use.
There are risks to doing this. Customers holding you to ideas that are in essence just ideas, not commitments to develop something. The risk is you add something to the roadmap and then for some reason or another it has to be removed or changed. Expectations that this created then have to be managed. If done well this can be an incredibly powerful way of engaging and ultimately committing customers to the future of your product and company by making them co-creators.
If you were to offer a feature request and/or ideas section on your site, this could even be incorporated into the approach. Submitted ideas that are incorporated into the product roadmap is an incredibly tangible way of showing customers that they are co-creators of your product.
Microsoft does this really well for Office 365 features and they took this approach from Yammer where I used to work until we were acquired by Microsoft and we then perfected the approach.