Omnivore, a middleware that serves as a scalable API between POS companies and developers, has recently closed $10M of fresh funding… and we don’t get it. But more on that below.
Let’s start by noting that Omnivore exists for two primary reasons.
- The POS market is massively fragmented. As we’ve detailed in other posts, there are over 250 US restaurant POS systems and the largest single provider, until recent roll ups by Heartland and Shift4, was at 70,000 locations – barely 10% of the market. (We’re referring to NCR’s Aloha POS, but that POS is shedding > 10% of its users annually due to some horrible business practices).
- Too many POS companies are run by inept people. These are people that don’t reply to outreach for business development and can’t be bothered to make relatively trivial investment to help themselves (we can only imagine how horrible their customer response must have been, too). As such, developers who must integrate to the POS spend more time chasing down a response than they do building their damn product.
For solving these two problems, Omnivore deserves praise. But when you understand this industry at the level we do, Omnivore’s raise becomes a real head-scratcher.
First, POS integrations are a problem, but it’s a problem that’s rapidly disappearing. Cloud POS companies are almost always API-first and even a large portion of legacy POS companies have invested in their API architecture and written it off as a cost of doing business – i.e. very few POS companies have tolls for integration. If you want an example look no further than the good work being undertaken by Global Payments and Shift4: these two POS horsemen are investing in universal APIs across their POS portfolios to bring more value to their merchants via integrations.
So as we’ve noted previously, POS companies are increasingly viewing their APIs and integrations as core business – as they should. Outsourcing this core value to a third party – in this case, Omnivore – poses huge strategic risks to POS companies. In this sense the API integrations that Omnivore offers are anachronistic: a definite problem 10 years ago, but not a real problem in 10 months.
Second, the integration costs middleware providers add are enormously uneconomic. Using the case study authored by Freepay, we see precisely how expensive middlewares like Omnivore are for developers and merchants alike.
A search one day revealed two competing services that promised to solve our integration woes: Omnivore and SimplicityPOS. Both offer their own “universal point of sale” API that provides a single cloud-based point of integration to connect us with a dozen or more POS systems, thus saving us the trouble of integrating with each different system individually. These services appeared to be the magical solution to cover all of our needs.
We started researching Omnivore first since it boasted an app marketplace (like an app store for hospitality businesses) that listed 11 of our known competitors. While Omnivore had posted its pricing online (they have since taken this down for reasons I can only guess involve scaring potential customers away), they did not publish their documentation publicly to show what their API could actually do. They did, however, offer a 14-day trial, so I jumped in and found the documentation we needed. Knowing that the trial would end and that I would be charged a minimum $250 per month regardless of whether I had integrated with any locations or not, I printed PDFs of every page of documentation and deleted my account.
Documentation revealed that, while they could support integrations with between 14 and 17 point of sales systems for simply reading a customer’s ticket, they could only support eight services for handling “card not present” payments: Aloha, Brink, Dinerware, InfoGenesis, Micros 3700, Micros Simphony 1, POSitouch, and XPIENT. Only five of these services surfaced in our local markets at all and only Aloha and Micros appeared in our top ten. Perhaps it could have been worth it to save the development time and hassle required to integrate with a dozen or more services. But only two? Not so much. Surely Omnivore offered us more than just that?
I got on the phone with a member of the Omnivore sales team and dug a little deeper.
- First, could Omnivore help us integrate with merchant accounts to process payments and complete the full user journey? No, but they could refer us to another service that will. Does Omnivore get discounts with that other service? Nope.
- Second, how does Omnivore approach integrating with legacy systems? Well, Omnivore sends a support team to install the integration at each individual location and takes an hour of their time. Sounds expensive. Oh, and a back of house server that’s not online will never work. Duh. Ok, no magic there.
- Third, how many locations have enrolled with Omnivore? At the time, they had enrolled only 5,300 locations and aimed to enroll 12,000 by the end of the year (including around 2,000 Chick-Fil-A locations largely useless to us as fast food counter service experiences). Odds were pretty high that few-to-no locations in our local markets had enrolled with Omnivore, so we would need to do Omnivore a favor by signing up restaurants and bars onto their platform ourselves to support our own app.
- Fourth, does Omnivore handle the licensing and certification between us and each point of sale provider? No, we still need to go through Aloha and every other POS company to license the app ourselves. Our partner restaurants that use Aloha will need to request that license. More merchants requesting the license would help Aloha take notice and speed up our application. Omnivore has a few relationships with Aloha, but none that waive the costs associated with licensing or do all that much to reduce the time it takes to integrate with them. The sales person estimated Aloha licensing to cost $30 per location per month (in addition to what Omnivore would charge), but he wasn’t sure.
- Finally, what does it take to get onto the Omnivore app marketplace? You need to sign up for the Omnivore Pro Plan at $1,000 per month. Do we get anything else for that service that’s worth the extra $9,000 per year? No, not really. Ok, cool. Bye.
Holy crap. So basically, we’d pay a flat $250 to $1,000 per month plus $20-$25 per location per month just to save us a little time integrating with a handful of bonus services we might not even need? Without any help integrating with payment processors? Without a solve for merchants using offline legacy platforms? With a very narrow existing restaurant base we can more easily market our app to? With absolutely no assistance forming necessary partnerships with these fascist POS partners? And, as a cherry on top, if we signed up 1,000 restaurants into their ecosystem, we’d pay Omnivore $21,000 per month or $252,000 per year (double what we’d pay a developer) and get nothing at all in return for expanding the Omnivore network?
Sure, it’s probably a headache to write code to integrate with these antiquated systems, but can it possibly be a big enough headache to pay that much? And Omnivore’s costs do not include the extra licensing fees per location we would have to pay some of the POS companies themselves.
After one call and five minutes running the numbers, I knew that we could never go into business with a solution using Omnivore. Many of the shuttered competitors like PandaPay, TABu, and Tally were all listed on the Omnivore marketplace, so we started to wonder if they were spending too much money on Omnivore with too few paying restaurant enrollments to stay afloat.
Further to this point, as a developer you need to build relationships with the POS companies. If you can’t figure that out then your company isn’t going to succeed. It’s the same rationale investors take regarding customer-less startups looking for funding: if you can’t figure out how to get customers without raising money then money isn’t going to help you.
Lastly, we should talk about the SKU data Omnivore is collecting. That Coca-Cola and Performance Food Group were investors tells you Omnivore is looking at monetizing the data it collects through its integrations via suppliers which, frankly, the industry needs. However, we have two questions that the investors should surely have answered.
First, in relative terms, we don’t think Omnivore has all that much SKU data; WhatsBusy has SKU data from 10x as many restaurants, for example, and it’s growing as more POS companies turn to us to help them productize their data. So what are the suppliers really after, or were they unaware of existing market dynamics around the data?
Second, why would POS companies let Omnivore take the upside in their transaction data? POS companies should be building partnerships to execute the upside on their SKU data, and many have with WhatsBusy (we don’t own the data or customer relationship, by the way). Maybe Omnivore becomes another partner, or maybe they don’t. Either way we already discussed the concerns we have with third party delivery/ordering companies usurping this value from the POS industry and Omnivore is no different. Barring changes to contracts Omnivore has with POS companies, we don’t see why POS companies wouldn’t disintermediate Omnivore since they already have all the SKU data – just not the know-how and time to productize it maximally.
Given that POS companies are owning their API integrations and becoming educated on the upside in their businesses (patting ourselves on the back for making this education possible via Reforming Retail), we just see too much risk in the business model of a middleware provider like Omnivore to understand what investors would see.
Then again there were countless investors that passed on AirBnB too.
