By Bill Scott, President, StoreReport LLC
Every now and then I get a request from a vendor that wants to know how their products are selling in our customers’ stores. I don’t mind providing that information. It’s a simple task and if the short amount of time I spend helps our customers, then all the better. Lately, the number of requests have been increasing.
It appears that some vendors are wanting to use their customers scan data for their benefit, which hopefully will trickle back down to the retailers. The disturbing part is that each supplier seems to have his own unique way in which he wants the data, how the data is formatted and when and how it is delivered. This is just an extension of doing things the way we always have, and I wish I could stop it before the mess we have had in the past trickles up to the present.
Each unique brand of POS equipment already has its own special way that allows the retailer to get scanned data out of it. There is XML, fixed width (with a variety of delimiters), paper reports, ASCII delimited text files, CSV, FTP, uploading files to a web page and on and on. I hope it has not gone too far to be standardized, but it will if we do not get a handle on it soon.
NACS suggested a standard XML format, but there are so many POS vendors doing their own thing that it’s only popular with a few large operators, and, since the footprint of the industry has changed (the size of the average c-store operator had decreased over the years), every time we turn around, we have to write a new format for someone else, and if the vendor decides to change the format, the whole process can easily become a non-functioning nightmare. The whole system is designed to be run my experts that are specialists in their field, and that pretty much limits the ability of the majority of operators to participate.
There are some vendors (and operators) who shrug off the differences of how the data is handled, what it looks like and how it is delivered. It’s a classic example of putting the cart before the horse and working on the wrong end of the problem. The answer is simple, and the first prerequisite should be that the vendor should retrieve the data on demand, instead of relying on the store operator to get it for him, formatting it for each of them specifically, and complying with the unique way of delivery each vendor requires. Because, if they don’t, it’s not likely that the process will ever work universally.
Since 2003, we perfected a method that should be employed by all vendors and operators, regardless of the system they are using, not simply because it standardizes the way the data is handled, but it will sidetrack the enormous problems we will face in the future. Our method may not be the most popular method, but I am convinced it is far more conducive to getting where the industry wants to go from here.
- The data needs to be collected in real-time and placed in a common area where suppliers and retailers can retrieve the data and use it on demand. Accumulating it over a fixed period of time, and then uploading it to the suppliers in batches, defeats the main prerequisite for the data being accurate. It’s ludicrous to expect 150,000 convenience stores to hire IT people to satisfy the vendor’s requirements.
- Suppliers (and operators) need the capability of accessing the data in its raw form and translating it into the format they desire. Things will work a lot better if 5,000 vendors convert the data to fit their software, than it is for 150,000 stores having to comply with 5,000 different formats. In addition, those 150,000 stores are going to be a lot less capable of doing the conversions that the suppliers, who mostly have IT departments that can comply with the needs of the retailers.
- Since the data is in its raw format, it will be much easier for entities needing the data to be able to use it. There are only a few fields needed to give the supplier everything he needs. Things like, tender ID, the UPC, the company providing the data, the store number of the retailer, the timestamp, the selling price, the discount, etc. The supplier should not expect the retailer to parse the data out in any particular fashion. The job of creating the data in an acceptable format should be the responsibility of the POS vendor, not the retailer and it should be a selling point for the POS provider.
Immediately, when the sale is made, the record of the sale should be available over a secure Internet connection. The turn rate of the item can be established by simply counting the number of items sold during the period in question. Using a standard I.S.O. timestamp should be all the supplier needs to figure out the time period needed. I was going to say the vendor needs to access a common database to convert the UPC to a description of the item, but if the supplier is selling that product to the store(s), he should know the description of the item himself.
For the past 50 years, there has been very little standardization of collecting and disseminating data. It seems like every time someone tries to standardize something, greedy hands get involved in the process and the use of the data quickly becomes costlier than the value of it. Retailers are rightfully confused and the confusion is costing everyone a lot of unnecessary grief and money, resulting in losses across the board.
Let’s see if we can get together on this in a way that will benefit the industry in general, and not simply line the pockets of those that worked on the idea. Working on a standard that will serve everyone’s needs is a far better solution than having a bully tell everyone else how it should be done.
