A well-functioning POS system is essential for us in the food service industry. The customer doesn't see it, but they feel the effects when something doesn't work, such as the numerous problems and negative experiences we've had since switching to the Lightspeed K series. Unfortunately, many of these problems end up with the customer.
Our experience with the Lightspeed K series
Since Lightspeed is an international company whose hotline sometimes leads to nirvana, we are writing our experiences here in the blog. Maybe colleagues will use it or maybe someone at Lightspeed will listen to it and make a change. Because for us as a well-functioning restaurant, changing the POS system (again?) is not easy. A lot of programming and training time goes into every POS system and, ideally, systems interlock. We deliberately opted for Lightspeed K because it can connect to OpenTable, our preferred reservation system for many years, and - theoretically - also to other systems for merchandise management, accounting and so on.
Problems with Lightspeed K
Unfortunately, we haven't noticed much of this yet - because the automatic connection with DATEV Kassenarchiv online (the only accounting connection Lightspeed offers!) seems to be seriously flawed. And Lightspeed has not responded to requests for Lightspeed Inventory or Rest API for the last two weeks.
This article is still under development. After weeks of trying to clarify the problems with Lightspeed with the support, the account manager and even an external IT support for Lightspeed, we are writing down our experiences here and will post them with screenshots and more detailed information for other colleagues.
Here is just a very quick, provisional list of problems that we have noticed - and which Lightspeed does not seem to have fixed:
- The lack of an override query when someone else books into the table is a big problem. You receive no warning and simply lose the specified order. This is absolutely unacceptable.
- The list of individual items in the overview is completely confusing. Instead of seeing „3 beers“, three separate entries are displayed for „1 beer“. The display is extremely small and confusing, several articles are displayed as individual articles instead of being summarized. This is reminiscent of Computerwelt 1982.
- For some inexplicable reason, it is not possible to transfer an order from one table to another. The reason for this is not clear.
- It is not possible to add cash tips to orders afterwards. This is a big problem, as guests often leave cash behind after paying by card. If you want to record this correctly, you're stuck with Lightspeed. This is an unforgivable mistake as it affects the correct handling of money and table payments. In response to this complaint, Lightspeed has indicated that no change is planned.
- There is no haptic or visual feedback when you place an order or order an item. This could easily be improved with subtle animations to facilitate perception.
- The most important point: glaring weaknesses in the transfer of turnover to DATEV Kassenbuch Online. Data can only be transferred to the DATEV Kassenarchiv anyway. This limitation alone is significant. While Lightspeed K allows you to differentiate sales in an exemplary manner (articles are separated according to product groups and summarized independently in menus, so we can split our articles finely in terms of accounting but set up logical menu connections in the cash register operation), this differentiation cannot be exported cleanly because DATEV only allows rudimentary information. The documentation on this is full of euphoria, but ultimately weak in detail and meaningless. However, it becomes really problematic when the transfer from the cash archive to the cash book fails. And this is obviously the case if you have used training data on a particular day, for example because a new menu has been set up and the processes have been checked in training mode or because you keep trying to track down the problems with paying bills with mixed tips. In this case, totals are transmitted that do not match, the DATEV cashbook export fails and you have to rework manually. Lightspeed's suggested solution: simply do not work with payment data on the days when sales are made. Or in other words: always close one day and on that day the employees should come in for training. Is that still possible?
