How a restaurant POS actually works, step by step
The chain of events from seating a party to money in the bank, and the five places it usually breaks. Authorisation is not settlement.
Insights
Page 10 of 11.
The chain of events from seating a party to money in the bank, and the five places it usually breaks. Authorisation is not settlement.
A screen times and routes tickets and cannot jam. Paper survives anything and cannot be bumped by accident. Why most kitchens end up running both.
Read the processing contract before the software one, pick your slowest fortnight, and rebuild the menu rather than importing it. The order that works.
Teach the nine-step sequence from seated to paid, then rehearse in service. The hard cases to train explicitly, and the two numbers that show it worked.
Build from the sales report, not the printed menu. Where modifiers go wrong, why notes fields are a leak, and the two people who must check it.
One daily, three weekly, two monthly, and the one everyone asks for that you should ignore. What question each report exists to answer.
Eight things, each tied to a question owners actually ask. If a system cannot do one of them, you find out in month four rather than in the demo.
Software is often a ninth of the total. Processing, hardware and the edges make up the rest, with a worked example and its assumptions stated.
Five ordinary questions neither system can answer alone, the two client lists that drift apart, and the honest case for leaving them separate.
Speed at the counter, a walk-in queue rather than a calendar, and chair rent mixed with commission. What to ignore from salon software.
Four pay structures, and where you work matters more than the licence. Why state comparisons are cost of living in disguise, and the arithmetic to do instead.
Not 100% against 45%. It is 45% of revenue against 100% minus every cost you just took on, and the question is whether your book is full.