Here’s A “Feature” POS Companies Should Add to Their Core ASAP

We give companies a lot of crap when they step outside their “core”. One could argue that the core of any product or company is always changing thanks to technology and innovation, and we’d certainly be open to debating the particulars.

For companies engaged in developing point of sale (POS) at least, we’ve vehemently warned of straying too far from the core. The reasons will ring redundant, but we’ll mention them again because we can.

1. POS companies have historically had low margins. This is why payment processing companies are buying POS companies and not the other way around. As such POS companies never developed a sophisticated methodology for allocating capital to R&D projects… because they had none
2. Until recently POS companies have had difficulty attracting high quality engineers and product personnel. The unsexy nature of the business (20+ years to achieve an exit of a few million dollars) was unattractive to innovators and people who would push boundaries. In other words, POS companies are not inherently innovative
3. Merchants are fickle, unsophisticated, and a real pain in the ass to deal with. This was only compounded by the fact that POS companies were poorly built and required inordinate amounts of support relative to conventional systems. Brick and mortar customers would quickly suck the will to live from any dreamer who entered the market with delusions of grandeur
4. On the macro, software is getting easier and cheaper to develop. It does not bode well for the limited resources of a POS company when three sweaty engineers from MIT can built a better mousetrap for X and make the POS company look utterly foolish for attempting it themselves

Yet there’s one obvious direction where POS companies should be planning their roadmaps.

The world is getting more connected. We’ve played Sisyphus in saying that POS companies need to build and support their own API. An API is the portal for connectivity to the outside world, and POS customers recognize that the POS is never going to replicate Uber even if the POS company is delusional in believing it will monopolize everything.

But we’re not here to harp on APIs. That’s right, we’re tired of rolling that ball up the hill; if you’re too dumb to realize you need an API then stop reading our content.

For those that have already built an API and want to know what’s next, the following is for you.

Online ordering and delivery isn’t going away. The economics for third party demand generation are still massively unproven, but consumers are only demanding more convenience. See the below infographic from Gloria Food as a primer.

But what happens when merchants use 3, 4, or more online ordering and delivery providers? Should they be expected to to cover their countertops with tablets, one for each provider?

Of course not.

You might be thinking that the ordering tablets exist because the third party providers are not integrated to the POS.

You would be incorrect.

The tablets exist because the POS has no native interface to manage and throttle orders from multiple third parties. So how does a merchant receive and process orders from Grubhub, Uber, DoorDash and more? Until now the “easiest” solution was a tablet on the counter.

To solve this problem POS companies should build an aggregate online ordering portal that includes rate throttling. Rate throttling, something done well by Olo, ensures that both the merchant and the customer manage expectations. In the case of the restaurant, rate throttling ensures the kitchen isn’t overwhelmed. For the customer, rate throttling gives them realistic timelines for when to expect their meals.

As far as we’re aware Orchard has been the only POS to do this, though they haven’t finished the order throttling component. Granted they had a head start in that they built an online ordering company first.

We built the online ordering dashboard in conjunction with Orchard’s completely open and documented API  because a significant portion of a QSR or Fast Casual’s business will come from outside their four walls. Any competitive, next-gen POS will need a flexible API to accommodate wherever restaurant tech goes. Informed operator should want to understand if 3rd party online orders are, in fact, incremental (and not cannibalizing existing sales). Orchard’s reporting supports tracking of different order sources so operators can understand this.

Thomas Cecil, Orchard CEO

Very simply, POS companies need to build an order aggregation portal. But if you haven’t built a stable API yet, promptly ignore this advice and just shoot yourself now.