From “Founding Sales: Sales for founders (and others) in first-time sales roles” by Pete Kazanjy founder of Atrium Sales Analytics. Follow Pete on Twitter and LinkedIn.
Consider checking out How to Use This Book and Who This Book Is For sections to start.
Introduction
You’ve just closed a new deal. You’re pumped up, having gotten a customer across the line and booked the revenue, with the check in the mail. You’re ready to repeat your success and get another contract signed. In fact, you’re starting to forget about the customer you just sold and turn all your attention to the next prospect.
Don’t give into that temptation! In a SaaS world, the reality is that the moment you close a new customer, it’s a countdown to when they will be renewing, or not renewing, their contract. And if you don’t ensure their success with your solution, they won’t be renewing. But that’s not the worst of it. Even before renewal comes up, they certainly won’t be buying more seats or units of your solution. And while they’re not buying more, they certainly won’t be telling their friends and colleagues nice things about your solution. They won’t be providing you with delightful marketing-ready testimonial quotes and videos. Worse, if a new leader comes into the organization and does a tool review to see what is being used (and what isn’t), she could easily decide to break your contract—and not pay the remaining installments. Yikes!
Why Customer Success Matters
While losing out on a renewal is a big problem for your business, unsuccessful customers present all sorts of other problems ahead of that. And you don’t necessarily have a year to fix them. While we talked in prior chapters about the benefits of longer contracts—they give you more time to get a customer to success—that doesn’t mean you can get away with skimping on customer success and then save the contract in a last-minute scramble. There’s actually only a short window in which you have a customer’s attention and faith and can work them to invest their time and attention in adopting your solution. It’s far easier to get a customer up and running as an extension of the sale process, with all the associated excitement, novelty, and executive buy-in, than to resurrect something that has fallen by the wayside and been deemed a failed purchase.
Now contrast this to a happy customer getting value from your solution. In their first couple weeks using the product, following a successful implementation, they already have some massive wins. And those wins are exactly in line with promises that were made during the sales process, demonstrating that they’re well on their way to achieving the expected ROI. So they decide that more team members should have licenses and ask to double the size of the contract. All the while, because they’re so proud of themselves for being smart purchasers of a new solution, they’re happy to take customer reference calls. In fact, they’ve already recorded a nifty little webcam video raving about your solution, which you’ve embedded into your sales deck. When the decision-maker who purchased your solution gives his talk at the fancy new-technology conference, he cites you as being core to his company’s success. And when one of their users leaves for a new role halfway through the year, her first call is to you guys to get a license for her new company.
That’s the virtuous cycle you want to be a part of.
Do customer success wrong, and bad things happen. Do it right, and great things happen. How great and how bad? Well, check out this chart detailing the monthly recurring revenue for three versions of the same hypothetical businesses. The 0% line shows what recurring revenue would be assuming that all customers stay customers forever. After fifty-eight months, the company is at $4 million in MRR. Then look at the yellow line. With 2.5% monthly churn (that is, at the end of every month, 2.5% of total revenue is lost due to customers who cancel), after the same fifty-eight months, MRR is at something like $2.8 million. With 5% monthly churn, it’s below $2 million. That is, you would have less than half the revenue that you won at some point in time, and paid marketing and sales expense to acquire.
Now take a look at the green line. This is what you get when, every month, 2.5% of your existing revenue upsells via expansion. That is, users and groups that are having success tell other users and other groups, and they buy more widgets, seats, or what have you. After that same fifty-eight months, you’re over $7 million in MRR. Pretty impressive.
While this demonstrates the importance of customer success as you scale, it’s even more important when you’re just starting out. Getting those first few customers to take a leap of faith on your solution is hard. Make sure that they get the promised value out of it, and it’ll be that much easier to get the next few customers. And those prospects will have to take less of a leap of faith, since your existing customers have already told them about you over a beer!
Yes, your product can have features that naturally make it viral within an organization, or make it sticky by getting users to put in lots of data. All of that can help with churn reduction and upsell. But none of that happens without first getting customers up and running and successful, quickly. So let’s get you set up to do so.
So what is good customer success?
Above all else, customer success is about fulfilling the promises that were made during the sales process. The customer handed you money in exchange for a promise of value, and now you’re going to deliver that value.
What does that value look like? Conveniently, it’s documented in your Sales Narrative. Those KPIs that you said you were going to raise or lower for the customer? That’s customer success. So if we were TalentBin, this would be all about driving more engineering talent into the top of the customer’s hiring funnel. And if we were Textio, it would be about optimizing job postings such that more applicants would apply per post and posts would attract more diverse applicants. Customer success is about delivering on your ROI promises, and doing so for each of the involved stakeholders. Was there a certain set of value propositions for the manager, but others for the individual? Well, you’re going to want to check both of those boxes, and make both of those “customers” successful.
You methodically, and in a stepwise fashion, engage with prospects and drive them down the sales pipeline toward being a customer. Now, the same approach will ensure that you deliver the success you promised those customers, and find yourself on the happier versions of those revenue graphs above. Methodical, in that it will be rigorous the same way your discovery, presentation, demo, and pipeline management was. And stepwise, in that it’s not a question of getting a customer implemented, handing them the keys, and forgetting about them. Rather, after implementation, customer success turns to cadenced check-ins, instrumentation of success markers, and documentation of ROI achieved, all aimed at supporting an airtight case for renewal at the end of the contract.
Mechanisms for Customer Success
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.
Implementation
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 thirty-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.
So for 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).
Once 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 is important, because it 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 fifteen 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 (e.g., in-product tools, documentation, etc.) 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, you should 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 implementation. But your mileage may vary.
Implementation Calls—One and Done
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 you 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.
Pre-Call Planning and Pre-Work
Your implementation meetings should be run from your sales presentations. That is, there should be 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.
At 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.
Rediscovery
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.” That is, 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.
Agenda Items
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.
For instance, 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 should 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 the Pitching chapter: 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.us, or heavier-weight solutions like GoToMeeting or WebEx, can be good here.
For example, a 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.
Group Calls vs. One-on-Ones
When it comes to implementation calls, you’ll often be tempted to do “group calls.” That is, 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 should 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.
Homework, Follow-Up Calls, and Monitoring
When you conclude your implementation, you want to be sure that a “summer break” mindset doesn’t set in for your users. That is, 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.
Take, for example, 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. 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!
Materials and Support Contacts
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, well, with those materials, they can easily access it.
Missed Meetings and Re-Implementations
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 reschedule. 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. That is, if it costs $70 in labor to execute an implementation, and a user needs one or more refreshers per year, now add this up across dozens of customers, 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.
Implementation Projects/Multistage Implementations
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. Multi-stage 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. Meetings should be calendared, and you should use the same “micro-contract” approach to ensure that you have commitment for the next step at each stage of the process.
Project Kickoffs Calls and Discovery
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.
It’s important that this sort of call involves 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 (i.e., “To Be Done,” “Scheduled,” “In Progress,” “Completed,” “Hung,” or what have you).
This is a good example of something pretty basic from the folks at 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 (e.g., “This is the CMO. She owns this, this, and this. This is the VP of IT. He owns this, this, and this.”). This is an example that I threw together, patterned after some spreadsheets I’ve seen.
A “live status” spreadsheet like that can later serve as a wonderful “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.
Progressions and Status Reporting
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.
Advanced Progress Tracking
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.
Implementation Item Execution Proactivity
As noted in the “one and done” section above, to 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. A great example of this is Outreach.io’s 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 fifteen-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 okays that, just to make it as easy as possible. You should 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.
Snags and People Wanting to Diverge
Be mindful of snags in your implementation process. Firstly, as noted with one-and-done implementation calls, 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?”
If 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 whatever. 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...
Completion
When you’ve completed all the relevant steps of implementation, and the solution is “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. That is, 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.
Charging for Implementation
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, well, you might consider charging for that.
Inducements for Users/Stakeholders
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. That is, “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. That is, in addition to helping them understand how this is going to make their job easier and why it’s going to be 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. That is, 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.
At 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 (i.e., 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 (i.e. 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.
Inbound Response & Support Tickets
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 the Inbound Marketing chapter here, in that support is rather similar—it just happens to be for existing customers rather than prospects.
Inbound Support Request Capture
The 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.
There are a variety of shared-inbox solutions that make managing a dedicated support email address easy like Front, Help Scout, and others. More involved support solutions like Zendesk, Desk.com, Freshdesk, and Salesforce ServiceCloud can also let you easily present a <support@domain.com> email address that then gets “captured” by the support software, and ticketed in a way that lets you understand which issues need to be addressed, which are in progress, and which have been solved.
General Support Tenets
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. That is, 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 pissed, and wants to both get her toy back and express some frustration.
So while 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’s been resolved—or she tells you that it’s no longer an issue.
Rapid Response
The next most important key to 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 acknowledgement functionality, which is helpful, but I like to let the customer know the moment that a human starts working on the ticket too.
Response Tracking
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.
Canned Responses and Macros
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 “frequently asked question” responses 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 “canned responses” (the support version of an email template), along with automatically updating certain statuses and tagging with 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.
For example, if 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 thirty 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.
Ticket Tagging/Product Feedback
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. That is, the information contained in support request 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.
So if 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.
Other Inbound Support Tools
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
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 me.”
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 chart 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.
Social Support
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 “hard” (that is, requiring users to fill out lots of fields in a complicated support request form) may bite you in the ass. Your customer may just decide to open a new browser tab and dash off 140 characters of pissed-off 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. 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@yourdomain.com> address so you can fix their issue.
Of course, social 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
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.
Proactive Customer Monitoring
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 and 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.
Inspection
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.
Custom Reporting
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. On TalentBin, for example, 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.
Dedicated Tooling
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.
Acting on Data
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. That is, 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, 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!
Success Outcome Capture
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.
In product
If you can design your product in a way that captures outcome value, all the better. For instance, in TalentBin, there was 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. If you were Textio, for example, 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.
Survey/Conversation
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” are net promotion scoring survey software like AskNicely, Delighted, and so on. Surveys can be implemented to automatically send at certain times (i.e., 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?”
Quarterly Business Reviews
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 (that is, 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?
If 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. 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. That is, 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!
Participants
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, however 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.
Tooling and Approach
As with many of these things, a nice slide deck template that outlines the information you want to transmit is a great start. This is an example of a QBR deck for a solution provider that 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: “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. That is, say only five recruiters are using your fancy software, and you can show that they’ve saved fifty hours per recruiter per month over the previous quarter, aligning to $30,000 in saved salary expense. Well, if you know there are twenty other recruiters in the account, they’re clearly wasting $120,000 in salary expense across the rest of the recruiting team for each quarter those others aren’t users. What are we waiting for?!
This is a slide that focuses on how much key performance indicators have improved as a result of implementing a solution.
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. So 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.
Outcomes and Next Actions
Coming out of the QBR, guess what: you need to implement those next actions. So whatever the plan of action, you should 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.
Reporting on QBRs
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 sixty days that you need to schedule and prepare materials for.
Support Sites & Asynchronous Support Materials
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.
Most support software also provides functionality that allows users to search across the support articles, or suggests support articles that match the initial input a user puts into a form. Lastly, they provide analytics on these documents to show how frequently users are reading them, which helps you understand the benefits they’re providing, and also where there might be confusion about the product.
As you build your support site, you can definitely start basic and work your way up. Support materials have a tendency to accrete over time, and that’s a good thing. To start, one valuable item to house on your support site is a fully recorded kickoff call—Camtasia and ScreenFlow are great tools for this—to which customers can refer if they get confused later. Even better is a kickoff call that is broken into its constituent parts, like “This section is how we set up our account” and “This section is where we learn how to use basic search” and “This section is where we learn how to use advanced search” and so on.
Like with your sales deck slides, you can think of this sort of materials as “object oriented” instead of monolithic. Take that same work you did to record the entire implementation video and slice it up into individual snippets that address key parts of using the product. Each of these can later be used to create a specific support article that is focused on that topic.
Another great thing to house in a support site are new product announcements. Frequently the marketing and sales org will make video, screenshot, and text materials to explain new features when they’re launched. These can easily be repurposed in a pinch as support materials (though typically your marketing demo videos will be more focus on benefits and value than “how to” use the features). But until you have the time to make support-specific versions that are more detailed in nature, by all means, use what you have! Either way, a dedicated support article that documents the goals of a new feature and how to use it can be a great resource to email to your existing users, and for merchandising in the product if you have a means by which to do so.
Beyond core workflows and new features, it can be hard to know when to spin up a support article. On the one hand, they can be really helpful in reducing time spent answering support queries. On the other hand, they can be time consuming to produce, so you don’t want to go off the deep end creating one for every edge case. The rule of thumb I like to use is similar to the one I mentioned in the Sales Materials chapter for creating appendix slides for your sales deck: if a question comes up more than once, it’s probably worth the time to spin up a support note addressing it and a macro to answer the question.
It might seem like a pain to take an hour out of your day, but if you’re using good support software, you’ll create all sorts of great benefits. First, you’ll make it possible for users to self-serve support on yet another topic. Beyond that, for the queries that still make it into your support queue, support software will often recommend the right article and macro to use—you’ll be setting future you up for success, because your past hard work will be resurfaced to you magically. And you’ll be well set up for when you start hiring support personnel to help out too. Lastly, you’ll have that nice note available to shoot over to the customer rather than having to re-type it again and again.
One note on notes (heh). While many of the benefits of support notes flow from time efficiency, you don’t want to lose the opportunity to make a customer feel loved. So when responding to inquiries with a support note, first make it clear that you have a hunch that this support note will answer their question. (I like to bake this caveat into the macro text so I’m less likely to forget it.) Moreover, make sure to articulate that you’re simply sending the note in the interest of perhaps expediting the solution for them and that if they would prefer to get on the phone to address things in more detail, that of course you’d be happy to do that.
What do you don’t want—especially early on—is a situation where a fantastic, high-satisfaction interaction with a customer is spoiled by them thinking that you’re just trying to get rid of them. There will be many customers who are ecstatic to get that well-documented support note, and use it to solve their problem. They likely have a busy schedule, and the notion of trying to calendar something with you seems not so exciting to them. However there will be a class of customer (the same one who might use your inbound phone line!) who really wants to talk to a human. If it looks like you’re stiff-arming them with a macro and support note, with no offer to talk live, they’re not going to be happy campers.
New Release Communications/Ongoing Training
It sounds obvious, but one of the biggest missed opportunities in early-stage customer success is insufficient investment in the documentation, announcement, and adoption of new features. In early-stage software, the reality is that you’re likely iterating your product pretty substantially as you go, adding new features and extending existing ones. The funny thing is that while new features get incorporated fairly regularly into prospect-facing materials—like demos, slide decks, and so on—folks forget about the customers who have already bought a version of the product that didn’t yet have these magical enhancements.
That’s a problem. If your customers are not being kept up to date on your advancements, but are being wooed with the latest and greatest versions of your competitors products, you’re missing out. And if your evolved features are addressing pain points that were surfaced via support channels, well, all your customers likely have those pain points. If you aren’t communicating that they’ve been solved, they’re likely still being frustrated by them. Further, while customers primarily buy your solution, as is, to solve an immediate problem, there’s a part of them that is “buying the company.” That is, they’re also buying into the belief that you will continue to get better at solving this problem for them, with better and better technology. If you are indeed iterating your product and shipping new features, you need to show it to your customers and get credit for that momentum. You want them to say to themselves, “You know, it was a really great idea that I bet on these guys. They’re always coming out with great new things for us.” Lastly, appropriate communication of new features and functionality is a fantastic way to reengage disengaged customers who are at risk of churning.
Materials
What materials should you use for this? Well, as noted above, creating a support site note as part of your release process will help ensure that you at least have the key information readily available: what the goal of the feature is, why it’s helpful, and how to use it. This is a pretty good example of a TalentBin new feature support note:
Recording a lightweight demo video to show this off in a visual fashion is also good. This is an animated gif that demonstrates the “automatic personalization” referred to in that support note:
Of course, having this information available is great, but merchandising it solely on the support site isn’t nearly as good as bringing it to your user—in the product, in their inbox, and on your various other properties. Use your support note and associated screenshots and videos in customer-facing emails, or even “webinars,” about the new features. (If you record those webinars, you now have yet another great support asset.) You can also merchandise announcements in your product using “new feature announcement banners” that can be dismissed. Some support solutions like Intercom include banners or fly-ins as part of their customer communication features.
Finally, once you’ve taken the time to create new-feature notes and announcements, get as much mileage as you can out of them. Even after the initial announcement period, this sort of material can be used for email campaigns to introduce users to features over the first few months of their onboarding.
Recipients
You might think that you should only be sharing this information with your users. On the contrary, you want to share new features with anyone in your accounts who has a stake in the successful deployment of your solution. So while non-user decision-makers likely won’t need a demo, you definitely want to have them on the distribution list for these email announcements. You want them to be glad that they made the decision to buy your solution. And if you are doing a good job staying top of mind—with a drumbeat of ongoing releases and customer success support—that can be a great source of upsell opportunities.
Be mindful of adding those users and their email addresses to your CRM in such a way that you can easily execute these communications. Extra credit if you have various stakeholders modeled in a way that allows you to execute different reporting for different communications. For instance, do you want to execute a webinar on ROI calculation for your solution, which would be appropriate for decision-makers but not for end users? Well, having a “type” field in your CRM that can be set to “User” or “Manager” can help you with that.
Implementation and Monitoring
Communication of a new feature isn’t where responsibility ends, though. As noted above, customers have to actually adopt those new features to get value from your ongoing product improvement. So what does this mean? Well, often you’ll have new features that require substantial implementation effort.
Take TalentBin’s “automated follow-up campaigns” feature. At one point, TalentBin shipped the ability for recruiters to automatically send follow-up emails to candidates that they discovered in the TalentBin database—“drip marketing” functionality that substantially raises response rates from candidates. To make it easier for recruiters to adopt this feature, we actually provided a bunch of “canned” campaign email templates on various topics that would be relevant to candidates. Still, a number of these templates needed customization to be specific to the customer before they could be truly useable. Which is why, when we released the new feature, the TalentBin customer success team went through their assigned accounts and engaged the relevant stakeholders to get on a “new implementation call.” That way, we could walk them through the new feature, and get those templates customized so they would be ready for use. It was worth the time investment, because customers using campaigns would get much more value out of the solution than those just sending “one and done” emails. Of course, as soon as the feature went live, it became part of our onboarding training—but we had to loop back to hundreds of existing customers to make sure that they could access the new functionality in an impactful fashion too.
Renewals
It bears repeating: the goal of customer success is to ensure that customers get the value they were promised when purchasing, so they will continue to be customers. In a SaaS world, if they don’t get value, they won’t renew. Everything we’ve covered has been in support of that goal. So by the time a year has passed (the typical length of a SaaS contract), it should be just an absolute no-brainer for the customer to renew. After all, you’ve done such a good job helping them capture tons of business value from your solution, in a way that was fully documented. So first things first: to ensure renewals, make sure that folks get to value.
But even if you’ve done all those things right, you still need to capitalize on it by executing a good renewal process. These are some ways to do that.
Automatic Renewals
First, in your order form and master service agreement, you should have an automatic renewal clause. Customers may seek to negotiate it out, but most will never consider it, and this way, your solution just default renews. When the time to renew comes around, you just run the credit card on file using something like Recurly, Zuora, or Aria Systems. With automatic renewals, it can also be nice to provide a courtesy email note a month or so out. This doesn’t mean that you can skimp on getting customers to success, but it can help in some edge-case scenarios where implementations have taken far longer than they should, stakeholders have left a company (resulting in a new “sales” cycle simply to get adoption of what has already been paid for), and so on. Further, automatic renewal at existing pricing can be a boon to a customer if you raise your pricing as you add new functionality and the product gets more robust.
Renewal Calls
If you don’t have automatic renewals, then you’ll have to have whoever is in charge of your renewals process—either you as a founder when you’re small, or a Customer Success Manager or Account Manager when you’re bigger—execute a renewal call. This is very similar to the quarterly business reviews that we discussed earlier in this chapter, where the goal is to summarize success to date as compared to promised goals, and to discuss customer business goals for the period ahead. But in this case, the goal is to summarize the customer’s success across the entire term, and to discuss of organizational goals for the year ahead—a sort of “jumbo QBR.”
Timing
Renewal calls should be close enough to renewal that you can immediately send a renewal contract to be signed, but far enough out that if there seems to be a snag, there’s enough time to help remediate and get to a renewal. If your final QBR is three months from the end of the contract, then a renewal call six weeks from the end of the term can be a good compromise. Calendar that renewal call as soon as the final QBR is executed.
If you’re doing a good job in your QBRs, by that second-to-last QBR, you should have a sense if the account is going to renew; if it looks like there are issues, start a plan to fix that as soon as possible. However, if for whatever reason you get to your renewal call only to find out that there are showstoppers, there’s always the option of adding some more time to the end of the contract to resolve those issues. This is to say, you can often extend a contract a month or two without requiring payment in order to resolve those issues.
Materials and Prep
As with QBRs, come to the renewal call prepared with all the success metrics that the account has accrued over the contract term; you’ll want to have all the proof necessary to show that they have gotten value for their investment. All the success metrics that your CS staff has been counting up and logging in the CRM? Those should be brought to the fore for the call, in what amounts to a “grand finale” QBR deck.
Closing and Upselling
As with pitching itself, it’s important during the renewals process to actually ask for the business, again. Even if you have an auto-renew clause in your agreement, you want to validate that the customer is indeed bought into a renewal. In that scenario, that might sound something like “Fantastic. Well, I’m glad that we got to review all of this and that we’re helping you <business goal your solution solves>. Your contract will be renewing on <date> and we’re looking forward to working together in the year ahead.”
Part of the renewal call discussion should be focused on the business goals of the customer organization for the year ahead, and that’s where potential opportunities for upsell can be unearthed. Are they planning on hiring thirty more salespeople, each of whom could potentially be a user of your product? Now is the time to discuss whether it would make sense for them to buy those additional seats now so they can get a volume discount, rather than adding them one at a time over the year.
Learning From Your Customer Success Team
While all of the above activities are key to getting customers to success, and eventually renewing their contracts, an effective customer success function can and should play a larger role in your organization. That is, because it’s uniquely positioned to have meaningful, ongoing interactions with your customers, customer success can often pass on a wealth of information to sales and marketing, product development, and other key functions.
Product Development
An outcome of all of your customer success activities—rigorous onboarding, inbound support request capture, and proactive monitoring—will be a wealth of information on what customers like about the product, and what they don’t. Customer success uses this information to resolve issues and enable success, but it’s also important to feed this intelligence back to the product development organization. If certain features are hard to use, and create a large amount of inbound support requests, product and engineering can prioritize refactoring those features. That will in turn not only reduce the support resources needed to paper over that issue, but will ideally enable more success, creating happier customers who are less likely to churn (and more likely to generate positive word of mouth).
Sales
Your customer success team will also be the first people to know that a user or decision-maker is departing from one organization to join another. This is a prime opportunity to follow them to the next company as well, as typically the settling-in period in a new role is accompanied by setting up new tooling. Handing this information off to sales to execute on in a timely fashion is paramount.
Customer success can also be extremely helpful in surfacing customers willing to do customer reference calls with prospects. Connecting prospects with customers who are rabid fans due to their success is a great way to get deals across the line, and your customer success staff can help you achieve that.
Marketing & PR
As your company matures, your pitch should too. That is, you no longer have to speak about hypothetical success—now you can point to real-world examples of how your solution is changing how your users do business. Customer success plays a key role in finding valuable usage data and product evangelists and passing that information back into your marketing and media outreach.
Success Proof
Earlier in the chapter, we talked about the importance of capturing successful outcomes in your CRM so you can report that information back to the client. Equally important, though, is having the ability to report those outcomes across all users, or particular subsets of accounts. As customers reach their goals, customer success can harvest this information and provide it to marketing for use in “proof of success” collateral like slides, videos, and so on, as discussed in the Sales Materials chapter.
Events/Customer Advisory
Customer success will be best positioned to identify cheerleaders and advocates who can be helpful in the context of conferences, speaking opportunities, and customer feedback on new product.
If customer success is going to help all these other parts of the organization, the first step is to make them aware that these are activities that they should be engaging in. The second, more advanced, step, especially as you start establishing a specialized customer success function, is to provide compensation inducements to them. For instance, offer a $50 bonus for each upsell or new opportunity (again, contingent on the size of your typical deals) identified by customer success that ends up getting sold.
Customer Success Calendar Management & Specialization
As discussed in the previous chapter, as you start to have more responsibilities that occupy your time—but before you bring on staff to hand those off to—you’ll have to be mindful of splitting your calendar to achieve them.
Previously, you had to find time for prospecting, initial pitches, and down-funnel follow-up meetings; now, you’re adding implementation meetings, monitoring success KPIs, QBRs, and renewals! It’s a lot, so it’s vital that you be vigilant about blocking segments of time on your calendar, or those activities won’t get done.
The first step is to make sure that meetings for customer success activities—implementation calls, kickoffs, check-ins, and QBRs—get on the calendar as soon as deals are closed, so your future time is “burdened” appropriately. The second step is to start tracking these activities in your CRM. The same way you may have a “Demo” event activity or “Follow Up” meeting activity, you should track “Implementation Meetings” and “QBRs” such that, with a simple report, you can see, for example, all accounts that have a Closed Won opportunity but have not yet had an implementation meeting.
After you have onboarded a dozen or so customers (depending on the size of your deals), you should start to think about how you could hire someone to take this responsibility off of your plate. Importantly, because of your experience onboarding, getting to success, and doing QBRs for that initial set of customers, you should have the beginnings of a customer success “playbook.” Codify it in documentation and process (again, to be tracked in the CRM), such that you can hire that first CS specialist, get him to success, and then start the process of stamping out more of him.
When you get to the point where you are adding a substantial number of customer success staff, you’ll want to be clear about who is responsible for what to get the most out of your investment.
Responsibility Specialization and Compensation
The compensation of customer success staff is heavily influenced by the responsibilities they bear. Firstly, as an aside, as of the mid-late 2010s, the compensation models of customer success staff have not yet seemed to wake up to the realities of the importance of customer success in a “renewals world.” That is to say, if you refer to the revenue growth chart in the introduction of this chapter, and look at the scenarios with differing churn numbers, you can see the deep importance of customer success. That should be reflected in the level of talent you are willing to pay for, and the compensation requirements that flow from that. Historically organizations have viewed support and customer success as a cost center to be minimized, rather than considering the opportunity cost of under investment in the function: higher churn rates, lower lifetime customer value, and reduced opportunities for upsell and positive word of mouth.
That said, one of the most important determinants of how you compensate your customer success staff is their commercial responsibility, or its absence. That is, will your customer success staff be responsible for renewals? Or will an “account management” staff or even the primary account executive staff be responsible for these? Generally, focusing account executives on new business is the right approach; focusing efforts and not splitting attention is typically the best way to assure that things are done right. AEs that are “responsible” for renewals often follow the same pattern, showing back up to an opportunity 60 days from renewal—270+ days from the last time they exchanged emails with the client. Approaching a client with the attitude of “OK, so catch me up!” is not a recipe for a functional success and renewal motion. The best organizations specialize this responsibility.
Who, then, should be responsible for renewals? There are typically two approaches. Customer Success staff can be responsible for renewals; you might even base part of their compensation, in a variable fashion, on renewals and upsells. The other approach is one wherein responsibilities are split, and Customer Success is responsible purely for “success” activities, like implementations, ongoing support, quarterly business reviews, and so on, but another “commercial account manager” is responsible for seeking out upsell opportunities and ultimately renewing the business. This latter approach offers the benefit of specialization and eliminates the concern (oft stated but dubious, in my opinion) that success staff can’t “close.”
My take on this is that early on, when there are fewer customers, that level of specialization creates unnecessary overhead. That is, creating specialization between Account Executives who are hunting new business and Success and Account Management staff who are “farming” existing business certainly makes sense—the behaviors and operational tempo of a new-business hunter are very, very different than those of an existing-business farmer. But at the very early stage, specialization between Customer Success staff and Account Management staff creates more complexity and overhead than benefit. Having a class of customer success person that’s responsible for the implementation, ongoing support, quarterly business reviewing, and eventual renewing of customers seems to be the best balance. You get both specialization and the “close to the metal” benefit of a rep who’s deeply familiar with the 100, 200, 300 accounts that he is responsible for.
Later Specialization
Later, as your customer base grows into the hundreds or thousands, more substantial specialization of success and support roles may make sense. For example, you might split out inbound response support versus implementation versus ongoing “success” versus account management and renewals. The benefit of this is that you can get efficiencies of specialization and scale. You can provide a better level of service to folks who are chatting on your support chat widget or sending in tickets if people are staffed purely to deal with those; otherwise, they’ll be left waiting until a customer success manager gets off an implementation call and can turn her attention to tickets. Or you can have more senior, more skilled, and thus more expensive customer success staff focused purely on implementation, quarterly business reviews, and project management of success activities, while more junior (and less expensive) staff focus on first-line ticket response—not dissimilar from the specialization of SDRs and AEs in a pre-sales environment.
Regardless of how deep you get into customer success in your company’s earliest days, the most important thing is to think about it at all. The biggest error founders and other first-time revenue leaders make, aside from the inability to sell at all, is insufficiently investing in the success of customers once they have been sold.
If at very minimum you have a success mindset, and choose from the approaches above, you will already be far ahead of the game.