editione1.0.1
Updated August 22, 2022You’re reading an excerpt of Founding Sales: The Early-Stage Go-To-Market Handbook, a book by Pete Kazanjy. The most in-depth, tactical handbook ever written for early-stage B2B sales, it distills early sales first principles and teaches the skills required, from being a founder selling to being an early salesperson and a sales leader. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, commentary and future updates, and a high-quality PDF download.
The broad bucket of implementation is the set of steps that you take after a customer has signed to get them quickly up and running, and can include technical implementation steps, user training, and more. Depending on the complexity of your solution, this could be as simple as a 30-minute call and guided tour, or as complicated as a multi-month, full-blown professional services engagement. In either case, though, implementation is the first step on the road to customer success, without which you’re putting yourself at a substantial disadvantage. Invest in it accordingly.
The goal of implementation is to execute all the preconditions needed for your customer to have success with your solution. So the first step is to understand what those first steps are. This ranges from the completely mundane, like securing credentials for a user, to the more involved, like integrating with existing systems, migrating data over from legacy systems that your solution is complementing or supplanting, and so on. It also includes user training for all archetypes of users: individual contributors, managers, and beyond.
exampleFor a company like Textio, makers of job posting optimization software, implementation would start with securing credentials for all the recruiters who would be using the solution. Next, they’d hold training sessions with those users to understand how best to use the system, and with their management to help them understand that the system is being properly used and creating the promised value for the organization. And it would keep going all the way to securing proper integration with the customer’s existing applicant tracking system to ensure that Textio could start learning from the organization’s prior job postings (and the applicants and eventual hires that came from them).
importantOnce you understand how many of these steps need to be taken, and have a sense of how much time that should take, you’ll start to see how involved this might be. This will indicate whether your implementation process can be as simple as a one-and-done call and screen share with the primary user of your product (or even a self-guided onboarding tour, for extremely inexpensive, uncomplicated solutions), or if it will require a series of meetings with various stakeholders, project managed to completion.
There isn’t a single correct answer. It’s simply a question of making sure that you are doing all the things needed to get your customers to success, and not stopping short. So if that means it will be a multi-person project that spans several weeks, that’s fine. Just set that expectation during the sales process and, importantly, make sure that your pricing can support this level of engagement in the long run. If implementation takes 120 minutes all-in per customer, and a customer success rep who costs ~$50K a year can do 15 a week, that’s ~$70 of implementation labor cost right there. If your product costs ~$20 a month, that math doesn’t work. Either your product will have to cost more or you’ll have to think about how you can use cheaper, non-labor-intensive resources (for example, in-product tools, documentation, and so on) to reduce that implementation cost. For our purposes, we’re going to assume we’re dealing with a fairly costly product, around ~$1K+ per user per year.
For reasons touched on above, early in your go-to-market, it’s fine to over-invest your personal time resources to ensure that your first customers get to success. But in the back of your head, be thinking about the salaries you will eventually need to pay your dedicated customer success staff, which will have to come out of licensing revenue. Make sure that what you charge can support that customer success burden. Moreover, if implementation is particularly beefy for your solution, consider charging a one-time implementation fee to account for that. (A good rule of thumb is to triple the labor costs associated with the implementation process—so if it takes a week of employee hours, costing you ~$1K, you might charge ~$3K.) With most SaaS products, though, by virtue of their “flip the switch” nature, implementation doesn’t require that kind of heavyweight involvement. But your mileage may vary.
If your solution is straightforward enough that you can thoroughly cover implementation in a 60-minute meeting or less, then that’s a tried-and-true approach. It’s a nice block of time in which you can hold the customer’s attention and walk through a checklist of things to take care of, concepts to explain, and actions to take.
Early on in your go-to-market, on-site implementation can be a good approach. I suggested selling locally to start so I could go on-site to present and demo without getting in a plane; now you can do the same with implementation, ensuring rich communication and getting your customer bought-in. Face-to-face time is so important early in your company’s life (and it never hurts to bring cookies and your latest logo schwag to set a friendly tone). Eventually, though, holding these meetings by phone and screen share will be the more scalable way to do this.
Your implementation meetings should be run from your sales presentations. You’ll need to do pre-call planning, where you review your CRM for information from whoever sold the deal (early on, likely you) about who the user(s) will be, who the decision-maker and other stakeholders are (if they are different from the users), and what the business rationale for the purchase was.
Beyond simple pre-call planning, if there are specific pre-work actions that need to be handled to make your face-to-face time more efficient—like securing user credentials, loading the client’s logo into the UI of their instance of your product, or what have you—do that too. And make sure you’re familiarizing yourself with the parts of their business that your solution helps, and the specific user or stakeholder you’ll be working with, using available resources like LinkedIn, their career site, or whatever else.
exampleAt TalentBin, our planning included reviewing the customer’s careers page to see what sort of technical roles we would be setting up searches and folders for during the implementation call. We would also check out the LinkedIn profile of the user we’d be implementing to see if they were a technical recruiter, a generalist recruiter, or maybe concerningly, an engineering leader or HR generalist (which would require that we delve into recruiting actions and best practices, not just new software tools). Just as with a sales pitch, you want this information in your back pocket so you aren’t blindsided and are best set up for success.
Just as you start your sales presentations with discovery, you should typically start your implementation calls (and kickoff calls, for more involved implementation projects) with rediscovery. State what you believe the customer’s business goals are and how the solution is going to be used to achieve them. At TalentBin, this might have been something like, “It’s my understanding that you’re going to be hiring a dozen software engineers over the coming year, mixed between Ruby developers and some front-end specialists. And to help with that, you bought this TalentBin seat. Is that right?” You want an affirmative statement of what your agenda is for the coming twelve months (or whatever the term of the contract is), so you know that you’re on the same page and can start working together toward these goals.
And if there is some sort of slippage between what the customer’s goals or beliefs are, and what you thought their goals had been, fantastic—now you know that and can course correct, rather than charging through an implementation call that drives toward the wrong goals. Or if, for whatever reason, they purchased the solution to solve problems that it doesn’t solve (yikes! How the hell did this deal get sold?), you can quickly act to correct there too. Whatever goals you agree to during this rediscovery, make sure that you are documenting them in your CRM. Or, at very least, make sure that you memorialize them in a follow-up email to the user and stakeholders after the call, so it’s there to refer to if there is confusion down the road.
As you think about the agenda for your implementation calls, begin prioritizing the points you’ll cover, from those that are crucial to success to other important items, with optional topics last. Things that absolutely must be covered might include ensuring that the user can actually access and log in to your solution (I know, you’d be shocked), that they have the relevant software downloaded onto their computer, that your solution is obviously bookmarked in their browser or shortcutted on their desktop or dock (you want to make it very easy for them to get back to your solution), or that any relevant data feeds are set up.
If your solution requires a user to OAUTH into their email or another system, it’s critical to walk your new customer through that process first and foremost. If you train them on everything else but that action can’t be completed, what was the point? If setting these data feeds or authentications can end up being fiddly or time consuming, it may make sense to have an initial setup call before the longer, more formal training call. That way, you can put all those setup items to bed and deal with any tripwires that come up, and you’ll still have the full time allocated to the implementation call to tackle training and higher-value work.
Having covered setup items, you need to next focus on the core actions that are taken in your solution. A brief refresher (perhaps with a couple slides) may be appropriate here to set the context of the training. If you end up selling to larger organizations where the user hasn’t seen the solution before (ideally, less the case when you’re selling to “deer”-sized, mid-market, not-too-small, not-too-large, accounts to start, but not uncommon), you’ll also need to sell the users on why they should be excited about the solution. (Use the same rationales discussed in Sales Pitches for Startup Founders: it’s going to make their jobs easier, make them smarter and better at their work, and potentially get them a better job in the future!)
During implementation, to whatever extent possible, have the user execute actions and, ideally, do actual, productive work. Often implementation staff will just flip on their screen share and do a show-and-tell. This is inadvisable, in that your user will not be engaged and will quickly whip out their iPhone to see the latest on Instagram. If you can, use a screen-share solution that allows the users to share their screens. If it allows you to use some sort of pointer or cursor to show them where to click, even better—do that. You want them to be mousing and typing and doing things, with your coaching. Things like join.me or Zoom, or heavier-weight solutions like GoToMeeting or WebEx, can be good here.
exampleA typical TalentBin implementation call included setting up a job requisition project folder, setting up and saving a search, demonstrating how to view and dismiss profiles, reaching out to viable candidates, and dropping those candidates into a drip-recruiting marketing campaign. At the end of the call, the user had ideally executed outreach, put a handful of candidates in drip campaigns, and maybe even gotten a response from a candidate, or at the very least an email open notification.
Talk about a great outcome from an implementation call: a user who is fully set up, has executed and familiarized herself with the business motions necessary for success, and has actually done some work that can provide the promised ROI. That’s the ideal.
If you’re wondering what these steps might be for your solution, think back to your demo script. You set it up to rehearse the most important, valuable elements of your solution for your prospect, and to do so in a logical, progressive fashion. Your implementation process likely should align with that. It’s kind of like a demo, but one where the user is doing the driving.
When it comes to implementation calls, you’ll often be tempted to do group calls. If there are going to be a dozen users of your software, you might think, “Well, I can do this once, get them all with one call, and move on to the next. Efficient!” This can be really dangerous, especially early on in your go-to-market.
Group implementation calls suffer from the same issue that group sales demos suffer from: lack of accountability. Everyone thinks that someone else is responsible for paying attention, so no one does. Even if you’ve instructed everyone to follow along with your screen share and do the work on their side, you can’t tell if they’re actually doing it. Not to mention that you now have, say, five folks who can potentially trip up and need to ask a question, slowing down everyone else. The result is typically an uncontrolled call that fails to achieve your objectives. Worse yet, now you have five half-trained, half-implemented users who are responsible for that account’s success with your solution. Remember that churn thing we were talking about? You now have five churn time bombs. Again, your ability to conduct one-on-one implementation may be constrained by what you can charge for your product. But if each of those users represents ~$1K of revenue (multiplied by many years of renewals), then you shouldn’t be skimping. Especially at the beginning.
Oddly, you may run into managers who want you to do a group training, thinking that it’s somehow more efficient for their team. You can feel empowered to push back against this—if it’s an hour per user separately, or an hour with them all on a call together, it’s still an hour of each user’s time. It’s actually your time that’s being expended to a greater degree. Just explain why the way you do it drives success. Help them understand that more value is provided through separate calls, and that they’ll look like heroes for allowing it. And remember, if you acquiesce, you’re setting up more churn time bombs for yourself to deal with later.
When you conclude your implementation, you want to be sure that a summer break mindset doesn’t set in for your users. Don’t let them feel like students sprinting out of class on the last day of the school year, looking forward to a couple months before they have to think about school again!
A great way to avoid this sort of thing is to set a back-check meeting for a couple weeks out. Then, assign some specific homework to be executed in the interim, which the users know you will review by monitoring their usage. One of the beauties of SaaS software is that you have insight into the actions that users are taking or not taking. Make it clear that you will keep an eye on that information to make sure that users are having success, to jump in if there appear to be problems, and to report to deal sponsors (like their boss!) that the promised ROI is being achieved. We’ll touch on monitoring more later, but even just talking about it from the outset can help create a usage tailwind.
Ideally this monitored homework assignment should require very distinct, measurable actions—for instance, doing X specific action Y times by the end of the first week. Be clear that users who do this homework have X% more success than folks who don’t, which is why it’s assigned.
exampleTake Teamable, makers of clever referral recruiting software that helps recruiters mine their internal networks for potential fits for open roles. Say they spent their implementation call demonstrating how a recruiter should process referral candidates for a single internal staff member. The homework goal might be to reach out to ten referral candidates of ten internal staff in the first week, for a total of a hundred potential candidates, and to get ten interested responses. This is eminently achievable, and a mild scale-up of what was done in the implementation call, all focused on driving demonstrable ROI as quickly as possible.
As with down-funnel sales work, don’t end the implementation call until that next meeting is actually on the calendar and you’ve sent the meeting invite for it. When it comes to scheduling a follow-up meeting, it can be just as time consuming to chase down a customer as a prospect. Avoid being in that situation!
Before concluding the meeting, verify that the user knows how to get in touch with you if he has an issue. More on this in a bit, but making sure that there is an easy way to get in contact with Support (which might be you right now), both in the product and via email, is key. If you are able to record your onboarding call and provide it after the fact, this can be a helpful reference for the user (and a “tale of the tape” to go back to, if there are any issues in the future). You can share the script or checklist that was used too. If the customer is trying to remember that one really neat thing that you showed them, then with those materials, they can easily access it.
If meetings are missed, you should push hard to reschedule them, to ensure that implementation is happening the way that will enable success. Make sure that you have tracking in place to know which users and accounts have had their implementations, which need to, and which need to be rescheduled. Again, you don’t want to plant churn time bombs to be discovered at a later juncture.
That said, a video-recorded, canonical implementation call can be a helpful piece of collateral for someone who needs a refresher (again, better if you record their actual call for them to refer to) or for someone who would like to see what a call looks like.
Occasionally you may find that users need to be “re-implemented” in some regard, because they’ve either gotten out of the habit of using your solution or need a refresher. Or the original user of your product may leave the org, meaning that you need to onboard her replacement. In addition to preserving that customer’s implementation recording, having weekly group implementations for this purpose can be helpful. If it costs ~$70 in labor to execute an implementation, and a user needs one or more refreshers per year, now multiply this by dozens of customers, and that could add up if done individually on an ad-hoc basis. For users who’ve already had an initial implementation, a standing group call can be a great way of accommodating the five, ten, or more users, across customers, that might need some help in a given week. Early on, though, you probably want to overinvest in going the extra mile to make sure that people are successful. So if someone needs to be re-implemented, by all means, get it on the calendar and do it, whether it’s an individual user or, even more importantly, a decision-maker or manager who is responsible for the people using the system.
If your solution is more complex, and requires the involvement of different parties, you may not be able to take a one-and-done approach. This is fine, and shouldn’t be avoided. Just be sure that your pricing supports more involved training. Multistage implementations can actually be a good thing—the more effort it takes to get something up and running, the less likely someone is to rip it out down the road. So getting good at these implementation processes can be a substantial competitive advantage for you.
When approaching a more complex implementation, think of it as akin to a multistage sales process, not unlike the one you probably went through to get the initial contract executed. Calendar the meetings, and use the same micro-contract approach to ensure that you have commitment for the next step at each stage of the process.
When your implementation involves multiple steps, it’s often good to have a kickoff call with all of the relevant stakeholders and participants, where you can review timelines and what is needed from each participant and get collective commitment in front of all of the other stakeholders.
importantThese calls should involve the sponsor or sponsors of the project, and any internal vendors whose help will be required to get everything up and running. Make sure that those folks are identified and commit to attend the call. During the meeting, as with one-and-done implementation calls, make sure to restate the customer’s goal for the solution and walk stakeholders through what they need to do to get there, along with the ideal timeline.
Having visuals for this meeting can be really helpful. This could be a slide that demonstrates the major steps, and timeline, for implementation (which you might have already created for your sales presentation). Or it could be a live, shared Google Sheet, with line items for each deliverable or action, their customer-side owner, a targeted date associated with it, and the relevant status of that item (To Be Done, Scheduled, In Progress, Completed, Hung, or what have you).
Source: Teamable
One favorite approach is having a templated Google spreadsheet from which you can create a copy for each customer. Ahead of your kickoff, identify, with the help of your deal sponsor, the various customer-side stakeholders for each item (for example, “This is the CMO. She owns this, this, and this. This is the VP of IT. He owns this, this, and this.”). I threw together an example, patterned after some spreadsheets I’ve seen.
A live status spreadsheet like that can later serve as a source of truth as you progress through the various steps. Introducing it at the start sets the expectation that you’ll be marching down that project plan, and that everyone will have access to it to see what’s being accomplished (or not, if things go sideways). There are fancier professional services project-tracking tools that provide this functionality, but to start, a simple shared Google spreadsheet is probably good enough.
Once you have all those stakeholders identified, it’s time to execute the various steps you’ve listed. As they are completed to satisfaction, mark them as completed in your implementation project plan.
Status reporting can end up being a substantial amount of overhead, which is why it can be so valuable to streamline things with a shared spreadsheet and a dedicated implementation thread via email. As important items are checked off, you can update the spreadsheet, and then link to it in an email notification to the group thread. This gives stakeholders a reassuring sense of forward momentum that their project is progressing and further establishes your credibility. It also creates a way that customers can get status updates whenever they would like, even between weekly status emails.
Your granular project tracking will likely be executed in a project spreadsheet to start, but as you acquire more customers, and as you have multiple implementations in progress, you’ll want to think about moving this to your CRM. The problem with keeping status information in different spreadsheets is that it’s difficult to query across multiple documents to see the aggregate implementation status of your customers. The right way of dealing with this is to track this information in your CRM.
This could be as simple as a post-sales status field on the relevant opportunity in your CRM correlated with different meaningful implementation stages. Or if you want to get fancier, it could be distinct activity items that need to be retired, each associated with the closed opportunity. However you approach it, the important thing is the ability to say to your CRM (or substitute system) something like “Show me all the opportunities that are closed-won, but in various states of completion.” For example “Show me all the opportunities that have close dates in the last fourteen days, but which haven’t yet had their initial kickoff call.” That way, you can see if any accounts are in some sort of red-flag situation.
importantTo the extent that you can do the work for the customer, do it. And to the extent that you can make things as simple as possible when you can’t do the work yourself, do that too.
exampleOutreach.io has an excellent implementation process. They sell a sales email and calling automation solution, so it’s critical that they connect their software to the customer’s Salesforce instance. In fact, this is so important that they build in a specific call with an approved Salesforce admin on the customer side to get that set up. It’s a 15-minute call if all goes according to plan (and sometimes it doesn’t), but it’s so important to the rest of implementation that they make sure to get that executed first and foremost. And they do so by using screen-sharing software so the implementation specialist can take control of the customer’s mouse if the customer is OK with that, just to make it as easy as possible.
Consider how proactivity like this could be used in your implementation process to make sure that the things that need to get done, get done.
importantBe mindful of snags in your implementation process. If something falls off the calendar, always get it back on. This becomes all the more important with a multi-step implementation, as there are more opportunities for those failures to occur.
If a further meeting falls off the calendar, reschedule it. If, for whatever reason, there are multiple failures, then be clear about the implications of this to the customer-side party who is precipitating the issue. Something along the lines of, “The reason we need to have this call is because I need fifteen minutes with you to XYZ. That is important because it’s required for the next step of our implementation, which overarching stakeholder name was hoping to get completed by date. What can I do to help get this completed so we can attain that goal?”
cautionIf for whatever reason you keep being stonewalled by an ancillary stakeholder, be careful about running back to your sponsor to tattle. Implementation projects are like multi-stakeholder sales, but after the sale has already taken place. You don’t want to be seen as going around tweaking noses, even if you have the imprimatur of the CMO, CIO, or whomever. Your goal should simply be to act as the agent of your deal sponsor, doing your best to advance the goals of the project and diligently documenting those efforts in the form of well-written emails, meeting invites, and status update emails, along with a tracking spreadsheet. You never know when that person you’re working with to execute an implementation action, post-sale, can end up at another organization and have something nasty to say about your solution while it’s being considered for purchase.
When you’ve completed all the relevant steps of implementation, and the solution is largely operational, memorialize that to your various deal sponsors so they know that it’s time to start expecting to see the return on their investment. For example, if it takes two months to get things up and running, you don’t want your deal sponsors thinking, “Why haven’t we seen a return yet?” and holding it against you. This is another benefit of good status reporting during the implementation project—your deal sponsors are seeing the work that you’re doing and the value that you’re providing in driving the desired change in their organization.
If your implementation process is drawn out and requires a substantial amount of labor on the part of someone in your organization, consider charging for it as a professional service. This can be helpful if your customers’ implementations vary significantly in complexity and therefore demand varying resources from your team that haven’t been built into the pure licensing costs of your solution.
A good example of this would be a solution that hooks into others enterprise systems, but could potentially be used without those hookups. If a customer doesn’t require any implementation hookups beyond their standard onboarding and training, then standard licensing would cover them. But if a different customer needs integration with three or four other systems, which represents 20+ hours of meetings, calls, and so on from a systems engineer on your team, then you might consider charging for that.
While you would hope that everyone involved in implementation would be excited about embracing new technology that will help them do their jobs better or, at a very minimum, follow through on something that their superior has instructed them to do, you can’t always rely on that. You have to consider your solution’s different value propositions to different stakeholders (individual users, line management, leadership), just as you did during the pitching process—“What’s in it for me?” continues even during this stage.
One great way of helping with that is to provide inducements to individual users to heartily embrace implementation. In addition to helping them understand how this is going to make their job easier and why it’s going to make the organization more successful, consider positioning how this will make them more in-demand professionals, now and in the future. A more advanced version of this could be actual certification in your solution: when the individual goes through all the steps of implementation, executes on the various pieces of homework, and attains some version of success with the solution, you can award them with certification.
exampleAt TalentBin, we offered TalentBin Certification, awarded to those who passed a lightweight test after implementation (that really just acted as an open-book quiz to compel paying attention to the topics we covered, or at least going back to the materials later) and completed a certain set of actions (for example, putting 50 candidates into drip campaigns). Certification included a digital PDF certificate and entry into a registry that could be checked by employers. Of course, this aligned with the interests of our customer success team—if users were familiar with how to achieve success, and incentivized to take the actions that would drive ROI for their companies, that was a big win for everyone involved!
Inducement can also be as simple as sending hearty helpings of company schwag to users who have gone through implementation. T-shirts, Post-it notes, high-quality pens, you name it. If you’re selling software that costs hundreds to thousands of dollars per user per year, then ~$5 worth of nice pens and Post-its is certainly worth it, and a nice reminder to users that their customer success manager loves them and is invested in their success. Plus, it can’t hurt to have a reminder of your solution papered all over their desks. It is absolutely amazing how much buggy software and occasional hiccups can be papered over by sunny, delightful customer success. Constantly remind the user that you’re in their corner.
This is one of the reasons why customer success staff are often compensated not on renewal metrics but instead on success precursor metrics (the proportion of the users they are responsible for who have logged in or attained some measurable outcome in the last 30 days). Alternately, you might compensate customer success managers based on their assigned users’ net promotion scoring or customer satisfaction survey scoring. The point is, guiding and rooting for your customers’ success—whether that means making them better professionals, helping them prove their value to their bosses, getting them raises, or positioning them for better jobs—is a great way to make sure that they are excited about your solution.
Once you’ve completed implementation, it’s time to drive your users to a return on their investment as quickly as possible. Let’s talk about the tooling you’ll need to achieve that.
The first bucket of tools allows users to easily contact you when they hit snags and need help. We’ll talk later about proactively identifying users who are having issues and engaging them before they even reach out. But the first step is having a means by which users can get in touch with you when they have issues.
You’ll recognize a lot of the same tenets from Early Inbound Lead Capture and Response, in that support is rather similar—it just happens to be for existing customers rather than prospects.