One of the most critical aspects of any good customer success program is designing programs, engagements, and touch points to meet customers where they are comfortable and also meet where they want to be met. Years ago when customers did not have choices, customers had to follow vendors rules and engage with vendors on the vendor’s terms. Today customers have a vast amount of options, and their business is often portable. Vendors need to make the customer experience and the effort to engage with the vendor as seamless as possible. Unfortunately, this is easier said than done for most vendors.
To build a customer program that scales you need to focus on mapping out and building success plays, engagements, and customer outcomes that are repeatable and can be deployed to address 80% of your customer’s needs. If your customer base has much variance, you may find building repeatable plays that a significant portion of your user base can use a difficult task. The issue is every customer is different, is looking for different ways to achieve success and is set up with varying degrees of technical aptitude and personalities. Let me give you an example.
Many of the customers I have worked lean heavily into the deep technical side of databases and infrastructure. Many of them are brilliant engineers who know and are comfortable with low-level database and operating system code. When we engage with these users, they have a very distinct way of consuming and acting on any help and knowledge we provide them. They are looking for a framework and some general guidance, but they will do the work for themselves. You can often hear them say point me in the right direction and get out of my way. For example, when these users are planning an upgrade, they want to know where the upgrade docs are, what are the common problems people run into, and if there is anything that could impact their upgrade based on their usage. These types of users represent about a 20% of the customer base at my previous company.
On the opposite extreme, several customers are just more comfortable having an expert run with a project end to end. They will scope it out and want regular updates, but they want to outsource a specific outcome to you. Given that same upgrade project, they want someone to do a significant portion or all of it for them. They expect scoping, testing, migrating data, and other tasks are all outsourced in part or in full to the vendor. These users want to see success stories from previous customers, want to know you have a playbook to make the upgrade go smoothly with no ( or limited ) impact to the business. This group represents another 20% or so of the customer base.
The vast majority of customers in my experience fall into a category in between the other two. They are looking for some hands-on help, but a lot more guidance to lead them through the main steps. In the upgrade example, this would mean they are looking for someone to walk them through all the main stages and best practices of an upgrade. Guiding them, best practices, and helping them avoid common pitfuls. Often this falls to a CSM or a TAM to assist and guide.
In the above example, there is a simple outcome, but three very different ways to achieve that outcome. Being able to understand and recognize these different pathways to an outcome is critical when you are creating a scalable customer program. In May I attended the Technology & Service World Conference , many of the leaders in the customer success space where not only talking about this very concept but also sharing how successful this approach has been for them. They touted not only how this helped customers become successful, but also lowered their costs, and improved their revenue. Minimally I would recommend success plays and outcomes be built to serve the 3 most natural pathways: allow users to either self-help, have a guided experience, or to get someone to do it for them.
Here are some tips and tricks that can help you figure out where customers are and how to best serve them:
1. Ask questions and listen: This is a fundamental skill for anyone who works with customers. Listening more than talking, especially at first is vital. There will be plenty of time for education later on. You want to understand the customer’s pains, their outcomes, their future projects, and where their business is going. You want to get a good sense when they onboard and then talk regularly ( quarterly or semi-annually ) to refresh your understanding and knowledge.
2. Don’t focus on the technology, focus on the business: This is difficult for really technical folks, but as a TAM or CSM if we are continually thinking about the customer’s business first and what outcomes they need, then when understanding those help to use the technology to solve those problems you will have a much better customer experience and much higher chance of helping the customer achieve their goals. An example I run into a lot is with customers asking for a high availability (HA) solution. There are dozens of ways to improve the availability of the app; it’s our job to help the customer find the right one. You need to understand the why before you can define the right how. Maybe they need to harden their HA because they had a recent outage, perhaps they need it to satisfy some compliance, or maybe they hired someone new who puts a premium on continuity. Each of these can open up subsequent discussions, for instance, if a customer has had a recent outage, you may want to talk to them about first preventing the outage before tackling a more complex HA strategy.
3. Don’t assume: This is rather general advice, but so vital. The first thing to remember is customers don’t have the same background and experience as you do. You need to understand their background before giving advice. I can’t tell you the number of times I have made this mistake earlier in my career. As a consultant, I would often assume a certain level of comfort and skill with our technologies that the users I was working with didn’t understand. Get to know and understand where the customers are, and make sure you not only meet them at their skill level but try and educate them and elevate them. Try to use common industry-specific terms, and terms and examples the users are comfortable with.
4. Not everyone is like you: This is also an assumption, but the most significant assumption I have seen technical engineers make is assuming that everyone has a similar learning and working styles to them. You want to have specific success plays and outcomes designed for the different types of way users work. Some people want to work and learn by doing it themselves, others want you to guide them step by step, and others want to have someone else do it for them entirely. Know your customers, their skill sets, and their preferred working styles.
5. Put yourself in their shoes: Having empathy for someone and the situation they are in helps provide a bound and assures everyone is working towards the same goal. Understanding the pressure, deadlines, and expectations your customer and user is under can help you build the best way to help them out. If you have a good understanding of this, you may find out that your standard policies or normal process may not work. Let me give you an example. Let’s assume you have a customer who has a seemingly small problem in their development environment. This particular issue may not usually make it to the list of top things to focus on immediately. In support, this may classify as a severity 3 issue, non critical on a non-production system. However, what if you knew this small problem was blocking a significant release of new software that has to go live in two days, or the user risks being fired? Context is important.
6. Integrate, understand, and document the company, the business, and the people: All customers, but especially large ones want to have a smooth and seamless integration with their service providers. However, what defines a smooth and seamless integration is often different for each customer, what is common amongst all the customers I have talked to is they want you to understand their company, infrastructure, and needs intimately. Customers want you to use that intimate knowledge to craft services, suggestions, discussions, and projects that are built specifically to their needs. Being able to use this “inside” knowledge can help turn you into a partner instead of another service provider. Let me give you some examples.
All businesses go through cycles. Accounting firms have tax seasons. Eccomerce companies have Black Friday and Cyber Monday. Gaming companies launch new games. Benefits companies have open enrollment.
Every company has some regular events and some cyclical nature to their business. Knowing what these are and how they impact your customer and the apps their use can help you craft proactive and relevant conversations. For instance, a few months before “Black Friday” discussing scaling, performance, and contingency plans is generally a good idea. Similarly recommending or even trying to do an upgrade for an accounting firm during tax season is probably a bad idea.
Similarly this “inside knowledge” helps you avoid awkward conversations and giving misaligned advice. A reasonable suggestion for most customers to fix a bug is to upgrade their software to the latest and greatest. Often you will hear service providers say “Well you are X versions behind, why don’t you upgrade to the latest and see if that fixes the issue.” This suggestion may be reasonable for some subset of your customer base, but for another subset, it is not. If a customer has 1000’s of servers that are all kept in sync, suggesting they roll out a major new release of software to fix a bug potentially is probably going to not only be a costly, but it will likely generate an unhappy response from the customer’s management team.
Finally, this knowledge helps you meet or exceed customer expectations. Often you will find that customers internal processes have specific checkpoints or rules. Understanding what these help you to integrate more effectively. Some customers, for instance, require that during a severity one outage, they have all the key stakeholders get in a “War Room” until the crisis is over. Sometimes they expect vendor representatives to join this war room too. Even if you can’t meet this expectation, knowing about it and working around it is infinitely better then not knowing about it at all.
It is vital that as you work with customers, you not only understand their needs, expectations, and skillset, but you meet them in a place where there are comfortable and where they can be most productive.