A while back I was having a discussion, not quite a debate, but a discourse with an extremely smart VC — far smarter than me — who was relatively new to SaaS, having spent more time in B2C.
Like a lot of folks tip-toeing from B2C to SaaS, his first stop was in freemium. He was obsessed with apps that you can “grab and go” with — use in just seconds. Like Canva, Zoom, or Slack.
The thing is, I told him, I hear you, I get it. For a simple, cheap tool, that totally makes sense. If I’m paying $0 or $5 a month, I better be able to start using your SaaS app in about 60 seconds, ideally. 10 minutes max.
But a true solution to an enterprise-grade problem, almost by definition, usually requires business process change. Which can and indeed usually should include onboarding, training, follow-up, and often, a full-time admin of your product on the customer side. And that’s a good thing, at least, 8.5 times out of 10.
In fact, my uber-learning is one of the Top 10 reasons customer success is so important is to make sure this business process change is implemented. If you do nothing else in Customer Success, make sure you have full engagement by Day 5, Day 15, Day 30, Day 60 … whatever exact amount of time is right for your app. But make sure it happens. And what you are really making sure happens is business process change.
It’s OK that your app is more work to deploy than Facebook … if it radically improves a complex business process:
- Changing, say, how you manage your call center, how you train your workforce, how you manage your customer relationships, etc. — the things that many of our apps do — is a big deal. And a lot of work. But along with this big change (should) come big returns. And thus, customers are willing to invest the time.
- Most SMB SaaS apps are really ERP 2.0 for a vertical or industry. A new ERP, to get the benefits of that ERP … always requires business process change. You can’t pick this up in 60 seconds. A new financial system, a new task management system, a new order management system … can be epic. But it ain’t an Instagram-like deployment, even in an SMB.
- If you don’t actively manage business process change, engagement will be far lower for most business process SaaS apps. Yes, I can grab Slack for my product team. But want the whole frickin’ enterprise to use it? You better have training. Emails. Follow-ups. Active management of usage. And yeah, probably — a Slack Admin. Otherwise, outside of its hot spots — you’ll only hear crickets on most Slack channels.
Now it’s not quite all this simple. The bigger the customer, the most likely it is they’ll have someone fully dedicated to deploying, managing, and tracking your app. That’s a good thing and can help a lot. Oftentimes, post-sale, your customer success team will spend a huge amount of time with these folks.
The smaller the customer, the less likely it is your customer will have a person to help manage this business process change. Your team then will more likely be doing the training, doing the change management themselves. That means oftentimes, business change has to be more incremental, and managed in stages. And it will take a lot of time. A lot of time. And a lot of follow-up.
But wherever your product comes out on the “work to deploy” spectrum, don’t fear business process change. I say run to it, embrace it. If your app could either be a “grab and go” tool or a full business process change solution, I say, let it do both, but embrace the work it takes to make your app 10x-20x more valuable to your customers. Yes, this will help with churn. It will make your app stickier and harder to rip out. But it’s much more than that. It will ensure your app truly changes a core business process in an important and fundamental way. That’s what really matters. And customers will pay a lot, lot, lot more for that. A lot more. At least — once you get good at it.
Look at ServiceNow. It has 1,500+ customers that pay $1m a year, an 99% GRR. Yes, they take a while to close. Yes, it involves a lot of business process change. But after that, boy. They stay forever.