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.
Once you’ve completed implementation, it’s time to drive your users to a return on their investment as quickly as possible. Let’s talk about the tooling you’ll need to achieve that.
The first bucket of tools allows users to easily contact you when they hit snags and need help. We’ll talk later about proactively identifying users who are having issues and engaging them before they even reach out. But the first step is having a means by which users can get in touch with you when they have issues.
You’ll recognize a lot of the same tenets from Early Inbound Lead Capture and Response, in that support is rather similar—it just happens to be for existing customers rather than prospects.
importantThe key here is to ensure low friction to get in touch. If you make it hard to ask a question or provide feedback, your user will simply close your solution and go back to the way that he used to do things. You want to make sure that when folks have an issue, they can complain and complain easily, because hearing that feedback is a requirement to fixing the root issue!
At the most basic level, this can be a big Help or Support link. Ideally it should live prominently on the side of the browser window or app screen and allow users to quickly jot down their issue and fire a message off to a monitored inbox with a click. This could be something as simple as a mailto link that points to support@yourdomain.com, where that email address has been set up as a listserv that people responsible for support (maybe you!) at your organization monitor. A more advanced version might be a Google Form that asks for structured information—keep in mind, though, that this can add friction for the user who needs help. Really, the most important thing is simply to know that someone is unhappy so you can jump all over it and help them get to success.
While they might sound obvious to some, I’m going to take a second here to note some general tenets of support communication. Though customer success should always be viewed as helping the customer to achieve the value they were promised during the sales process, inbound support is a bit of a two-step process. Unlike implementation, where the user is typically excited to be trying out her new toy, in the case of inbound support the new toy probably let the user down and broke in some regard. Now she’s annoyed and wants to both get her toy back and express some frustration.
cautionWhile your longer-term job is to get the user back on track and successful, the first step is usually to diffuse frustration, and to do so in a way that makes the user feel heard and empathized with. It’s often very tempting to blame the user when you realize that the cause of the issue can be something very basic (“Is it turned on?”). Resist this temptation and instead focus on making sure that you can save this relationship, by taking all the blame for the issue and validating the source of frustration. Moreover, they’re probably right. If it wasn’t turned on, why wasn’t that clear? That’s your fault, as a product development organization, for not putting the power switch on the front, where users can see it’s switched off.
Your goal is to soothe the angry customer, progress to fixing her problem, and persist until the issue has been resolved—or she tells you that it’s no longer an issue.
importantThe next tenet for inbound support is quick response. Eventually you may get into Live Chat (more on this in a second), but to start, even asynchronous support email requires extremely quick response time. If you’re at a very early stage, you may even consider a direct phone call back so you can quickly solve the problem in a rich, synchronous conversation. This may not be scalable later, but early on, the quicker you can solve problems for your users, the more excited they will be about your solution—and the less time they’ll spend stewing, frustrated with how your solution let them down. Furthermore, your support will have an air of honest-to-goodness TLC that will reflect highly on your solution. Again, you’d be amazing how much awesome support can paper over issues with a solution, especially when it’s early and things may be rough around the edges.
Even if you can’t solve the issue for the user instantly, at the very least you should aim to quickly acknowledge that the ticket has been received and communicate some time frame within which they should expect follow-up. Most of these more involved ticketing systems include automatic email acknowledgment functionality, which is helpful, but I like to let the customer know the moment that a human starts working on the ticket too.
As with sales opportunities, you’ll want to keep track of the state of a support request, so you can know which ones need you to act, which are in progress, and which ones are done. Basic support software will help you do this, but make sure that you’re practicing good hygiene when you respond to requests, marking them as in progress and only closing out tickets when it’s become clear that you’ve solved the problem. And not just, “Okay, I didn’t hear back from you, so I’m going to close this.” Make sure you have an affirmative statement that you fixed their issue, or that they no longer need your help. Otherwise you’re going to have a hot mess of confused email threads, customers waiting for help, or unnecessary follow-up with folks whose problem you’ve already solved. Like an inbound marketing and sales pipeline, you want to work the ones that came in most recently and haven’t been acted on first; once those have been addressed, fall back to the other open tickets.
Once you get a goodly number of users on your solution, you’ll start seeing patterns in your support queries—namely, multiple users running into the same issues. This is good. Not only can you construct FAQs (frequently asked questions) that will make you more efficient, you can usually also identify opportunities to fix this user frustration in the product, so it won’t become a support ticket. (A good way to think about it is if a user takes the time to complain about something, there’s probably 10x more who ran into the same issue and didn’t complain!)
Support software includes what are known as macros, which allow you to use pre-written (or canned) responses—the support version of an email template—along with automatically updating status and tagging of your tickets. As soon as you start seeing patterns in your support requests, you should start creating canned responses. At first they can just be text based, providing the information that is requested. But as you get more involved, consider providing links to more robust support articles you create using the support site functionality of most of these support software providers.
exampleIf you’re were NextWave Hire, makers of recruitment branding software, and you constantly saw people asking how they could load their NextWave Hire employee testimonials into social marketing software like HootSuite, you might consider spending 30 minutes to stand up a support article on how to do that, step by step, with screenshots. This way, you know you’re providing a richer educational experience, and each time you get that question, you can quickly fire off a macro linked to that article, getting the user exactly what they need and on their way. Moreover, when you later add a front end and search to your support site, users may be able to self-serve these solutions without involvement by a support agent—helping them get their solution faster, and freeing up support agents for stickier issues that need their involvement.
Above and beyond helping your users get the value they were promised when they purchased your solution, rigorous support can be extremely valuable in guiding your engineering and product efforts. The information contained in support requests often points toward the highest-impact moves you could be making next—whether bug fixes that reduce common issues or new features that address the unmet desires users are surfacing. However, in order for this information to make it to your product development organization, first it has to be cataloged and tagged appropriately. Typically, this means adding tags to tickets that describe the features that they stemmed from.
exampleIf you were Textio, makers of job posting optimization software, and you saw users having issues trying to save job descriptions from the editor interface and complaining to support that they were losing their work, you might tag those tickets with the part of the product (editor) and the desired functionality (saving) in question.
Don’t go overboard, but keep in mind the ultimate goal of this exercise: to be able to take this information at, say, the end of the month and see what features are causing the most support tickets—the better to guide decisions about product development.
While email-based, ticketed support is the expected industry standard across SaaS, there are a number of other methods of providing responsive support and a number of other venues where you may end up engaging with your users.
Live chat is becoming more and more popular, both for desktop-based customer success and, more and more, for mobile-based solutions. The value of live chat for support again echoes the value of live chat for lead capture: immediacy. Being able to quickly solve a user’s issue at the moment of their frustration keeps them from disengaging with your solution—and on their merry way to achieving the value you promised them. Not only can your agent resolve the issue quickly, which is a benefit to the customer, the rapid back-and-forth of chat provides the customer a sense that something is being done to help them.
Moreover, chat makes it much easier for you to elicit further information from the customer about their issue. If a customer’s initial email to support is half-formed or missing information (which they often are), then asking for clarification is an exercise in email-tag. With chat, on the other hand, the rapid back-and-forth allows your support agent to pull the relevant information out of the customer.
And while it might seem that live chat would be more costly, typically a support agent can hold a handful of these conversations at once. So ultimately it may not require more personnel time than email-based support tickets. That said, it does require someone to be on call, at least during certain times, which can be challenging if your support team is only you or a single customer success person who’s handling implementation calls, follow-up calls, and inbound support requests. (More on this later when we talk about support specialization.) Some chat support software, like Intercom or Zendesk Chat, gives you the best of both worlds, behaving like chat software when you or your customer success staff are online and available, and behaving like more traditional asynchronous email when they’re not. So if you have to be on an implementation call, and a customer files a support request, it is received like an inbound email request; other times, when you’re on duty for support, you’ll receive a chat.
Twitter is another place you might find yourself providing customer support. Well, issue diagnosis and resolution rarely takes place on Twitter, but it’s another channel where your customers may end up venting their frustrations about something wrong with your solution.
Firstly, if you’re seeing this kind of frustration on Twitter, consider that you may not be making it as easy as you should for customers to vent directly to you. This is where the fallacy of trying to make support difficult (requiring users to fill out lots of fields in a complicated support request form) may bite you. Your customer may just decide to open a new browser tab and dash off 140 characters of angry diatribe that will unfortunately be consumed by all of his followers!
That said, even if you make things as easy as possible, you’ll likely still end up with folks talking about you on Twitter—whether it’s existing customers or people considering your solution. Most support software now includes some version of social listening to bubble up potential issues and create tickets out of them. Early on, this may be unnecessary; you may have too few customers to worry about them taking to social media. However, if your accounts happen to have lots of users of your solution (for instance, a customer has 100+ employees using the software), pretty quickly you could end up with a few thousand folks with the potential to create social media headaches.
Supporting consumer products on Twitter is far beyond the scope of this discussion, and typically much harder than doing so for enterprise users. With enterprise users, the best approach is to simply treat social comments as an initial inbound support request: do your best to acknowledge, let them (and others who follow them) know that you’re on the case, and describe what action you’re going to take or need them to take. Thankfully, at an earlier stage, you likely won’t have too many users, so it should be pretty darn easy for you to take their names and geography (typically included in their profiles), look them up in your database, and then engage them directly via your typical support process. Ideally your first outreach should include a proactive suggestion of what the solution might be, based on the tweets. And of course tell them in a public reply that you emailed them with a proposed solution, or with a follow-up question. If you can’t figure out who a user is because he or she has an atypical alias that doesn’t align with the name of a user in your database, reply that you tried to find them and couldn’t. Then give them the URL for a support article that best solves their issue (if you have one), and tell them to email your support address so you can fix their issue.
Of course, social media can also be a great place to encounter people raving about your product or asking questions about it before they actually enter the sales process. Taking the opportunity to give those folks a high five or to direct them to a sales rep (or, even better, direct a sales rep to them) can be a cherry on top of a social support mechanism.
Phone support can be costly, in that you have to have someone who is standing by to answer calls (much like you need to do with chat). That said, early on, we’re not really interested in being as cost efficient as we can; we want to sniff out early indicators of issues so we can systematize their solution. So at the outset, having a phone number for folks to call—and you’ll be surprised how many would prefer to chat and file email support requests than talk to a human—can be a great way to give early customers the white glove treatment. Take the opportunity to learn fantastic information about their challenges with your product and their hopes and dreams for what it could be for them. Later on you can make the choice to remove that option as you seek to manage the economics of your support mechanisms.
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.