We are all familiar with the tale of Blockbuster. If not, here’s a quick rundown.
Blockbuster ran a chain of very successful video rental stores in the 1990’s. As the internet developed, people preferred to rent movies from the comfort of their homes instead of driving to a store. Netflix, the pioneer in in-home movie rentals, tried selling itself to Blockbuster, but Blockbuster thought itself invincible. The market predictably changed, Blockbuster declared bankruptcy, and Netflix flourished.
Hindsight is 20/20. Hopefully.
Part of the value of learning about past failures is to avoid the pain. “Those those who do not remember the past are condemned to repeat it,” or something like that, right? So when stories of Blockbuster and Borders permeate our recent past, one has to wonder how some people still don’t learn from someone else’s failures.
Yet this is legacy POS to a fault. The brick and mortar market is and has been undergoing drastic change yet too many legacy POS providers have found themselves flat-footed. If their organizations were the only ones to suffer, that would be one thing. But because legacy POS companies have dealer channels and customers – who must go through a painful process to replace their POS – these bonehead moves have adversely affected many people who are likely viewed apathetically as collateral damage.
Before we proffer the unquestionable solution, let us turn our attention to the legacy POS providers (ISVs) who are undoubtedly reading this and stewing. Okay Mr. Legacy ISV: we dare you to answer the following questions honestly.
- My merchants want to come into the store to update their menus/items?
- My merchants want to come into the store to see a report?
- My merchants want to key online orders into their POS at the store?
- My merchants want their businesses to crash with one hardware failure?
- My merchants want their businesses hidden from customers on Google, Yelp, Bing and others?
- My merchants want an expensive headache when integrating third party services?
- My merchants want to waste money on marketing and never measure ROI?
- My merchants want no way to remotely diagnose and support issues?
- My merchants want to be using outdated software with known bugs?
- My merchants want to waste money on inventory and labor?
If you answered yes to any one of these questions you should be ashamed. Yet we know legacy POS companies who, if honest, would have answered yes to all of these.
Why should legacy ISVs be ashamed? Because the cost to fix this is trivial.
Let’s go bottom-up.
An average store produces 25MB of daily transaction data in antiquated, flat-file formats – which is much larger than SQL data of the same history, but we’ll use the larger figure to be conservative in our numbers. Over the course of a year, that’s a little over 9 GB in data volume. If we assume each location maintains 3 years of historical data, that’s 30GB per store.
To move the data to the cloud one would need to use a snapshot replication service. These services are based on active server time. That is, the longer your replication takes, the more it costs. Time is based on the amount of data being replicated, along with the data upload speed. For ongoing transactions, one would then use a transactional replication service that sends any new data up to the cloud when it occurs.
Here’s a pricing chart of server time from Amazon’s data replication services.
For the purposes of POS replication, there’s no need to use c4 instances though it could be argued that multi-AZ should be used for redundancy. Therefore we’ll calculate a range of pricing to remain consistently conservative.
The biggest variable is merchant upload speed. If we assume that we don’t compress the database on the first upload, it could take a while. Let’s assume the average legacy merchant has an upload speed of 1 MB per second. That equates to 3.6GB transferred per hour, which means you could shoot up the 30GB of data in 8.5 hours.
Taking that 8.5 hours of server runtime and multiplying by the cheapest option ($0.018/hour) through the most reasonably expensive option ($0.292/hour) produces a cost range of $0.15 and $2.45 to replicate the data. Oh, and this doesn’t include any sort of compression, which could cut that price by 90%.
Suffice it to say snapshot replication is CHEAP – reasonably WAY LESS than $2.50 to replicate historical data.
On an ongoing basis you’d want to send up the new transaction data preferably every few seconds. Over the course of a year, the cost for this is 1/3rd of that $2.50 price – another $0.85 per annum.
So full replication costs for one location are less than $4 per year.
Now we need to talk about data storage. Replication instances come with some storage, with AWS giving us a free 50GB per t4 instance. Let’s ignore this and assume an ISV has to pay for all their storage separately. We’re going to recommend porting that data over to Amazon’s S3 service for latency (and because there’s already a permissioning layer for API access).
If we assume the average legacy ISV has 5,000 merchants, with each merchant needing to port over 30GB of historical data, that’s 150TB of data. At $0.022 per month per GB, that’s $3,300 in annual storage fees.
Adding the costs for replication ($4 * 5,000 locations) with the costs for storage ($3,300) get us to $23,300. This should be a worst-case cost for replicating data from 5,000 locations. Any decent engineer would be able to knock another $15,000 off this with compression and instance management, but we’re ignoring that just to show how ridiculous legacy ISVs are behaving.
If we take that worst-case number above ($23,300) and divide it across the ISV’s 5,000 merchant locations, the annualized cost to move data to “the cloud” is $4.66 per location.
Now that the cost is clear, why should an ISV invest the money to do this? What’s in it for them? Aside from the ethical considerations of collateral damage to their dealers and customers, why give up that country club membership and new jet ski?
Because they could buy more even jet skis if they pulled their heads out of their asses.
Replicating data means resellers can claim that your POS system is more relevant (look at how customers are increasingly demanding cloud POS systems). Customers also have a better experience with seamless third party integration (enabled via the S3 API). Both considerations mean less churn for the ISV.
But we haven’t even talked about the immediate financial benefits.
As soon as an ISV has the transaction data, they can begin incrementing their own revenue substantially. By passing the data to merchant prescriptive analytics products (which are sold preemptively on ROI), ISVs can now increment revenue per account. How much? Let’s go through some real world examples.
We find the merchant attach rate for prescriptive analytics to be between 30% and 50%. This large discrepancy is based on segmentation: a small merchant who runs a lemonade stand is not going to pay for much besides POS and payments, whereas larger merchants – over $750K per year in revenue – find greater ROI in data solutions. In fact a merchant who does $1MM a year in revenue can expect $50K in ROI from prescriptive analytics.
Let’s make the math easy and say the price for the prescriptive analytics tool is $100/mo. Since legacy ISVs have proven incapable of even building decent database structures, they’re going to need to find a white label partner for the prescriptive analytics. Like Apple’s app store model, let’s assume the developer takes 70% of the revenue and the ISV the remaining 30%.
We also know from experience the sales cycle for conversion is < 90 days. Let’s assume it takes the full 90 days just to be conservative on our math again. So between 30% and 50% of an ISV’s customers are paying $30/mo for 9 months in the first year. Want to know what that amount to?
9 months x $30/mo x 30% conversion (being conservative!) of 5,000 merchants = …
$405,000 a year for a measly $23,300 investment!!! That’s an ROI of 1,640%. And it’s not even including additional product or services revenue (which we’ve proven to be at LEAST as much).
Oh, and by the way, this is the financial benefit in only the first 12 months: never mind that this is an ongoing revenue stream. And really, since there are no other costs associated with this revenue, it’s actually pure profit.
But of course having data makes the ISV relevant in tomorrow’s market – where 100x the revenue will be made possible as POS companies start to tap merchant marketing budgets with data partnerships (which will be discussed in a later post).
The math on this is incredibly clear. The problem with many legacy ISVs is that they have no shareholders who are educated enough to relay this reasoning. And like their merchant customers, too many ISVs cannot be bothered to return emails or phone calls. Yet it’s crazy when we objectively examine the numbers, especially since the ISVs have the most to gain from a trivial investment. Maybe their acquiring payments companies will pay more attention as here we are, eight years after the introduction of cloud POS, and the majority legacy ISVs still haven’t figured this out.
Add comment