Once you figure out what you’re doing – and I maintain it’s a continuous learning process – you can make the data entry and the functionality of the POS as complicated or as simple as you would like. However, at a minimum, each item, be it a comic book, a trade, or a toy, requires a unique entry in the system which includes the following data: description (or name), price, initial quantity (if you’re tracking inventory), and UPC (if available).
It took us a few months to get the bugs worked out. Sure, we could have read a few articles online, played around with some tutorials, or even just read the manual, but where would have been the fun in that? The “try stuff and see what happens” method of learning has served me well for 30 years. Hell, that’s how I’ve learned every software tool I’ve used in my engineering career. Why should a POS system be treated any differently? I mean, there’s just something so satisfying about pushing lots of buttons and finally stumbling upon whatever function you’re looking for, or better yet, something totally unexpected. It’s just a shame that sense of adventure or exploration is missing from today’s culture of instant gratification. But I digress.
Although it was a continuous learning process, we eventually figured out how the software worked, and more importantly, we determined which parameters and data sets we wanted to keep track of. Based on those requirements, we developed a repeatable process for handling our new items on any given Wednesday.
We would first count the new shipment to make sure everything was included and that there were no damages – not that Diamond would ever screw up an order. One of these days I’ll have to tell you about the time our entire order of 52 Week 52 was replaced by Checkmate. Good times. Now, while counting the order is pretty standard procedure for probably all comic book stores, our process had a few more steps to it.
After each title was counted, enough copies would be set aside to fill the pull lists, and one copy would be set aside, in a special pile, for entering into the POS database. The rest would be put on the shelves.
Once everything was counted and the pull lists filled (especially those of our customers who like to stop by before we officially opened for the day), we entered all the new items into our POS database. This involved creating a unique entry for each item. In the “Description 1” field, we typed the Title and issue number. We also had a “Description 2” field in which we included data such as “2nd printing” or “variant cover”. At a minimum, we also filled in the vendor, cost, quantity, and UPC fields. The end result looking something like this:
Department: Comic Book
Vendor: DC Comics
Description 1: Detective Comics #840
Cost: $2.99
Quantity: 50
UPC: 76194120019484011
Once entered, the books joined their brothers on the shelves.
There’s an old saying in many industries that is very applicable here; “garbage in, garbage out.” In other words, the system is only as good as the data you feed it. If you enter crappy data, you’re gonna get crappy data. And actually, how you enter said data is just as important. The set-up is really the lynch pin to the entire operation.
For example, let’s say in month N, employee A enters Friendly Neighborhood Spiderman #525 into the database, and she does so by typing “Friendly Neighborhood Spiderman #525” into the Description field, which in my book, is the correct way of doing so. And let’s say this employee follows the same syntax for the next several months. Smooth sailing, right?
Well, now we’re at “the next several months” plus one, and for whatever reasons, employee B is entering the data. Let’s say this employee just happens to be lazy, and enters the comic as “FN Spiderman #530.” Now, as long as the UPC is correct, the system will always find the book during a purchase and adjust the inventory quantity accordingly. But let’s say the scanner isn’t working, or you want to bring up a list of all Friendly Neighborhood Spiderman issues. Well, if you sort alphabetically, or do a search for “friendly,” #530 will not show up. And let me tell you something… for a detail oriented guy like myself, that’s incredibly frustrating.
Most of the problems we encountered were just variations of that same theme, i.e. we made errors during the set-up. Unlike Microsoft Office, in which a paperclip thinks it’s smarter than you, the POS system only does what you tell it to do, with the data you give it. Yet in my opinion, those few negatives were completely dwarfed by the numerous positives a POS system brings to the table, or in this case, the check-out counter.
The system integrates credit card processing, which was a big deal for us as most of our customers preferred to use credit cards. Yeah, as the retailer you have to pay a processing fee and the transaction doesn’t actually hit your books for a couple of days, meaning even though somebody bought $25 of comics on Thursday, the money won’t appear in your checking account until Monday, but I still say it’s better than having a bunch of cash lying around.
Gift cards are also a breeze for the retailer to load and equally as breezy for a customer to use when the store is running a POS system – just like at any other retail store. Imagine that; an LCS utilizing the same modern conveniences as all other retail stores.
You also have a detailed history of each transaction, with a receipt automatically printed and the electronic record stored. Those transactions can even be augmented by setting up profiles for your regular customers to track what items they’ve purchased and how much they’ve spent; data that comes in handy if your store has a rewards programs or you like to make recommendations based on purchase habits.
And of course, all of this recorded data makes certain tasks very easy. For instance, right now, it’s tax season, and all I have to do is export sales report from our POS systems and email that file to our accountant, and wham-oh, the dishes are done, man.
Another for instance is reviewing sales history to make more accurate initial orders. One of my Sunday afternoon tasks was to pull up a list of all the items sold that week, which I would then add to a ridiculously nerdy spreadsheet that I constructed to track all manner of sales data for comics including, but not limited to, graphical breakdowns of quantities sold vs. time. In other words, I could quickly see how many copies of each comic sold the first week, how many on the second week, etc. Ultimately seeing how long they sat on the shelf. That way I could ask things like, “do we really need to order 30 copies of Shadowpact if 12 of them are going to sit on the shelf for six weeks before someone buys them?
In Part 3, I will discuss my opinions of Diamond's customized POS system and why I think there is a resistance to this technology among retailers.
No comments:
Post a Comment