editione1.0.1
Updated August 22, 2022You’re reading an excerpt of Founding Sales: The Early-Stage Go-To-Market Handbook, a book by Pete Kazanjy. The most in-depth, tactical handbook ever written for early-stage B2B sales, it distills early sales first principles and teaches the skills required, from being a founder selling to being an early salesperson and a sales leader. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, commentary and future updates, and a high-quality PDF download.
While low-friction inbound support and rapid response is fantastic, there’s a step beyond: proactive, preventative customer support. One of the beautiful things about modern software, particularly SaaS solutions, is that the customer actually uses it on your servers, or at very least, in a way that allows you to instrument their usage. This is in stark contrast to how things worked back in the day, with on-premises enterprise software that was installed on customers’ servers that were racked in their data centers. Then, you might have had no idea whether the software was being used and value was being provided to customers.
Now, SaaS delivery means you see what sort of usage customers and users are engaging in. And that’s crucial to your business. Because users are subscribed (and didn’t purchase a perpetual license of the software), they can just stop subscribing if they aren’t using the tooling (and deriving the promised value). The logical implication of that turns out to be: pay attention to whether customers are using the tooling the way they’re supposed to! This notion of customer success monitoring has really taken off only in the last few years, and the associated tooling is still being developed. However, there are fairly basic ways that you can accomplish this now.
It’s fairly common to architect your application such that a customer success manager can log in as the user to see what’s going on. This is helpful when troubleshooting but can also be great for customer success, as you can dip into customers’ accounts to check for the telltale signs of proper usage. You would be looking for those value precursors and value outcomes discussed above—the actions and outcomes that lead to the value you’ve promised.
The more advanced version of inspection is reporting that you can get from your engineering team (or, if you’re handy with SQL, maybe you can do it yourself). The downside here is that it can be expensive to have your engineering team stand up reporting for you. But if you have enough customers, it can be worth the investment.
There are a couple different types of reporting. One is comprehensive reporting for some trailing time interval that shows the key value precursor and outcomes for each user and each customer. That way, you can easily scan across and identify potential problems to address (and, on the flip side, users having great success for use in marketing materials and customer references).
Then there are more prescriptive reports that alert you to just the specific users who need help by showing which users and customers fell below designated usage levels. This can be as basic as surfacing users who haven’t logged in for some period of time. Or you can look for more specific indications that a user is struggling.
exampleOn TalentBin, running searches that yield zero results, or unusably large numbers, suggests a problem; we could have designed reporting to alert us to that usage issue, which was likely to block success.
The important thing is to instrument leading indicators of non-success so you can jump on them before that bad or nonexistent usage becomes ingrained.
You may also be able to hack existing tooling to provide you this information. If your product and engineering team uses something like Mixpanel or similar, you can sometimes use that software to set up this kind of customized reporting. Or, if you want to get really fancy—and likely you would do this only after you have a customer success rep or two—you can use purpose-built customer success instrumentation software like Gainsight or Catalyst, which not only pulls user activity into the system, but allows you to act on it with communication templates, playbooks, and the like. You can almost think of things like this as the CS person’s pipeline, which they’re constantly combing to see where they can move a customer down the road to success, the same way a sales rep would with prospects in the CRM.
Of course, having this data is all well and good, but if you don’t do anything with it, it’s not super helpful. First, that means consuming it. You have to prioritize time, on a recurring basis, to review this information. Identify people who are having great success (and give them kudos, and log them as potential customer references) and those who are not doing well. Once you’ve done that, you need to act on it.
Doing so is a little more delicate than responding to inbound requests. In this case, you’re calling out that the customer appears to have an issue with their usage that makes them aberrant. So this takes some finessing and is best approached from the standpoint of “I want to help you have success,” “I want to help you be the best you can be,” “I want to learn what’s keeping you from being able to achieve success, and fix it,” and so on. Remember the pitching we talked about in implementation, and the importance of those user-facing value props? This is where you trot them out again. Later you can get into the heavy artillery and involve their management or original decision-makers (if that’s a different person).
Shockingly enough, a lot of the time, it can just be a case of the user or customer having competing demands on their time, and being not great at prioritizing use. Often you can take on the role of manager here to ensure that they’re blocking sufficient time, and can even use calendar reminders to help with this.
Other times there are actual issues that need to be resolved. Engaging users and prompting them in an open-ended fashion about what the issue is can be a fantastic way to see where there are weaknesses in the product or where there are out-and-out bugs. Sometimes it’s a simple fix. Perhaps the user was confused about a feature, and once you show him how to resolve it, he’s off to the races again.
Another fairly common situation is that the user to whom a license was assigned leaves the company and their manager doesn’t have a rigorous transition plan in place. That’s also easily resolved; you’ll want to engage with the relevant decision-maker to secure a new user, and run them through the relevant onboarding programming. The same is true if you have a decision-maker who leaves the organization. This is why you’ll want to instrument usage even at the managerial level.
If someone’s usage disappears from your reporting dashboards, perhaps they’ve disappeared from the org—which is important to resolve for this particular implementation. But if that customer was excited about the product and having success, then perhaps that decision-maker is in the market for your solution again at the new company she landed at! Another reason even managers are important users to proactively instrument.
Of course, there are occasionally problem users—folks who, even after you’ve resolved all their supposed issues, continue to not do the things required for success. Often these are folks who either have another competitive tool or process that they prefer or weren’t involved in the process of procuring your solution and aren’t bought-in on it. To the extent you can, make your case about how this will help them do all the great things they want to do, now and in the future at other jobs. Help them understand the opportunity cost of not using the solution—whether that’s missed hires, lost revenue, or whatever your product’s value proposition is. If that fails, involve the deal sponsor to see if you can secure a different user. Of course, do so in a respectful way, but make sure to detail all the efforts you’ve undertaken. If it’s a situation where the entire organization has licenses, like a CRM, and there isn’t a question of swapping in another user, just make a note in your CRM about the problem user (almost like closed-lost notes for prospect opportunities) and move on. If it’s a situation where only a subset of staff at the organization have licenses, and your licenses are scarce, then seek to get another user in that seat.
It’s important to remember that you can’t spend all your time on every user, and at a certain point, you have to cut your losses. In fact, typically you want to spend your time on the C+/B- users—you may never be able to save the users who are at F and D levels. The B+ and A users are on their merry way and don’t need much attention. So spend your time getting those C+/B- users up to B+ levels. This is especially true when you as a founder are doing the customer success work, but it continues to be true even when you have a handful of customer success staff.
Many of these issues are really easy to resolve, but the important thing is being able to identify that something is amiss and jump into it, before things get worse. And to do that, you need to have proactive monitoring!
In addition to monitoring usage to get ahead of any problems, a successful customer success function needs to understand and quantify users’ success—and then make sure to tell them about it! In business speak, this evidence of success is often known as outcomes.
In the sales process, you promised certain kinds of business value to your customer. Instrumenting the achievement of that value is important for a variety of reasons. When customers can see that they are achieving the desired business value, they’re more likely to stay customers. Moreover, by documenting and capturing success outcomes, you’ll be able to use that information in go-to-market materials, like sales decks, customer success stories, and so forth—more on that later in the chapter. There are a couple of ways to go about this.