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.
When it comes to customer success, there are a broad array of tools to get the job done. That said, don’t think that you need to employ all of the approaches we’ll touch on. They are presented in order of most integral to more optional. All will deliver value, but depending on your bandwidth, you may need to pick and choose until you have dedicated customer success staffing. Regardless, they’re all good to have in the back of your head.
The broad bucket of implementation is the set of steps that you take after a customer has signed to get them quickly up and running, and can include technical implementation steps, user training, and more. Depending on the complexity of your solution, this could be as simple as a 30-minute call and guided tour, or as complicated as a multi-month, full-blown professional services engagement. In either case, though, implementation is the first step on the road to customer success, without which you’re putting yourself at a substantial disadvantage. Invest in it accordingly.
The goal of implementation is to execute all the preconditions needed for your customer to have success with your solution. So the first step is to understand what those first steps are. This ranges from the completely mundane, like securing credentials for a user, to the more involved, like integrating with existing systems, migrating data over from legacy systems that your solution is complementing or supplanting, and so on. It also includes user training for all archetypes of users: individual contributors, managers, and beyond.
exampleFor a company like Textio, makers of job posting optimization software, implementation would start with securing credentials for all the recruiters who would be using the solution. Next, they’d hold training sessions with those users to understand how best to use the system, and with their management to help them understand that the system is being properly used and creating the promised value for the organization. And it would keep going all the way to securing proper integration with the customer’s existing applicant tracking system to ensure that Textio could start learning from the organization’s prior job postings (and the applicants and eventual hires that came from them).
importantOnce you understand how many of these steps need to be taken, and have a sense of how much time that should take, you’ll start to see how involved this might be. This will indicate whether your implementation process can be as simple as a one-and-done call and screen share with the primary user of your product (or even a self-guided onboarding tour, for extremely inexpensive, uncomplicated solutions), or if it will require a series of meetings with various stakeholders, project managed to completion.
There isn’t a single correct answer. It’s simply a question of making sure that you are doing all the things needed to get your customers to success, and not stopping short. So if that means it will be a multi-person project that spans several weeks, that’s fine. Just set that expectation during the sales process and, importantly, make sure that your pricing can support this level of engagement in the long run. If implementation takes 120 minutes all-in per customer, and a customer success rep who costs ~$50K a year can do 15 a week, that’s ~$70 of implementation labor cost right there. If your product costs ~$20 a month, that math doesn’t work. Either your product will have to cost more or you’ll have to think about how you can use cheaper, non-labor-intensive resources (for example, in-product tools, documentation, and so on) to reduce that implementation cost. For our purposes, we’re going to assume we’re dealing with a fairly costly product, around ~$1K+ per user per year.
For reasons touched on above, early in your go-to-market, it’s fine to over-invest your personal time resources to ensure that your first customers get to success. But in the back of your head, be thinking about the salaries you will eventually need to pay your dedicated customer success staff, which will have to come out of licensing revenue. Make sure that what you charge can support that customer success burden. Moreover, if implementation is particularly beefy for your solution, consider charging a one-time implementation fee to account for that. (A good rule of thumb is to triple the labor costs associated with the implementation process—so if it takes a week of employee hours, costing you ~$1K, you might charge ~$3K.) With most SaaS products, though, by virtue of their “flip the switch” nature, implementation doesn’t require that kind of heavyweight involvement. But your mileage may vary.
If your solution is straightforward enough that you can thoroughly cover implementation in a 60-minute meeting or less, then that’s a tried-and-true approach. It’s a nice block of time in which you can hold the customer’s attention and walk through a checklist of things to take care of, concepts to explain, and actions to take.
Early on in your go-to-market, on-site implementation can be a good approach. I suggested selling locally to start so I could go on-site to present and demo without getting in a plane; now you can do the same with implementation, ensuring rich communication and getting your customer bought-in. Face-to-face time is so important early in your company’s life (and it never hurts to bring cookies and your latest logo schwag to set a friendly tone). Eventually, though, holding these meetings by phone and screen share will be the more scalable way to do this.
Your implementation meetings should be run from your sales presentations. You’ll need to do pre-call planning, where you review your CRM for information from whoever sold the deal (early on, likely you) about who the user(s) will be, who the decision-maker and other stakeholders are (if they are different from the users), and what the business rationale for the purchase was.
Beyond simple pre-call planning, if there are specific pre-work actions that need to be handled to make your face-to-face time more efficient—like securing user credentials, loading the client’s logo into the UI of their instance of your product, or what have you—do that too. And make sure you’re familiarizing yourself with the parts of their business that your solution helps, and the specific user or stakeholder you’ll be working with, using available resources like LinkedIn, their career site, or whatever else.
exampleAt TalentBin, our planning included reviewing the customer’s careers page to see what sort of technical roles we would be setting up searches and folders for during the implementation call. We would also check out the LinkedIn profile of the user we’d be implementing to see if they were a technical recruiter, a generalist recruiter, or maybe concerningly, an engineering leader or HR generalist (which would require that we delve into recruiting actions and best practices, not just new software tools). Just as with a sales pitch, you want this information in your back pocket so you aren’t blindsided and are best set up for success.
Just as you start your sales presentations with discovery, you should typically start your implementation calls (and kickoff calls, for more involved implementation projects) with rediscovery. State what you believe the customer’s business goals are and how the solution is going to be used to achieve them. At TalentBin, this might have been something like, “It’s my understanding that you’re going to be hiring a dozen software engineers over the coming year, mixed between Ruby developers and some front-end specialists. And to help with that, you bought this TalentBin seat. Is that right?” You want an affirmative statement of what your agenda is for the coming twelve months (or whatever the term of the contract is), so you know that you’re on the same page and can start working together toward these goals.
And if there is some sort of slippage between what the customer’s goals or beliefs are, and what you thought their goals had been, fantastic—now you know that and can course correct, rather than charging through an implementation call that drives toward the wrong goals. Or if, for whatever reason, they purchased the solution to solve problems that it doesn’t solve (yikes! How the hell did this deal get sold?), you can quickly act to correct there too. Whatever goals you agree to during this rediscovery, make sure that you are documenting them in your CRM. Or, at very least, make sure that you memorialize them in a follow-up email to the user and stakeholders after the call, so it’s there to refer to if there is confusion down the road.
As you think about the agenda for your implementation calls, begin prioritizing the points you’ll cover, from those that are crucial to success to other important items, with optional topics last. Things that absolutely must be covered might include ensuring that the user can actually access and log in to your solution (I know, you’d be shocked), that they have the relevant software downloaded onto their computer, that your solution is obviously bookmarked in their browser or shortcutted on their desktop or dock (you want to make it very easy for them to get back to your solution), or that any relevant data feeds are set up.
If your solution requires a user to OAUTH into their email or another system, it’s critical to walk your new customer through that process first and foremost. If you train them on everything else but that action can’t be completed, what was the point? If setting these data feeds or authentications can end up being fiddly or time consuming, it may make sense to have an initial setup call before the longer, more formal training call. That way, you can put all those setup items to bed and deal with any tripwires that come up, and you’ll still have the full time allocated to the implementation call to tackle training and higher-value work.
Having covered setup items, you need to next focus on the core actions that are taken in your solution. A brief refresher (perhaps with a couple slides) may be appropriate here to set the context of the training. If you end up selling to larger organizations where the user hasn’t seen the solution before (ideally, less the case when you’re selling to “deer”-sized, mid-market, not-too-small, not-too-large, accounts to start, but not uncommon), you’ll also need to sell the users on why they should be excited about the solution. (Use the same rationales discussed in Sales Pitches for Startup Founders: it’s going to make their jobs easier, make them smarter and better at their work, and potentially get them a better job in the future!)
During implementation, to whatever extent possible, have the user execute actions and, ideally, do actual, productive work. Often implementation staff will just flip on their screen share and do a show-and-tell. This is inadvisable, in that your user will not be engaged and will quickly whip out their iPhone to see the latest on Instagram. If you can, use a screen-share solution that allows the users to share their screens. If it allows you to use some sort of pointer or cursor to show them where to click, even better—do that. You want them to be mousing and typing and doing things, with your coaching. Things like join.me or Zoom, or heavier-weight solutions like GoToMeeting or WebEx, can be good here.
exampleA typical TalentBin implementation call included setting up a job requisition project folder, setting up and saving a search, demonstrating how to view and dismiss profiles, reaching out to viable candidates, and dropping those candidates into a drip-recruiting marketing campaign. At the end of the call, the user had ideally executed outreach, put a handful of candidates in drip campaigns, and maybe even gotten a response from a candidate, or at the very least an email open notification.
Talk about a great outcome from an implementation call: a user who is fully set up, has executed and familiarized herself with the business motions necessary for success, and has actually done some work that can provide the promised ROI. That’s the ideal.
If you’re wondering what these steps might be for your solution, think back to your demo script. You set it up to rehearse the most important, valuable elements of your solution for your prospect, and to do so in a logical, progressive fashion. Your implementation process likely should align with that. It’s kind of like a demo, but one where the user is doing the driving.
When it comes to implementation calls, you’ll often be tempted to do group calls. If there are going to be a dozen users of your software, you might think, “Well, I can do this once, get them all with one call, and move on to the next. Efficient!” This can be really dangerous, especially early on in your go-to-market.
Group implementation calls suffer from the same issue that group sales demos suffer from: lack of accountability. Everyone thinks that someone else is responsible for paying attention, so no one does. Even if you’ve instructed everyone to follow along with your screen share and do the work on their side, you can’t tell if they’re actually doing it. Not to mention that you now have, say, five folks who can potentially trip up and need to ask a question, slowing down everyone else. The result is typically an uncontrolled call that fails to achieve your objectives. Worse yet, now you have five half-trained, half-implemented users who are responsible for that account’s success with your solution. Remember that churn thing we were talking about? You now have five churn time bombs. Again, your ability to conduct one-on-one implementation may be constrained by what you can charge for your product. But if each of those users represents ~$1K of revenue (multiplied by many years of renewals), then you shouldn’t be skimping. Especially at the beginning.
Oddly, you may run into managers who want you to do a group training, thinking that it’s somehow more efficient for their team. You can feel empowered to push back against this—if it’s an hour per user separately, or an hour with them all on a call together, it’s still an hour of each user’s time. It’s actually your time that’s being expended to a greater degree. Just explain why the way you do it drives success. Help them understand that more value is provided through separate calls, and that they’ll look like heroes for allowing it. And remember, if you acquiesce, you’re setting up more churn time bombs for yourself to deal with later.
When you conclude your implementation, you want to be sure that a summer break mindset doesn’t set in for your users. Don’t let them feel like students sprinting out of class on the last day of the school year, looking forward to a couple months before they have to think about school again!
A great way to avoid this sort of thing is to set a back-check meeting for a couple weeks out. Then, assign some specific homework to be executed in the interim, which the users know you will review by monitoring their usage. One of the beauties of SaaS software is that you have insight into the actions that users are taking or not taking. Make it clear that you will keep an eye on that information to make sure that users are having success, to jump in if there appear to be problems, and to report to deal sponsors (like their boss!) that the promised ROI is being achieved. We’ll touch on monitoring more later, but even just talking about it from the outset can help create a usage tailwind.
Ideally this monitored homework assignment should require very distinct, measurable actions—for instance, doing X specific action Y times by the end of the first week. Be clear that users who do this homework have X% more success than folks who don’t, which is why it’s assigned.
exampleTake Teamable, makers of clever referral recruiting software that helps recruiters mine their internal networks for potential fits for open roles. Say they spent their implementation call demonstrating how a recruiter should process referral candidates for a single internal staff member. The homework goal might be to reach out to ten referral candidates of ten internal staff in the first week, for a total of a hundred potential candidates, and to get ten interested responses. This is eminently achievable, and a mild scale-up of what was done in the implementation call, all focused on driving demonstrable ROI as quickly as possible.
As with down-funnel sales work, don’t end the implementation call until that next meeting is actually on the calendar and you’ve sent the meeting invite for it. When it comes to scheduling a follow-up meeting, it can be just as time consuming to chase down a customer as a prospect. Avoid being in that situation!
Before concluding the meeting, verify that the user knows how to get in touch with you if he has an issue. More on this in a bit, but making sure that there is an easy way to get in contact with Support (which might be you right now), both in the product and via email, is key. If you are able to record your onboarding call and provide it after the fact, this can be a helpful reference for the user (and a “tale of the tape” to go back to, if there are any issues in the future). You can share the script or checklist that was used too. If the customer is trying to remember that one really neat thing that you showed them, then with those materials, they can easily access it.
If meetings are missed, you should push hard to reschedule them, to ensure that implementation is happening the way that will enable success. Make sure that you have tracking in place to know which users and accounts have had their implementations, which need to, and which need to be rescheduled. Again, you don’t want to plant churn time bombs to be discovered at a later juncture.
That said, a video-recorded, canonical implementation call can be a helpful piece of collateral for someone who needs a refresher (again, better if you record their actual call for them to refer to) or for someone who would like to see what a call looks like.
Occasionally you may find that users need to be “re-implemented” in some regard, because they’ve either gotten out of the habit of using your solution or need a refresher. Or the original user of your product may leave the org, meaning that you need to onboard her replacement. In addition to preserving that customer’s implementation recording, having weekly group implementations for this purpose can be helpful. If it costs ~$70 in labor to execute an implementation, and a user needs one or more refreshers per year, now multiply this by dozens of customers, and that could add up if done individually on an ad-hoc basis. For users who’ve already had an initial implementation, a standing group call can be a great way of accommodating the five, ten, or more users, across customers, that might need some help in a given week. Early on, though, you probably want to overinvest in going the extra mile to make sure that people are successful. So if someone needs to be re-implemented, by all means, get it on the calendar and do it, whether it’s an individual user or, even more importantly, a decision-maker or manager who is responsible for the people using the system.
If your solution is more complex, and requires the involvement of different parties, you may not be able to take a one-and-done approach. This is fine, and shouldn’t be avoided. Just be sure that your pricing supports more involved training. Multistage implementations can actually be a good thing—the more effort it takes to get something up and running, the less likely someone is to rip it out down the road. So getting good at these implementation processes can be a substantial competitive advantage for you.
When approaching a more complex implementation, think of it as akin to a multistage sales process, not unlike the one you probably went through to get the initial contract executed. Calendar the meetings, and use the same micro-contract approach to ensure that you have commitment for the next step at each stage of the process.
When your implementation involves multiple steps, it’s often good to have a kickoff call with all of the relevant stakeholders and participants, where you can review timelines and what is needed from each participant and get collective commitment in front of all of the other stakeholders.
importantThese calls should involve the sponsor or sponsors of the project, and any internal vendors whose help will be required to get everything up and running. Make sure that those folks are identified and commit to attend the call. During the meeting, as with one-and-done implementation calls, make sure to restate the customer’s goal for the solution and walk stakeholders through what they need to do to get there, along with the ideal timeline.
Having visuals for this meeting can be really helpful. This could be a slide that demonstrates the major steps, and timeline, for implementation (which you might have already created for your sales presentation). Or it could be a live, shared Google Sheet, with line items for each deliverable or action, their customer-side owner, a targeted date associated with it, and the relevant status of that item (To Be Done, Scheduled, In Progress, Completed, Hung, or what have you).
Source: Teamable
One favorite approach is having a templated Google spreadsheet from which you can create a copy for each customer. Ahead of your kickoff, identify, with the help of your deal sponsor, the various customer-side stakeholders for each item (for example, “This is the CMO. She owns this, this, and this. This is the VP of IT. He owns this, this, and this.”). I threw together an example, patterned after some spreadsheets I’ve seen.
A live status spreadsheet like that can later serve as a source of truth as you progress through the various steps. Introducing it at the start sets the expectation that you’ll be marching down that project plan, and that everyone will have access to it to see what’s being accomplished (or not, if things go sideways). There are fancier professional services project-tracking tools that provide this functionality, but to start, a simple shared Google spreadsheet is probably good enough.
Once you have all those stakeholders identified, it’s time to execute the various steps you’ve listed. As they are completed to satisfaction, mark them as completed in your implementation project plan.
Status reporting can end up being a substantial amount of overhead, which is why it can be so valuable to streamline things with a shared spreadsheet and a dedicated implementation thread via email. As important items are checked off, you can update the spreadsheet, and then link to it in an email notification to the group thread. This gives stakeholders a reassuring sense of forward momentum that their project is progressing and further establishes your credibility. It also creates a way that customers can get status updates whenever they would like, even between weekly status emails.
Your granular project tracking will likely be executed in a project spreadsheet to start, but as you acquire more customers, and as you have multiple implementations in progress, you’ll want to think about moving this to your CRM. The problem with keeping status information in different spreadsheets is that it’s difficult to query across multiple documents to see the aggregate implementation status of your customers. The right way of dealing with this is to track this information in your CRM.
This could be as simple as a post-sales status field on the relevant opportunity in your CRM correlated with different meaningful implementation stages. Or if you want to get fancier, it could be distinct activity items that need to be retired, each associated with the closed opportunity. However you approach it, the important thing is the ability to say to your CRM (or substitute system) something like “Show me all the opportunities that are closed-won, but in various states of completion.” For example “Show me all the opportunities that have close dates in the last fourteen days, but which haven’t yet had their initial kickoff call.” That way, you can see if any accounts are in some sort of red-flag situation.
importantTo the extent that you can do the work for the customer, do it. And to the extent that you can make things as simple as possible when you can’t do the work yourself, do that too.
exampleOutreach.io has an excellent implementation process. They sell a sales email and calling automation solution, so it’s critical that they connect their software to the customer’s Salesforce instance. In fact, this is so important that they build in a specific call with an approved Salesforce admin on the customer side to get that set up. It’s a 15-minute call if all goes according to plan (and sometimes it doesn’t), but it’s so important to the rest of implementation that they make sure to get that executed first and foremost. And they do so by using screen-sharing software so the implementation specialist can take control of the customer’s mouse if the customer is OK with that, just to make it as easy as possible.
Consider how proactivity like this could be used in your implementation process to make sure that the things that need to get done, get done.
importantBe mindful of snags in your implementation process. If something falls off the calendar, always get it back on. This becomes all the more important with a multi-step implementation, as there are more opportunities for those failures to occur.
If a further meeting falls off the calendar, reschedule it. If, for whatever reason, there are multiple failures, then be clear about the implications of this to the customer-side party who is precipitating the issue. Something along the lines of, “The reason we need to have this call is because I need fifteen minutes with you to XYZ. That is important because it’s required for the next step of our implementation, which overarching stakeholder name was hoping to get completed by date. What can I do to help get this completed so we can attain that goal?”
cautionIf for whatever reason you keep being stonewalled by an ancillary stakeholder, be careful about running back to your sponsor to tattle. Implementation projects are like multi-stakeholder sales, but after the sale has already taken place. You don’t want to be seen as going around tweaking noses, even if you have the imprimatur of the CMO, CIO, or whomever. Your goal should simply be to act as the agent of your deal sponsor, doing your best to advance the goals of the project and diligently documenting those efforts in the form of well-written emails, meeting invites, and status update emails, along with a tracking spreadsheet. You never know when that person you’re working with to execute an implementation action, post-sale, can end up at another organization and have something nasty to say about your solution while it’s being considered for purchase.
When you’ve completed all the relevant steps of implementation, and the solution is largely operational, memorialize that to your various deal sponsors so they know that it’s time to start expecting to see the return on their investment. For example, if it takes two months to get things up and running, you don’t want your deal sponsors thinking, “Why haven’t we seen a return yet?” and holding it against you. This is another benefit of good status reporting during the implementation project—your deal sponsors are seeing the work that you’re doing and the value that you’re providing in driving the desired change in their organization.
If your implementation process is drawn out and requires a substantial amount of labor on the part of someone in your organization, consider charging for it as a professional service. This can be helpful if your customers’ implementations vary significantly in complexity and therefore demand varying resources from your team that haven’t been built into the pure licensing costs of your solution.
A good example of this would be a solution that hooks into others enterprise systems, but could potentially be used without those hookups. If a customer doesn’t require any implementation hookups beyond their standard onboarding and training, then standard licensing would cover them. But if a different customer needs integration with three or four other systems, which represents 20+ hours of meetings, calls, and so on from a systems engineer on your team, then you might consider charging for that.
While you would hope that everyone involved in implementation would be excited about embracing new technology that will help them do their jobs better or, at a very minimum, follow through on something that their superior has instructed them to do, you can’t always rely on that. You have to consider your solution’s different value propositions to different stakeholders (individual users, line management, leadership), just as you did during the pitching process—“What’s in it for me?” continues even during this stage.
One great way of helping with that is to provide inducements to individual users to heartily embrace implementation. In addition to helping them understand how this is going to make their job easier and why it’s going to make the organization more successful, consider positioning how this will make them more in-demand professionals, now and in the future. A more advanced version of this could be actual certification in your solution: when the individual goes through all the steps of implementation, executes on the various pieces of homework, and attains some version of success with the solution, you can award them with certification.
exampleAt TalentBin, we offered TalentBin Certification, awarded to those who passed a lightweight test after implementation (that really just acted as an open-book quiz to compel paying attention to the topics we covered, or at least going back to the materials later) and completed a certain set of actions (for example, putting 50 candidates into drip campaigns). Certification included a digital PDF certificate and entry into a registry that could be checked by employers. Of course, this aligned with the interests of our customer success team—if users were familiar with how to achieve success, and incentivized to take the actions that would drive ROI for their companies, that was a big win for everyone involved!
Inducement can also be as simple as sending hearty helpings of company schwag to users who have gone through implementation. T-shirts, Post-it notes, high-quality pens, you name it. If you’re selling software that costs hundreds to thousands of dollars per user per year, then ~$5 worth of nice pens and Post-its is certainly worth it, and a nice reminder to users that their customer success manager loves them and is invested in their success. Plus, it can’t hurt to have a reminder of your solution papered all over their desks. It is absolutely amazing how much buggy software and occasional hiccups can be papered over by sunny, delightful customer success. Constantly remind the user that you’re in their corner.
This is one of the reasons why customer success staff are often compensated not on renewal metrics but instead on success precursor metrics (the proportion of the users they are responsible for who have logged in or attained some measurable outcome in the last 30 days). Alternately, you might compensate customer success managers based on their assigned users’ net promotion scoring or customer satisfaction survey scoring. The point is, guiding and rooting for your customers’ success—whether that means making them better professionals, helping them prove their value to their bosses, getting them raises, or positioning them for better jobs—is a great way to make sure that they are excited about your solution.
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.
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.
If you can design your product in a way that captures outcome value, all the better. At TalentBin, we had a concept of stages associated with candidate profiles, and one of those stages was Hired. If people were buying TalentBin to help them hire hard-to-find engineering talent, chronicling when that happened was one of the most direct ways of proving its value.
Sometimes successful outcomes may be harder to capture, so you can look to instrument the precursors to that outcome value as well.
exampleIf you were Textio, you could capture the number of job postings that had been improved, and what the level of improvement was, by comparing the Textio score of the job requisitions before and after optimization. Of course, the best of all worlds for Textio would be capturing that precursor behavior and also capturing the improvements of job-view-to-apply, phone-screen-to-apply, and phone-screen-to-hire ratios that even more concretely prove the value of the product.
Sometimes instrumenting value directly in the product is challenging. Moreover, while quantitative indicators of value achievement are great, they leave out more qualitative measures. For both of these reasons, eliciting value attainment feedback directly from users can be really helpful. There are a variety of ways that you can go about this, and some may be more doable than others depending on the scale of your customer base. The simplest approach is just being mindful to ask your users what they’ve accomplished when you interact with them or during scheduled catch-up calls. For instance, we discussed the notion of a 30-day check-in call. Part of that call could be focused specifically on documenting value that the user has achieved (or not achieved, in which case, you now know what you need to fix).
More involved versions of asking your customers include survey software for net promotion scoring (NPS) like AskNicely, Delighted, and so on. You can implement surveys to automatically send at certain times (for example, 45 days after initial kickoff) or can even be embedded directly in the UI. You can customize them to not only capture standard net promotion data like, “On a scale of 1 to 10, how likely are you to recommend this product to a friend?” but also explicitly ask value capture questions like, “Does this make you more efficient?” or, “How many hires have you made?” and so on.
However you capture this information, it’s important that you do it in a way that is reportable after the fact. Your CRM can be a great way to do this. If you can get proactive about capturing these success signifiers as Activities with time stamps on them, suddenly you can report on them to answer questions like, “How quickly do customers get to ROI payback?” or, “What proportion of our customers get to what level of success in the first month? Second month? Third month?”
There are all kinds of benefits to instrumenting and capturing success signifiers. But you can’t forget to reflect this customer success information back to the customers themselves. That might sound a little weird—if they’re having success, you’d think they’d know, right? No! Customers are super busy, use dozens of tools, and have all kinds of competing vendors whispering in their ears that their software would provide a better, faster, smarter solution than yours. You need to do a good job of documenting and reflecting back the success your customers are having, so it’s super clear that they’re getting that all-important ROI.
If you’re proactive about sharing this ROI information, great things happen. You’ll be top of mind with users and decision-makers, who will understand why this was a great investment of their time and budget. And if there are other potential users of your solution in the organization, it’ll be that much easier for you to sell more seats. These decision-makers and users also interact with friends and colleagues that share their business challenges. Making sure your ROI proof is readily available will arm them to be great promoters to others. And it helps cement their existing commitment bias ( aren’t they smart for choosing you?), which is very helpful if competitors and alternative solutions show up in their inboxes. Why would you open an email about a competing solution when you know that you’re getting great value from the one you’re using?
cautionIf you don’t do a good job reminding customers of their successes, the opposite can happen. You’ll miss out on upsell opportunities, as no one is clear on why your solution is a great investment. You’ll miss out on word of mouth because your decision-makers and users aren’t armed to advance those arguments for you. And you’ll leave yourself wide open for competitors to come in, making a case that their solutions can provide more value. Not good.
The best way to achieve scenario A, and to effectively share success data with your customers, is to implement quarterly business reviews (QBRs). Oddly named—probably better to call them something like success reviews—these are formal quarterly checkpoints between a vendor and a client to document progress against joint business goals. This is the means by which a vendor can present formally the value that has been delivered to the client so the customer can say, “Wow. This is great. I’m so glad that I’m doing business with you. I’m totally going to renew when the time comes around. In the meantime, I’m going to think about how I can maybe reallocate some budget from the other solutions I’m using, since clearly yours is working so well. Oh, while I’m at it, I’ll tell all my peers at different organizations about this next time we have cocktails.” At least, that’s the best-case scenario!
Quarterly business reviews should generally include the same participants who were involved in the selling process, with a particular focus on the decision-maker who spent his budget on your solution. A decision-maker who is a seasoned software purchaser will typically expect this sort of thing—and, in part, expects you to do his homework for him vis-à-vis the ROI that has been generated to date. I know that sounds a little weird. You clearly have an incentive to demonstrate substantial ROI, so why would customers leave that up to you to prove? Well, again, your customers are busy people dealing with the day-to-day of their jobs, so if you can do this for them, they’ll love you for it. Plus, they’d love for you to make them look smart for choosing your solution.
Involving users may make sense, but if there are too many to be practical, better to focus on the primary decision-maker. So too if there are problems in adoption or usage in parts of the user base that need to be addressed candidly with the decision-maker—you don’t want users in the room for that discussion.
As with many of these things, a nice slide deck template that outlines the information you want to transmit is a great start. This example of a QBR deck for a solution provider helps telesales organizations do a better job handling their inbound calls.
Your template should include a place to list the shared goals that drove the purchase of the solution—an opportunity to do rediscovery and ensure that the same business pains continue to be priorities. Start with something like this:
example“When you first purchased TalentBin, it was because you had five open headcount for Ruby on Rails engineers and were looking at this tool as a means to help with that. Is that still the primary technical hiring challenge you’re facing?” This rediscovery should be paired with the KPIs for the key business process that you were looking to improve, both before and after the solution was implemented.
If things are going great, and you can demonstrate that substantial value is being captured, then you should feel empowered to note opportunities for more ROI with more adoption. Say only five recruiters are using your fancy software, and you can show that they’ve saved 50 hours per recruiter per month over the previous quarter, aligning to ~$30K in saved salary expense. If you know there are 20 other recruiters in the account, they’re clearly wasting ~$120K in salary expense across the rest of the recruiting team for each quarter those others aren’t users. What are we waiting for?!
Below is a slide that focuses on how much key performance indicators have improved as a result of implementing a solution.
Source: IRMC
If there are issues, you should know this ahead of time from your success instrumentation, and address them in the presentation. Are seven of the account’s users adopting well, and gaining ROI, but three aren’t? Present this, along with the opportunity cost of non-adoption, and come with a proposal of how you’d like to address this issue to ensure maximum ROI for the decision-maker. Again, you’re being proactive and doing a bit of her job for her, which will be welcome. Also, if there are issues, attempts at upsell and cross sell in a QBR will probably be looked at as pretty lame. So don’t do that until you’re delivering on your promise for the existing folks.
Ultimately, the goal of the QBR is to assess the state of the relationships and sell the next steps that are most beneficial to you and the client. If that means retraining for problematic users, then you should be selling that. If everything is great, you should be selling participation in customer-success marketing collateral, like videos, slides, and case studies, and such, wherein the success metrics that you just reviewed and everyone gave each other high fives over can be documented in an easily shareable format to get in front of potential customers, and in so doing, make your client look like the brilliant thought leader she is for being so forward thinking!
These recommendations should be the conclusion of the QBR, along with discussion and buy-in by the decision-maker that these are the right next steps and a proposed action plan to achieve them.
Depending on the size of the customer and the amount of revenue that you’re looking to preserve, this QBR could be done on-site or digitally. If you’re going to do it on-site, you can often add in some user-facing activities, like retraining, a live Q&A session, or even just a customer appreciation thing like pizza, cookies, schwag, and so on. If the QBR is delivered over a digital presentation, you should ideally record it so it’s available for reference after the fact.
Lastly, if your solution isn’t revenue intensive enough to justify the staff time to execute a QBR of the type described above, this doesn’t mean you shouldn’t be explicitly sharing success information on a cadenced basis. Your goal remains the same: getting a customer excited about the value they’re getting out of your solution. If your product is particularly low cost, consider how you might develop an automated QBR that delivers all the same metrics and proof that you would cover in a face-to-face or digital presentation, but does so via email and potentially in the product.
Coming out of the QBR, guess what: you need to implement those next actions. So whatever the plan of action, summarize it in a follow-up email to the relevant participants. Then the responsible party should start cranking on that, as the clock is ticking on execution of that ahead of the next QBR.
Just as you report on your deal pipeline, you want some sort of method to report on QBR execution. Early on, this could be a Google Sheet that simply lists each QBR in its own row, which you populate when you first onboard the customer. Eventually, of course, this should live in your CRM—a standard way to approach this is to have an event of type QBR with a completion state field that you can set to To Be Scheduled, Scheduled, or Completed. And when an opportunity is closed-won, set that QBR field to automatically populate at quarterly intervals such that you can easily run a report to see the To Be Scheduled QBRs in the next 60 days that you need to schedule and prepare materials for.
While most of the things we’ve discussed have been one-off actions that are either proactive or reactive in nature, asynchronous support materials are also a powerful way to drive more and better success with your customers. Much like we look for places where we can templatize and collateralize our sales message—with email templates, slides, videos, PDFs, and so forth—we can do the same in customer success.
And the benefits are the same: you can make sure that the information that you’re providing is correct, since you wrote it once and double- and triple-checked it. But even more importantly, customers usually just want to solve their problem and get on their merry way. If they can do that by reading a success note or watching a quick video, that can often be more satisfying than having to file a support request or engage in a chat conversation with an agent—not to mention that by letting customers answer their own questions, when appropriate, your success staff can spend their time on implementations, QBRs, and thornier support issues.
The traditional way to do this is via a support site. Most support software like Zendesk, Desk, Freshdesk, and so forth have lightweight content management systems that allow you to create a dedicated page for a given topic (usually in the form of a how-to answer) with text, embedded images and screenshots, and even videos, that lives on a hyperlink. Moreover, they typically let you embed links to these pages in support response macros/canned responses to let support staff quickly respond to inbound requests with the relevant answers.