If you’re doing SaaS for the first time (or even the second), the whole idea of charging for “Services” may seem an anathema. It sure did to me.
- If your product is so easy to use that you barely need sales people, why in the world would I need to charge for implementation? For support? For training and engagement?
- And isn’t it a bit unseemly to charge for services? Doesn’t it sort of say your product is Old School? SAP-level clunky?
- And isn’t services revenue a friction-full waste of time anyway? I mean, it’s not recurring. It’s not true ARR. Does it even count? I’m a SaaS company.
Maybe. Maybe for the 15% of the world that is like you and me, charging for services doesn’t make any sense, perhaps even anti-sense.
Turns out though, that in the vast majority of six-figure contracts, virtually every seven-figure contract, and quite a few five-figure contracts … there’s always a services component.
And it almost always seems to average out to 15-20% of the ACV.
I remember the first time I experienced this confusion myself, on one our first high-five figure contracts. We had a brutal negotiation over price. And then, at the end, they send us a Schedule for Services. After getting beat down on pricing on the annual contract price … the Schedule for Services they send us (without me even asking) guaranteed us another $20k a year in services, with $250 an hour as the assumed price for the services.
I didn’t fully understand what was going on here until I became a VP in a Fortune 500 tech company.
But the answer, it turns out, is simple once you get it.
First, in medium and larger customers, there’s always change management to deal with when bringing in a new vendor. And they not only understand there’s a cost associated with that (soft even more than hard) … your buyer wants to do the least amount of change management herself as possible. If you can do the training for her for a few bucks and saves her a ton of time … that’s an amazing deal.
Second, in medium and larger customers, they often have no one to do the implementation work themselves. So even if you weren’t saving your customer theoretical money by helping with implementation, roll-out, support etc. … they probably have no one to do this internally anyway. You’re going to be doing some, a lot, or all of this for them. They are OK paying for this, in the enterprise at least.
And most importantly … it’s how business is done. And — budgeted. When most larger companies enter a new vendor into their ERP system, they typically add an additional budget item or two along with the core contract price. One additional line item for service and implementation, in most cases. And in some cases, an additional budget for other add-ons necessary to make the implementation a success (e.g., an EchoSign on top of Salesforce). Both of these are often line-item budgeted at 15-20% of the core contract value for the product.
So net net …
- You probably can’t charge another 15-20% for services and implementation and training for a $99 a month product. Well maybe you could, but it’s probably unprofitable and not worth it.
- But, as soon as the sale gets into the five figures, considering adding 15-20% for Services. You’ll probably get it.
- And plan for charging, and delivering, additional services revenue in mid-five figure and larger deals. The customers are happy to pay, and in fact, will expect it.
And if you don’t charge … you’re just leaving money on the table. You’ll have to do the work anyway. You may send negative signaling that you aren’t “enterprise” enough, that you aren’t a serious enough vendor.
And importantly, this extra services revenue still “counts” as recurring revenue if it’s < 25% or so of your revenues. I don’t mean that literally (it doesn’t recur), but what I mean is that Wall Street and VCs and acquirers and everyone will still consider you a 100% SaaS company if <= 25% of your revenues are nonrecurring. And you’ll get the same SaaS ARR multiple on those extra services revenues.
Same multiple. No extra work. 10-25% more revenue.
Don’t leave the services revenue on the table.
(Cross-posted @ saastr)