Skip to main content

POS Implementation Guide — Restaurant

This is the real-world implementation methodology for onboarding a restaurant onto FlowPOS. Restaurant implementations are fundamentally different from retail: the complexity lives in the menu, the service model, the kitchen workflow, and the speed of service — not in the product catalog. Success is 80% operational decisions + data preparation, not software configuration.

✅ POS Implementation Guide — Restaurant

Phase 1 — Business Discovery (Understand the Operation)​

🎯 Objective​

Understand how the restaurant actually operates — not how the owner thinks it operates. A restaurant is a system of simultaneous moving parts. You must map all of them before touching configuration.

What you must gather​

Business structure

  • Legal business info (NIT, fiscal address, SAT regime)
  • Number of locations / branches
  • Ownership model (single owner, franchise, chain)
  • Operating hours per day and per location

Service model (critical — defines everything else)

  • Dine-in only
  • Takeout only
  • Delivery (own fleet, third-party: Uber Eats, Hugo, Rappi)
  • Drive-thru
  • Catering / events
  • Bar service (drinks-only station)
  • Counter service vs. table service

Key operational questions

  • Do they split bills by seat or by table?
  • Do they handle tips? How are tips distributed?
  • Do they allow partial payments (cash + card)?
  • Do they manage open tabs (bar model)?
  • Do they have happy hour or time-based pricing?
  • Do they sell by weight (buffet, deli)?
  • Do they have a loyalty or points program?
  • Do they handle reservations?
  • Do they need kitchen display screens (KDS) or kitchen printers?
  • Do they use a separate bar printer?

👉 Output: ✅ Implementation scope ✅ Service model map ✅ Modules to enable (tables, delivery, kitchen, bar, etc.) ✅ Complexity level

Phase 2 — Menu Architecture (CRITICAL in restaurants)​

This is the most complex and most underestimated phase. A bad menu structure will cause problems every single day of operations.

🎯 Menu hierarchy to define​

Menu
  └── Category (Entradas, Platos Fuertes, Postres, Bebidas…)
        └── Item (Pollo a la plancha, Limonada, Brownie…)
              └── Modifier Group (optional but critical)
                    └── Modifier Option (Término de cocción, Tamaño, Sin cebolla…)

Modifier groups — the core complexity​

Modifiers are what make restaurants hard. Every modifier group needs:

FieldExample
NameTérmino de cocción
Selection typeSingle (pick one) or Multi (pick many)
Required or optionalRequired
Min selections1
Max selections1
OptionsRojo, Tres cuartos, Bien cocido
Extra charge per optionQ0 / Q5 / Q0

Common modifier group types to expect:

  • Cooking temperature (steaks, burgers)
  • Size / portion (small, medium, large)
  • Add-ons (extra cheese, extra protein)
  • Removals (sin cebolla, sin gluten)
  • Side choice (included side dish selection)
  • Sauce choice
  • Bread / base choice (pizza, sandwiches)
  • Preparation style (frito, al vapor, a la plancha)

Combos and promotions​

  • Fixed combos: burger + fries + drink at a fixed price
  • Half-and-half: two items split (pizza ½ + ½)
  • Meal upgrades: +Q10 to make it a combo
  • Happy hour: category-level discount at specific hours
  • Daily specials: item available only on certain days

Many restaurants have different menus per channel:

  • Dine-in menu vs. delivery menu (different prices or items)
  • Lunch menu vs. dinner menu
  • Bar menu vs. kitchen menu

👉 Output: ✅ Full menu structure document ✅ Modifier groups per item category ✅ Combo and promotion rules ✅ Menu variants per channel

Phase 3 — Master Data Preparation (Most painful step)​

This is where implementations fail — same as retail, but the data is messier. Most restaurants have their menu in a printed card, a WhatsApp message, or the owner's memory.

🎯 Data to collect​

1. Menu items​

Columns:

  • Item name
  • Category
  • Description (for online ordering / client portal)
  • Base price
  • Tax type (exento, 12% IVA — per SAT Guatemala rules)
  • Available for: dine-in | takeout | delivery
  • Available days / hours (if restricted)
  • Kitchen station (grill, cold station, bar, fryer…)
  • Active / inactive

2. Modifier groups and options​

Columns:

  • Item name (or category it applies to)
  • Modifier group name
  • Selection type (single / multi)
  • Required (yes/no)
  • Option name
  • Extra charge

3. Combos​

Columns:

  • Combo name
  • Items included
  • Combo price
  • Individual item prices (for partial combo discounts)

4. Ingredients / recipes (if inventory control is in scope)​

Columns:

  • Item name
  • Ingredient name
  • Unit (gr, ml, piezas)
  • Quantity per serving

⚠️ Ingredient-level inventory is optional for v1 but should be scoped explicitly. Many restaurants start with item-level stock counts only.

5. Suppliers​

Columns:

  • Supplier name
  • Contact
  • Products supplied
  • Payment terms
  • Delivery frequency

6. Staff and roles​

Columns:

  • Name
  • Role: manager | cashier | server | bartender | kitchen
  • PIN (for POS login)
  • Commission or tip pool participant (yes/no)

👉 Output: ✅ Clean menu import file ✅ Modifier group import file ✅ Staff roster ✅ Data mapping to FlowPOS tables

Phase 4 — Floor Plan & Table Configuration​

Dine-in service requires mapping the physical space.

🎯 Define​

Zones / sections

  • Main dining room
  • Terrace / outdoor
  • Bar area
  • Private room / events room
  • Drive-thru lane

Tables per zone

  • Table number or name
  • Seating capacity
  • Joinable tables (tables that merge for large groups)
  • QR code per table (for self-ordering, if in scope)

Service stations

  • Which server attends which zone
  • Whether the system enforces station ownership or allows any server to service any table

Bar model (if applicable)

  • Open tab by customer name or seat
  • Tab transfer between servers
  • Tab hold and close flow

👉 Output: ✅ Floor plan diagram ✅ Table list with zone and capacity ✅ Station assignments

Phase 5 — Kitchen Workflow Configuration​

This defines whether the kitchen runs smoothly or collapses under pressure.

🎯 Define​

Kitchen stations

  • Grill / hot station
  • Cold station / salads
  • Fryer
  • Bar / beverages
  • Desserts / pastry
  • Expediting station

Order routing rules

  • Which menu category goes to which kitchen station
  • Do beverages print separately at the bar?
  • Do desserts fire immediately or on request?
  • Does the system hold items until the full table orders?

Output method per station

  • Kitchen Display Screen (KDS): real-time, no paper
  • Kitchen printer: physical ticket per order
  • Both (KDS + backup printer)

Ticket format decisions

  • Print item name only, or include modifiers
  • Print table number and server name
  • Print order time
  • Fire vs. hold courses (starter fires immediately, main fires on request)

Bump / completion flow

  • Does the kitchen mark items as ready on screen?
  • Does the server get notified when an order is ready?
  • Does the system track ticket time (speed of service metric)?

👉 Output: ✅ Station list with routing rules ✅ Hardware list per station ✅ Ticket format decisions ✅ Course firing rules

Phase 6 — Hardware & Infrastructure Setup​

Restaurants have the most complex hardware footprint of any retail vertical.

🎯 Define per location​

POS terminals

  • How many terminals at the counter / bar
  • Tablet-based service (server takes order at table)
  • Self-ordering kiosk (if in scope)

Printers

  • Receipt printer (cashier station)
  • Kitchen printer(s) per station
  • Bar printer
  • Label printer (takeout bags, delivery orders)

Kitchen Display Screens (KDS)

  • Screen per station vs. one central screen
  • Bump bar or touch screen

Network

  • Wired vs. Wi-Fi per terminal
  • Router / switch requirements
  • Internet backup (USB modem for connectivity failure)
  • Local mode: does the POS work offline?

Cash management

  • Cash drawers per terminal
  • Cash drop / blind count procedure
  • Float (fondo de caja) per shift

👉 Output: ✅ Hardware checklist per location ✅ Network diagram ✅ Cabling / installation requirements

Phase 7 — Process Configuration (This defines success)​

You configure workflows, not screens. A misconfigured restaurant workflow breaks service during the peak hour rush.

Must define​

Order flow

  • Table opened by: host, server, or self-service
  • Order entry: cashier-only or server tablets
  • Order modification rules (after sending to kitchen: who can modify, and with whose approval)
  • Void and discount authorization (manager PIN required?)
  • Split bill: by seat, by item, or by amount

Payment flow

  • Accepted methods: cash, card (POS terminal), QR (Visa/MC QR Guatemala), store credit
  • Tip handling: included on card receipt, separate prompt, or cash-only
  • Bill rounding rules (Guatemala: nearest Q0.05 or Q0.10)
  • FEL electronic invoicing (SAT Guatemala): trigger on every sale or on customer request
  • Invoice by: NIT, CUI, or CF (consumidor final)

Shift management

  • Shift open / close procedure
  • Cash count (arqueo) at open and close
  • Z report generation
  • Tip pool distribution at shift close

Delivery flow (if applicable)

  • Own delivery: assign to delivery rider, mark as dispatched, confirm delivery
  • Third-party (Uber Eats / Hugo / Rappi): order comes in via integration, routed to kitchen as normal order, marked fulfilled in both systems
  • Delivery order contains: address, contact, special instructions, estimated time

Returns and voids

  • Void before sending to kitchen: free
  • Void after sending to kitchen: requires manager approval + reason
  • Full order cancellation: refund process + kitchen notification
  • Comps (complimentary items): manager auth, reason required

👉 Output: ✅ Order flow SOPs ✅ Payment flow SOPs ✅ Shift open/close procedure ✅ Void and discount authorization matrix

Phase 8 — Staff Training​

Restaurant staff turnover is high. Training must be fast and repeatable.

🎯 Training tracks​

Cashier / counter

  • Open shift
  • Take order (dine-in and takeout)
  • Apply modifiers and combos
  • Process payment (cash, card, QR)
  • Issue FEL invoice
  • Handle void / discount (with manager)
  • Close shift + cash count

Server (tablet-based)

  • Open table
  • Take order at table
  • Fire courses
  • Transfer table (if applicable)
  • Request bill
  • Split bill

Manager

  • Authorize voids and discounts
  • Manage shifts
  • View real-time dashboard (sales, open tables, kitchen times)
  • Generate end-of-day reports
  • Handle hardware issues (offline mode, printer jams)

Kitchen staff

  • Receive orders on KDS
  • Bump (mark as ready)
  • Understand modifier display
  • Handle modification/void notifications from front of house

Training environment​

  • Separate training mode or training business in FlowPOS
  • Practice orders that do not affect real inventory or FEL
  • Printed quick-reference card per role

👉 Output: ✅ Training completion checklist per role ✅ Quick-reference card per role

Phase 9 — Pilot Service (Soft Opening)​

Never go live on a Saturday night.

Steps​

  1. Choose lowest-traffic shift for go-live (Tuesday lunch, for example)
  2. Import all data, verify menu is complete
  3. Do a full dry run with staff the day before (fake orders, fake payments)
  4. Go live on pilot shift with implementation consultant present
  5. Run parallel (paper backup) for first 3 days
  6. Collect issues list, fix before expanding to more shifts

What to watch during pilot​

  • Order accuracy (modifiers printing correctly in kitchen)
  • Speed of order entry (is the menu easy to navigate?)
  • Payment flow (tip handling, FEL, split bills)
  • Printer connectivity (most common failure point)
  • Kitchen ticket timing (are courses firing correctly?)

👉 Output: ✅ Pilot sign-off checklist ✅ Issue log

Phase 10 — Full Go-Live & Monitoring​

After pilot success:

  • Enable all service hours and channels
  • Enable delivery integrations (if applicable)
  • Enable online ordering (if applicable)
  • Monitor daily: sales vs. expected, voids, discounts (abuse indicators)
  • Monitor weekly: menu item performance, average ticket, table turn time
  • Monitor kitchen: average ticket time per station

⭐ What Data You Need (Checklist — Copy/Paste)

Business​

  • Business legal info (NIT, fiscal name)
  • Branches / locations
  • Service model per location (dine-in, takeout, delivery)
  • Operating hours
  • Full item list with prices and categories
  • Modifier groups and options per item or category
  • Combos and promotions
  • Tax type per item (IVA 12% or exento)
  • Menu variants per channel (dine-in vs. delivery pricing)

Floor Plan​

  • Zones / sections
  • Table numbers and capacity

Kitchen​

  • Station list
  • Routing rules (category → station)
  • KDS or printer per station

Staff​

  • Roster with roles and PINs
  • Authorization levels (who can void, who can discount)

Inventory (if in scope)​

  • Opening stock per item (or per ingredient)
  • Supplier list

Payments​

  • Accepted payment methods
  • Tip handling method
  • FEL configuration (NIT, CAF series)

⭐ Biggest Mistakes (Very Important)

These are real restaurant implementation killers:

  1. Incomplete modifier configuration — items reach the kitchen with wrong or missing modifiers, orders come back wrong, kitchen loses trust in the system
  2. No kitchen routing rules — everything prints at one station, kitchen collapses
  3. Skipping the dry run — staff sees the system for the first time during live service
  4. Going live on peak hours — first go-live must be a quiet shift
  5. FEL not tested before go-live — SAT connection fails, cashier doesn't know what to do
  6. No void authorization matrix — cashiers void freely, loss prevention impossible
  7. Tip handling not defined — conflict between management and staff on day one
  8. No offline mode plan — internet drops during service, POS stops, everyone panics
  9. Delivery integration not tested — third-party orders arrive but don't route to kitchen
  10. Training only done once — high turnover means you need a repeatable onboarding process, not a one-time session

⭐ Pro Tip (FlowPOS architecture insight)

For restaurants, your system must support:

  • Modifier groups with min/max selection rules and per-option pricing
  • Multi-station kitchen routing with independent print/display per station
  • Course firing (hold entrées until starters are bumped)
  • Table status lifecycle (available → seated → ordered → billed → closed)
  • Split bill by seat, by item, and by amount
  • Open tabs (bar model)
  • FEL electronic invoicing on every transaction (SAT Guatemala)
  • Shift management with cash count and Z-report
  • Delivery order lifecycle with third-party integration hooks
  • Real-time dashboard: open tables, kitchen times, sales

⭐ Restaurant-Specific FlowPOS Modules Checklist

ModuleRequiredOptional
Menu management (with modifiers)✅
Table management + floor plan✅ dine-in
Kitchen routing + KDS/printer✅
FEL electronic invoicing (SAT)✅
Shift management + cash count✅
Delivery order management✅
Online ordering (storefront)✅
Ingredient-level inventory✅
Loyalty / points program✅
Reservations✅
Self-ordering kiosk✅
Server tablets✅

⭐ Implementation Timeline (Realistic)

WeekActivity
Week 1Business discovery + menu data collection
Week 2Menu data cleaning + FlowPOS configuration (menu, modifiers, floor plan)
Week 3Kitchen routing + hardware setup + staff roster
Week 4Staff training (all roles) + dry run
Week 5Pilot go-live (quiet shifts) + issue resolution
Week 6Full go-live + hypercare support
Week 7–8Monitoring + fine-tuning (menu changes, routing adjustments)

For multi-location chains: add 1–2 weeks per additional location after pilot is validated.

If you want, the next deliverables from this guide are: ✅ Excel template for menu + modifier data collection ✅ Kitchen routing configuration worksheet ✅ Staff training quick-reference cards (per role) ✅ FEL setup checklist (SAT Guatemala) ✅ Shift open/close SOP document ✅ Hardware checklist per restaurant type (quick service vs. full service) ✅ Multi-location rollout playbook ✅ Questions to ask the client (discovery session script)