How do I handle technical support issues with my POS system?

Protect guest service first, then touch the technology

When my POS system causes trouble during service, I treat it first as an operational disruption, not as a technical puzzle. For my team, that means not tapping around in five places at once, but narrowing the fault down cleanly within one transaction. For guests, it means I say openly that payment or ordering may be delayed for a moment and I keep the table attended. My first decision is always the same: is only one transaction failing, only one device, only one payment method, or the entire service flow. That order saves wasted attempts and stops a small issue from turning into a second one.

In everyday restaurant service, I organize a clear immediate-response role for this. One person stays with the guest or the affected table, a second checks the problem on the device, and only the shift lead decides on corrections. A typical example: an invoice cannot be completed. I do not let three servers try the same payment one after another. I note which table is still open, which payment method was intended, and whether any partial amount has already been posted. That discipline matters more than technical depth, because it prevents double charges, forgotten open tables, and contradictory shouted updates between service, bar, and kitchen.

Work out what kind of support case it actually is

I split support issues into four groups: taking the order, sending it to kitchen or bar, payment and closing, and access or role questions. That sounds simple, but in practice it is what keeps me efficient. If item selection works normally but orders are not reaching the production station, I do not start searching in the payment flow. If a card payment is failing, I avoid changing the order itself if I can. In BonZumo, the shared transaction data helps here: table, order, payment, and closing all refer to the same captured record. I can check the issue where it actually appears instead of reconstructing the entire evening backwards.

That is why I expect a short error report in everyday language from the team: what I wanted to do, what happened instead, which table or sale was affected, and since when it has been happening. A concrete report is far more useful than “the till is acting up.” For example: “Table 14, two mains added, order does not appear on the kitchen monitor,” or “counter sale 18.40 euros, cash works, card payment fails today on this device.” That lets me decide whether we are dealing with a station issue, a device problem, a payment connection, or an authorization topic. Especially during a shift change, this format prevents each person from interpreting the same case differently.

Never re-enter orders blindly

The most common risk in a support case is the duplicate order. If it is unclear whether an order was already saved or already sent to production, I do not enter it again by reflex. In BonZumo, I can reopen the affected table or transaction and check from the order context, note, and processing status what has already been captured. With configured production stations and kitchen monitors, I can also see whether the order is open or already being handled in the relevant station view. Only when the previous status is understandable do I decide whether to add it again, complete it, or simply inform the pass. That protects guests from receiving dishes twice and saves the kitchen from unnecessary work.

A typical organizational example from my own setup: on the terrace, a table of four orders two desserts, and shortly afterward the server says the ticket is “gone.” I do not start with the printer. I start with the table transaction. If the items are visible on the table but not on the monitor, the fault is more likely in routing or the station setup. If they are missing from the table entirely, the issue is order capture. If they are there and already marked as processed, I do not send them again; I clarify directly with the kitchen or bar instead. That keeps the decision tied to the actual data record, not to the noise level of the moment. That is exactly why a clean table context and traceable order flow are so valuable.

Handle payment issues separately from the order itself

When payment problems happen, I keep a hard separation between the sale and the payment path. If card payment stalls, that does not automatically mean the sale is lost. In BonZumo, partial payments, open amounts, tips, and receipt context remain visible in the same transaction. In support situations, that is crucial, because I can tell the team: do not delete anything from the table, do not ring the items in again, first check the open balance and any payments already recorded. A guest should not pay twice just because several people touch the same bill under time pressure. Especially with split bills by item or by equal shares, I assign each question to the affected share, not to the whole table.

In practice, I organize it like this: one person calmly explains the delay to the guest, while the shift lead checks through an authorized access whether any amount has already been recorded, whether only the terminal connection is failing, or whether the bill split is incomplete. If three guests have already paid and only the final card share remains open, I handle only that remaining balance. The fact that BonZumo keeps open and already settled shares together inside the same transaction prevents the classic confusion of a paper note, a shouted update, and someone’s memory. If I have set up terminal use, receipts, and bill splitting properly in advance, there is far less room for interpretation when something goes wrong; that is where Restaurant connections with clear setup requirements. becomes practically relevant.

Keep permissions, devices, and handovers clearly separate

Many supposed support problems are actually responsibility problems. A server does not need the same rights as the shift lead, and that is exactly as it should be. So when someone says something “doesn’t work,” I also check whether that person is even supposed to carry out that action. BonZumo uses roles and permissions to reflect responsibilities. In my operation, that means corrections, sensitive payment handling, or certain closing tasks are not available to everyone. That is not an obstacle. It protects us from spontaneous interventions in the wrong place. A technical fault and a missing permission can look similar in a stressful moment, but they have to be solved differently.

A realistic example: during busy evening service, a newly assigned shift lead tries to alter a transaction that has already progressed quite far, although that permission still sits with management. If I fail to notice that, I open an unnecessary support case with the provider. A better first check is simple: does the issue affect all devices or only this login? Does it affect every person or only this role? Does it happen only on the terrace or also at the counter? That logic helps me separate user error, role logic, and genuine system faults. At the same time, I record which device was involved, because a problem on one terminal, tablet, or checkout point is operationally very different from a disruption across the whole business.

Document every support case so it can actually be solved

When I contact support, I never send only “Please call back urgently.” I collect four things: the affected transaction or table, the approximate time, the exact last step, and the observed result. In BonZumo, transactions, receipts, cancellations, timestamps, and authorized actions remain traceable, and that is exactly what I use to turn a feeling into a verifiable case. For support, there is a big difference between “payment is broken” and “Table 22, 21:17, two items already paid separately, remaining balance card payment does not start, receipt still open.” That precision reduces follow-up questions and takes pressure off my team because the same story does not have to be retold three times.

After service, I do not review the day only emotionally; I review it against the closing. If there were discrepancies, open questions, or unclear cash movements, I look at the daily closing, Z reports, archive, and the related transactions. That helps me determine whether the issue only felt serious in the moment or whether it actually left a trace in the closing figures. After hectic shifts, that kind of follow-up is more reliable than anyone’s memory. For those questions, I regularly use Understand the day's activity before you close up, because the logic of closing, reports, and traceable transaction context is particularly useful in my daily operation.

The best support strategy is built before the next problem happens

Technical support problems can never be eliminated completely, but I can prepare for them so that the evening does not fall apart. I do that by training short standards and decisions, not long theories. Every new team member should know this sequence: stay with the table first, name the type of problem, do not enter anything a second time without checking, keep open balances visible, and involve the shift lead early. I also define which fallback process we use during short interruptions, for example who temporarily collects order notes, who informs the kitchen, and who re-enters transactions in an orderly way once the system is working again. That is organization, not improvisation.

What matters most afterward is a short debrief that produces real learning instead of blame. I ask: where was information missing, where was access unclear, where was the workflow too complicated? One example: if support cases almost always happen during bill splitting, I practice group bills and remaining balances specifically. If orders become unclear more often at one station, I review the configured production routes and whether they are understandable for service and kitchen alike. That turns each incident into a better next shift. For staff and guests, that is the fairest solution: not pretending technology always runs smoothly, but running the business so that even during a disruption, the work remains calm, traceable, and correct.