I’ve worked with several startups that fell into the following pattern:
- Selling a SaaS application at a healthy price (e.g., $100K to $200K ARR)
- With low, fixed-cost implementation packages (e.g., $25K)
- But a product that actually takes maybe $50K to $75K to successfully deploy
- Resulting in an unprofitable professional services business (and wrecking the market for partner services)
- High adoption failure
- And, depending on the initial contract duration, high customer churn [1]
For example, one company had a CAC of 4.0, churn of 25%, and services margins of negative 66% when I started working with them [2]. Ouch.
Before proceeding, let me say that if you have a low-touch, high-velocity, easy-adoption business model — and the product to go with it — then you don’t need to read this post [3]. If you don’t, and any of the above problems sound familiar, then let’s figure out what’s going on here and fix it.
The problem is the company is not charging the appropriate price for the services needed. Perhaps this is because of a zero-sum fallacy between ARR and services. Or perhaps they feel that customers “just won’t pay” that much for implementation services. Or perhaps their product takes more work to deploy than the competition and they feel forced to match price on services [4].
This under-pricing usually triggers a number of other problems:
- In order to work within the self-created, low-cost implementation services model, the company “hires cheap” when it comes to implementation consultants, preferring junior staff and/or staff in offshore locations.
- The company’s “implementation consultants” are overloaded, working on too many projects in parallel, and are largely focused more on “getting onto the next one” than getting customers successfully implemented.
- Once a certain number of hours are clocked on any given project, the consultants go from “in a hurry” to “in a big hurry” to finish up and move on.
- Customers are left high-and-dry with failed or partial implementations that, if left unfinished, will likely lead to churn.
- Customer success, whose job is to prevent churn, is left holding the bag and is pulled away from its primary mission of adoption, renewal, and expansion into the implementation-completion business, potentially changing its hiring profile from more sales-oriented to more product-oriented and/or complementing CSMs with customer success architects (CSAs) or technical account managers (TAMs) to try and fill the implementation void.
I sometimes consider fixing this corporate chiropractor work, because one maladjustment results in the whole organization being twisted out of shape [5]. The good news is that, as with chiropractors, one adjustment can pop the whole system back into alignment.
Now, before we move onto fixing this, there’s one more problem we haven’t discussed yet — and give yourself ten pats on the back if you figured out before I got here:
Who ever said the customer defined success as getting the software implemented?
Oh shit. We were so tied up trying to deliver a $25K services package that costs $40K to deliver that we forgot about the customer. What customer equates implementation with success? None. Zero. Nobody.
“Hey, it’s all set up now, you can login, gotta go!” is not the credo of a success-oriented consultant.
But what do we call our consultants again? Implementation consultants.
What do implementation consultants think they do? Well, implementations.
When an implementation consultant reads their own business card, what does it tell them they their job is? Implementations.
Are implementations what customers want? No.
So why do we have implementation consultants again? I have no idea.
What do customers what? Overall they want success, but what’s a good proxy? How about attaining their first business objective? If you sell:
- A recruiting app, running your first recruiting campaign
- A financial planning app, it’s making your first plan
- A demandgen marketing app, it’s running your first demandgen campaign
- A customer service app, it’s your first day running the call center
- A deflection app, it’s deflecting your first cases
- A sales enablement app, it’s training your first reps
- An IT support app, it’s handing your first tickets
So, what’s the fix here? While not all of this will be possible or recommended in all situations, here’s the long list:
- Re-frame services as in the success business, not the implementation business
- Eliminate the job title implementation consultant in favor of consultant
- Get services to make plans that end not with implementation, but with the achievement of an agreed-to first business objective.
- Increase your services pricing, if needed, so they can both deliver success and break even.
- Hire more experienced consultants who can better make customers successful and don’t be afraid to charge more for them. (They’re worth it.)
- Agree to an ARR price before negotiating the services price; refuse to trade one off against the other.
- Involve your services team in the sale well before the contract is signed so they propose the right prix fixe package (e.g., small, medium, large) or create an appropriately-sized bespoke statement of work.
- Modify your product so it is not at a competitive disadvantage on required implementation work.
# # #
Notes
[1] With one-year contracts, a failed implementation that takes 6-9 months to fail typically results in churn, whereas with three-year contracts, you will often get another swing at the problem.
[2] These horrific unit economics result in an LTV/CAC of 1.0 and make the company totally uninvestable. The CAC would be even higher if hard-ass investor added the services losses back into the CAC on the theory they were subsidizing sales.
[3] Product-led growth business models are great, but when companies that are not designed for them try to emulate pieces of the business model, they can get into trouble. Implementation is an area that quickly goes awry when companies not built for PLG attempt bottom-up, try-and-buy, viral go-to market strategies.
[4] In which case, an obvious solution is to reduce the deployment workload requirements of the product.
[5] Put differently, the sales bone is connected to the services bone, and the services bone is connected to the customer success bone.
Great article- where did you get to with the basket case-4 cac x 25% churn ?
Again excellent article- nice structure
Thanks. LTV/CAC of 1.0 happens. So does 100x pipeline coverage with 1% conversion rate. Do this long enough and you kind of see everything :-)
It makes sense to negotiate the ARR price first and separate from consulting services. However, the sales organization must also manage the pipeline of services with the same rigor as for the license. Too often the services are put in the pipeline as an afterthought, the license sale closes, and the consulting team is expected to drop all other clients to help the newest ‘critical customer’ sale.
Amen. And glad you said “sales” not services. Services manages the backlog. Sales manages the pipeline/forecast.
Hi Dave – great blog. You say that charging for implementation could potentially wreck the market for a services partner. This is true but if the startup doesn’t have the sales velocity to make it interesting for a partner to learn the product and therefore be good at configuring / integrating it as needed, then the startup won’t find partners. Or – the ones it does find – are substandard. Plus the product isn’t ready to be handed off to a third party for configuration work anyway. These are the challenges young startups face.
The solution is to first create this services organization (call it whatever you want, perhaps put it under Customer Success if you need to), measure the organization on successful go-lives and breakeven margin (no need to be profitable). Certainly do NOT measure it on revenue.
Then as the startup grows, morph this organization into being a back up for services partners. So when a new partner comes on, then the startup provides “expert services” in the background, at breakeven cost, so that the partner sees success, and of course so does the startup.
Thanks for reading, and I think I lean more disagreeing than agreeing as you seem to assume you cannot properly price for reasonably required services from the outset. My points are [1] you often can and don’t know unless you try, [2] if you give free or highly discounted services you ruin the market price point for such services — you have a de facto monopoly in brand-provided services and should charge more than RSIs, [3] I get your point that if you don’t have a great business that won’t attract services partners, true, but kind of orthogonal imho (and if you have to give away services to have a great business maybe there’s something deeper wrong), [4] agree to measure services in a SaaS company on breakeven margins and customer success (first-attained-biz-objectives, however, not go-lives which was kind of the point of this post), and [5] disagree that as you grow, your services org needs to be a “backup” for partners as some customers will want one throat to choke — so why not be a complement — and, what’s more — it’s possible that the core work itself is not that interesting or profitable for a partner and they may only be interested in broader services that envelop the tool as one part (e.g., finance transformation work vs. budget-system implementation work). Hope you are well and thanks for reading. /Dave