Look, few people are harsher on legacy POS than us. We find it ridiculous that these companies can’t invest a measly $20,000 in their own businesses to make their products more relevant and merchants more successful. That leads us to believe they’re either willfully ignorant as to where the market’s going, or they’re greedy.
The latter point might carry more water. Many of these legacy ISVs built their own bolt-ons and force-fed them to their jailed merchants in an effort to increment revenue. Loyalty, reporting, “analytics” – you name it, legacy ISVs have probably built it.
But in a delicious irony, cloud POS might beat legacy POS at its own game of avarice.
As much as legacy POS systems are a pain to deal with, the data is available locally. So if a merchant uses a legacy POS and wants a third party solution, that third party solution can build a software agent to tap into the local POS transaction data and extract it. Numerous third parties have done this over the past 20+ years; in fact, some merchants needed these third party data extraction services because their legacy POS dumped the data entirely (a la Micros 3700), leaving their finance departments quivering with frustration.
This, ultimately, is a huge architecture difference between legacy and cloud, but the new trend could become very unfavorable to the merchant.
On a cloud POS, the data is not locally available – it’s in the cloud. So if a merchant wants a particular loyalty program, for instance, they can’t simply grant that third party partner access to their POS to extract transaction data. Instead, the loyalty provider would need to get an API feed of the data from the ISV directly. And if the ISV already has a (likely-shoddy) loyalty program that they’ve built to increment their revenues, this third party solution would cannibalize those. Guess how that conversation ends?
This is the inherent danger of cloud POS, particularly from the ISVs that are “all-in-one”.
The merchant is only going to get what the ISV dictates they get, and that’s the end of it. As the ISV determines it wants to increase its breadth with additional, proprietary bolt-ons, merchants become more and more alienated.
The jury is still out on Shopkeep, but we will use their recent news as an example of what a cloud ISV could do to make their merchants’ lives miserable. That’s not to say Shopkeep will proceed down this path: we still need more evidence.
As background, Shopkeep has raised north of $70MM and hired new leadership. But they still don’t have a public API. What this means is that Shopkeep is only granting API access to third parties that they deem “fit”. I’m not advocating for an app store by any means, but what are Shopkeep’s criteria for determining who gets API access? It’s very nebulous and could be bad for the merchant.
For instance, Shopkeep recently purchased an online ordering solution, ChowBOT. This product will become the default service Shopkeep offers to its merchants for online ordering. The service will seamlessly tie online activity with the POS so orders and data don’t go misplaced – surely a noble cause anyone can get behind.
But the press release also mentioned that the service would integrate to delivery services, “… those like Uber and Postmates.” Okay, well what if the merchant has had a bad experience with those delivery providers and wants to use a different one? Or what if a particular delivery provider doesn’t even have coverage in the merchant’s geography? What if the only online ordering and delivery options offered through Shopkeep’s service charge merchants unreasonable rates based upon the terms Shopkeep negotiated?
Because Shopkeep is controlling who gets API access, the merchant might be significantly, and negatively, affected. And as the percentage of revenue from online ordering and deliveries grow due to consumer trends, the connection of your POS into the right third party platforms becomes a serious concern. If the merchant doesn’t like what the cloud ISV is offering because it’s too expensive or it doesn’t fit their business, the ISV is effectively saying “Too bad, so sad! Pound sand, amigo.”
If considering a cloud POS that views itself as an “all-in-one” provider, merchants need to be acutely aware of what the POS is locking them into, and if those services are, in fact, a good deal.
Although, as the market changes, it doesn’t even have to be cloud POS. As legacy POS systems update to replication (a pseudo cloud architecture that allows them to put data above store), local data will disappear. Aloha’s version 17, due out in about year, is one such update that will remove the local, historical grind files (i.e. transaction data) from the machine. Will NCR then erect a more formidable walled garden?
At least there were ways around the transgressions of legacy ISVs. With cloud and its hybrid variations, merchants might find all other avenues permanently blockaded. Be careful out there…
Since the merchant’s data is in the cloud and controlled by the ISV, what happens to all the data when the merchant changes his cloud based ISV provider?
The data is still used to help build analytical learning models, or at least it should be. So long as the data isn’t being shared externally and attributable to that merchant location, it should be of no consequence to the merchant. You have any idea what kind of data our credit card companies have on us? Not worth worrying about.
[…] And if Dutchie can’t get that payment margin, expect them to behave like Toast and start choking off third party integrations while they build their own, inferior versions of said tools. This post is now five years old but aging amazingly. […]