Setup is where a good system becomes a bad experience. The vendor installs the hardware in a morning; the part that decides whether your reports mean anything is the menu, and that is your work, not theirs. Done carefully it takes a week. Done in a hurry it takes two years to undo.
🗂️ Build the menu the way you read it
Your POS menu is not a copy of your printed menu. It is the structure your staff will navigate under pressure, and the structure your reports will inherit forever. Three layers, in this order:
- Categories. Match how the kitchen and the floor already talk: starters, mains, sides, desserts, beer, wine, cocktails, non-alcoholic. If your team says "apps", name it apps.
- Items. One item per thing a customer can order. Same name as on the printed menu — a server should never have to translate.
- Modifiers. The real work. Every variation, and whether it changes the price.
Two rules that save you later. Put the ten highest-selling items where they take one tap, not three — that decision pays off every night for years. And never create an item called "Misc" or "Open food": whatever ends up rung there disappears from every report you will ever run.
🧂 Modifiers, prices and the things that go wrong
Take your best seller and write down everything a customer asks for. That list is longer than you think, and each entry needs a decision:
| Type | Example | Decision to make |
| Required choice | Doneness, side, protein | Force it, so the ticket cannot leave incomplete |
| Free variation | No onion, sauce on the side, extra napkins | Add it, priced at zero. It must be a button |
| Paid addition | Extra cheese, add avocado, double shot | Set the price here, once, so it is never forgotten |
| Size or portion | Half, full, pitcher | Separate price, and separate inventory consumption |
| Allergy or safety | Gluten allergy, nut allergy | Must print loud on the ticket, not as a quiet note |
Prices go in once, in the system, and nowhere else. The moment a price lives in someone's head, it varies by who is working. And if you run different prices for dine-in and delivery, set that up now as a proper price level, not as a mental adjustment at the till.
🖨️ Routing, users and permissions
Three configuration jobs that take an hour each and prevent a year of friction:
- Print routing. Every item must know where it prints: grill, cold station, bar, expo. A drink that prints in the kitchen is a drink that arrives with the food.
- One login per person. Not one per role, not one shared code on a sticky note. This is the foundation of the next topic, and it costs nothing to do right on day one.
- Permission levels. Decide who can void a rung item, apply a discount, comp a table, open the drawer with no sale, and reprint a check. The default is usually "everyone", and the default is wrong.
Also set your day-end boundary — the hour the business day closes. If you serve past midnight and leave it at midnight, every late night splits across two days and your sales reports will never quite match your instinct.
📅 The switchover week
Do not go live on a Friday. The order that works:
- Days 1–3: build. Menu, modifiers, prices, routing, users. In the office, not on the floor.
- Day 4: ring your own menu. Take yesterday's tickets and re-enter them, exactly as they came. Every gap in the modifier list surfaces here, at no cost.
- Day 5: train. The eight tasks in topic 5, with everyone, before a customer is involved.
- Day 6: go live on your slowest shift. Both systems available, old one as fallback.
- Week 2: fix the list. Keep a running note of everything staff could not find. Fix it weekly, not "eventually".
Then verify the boring things before you trust the reports: that the tax rate is right, that a test transaction reaches your bank, that a printed check shows what you want it to show, and that yesterday's totals reconcile against the drawer. Find these on a quiet Tuesday rather than on a full Saturday.