The Case For
by Zac Bookman, OpenGov CEO and Co-founder
by Zac Bookman, OpenGov CEO and Co-founder
A lot of friends and early-stage CEOs of enterprise software companies think that Customer Success (CS) is the critical function to build after you develop a product and figure out how to sell it. Not so.
The critical function to build is Professional Services (PS). Annual Recurring Revenue (ARR) is sexy, and investors focus on it because it is easy to see, measure, and model. Yet, PS enables and accelerates ARR growth and maximizes lifetime value. This is harder to see, measure, and model. My advice is don’t focus only on the “sizzle” that gets you a good valuation in the short term. Focus on the “steak” and build a sustainable business that can gush cash for decades.
It took me years to figure out that top-line growth is intimately related to, often a result of, and even in service to Customer Lifetime Value and Gross Retention – each of which is lifted by a good “services” function. Yet all I had to do was talk to previous generations of enterprise software CEOs. They sold perpetual licenses, and the PS team was the one that “screwed” in the software so that it would never come out. More specifically, they installed, deployed, and implemented the software with the aim of drawing on a maintenance and support contract for many years. Often they literally “screwed” in servers.
Great returns for private equity firms over the last decade have been due in part to services teams doing such a good job that the software could rarely be ripped out. The models of 7-, 10-, or 12-year lifetime values that many investors use proved wrong. They underestimated the staying power of entrenched products, which can deliver recurring revenue for 15, 20, or even 25 years.
As SaaS CEOs, it’s more important that we ensure recurring revenue because we are renting or leasing the software as opposed to selling the actual code. If we expect to get 15, 20, or 25-year lifetime values, it’s the regrooved business processes, extensive configuration, data conversion, integrations, and enterprise-wide training that will ensure the software sticks around.
Professional services organizations run on a different business model than software. The software business model consists of building intellectual property and selling it on a license basis. In almost all cases, except the rare few where software is literally downloadable and self-explanatory (e.g. Dropbox or Airtable), a range of pre- and post-sale work requires experts to ensure the software is successfully adopted by the organization. Zach Nelson, the former CEO of Netsuite, told me that he refers to an ERP deployment as a “heart transplant.” At OpenGov, I sometimes say that “software does not walk in and turn itself on, and the customer does not wake up the next day and know how to use it.” We must implement and train the customer and its users to prevent “organ rejection” and ensure long-term success.
According to GAAP, software revenue is only real (i.e. not deferred revenue) if and as it is installed. Some of the larger and better enterprise software companies set up actual classrooms at customer sites—think Oracle and Workday and a host of accountants or billing clerks sitting in a lecture with hands-on-mouse. The expert teachers and trainers running these sessions are billed on an hourly basis or the entire post-sale experience is billed as a project from signing to “go-live.” Each dollar of ARR comes with at least a dollar of services at signing, and up to five dollars. Some companies charge for a workshop or pre-sale proof of concept that rolls into the deployment.
The term “go-live” can make people cringe as historically payment was tied to this key milestone. The advent of Software-as-a-Service (SaaS) has ushered in an important shift, namely, that more customers are willing to start paying for the software service at contract signing as opposed to go-live or launch. This can be a difference-maker for a young company burning cash.
Many investors I talk to think that professional services are bad words or a bad news story. One advisor told a friend to “be careful of becoming a “services” company,” notwithstanding that he was growing ARR by 80% a year at scale and his PS revenue amounted to 6% of total revenue. I gave my friend the opposite advice, noting the range of benefits detailed below.
It may be true that investors don’t value PS revenue for much and the valuation models turn on ARR. But that focus has led to a confusion or contortion, namely, that PS revenue is not important. On the contrary, you won’t get maximum SaaS revenue without the PS consulting revenue.
Given fundamental differences in their business models, software and services businesses carry tension. The operational differences should not diminish the strategic importance of building them together. For very complicated or heavy software products, the implementation and training can be practically as important as the R&D required to ship the product in the first place. Accordingly, and because a product may not sell or work properly without it, it’s good to start designing PS capabilities as the product itself is built.
You’ll need to staff up PS teams, usually with special skill sets to wire capabilities together to fit customer workflows. And those teams will need tools, documentation, training, and enablement materials to deploy the product as designed. Discriminating buyers want to know that your team can perform the “heart surgery” and they will seek references, so think of this as lowering your Customer Acquisition Cost (CAC) if that helps digest the investment required.
A deal is sold and then a Project Manager leads a team that might include an Implementation Analyst (also called a Business Analyst or Consultant), a Solutions Architect, and an Integration Engineer or other technical experts. They set to work, according to a deployment methodology, to ensure the software gets installed properly and customer users get trained to exploit its features and benefits.
If done well, this leads to adoption and usage. That leads to gross retention, hopefully because the software delivers so much value that the consumer surplus is undeniable and occasionally because it is just too much brain damage to switch off and change business processes again. A good deployment also leads to references, which lower the CAC (improving the “Magic Number”) and shrink sales cycles. Prospects call customers and hear “the team is great and we are getting value from the system” instead of “we bought it and we’re still in deployment.”
This has nothing to do with Customer Success, which is critical but which fully takes up the reins after go-live. It can be a good idea to introduce CS along with the project team during the sales cycle and certainly during the deployment. Both help continuity and promote team-selling. Yet, CS as a function is more closely related to what used to be called Account Management. For some companies, CS may be more about adoption. CS Managers (CSM) can be goaled on healthy retention metrics and they can also farm the customer base for upsell opportunities. Thus CS is often more closely connected to the Sales motion than the PS motion.
The relationships built by the CS team and the customers’ users help to cultivate the base, and the relationships built by the PS team can start even earlier and go as deep. Having gone through “surgery” together forms bonds with the people who will fight to keep the product and avoid another deployment (of a competitor’s product). These relationships can serve as a channel to sell more services and more software too. There is no time to sell like the fresh high of a recent buy or at a successful go-live.
Perhaps the best reason to care about PS is that it helps manage cash flow. A mature services organization can earn a gross margin approaching some software gross margins. Further, many enterprise software customers know they need PS and don’t factor it into the recurring price. Thus it can boost deal sizes and capture more wallet share at the time of contracting.
Early on, I had the idea to give away deployment services and keep more of the First Year’s Booking as recurring revenue. I nearly killed the company. Aside from bleeding cash, the lack of financial discipline engendered weak processes. We didn’t have the methodologies defined, the playbooks, the project management, the escalation and governance mechanisms, the billing rates and billing model, and the overall understanding of what was required to install our software in complicated enterprises. Nor could we create these processes without treating them as part of an overarching “business,” namely a PS business. The customers smelled the dysfunction and started whipping us around: “Change this,” “do that,” “I need this,” “build more,” “I don’t like that,” they would say. We turned into “caregivers” rather than “heroes” as we now say. Deployments dragged, NPS suffered, cash leached out the door, and morale sunk.
Charging for the time that your people spend on a customer forces discipline and measurement on your organization, as well as the prospects and customers. Scoping deals and presenting those scopes to customers leads to more alignment in the sales process and fewer failed deployments (and unhappy customers). A deeper understanding of what is required to make a customer successful leads to better budgets and financial plans, as well as appropriate staffing and even packaging and marketing. You can measure top performers in the PS business by not just the hours they bill, but also the post-deployment surveys of customers and their Net Promoter Scores.
If you were running an enterprise and about to buy a new software system, would you buy from the company that promises you a Customer Success Manager (CSM) or the company that accompanies that CSM with a detailed scope of work showing bios of all the experienced professionals who will install the system and train your staff along with the Gantt charts, RACI matrices, and the methodologies that they will use to do it? The latter wins in a landslide.
Good PS ensures that customers get what they pay for. It also ensures the business can sustainably serve the needs of new customers while continuing to invest in R&D (good PS often protects engineers’ time too!) and other core functions. So why don’t more entrepreneurs and new enterprise SaaS companies spend time building professional services organizations to match their product organizations?
There may be several reasons. First, many venture capital investors haven’t built and run enterprise software companies. They worked at or invested in Facebook, Google, Slack, and loads of impressive companies that haven’t needed a heavy enterprise apparatus. (Interestingly, many companies like Box and Slack have had to build this out as they moved upmarket). The venture partners who’ve run Sales or Operations know a lot about PS, and I suspect these folks assume that everyone knows as much.
Second, many books of the last decade extol the subscription or membership economy, as if clever pricing and Product Led Growth are the reasons why it’s so hard to rip out Salesforce. To be fair, there are very successful (usually productivity-oriented) applications that are light on services (e.g. LinkedIn or Carta) and which rely on good UX and UI to achieve bottoms-up and eventually top-down organizational or even industry-wide adoption.
Third, a lot of recent enterprise SaaS has been developer-focused, such as cloud databases, “DevOps,” logging, and security. Stimulated by the transition from on-premise to cloud infrastructure, these approaches cater to more sophisticated do-it-yourself users with polished APIs and SDKs, documentation, and robust communities.
Another possibility is that many PS professionals don’t always seek the limelight. They don’t detail the value they add to a software company. They don’t write showpieces and, if they do, their blogs don’t get featured the way pieces on sales and fundraises do. Nor do they care, in my experience. They typically love solving customer problems, diving deep into the data, mastering the software, and serving as pillars of competence for their organizations.
When things start to work, the best salespeople come to realize the value of PS. They start grabbing PS teammates and getting them involved in their deals. As PS professionals grow, some move into more technical delivery, others into more intensive project management, and still others move out into sales engineering or product work. They infect the organization positively.
If your PS revenue is less than say 20% of your software revenue, I doubt you are at risk of impairing business value by building a services business. And if you run an enterprise software company with less than 3-5% of sales from PS, I think you may be depressing the potential value of your company.
It is extremely difficult to build a good PS business, and it’s extremely difficult to build an enterprise software business. The benefits often outweigh the costs. Doing it right requires experienced leaders who are proud of their PS pedigree. Once rolling, the PS business will enable you to pull levers to create competitive differentiation against ankle-biters and incumbents alike and balance a financial profile for IPO and beyond.