The slippery slope from SaaS to managed services: When labor intensity makes sense in growing your startup

Happy customers are often one indicator of product-market fit, but how you made them happy will determine whether you’re building a sustainable SaaS business with scalable unit economics.

In particular, how much of your customer’s success is due to high-touch service and how much is due to value delivery from your tools or platform?

I’ve found the four-stage start-up maturity model, proposed by Matrix Partners’ David Skok and others, to be helpful in thinking about this problem: first you make your customers successful, then you focus on making that success repeatable, then scalable, and then ultimately profitable.

We’ve all been there: early products, particularly bleeding-edge MVPs, often lack key functions required by customers and/or a mature-enough user experience that promotes self-service. It’s sometimes easy to fill in the gaps with bodies, particularly in implementation.

If in moderation, extra handholding isn’t out of bounds, as the goal at this stage is customer success as well as creating social proof for prospects and positive signals for investors and team members. Labor also can speed market testing of complex features by using humans to replace technology behind the scenes — why build when you can simulate at a fraction of the cost and time.

But still having a big labor component six or 12 months down the line could be a cause for concern, particularly for investors who may have signed up for software economics and not managed services. Or it could be a signal of a different business model or more profound product issues that you should address now.

The first step to understanding this is keeping track of what’s going on regarding go-live, operational support and account management for early customers: who on your team is involved, what they’re doing, and how much time they’re spending.

It’s easy to forget the details once that prime logo hits your sales deck, and no one likes reporting their time. So at minimum, do a quick post-mortem after each implementation if you have high annual contracts (ACVs) or a standing weekly meeting for smaller-dollar SaaS products. You should also capture recurring labor supporting the account.

The goal here isn’t to nitpick your team’s actions, but to troubleshoot issues that would hamper building a playbook to repeat the process and ultimately scale it.

Once you have the data, then map all of the labor to their root causes, using the “Five Whys,” decision trees, or similar techniques to help suss this out.

For instance, labor could be triggered by the product not working as expected (bug requiring a workaround) or having a gap in critical functionality needed to complete the customer process (product immaturity). Or it could be to project manage a complex implementation among several customer departments and external partners.

As to why customers can’t provide the labor, maybe they don’t have the necessary product or technical knowledge, don’t have access to administrative functions, or just don’t have the time or interest.

Labor can be categorized into general sales or account management buckets, but use these sparingly if they mask the true reason.

Then for each entry, ask yourself:

• Are there signs of product strategy missteps that signal bigger issues?
• What do these tasks and effort levels look like in a more stable environment (i.e., a repeatable, scalable world) once product and processes are more mature? Understanding your competitive set and how they do business is helpful here. What do the economics of this destination look like?
• How much of this labor will naturally drop away as your team goes up the learning curve and routinizes processes?
• How does the “right” amount of labor depend on deal size, either your company’s ACV or the natural spread of deals (minnows requiring X labor and whales requiring Y).
• What is specifically required to reduce labor to the appropriate levels identified in the stable scenario? Identify the needed product features and UI enhancements, training, documentation, etc., and do a rough cut estimate on the investment required for each. Do you need new internal capabilities, such as solutions architects or SaaS-savvy account managers, to make this happen?
• Is it appropriate for the customer to pick up some or all of these tasks and what’s the right role for self service? How do you enable them to do that (training, documentation, etc.) or incent them through pricing structure. If there’s an issue with lack of customer sophistication, how do you mitigate that?
• If the labor is still required, is your team the best equipped ones to do it or should you explore partners, such as system integrators and consulting firms. This should dovetail into a separate consideration of your wider channel and partner strategy.
• For the labor that ultimately will remain within your company, is it being done in the right place? For instance, if there is going to be a higher managed services component to your business, moving functions to lower-cost locations could make sense, provided that you consider the impact on collaboration and communication.
• What’s the timeline for making changes happen, as you need to strike the balance between premature optimization (aka, “the root of all evils”) and appropriate optimization. You also want to gravitate towards traditional SaaS metrics at some point and excess labor can distort those KPIs.
• What’s your strategy regarding professional services and do you want to explicitly charge for consulting or generate revenue through bundling with SaaS fees? While software investors discourage professional services that exceeds 15% of total revenue, this can be an effective way of bootstrapping your company in the early days.

At the end of this process if you end up with a large labor component, then you need to seriously think about what business you’re in. There are plenty of great companies that profitably meld software and services, ranging from various managed services models to business process outsourcing (BPO).

But this isn’t SaaS and costs here have a much different relationship with revenue. Work with your investors and team to decompose your business to understand what’s happening. Are there problems of execution or product, or maybe your best product-market fit actually is something different than what you thought it was.