By Jerry Cibley
The POS Man
Editor's Note: This is the first in a series of articles on POS systems. Further articles will explore such topics as the needs of quick service restaurants (QSRs), online ordering, table-side ordering with tablet devices, pay-at-the-table solutions, retail environments and cloud-based POS alternatives.
Well over 100 restaurant POS systems are being offered for sale in the United States. So how does one choose a POS system from among the myriad choices available? Consider this: similar to the eateries they serve, POS systems also have their specialties. You wouldn't expect a white glove, haute cuisine restaurant to make the best bar-style pizza, and your neighborhood QSR would not serve a Filet Oscar prepared with a 10-ounce filet, asparagus, lump crab meat and bérnaise sauce.
Restaurant POS systems can be broken down into the following major categories based upon restaurant style:
Today, all restaurant POS systems have certain commonalities: they place orders for food and drink at POS terminals and print orders in the kitchen. Beyond that, there are significant differences. Let's begin with the heart, or core, of the system - the database.
There is almost universal agreement among POS professionals that the preferred type of database for POS systems should be structured query language (SQL). Most POS systems have migrated to the SQL standard, but many legacy systems are still not using an SQL database engine.
SQL is very stable and has an open architecture, making report customization a breeze utilizing an SQL report writer or through SQL query generation. It takes a bit of expertise, but that expertise is readily available among database programmers.
A major advantage of SQL is its robustness, so it experiences minimal data corruption. Stable data is paramount and, in my opinion, expected stability is a good enough criterion to use when selecting a POS system. No more re-indexing or dealing with such commands as deleting index files and performing sophisticated surgery from time to time on a corrupt database.
It may surprise you that three or four of the most common and popular POS systems are still using legacy and proprietary databases. If your POS system requires a re-start after adding or changing a menu item, odds are it is based upon a legacy database. A few databases are known as "self-healing," and although not SQL, they never fail or corrupt, and all terminals update changes in seconds without rebooting or manual update commands.
How does the POS handle the remote printing functionality? If a POS does not have a dedicated print server to manage the printing tasks and instead relies on the built-in Microsoft Windows printing capabilities, one can expect a great deal of printing issues to surface.
A dedicated print server insures that if a printer in the kitchen is offline or out of paper, the print job is immediately routed to a secondary, or backup, printer in approximately 30 seconds. When evaluating POS systems, it's essential to ask how long the POS waits before it re-routes an order to the alternate printer. I know of a system that has an eight minute delay before re-directing a failed print job.
In the restaurant world, 30 seconds is an eternity, but you need to allow a minimum of 30 seconds in case a chef is changing the paper mid-shift. However, an eight minute wait is just as bad as not having any type of printer redundancy.
It is also important to consider how a system deals with a catastrophic failure. Did you know that many systems no longer require a dedicated "server" or main computer? Instead, one of the stations will function in a dual capacity as server and station.
Ask your salesperson what happens if the server unit fails in the middle of a busy Saturday night. Are open checks constantly backed up to a mirrored drive or will the tech support restore you to yesterday's back-up, which contains yesterday's or last week's menu and no open checks?
Some restaurants may have $20,000 or more in open checks during a busy weekend. Imagine the restaurateur's horror if "restored" data does not include the open check file. The answer to this question is so critical it should be put in writing. There is no excuse for a system not having total redundancy and the ability to continue business as usual after a single point of failure.
Many POS systems claim to be Payment Card Industry (PCI) Data Security Standard (DSS) compliant but, in fact, are not. Thus, a system's PCI compliance should be confirmed via Visa Inc.'s website at http://usa.visa.com/merchants/risk_management/cisp_overview.html. Private-labeled versions of software that have any changes made to them by the manufacturer need to have unique and separate PCI certification. They cannot fall under the umbrella of the branded version. Also, to be fully compliant the POS system's primary unit, with keyboard, must be behind a locked door.
The traditional full-service POS model implemented in the 1990s has given way to a number of self-service models, rental programs, "free POS" programs and more. Merchants must decide if they are capable of switching out POS equipment on their own under the direction of a remotely based technician, or whether they are willing to pay the increased price for a POS system that comes with true on-site service. Both have a place, and I think that the cost savings available through some of the newer programs is certainly worth exploring.
Jerry Cibley, known as The POS Man, is a 25-year veteran of the POS business, as well as a seasoned payments industry professional. He has been the founder of three POS dealerships servicing New England during his career. Formerly in charge of national sales training for a major U.S. ISO, he specializes in teaching ISOs and merchant level salespeople the intricacies of the POS business so they can, in turn, provide expertise to the merchant community. For more information, please email Jerry at firstname.lastname@example.org or visit www.theposman.com.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next