Vertical ERPs (VERPs) will be one of the largest and most exciting software categories over the next decade. VERPs are purpose-built applications that centralize and automate core processes for a particular type of business (such as Toast, Mindbody, and Bonsai), consolidating the everyday workflows that would otherwise require a patchwork of tools.
The ultra-appealing aspect of VERPs is that those workflows overlap with cash flows. That means you can monetize a VERP not only with a SaaS model, but also via embedded fintech products—such as transaction processing and banking functions—that fit into customers’ operations naturally.
Because of those embedded fintech opportunities, VERPs offer a significantly wider opportunity than a garden-variety SaaS app. Also, “VERP + embedded fintech” wasn’t technologically feasible until very recently. As a result, now is the time when VERPs can rapidly multiply the TAM of already huge markets, and help previously sub-venture-scale segments rise to attractive venture-scale TAMs.
Now I’ll dive into a more detailed picture of this opportunity and technology, including some learnings from my own experience at Bonsai.
Many are vaguely familiar with enterprise resource planning (ERP) systems, but struggle to nail down exactly what it is. Oracle, which knows a thing or two about ERPs, defines them like this: "[A]n application that automates business processes, and provides insights and internal controls, drawing on a central database that collects inputs from departments including accounting, manufacturing, supply chain management, sales, marketing and human resources."
One key phrase here is central database. To run a business effectively, you need an accurate picture of what’s happening in it. That’s increasingly difficult for today’s businesses, which face sprawling operations across geographies and company functions, each of which is likely to use their own specialized software.
For example, three different departments—marketing in Europe, sales in the US, and manufacturing in Southeast Asia—may each run different stacks of software products. Their data and processes are siloed in those products. Within each department or region, the CRM may have one version of ‘active customers’ or ‘revenue,’ while the e-signing tool and contracts may have another slightly different one, while the invoicing, payments, and accounting products all have slightly different versions also.
None of these sources are “wrong” per se. They just have different definitions because they’re often used by different functions within the business for different purposes. ERPs ingest and reconcile these different data sources, so they can provide a single number for revenue, customers, products, or any other key business metric.
The other key phrase in the definition above is automates business processes. If you have a single agreed-upon definition for key business metrics, you can build business processes that avoid the risk of “garbage in, garbage out” that you face when every system has a slightly different definition of some key input or output.
So, an ERP represents everything from a business’s key inputs (people, COGS, etc) to its outputs (revenue, etc) and everything in between. It's a critical product for large and complex businesses, where each function like HR or marketing would otherwise have different and non-interoperable systems, data, and processes.
Smaller businesses face a lot of the same problems, but at a smaller scale.
They rely on a patchwork of horizontal software products (think Mailchimp, Typeform, Google Suite, etc). But just as it does with larger companies, this patchwork leads to fragmented data, and fragmented understanding, across business functions. Where’s the source of truth for the list of ‘active customers’? Where’s the single, true, complete list of all products, services, delivery dates? Tools like Zapier and Paragon help with data portability, but don't provide that single source of truth. These businesses are still stuck juggling multiple logins, monthly subscriptions, and duplicate data.
A vertical ERP (VERP) solves this by bundling all of these tools in one place. Specifically, a VERP:
Let's start with the first two points. VERPs bundle many horizontal products -- like contact forms, CRM, and invoices -- into a single package that’s highly opinionated for the given industry. Here are a few examples from well-known VERPs:
This may just seem like a bundle of commodity products. Indeed, there often are point solutions that are "better products" in absolute terms because they have a much deeper feature set and/or just do that one thing very well.
However, VERPs’ opinionated design and native integration provides defensibility and pricing power. VERPs are purpose-built for a business's specific use case, rather than requiring the business to stitch together and customize a variety of commodity products that still generally fall short of the ideal setup. The best VERPs embed the customs, assumptions, and best practices of a specific industry into the product. For example, tipping is common in service industries, while taking a deposit is common in certain types of consulting. Some industries operate on a cost-plus model, while others are more time-and-materials. The best VERPs understand and support these nuances across their various products.
These bundle-of-commoditized-yet-opinionated-software products aren’t that much different from what's been known as vertical software. However, VERPs are a significant change and improvement because they embed financial functionality, allowing the product to touch the cash flow as well as the workflow. And cash flow is king.
Vertical software is already an established category, and there’s been a first generation of VERPs, with well known examples like Shopify and Toast. However, several macro shifts have opened a golden age of VERPs.
The biggest enabler is the explosion and maturation of embedded fintech. Before, SaaS companies had one type of business model: subscription payments in exchange for using the software. Now, SaaS companies can introduce a new business model which can coexist with the old one: getting paid every time the business gets paid and/or transacts in some way.
Historically, it's been difficult to embed even simple financial products. However, there are now multiple robust options for adding everything from payments (Finix) and banking (Unit) to lending (Kanmon), payroll (Check), and even tax filing (Column).
These companies have abstracted the technical and regulatory complexity of financial products to the point that small teams without fintech expertise can manage them. Most of them have also adopted variable-oriented rather than fixed cost models, so it's cost effective for non-fintech companies to experiment with and not be scared away by high monthly fees or long term commitments.
There are significant demand-side factors at play too: all companies are now digital by default and nearly all companies could benefit from a VERP. It's no longer optional to have a website or accept online bookings or process card payments. Especially post-COVID, customers have a high bar for the digital capabilities of even the smallest businesses. Companies need digital products for every function, and they're realizing that a suite is superior to a patchwork.
The last big shift comes from the last 10+ years of heavy investment in technology and the maturation of the SaaS model. Thanks to the ease of building software products and the flood of capital into private and public markets to do so, many pure SaaS products have been commoditized through competition.
VERPs provide multiple novel ways to acquire, monetize, retain customers: whether it’s free software and pay-as-you-go fintech, directly monetized SaaS and upsold financial products such as lending, or more. Although the embedded financial building blocks are now available, the playbook for integrating them into a SaaS product and thoughtfully monetizing them is still being written.
In the next post, we'll discuss how to both evaluate VERP opportunities and then actually go to market with financial products. Click here to read Part 2, "How to Build a Category-Defining VERP".
Header image by Pablo Hermoso