Just Ask Gary: Why Restaurant POS Systems Won't Pass the Mustard for Your Community.


It is not uncommon for us to encounter communities who are considering a standard restaurant style Point of Sale system since, on the surface at least, they appear to be able to handle the needs of Dining Services.  It is not until we dig a little deeper that we discover the very real reasons why these types of systems simply do not work in a retirement community setting.


Certainly every POS system on the market will enable you to perform easy order entry and provide the needed item movement reporting that you require to manage your food service operations.  Some will even allow you to run a “tab” for customers and receive funds on account when they pay their bill.  While this might satisfy the basic operational needs for the Food Service Manager, it creates a huge administrative burden for those responsible for billing and Accounts Receivable. In a typical restaurant environment, few customers ever leave without paying their bill!


Let’s consider a straight declining dollar balance plan for your residents. While most restaurants might allow a few customers to run a “tab”, a typical retirement community will be looking at anywhere from 100 to 1000 “tabs” for which a regular POS system is simply not designed.  Those systems  may  require you to go into each and every customer’s profile at month end and create a statement, apply a payment to each account, clear their balance and renew any prepaid privileges you might provide them as part of their “meal plan credits”.  If that sounds like work to you, you’d be right!


Next, consider a Meal Click or Meal Points environment.  There are some  very creative methods in an attempt to replicate this complicated process with a standard POS system but in the end, it always creates more work and confusion.  


  • How does the system distinguish between items that are meal plan eligible and those that are not?  More importantly, can it distinguish them without cashier intervention or the need to ring them up as separate transactions.  

  • What happens when a resident does not use up all their meal credits?  Does someone have to tediously go in to each Resident account and update / renew their balance each month?


There is also the technology issue.  Most restaurant style applications need to store very limited data and therefore can get away with using a very low end, consumer grade database such as MS Access.  In a Retirement Community environment, you will want to store all transaction data for extended periods whether it be for financial reporting, audits, nutritional reporting, or simply the Residents desire to access their spending information.  As with most things, “you get what you pay for”.  Low end databases typically run into difficulties whether it is noticeably slower performance or, when the database gets too large, crashing the application.  Systems such as CARDWATCH employ enterprise class database technology that can easily store and index tens of thousands of transactions per day for years to come without any noticeable effect on performance.


One CARDWATCH client performs 28,000 multi-item transactions per day from 9 food service and retail environments with more than 24 POS terminals. Transaction and account data accumulated over the last 6 years has amounted to less than 300 megabytes of storage space and no detectable performance issues due to the robust nature and efficiency of data compression within the database.  These days, you can store that amount of data on a cheap USB flash drive!  Now that is efficient!


Lesson Learned: In the end, the “cheaper” restaurant POS solution may end up adding substantially increased labor costs in an effort to manage resident accounts effectively.


--------------------------------------


Gary McMullen has over 30 years experience in the Point of Sale and Privilege Management (meal & spending plans) industry and has provided consulting services to the Retirement Community and seniors housing market to help shape what is possible today.