.svg)
Technology
Buyer Beware of SMB Software Providers Trying to Move Upmarket
Many B to B software startups design their products, sales channels, business structure and operations for a small and medium business (SMB) buyer. There are many incentives and good reasons for this. Most don’t want to stay at this level, however, aiming instead for the enterprise. The enterprise segment comes with its own requirements, sets of challenges, and barriers, and getting there involves a lot of hustle and excellence in managing competing priorities. Not many companies and products make the up-market transition well. Buyer Beware.
Since there are a lot of opinions of where the divisions lie, let’s start by defining what we mean by Small, Medium, and Enterprise.
In the restaurant industry, most people use location count. And while the cutoff between segments is somewhat arbitrary, for the sake of discussion, and based on my decades of experience in this business, I’ll set some bounds. Small can be considered ten or fewer locations. Eleven to one hundred locations constitutes a medium sized restaurant system. And anything over one hundred one is an enterprise chain.
What differentiates one from another? Typically, three things:
Buyer personas (Enterprise chains will typically have a Chief Marketing Officer, for example, whereas in a Small restaurant group, the person who wears the marketing hat might bear the title of Marketing Manager or Director. Or the hat might even be worn by a restaurant manager or General Manager.
The complexity of the organization and its needs. The larger the restaurant group, the larger and more complex its operations and its needs. Enterprise will have a corporate office that oversees menus, marketing, and the like. These folks need access to information and reporting that is different from what a regional or local store manager will need, for example.
Product requirements. Small businesses typically have simpler management structures and therefore simply need less sophisticated products. When it comes to buying from software makers and other vendors, they are more easily influenced, in part because there is no large organizational inertia. The sales cycle can be quick: fewer than three months, typically, and just one person or a few people ultimately make the decision. Contrast that with selling into a multi-unit enterprise chain, where four to ten people from executive leadership and upper management may need to be involved in product evaluation and purchase decisions. The sales cycle can be extremely long: 6 to 24 months. This gets to the crux of this article.
The simpler needs and smaller buying team mean that an SMB vendor can use direct sales methods to generate cash flow fast. Buyers quickly go through the buyer’s journey from awareness to interest to consideration to purchase. This can go even faster if one or two buyers already have a relationship with someone at the vendor.
For obvious reasons, software companies find it fairly easy to break into the SMB market. R&D can be limited; product features can be basic; and many users have similar requirements, so there is broad appeal. Quick sales mean quick revenue. These companies may not be profitable for a while, but the revenue gives them a foundation for growth and ‘proof point’ for pitching venture capital and other investors.
Outside investors rarely have patience in revenue generation. This alone often “wags the dog” in GTM decisions.
The upmarket sales conundrum
Whereas SMB sales is a volume game, Enterprise sales is all about account-based marketing and complex sales. It’s much more complicated and slow moving, but, like an iceberg, it has a huge impact.
Vendors selling into Enterprise find it far too easy to miss a window of opportunity. POS systems may get replaced only every 7 to 10 years, for example. Lose the sale, and you lose the opportunity with that client for that product for nearly a decade.
Complicated needs require sophisticated software.
It goes without saying that Medium sized businesses have more complex needs. Enterprise has even more complicated organizational structures, operations, and needs. Here are a few examples.
- Larger operators cross state lines, and operations are complicated by differences in menus, sales tax rates, labor laws, and other regulations
- Enterprise restaurants typically have almost no corporate owned restaurants. This means many locations are franchises. These buyers may or may not be required to buy your product. Sales tactics and motions become much different and far more nuanced than the Small Business direct sales approach. The crueling crucible to sell a corporate contract can just give you a “license to hunt” the franchises.
- Staff turnover is a challenge everywhere. It’s exponentially more difficult for larger operators. Software needs to not only be easy to learn quickly; it also must include things like a robust self-service task-centric help system and the vendor must provide a robust implementation and support team. Selling hardware, onsite service and support is practically a must.
Consider what these different parameters and needs mean for the software provider.
- Much more complicated data structures and hierarchies, as well as reporting needs
- Ability to administer user and role-based permissions
- Security: PCI versus SOC-2 and penetration testing
- Coupling with or decoupling from payments providers and processors
- More complex and sophisticated user onboarding, training, and support as well as knowledgeable and well-staffed internal teams to support these functions
- Integrations with a broader set of vendors and behemoth software providers (which are typically glacially slow at everything)
- Menu changes that are “queued” for approvals and future publishing/push with regional differences
These are just a few examples of why it’s difficult for a software product built for SMB to scale up to adequately support an Enterprise operation.
Conclusion: Buyer Beware
If you operate more than ten units, how can you know whether your software vendor’s products will fit the needs of your organization, users, and for that matter - your guests? Ask questions. A lot of them. Here are just five to get you started:
- Does the vendor’s solution(s) work the way your restaurant does? This speaks to the product’s flexibility. You don’t want to be forced to conform to someone else’s way of doing business.
- Is the vendor solid, well-funded, and stable, to endure the considerable expense of developing, upgrading, and supporting a software product (or several)?
- Does the vendor demonstrate a technology stack, upgrade path and willingness to work with you to adopt new products and/or modules as your needs, budget and operational constraints allow?
- What is the vendor’s reputation among technology resellers and end users? And although one way to tell is to look at the brands they serve, a recognizable name-brand logo isn’t everything. Remember, some franchise systems let owners choose their software providers, and the vendor you are considering may only serve one or a handful of franchisees, not the entire brand.
- Does the software you are considering offer application programming interfaces (APIs)? But more importantly, are they well documented and open? This is essential for all the pieces of your technology ecosystem to ‘play nicely together in the sandbox’ so your operation can run as it should with few hiccups, even less downtime, and no finger pointing among vendors.
Up Next
I’ll explore that last point - integrations and APIs - in my next article in this series. In summary, today, the restaurant technology ecosystem lacks standards, and not enough people are pushing for these. We need to up-end the status quo for the benefit of everyone, from tech providers to operators to guests. Check back for a spicy discussion of this hot and somewhat controversial topic.
