Fooodo overview — the restaurant operating layer

Fooodo is the digital ordering and payments layer sitting on top of a restaurant's existing POS. Guests scan a QR code at the table, browse the menu, place an order, pay — and the order arrives in your POS exactly as if a waiter had typed it in. R-Keeper is the live reference connector today; the connector contract itself is POS-agnostic, with other POS connectors scoped per-customer and quoted on demand. The system is live across the full Čili Pizza network in Lithuania and Latvia today, processing real orders against real customers.

This page is for restaurant operators evaluating Fooodo or newly signed — the full feature picture, what's live today, and what's on the way.

The 60-second pitch

A guest sits at a table, scans the QR taped to the corner, and the menu loads. They pick what they want, optionally split the bill across people at the table, optionally add a tip or a donation, pay with card / Apple Pay / Google Pay, and the kitchen sees the ticket immediately. Your staff don't change their workflow — your POS still drives the kitchen. You get the same printer routing, the same KDS, the same reports.

Fooodo is not a QR menu. It's the operating layer that gives a restaurant a guest-facing front door without asking the kitchen to learn anything new.

Two ways guests order

The choice is yours, per table or per restaurant:

• Pay-First — built for takeaway and quick service. Guest pays, then the order goes to the kitchen. The kitchen never sees an unpaid order. If the guest abandons the cart, no work happens.
• Pay-Later — built for dine-in. The first round goes to the kitchen immediately when ordered; guests can add more rounds as they go; payment happens at the end. Closer to how a normal dine-in service feels.

You can mix both at one location — Pay-Later on dine-in tables, Pay-First on the takeaway counter. Full mechanics are in Order flows.

What guests can actually do

What you can do as an owner / operator

The admin panel (Filament-based) is where day-to-day work happens. The big surfaces:

Menu management

• Add, edit, archive, reorder products and categories
• Per-language fields (EN, LT) for names, descriptions, allergens
• Variants (small / large / family) and modifier groups (sauces, sides, additions)
• Dietary tags and allergen flags
• Photos
• Pricing — manual override allowed, but your POS is the source of truth: change prices in the POS and the next sync picks them up, never the other way round

Tables and QR codes

• Generate, label, and print QR codes for every table at every location
• Per-table flow toggle (Pay-First vs Pay-Later) — you can run different flows on different tables
• Per-table status — disable a single table without disabling the restaurant

Promotions

• Time-window discounts — lunch specials, happy hour. Set day, hour, minimum spend, eligible categories.
• Coupon codes — single-use or multi-use, % or fixed €. Bulk generation for email campaigns is in development.
• Loyalty card binding — link the POS personal-card programme (today's R-Keeper-specific example: Vilniaus Šeima) to the menu so guests with cards see the right pricing.

Full operator playbook for promotions, loyalty, cross-sell and donations: Discounts, coupons and loyalty.

Orders and live operations

• Live order list across all locations or scoped to one
• Filter by status, date, table, restaurant
• See Locked (the POS has the order open) and Error states immediately
• Manual payment correction for the rare reconciliation case
• Order data export

Restaurant settings

• Operating hours
• POS connector configuration (endpoint URL, restaurant ID, staging/mock mode) — R-Keeper is the live reference; the same shape is what other connectors plug into
• Payment configuration (Mollie account routing)
• Default flow (Pay-First vs Pay-Later)
• Feature toggles per restaurant (cross-sell on/off, bill-split on/off, etc.)

Reports

• User activity reports (orders per customer, location breakdown, source: app / QR / desktop)
• Date and restaurant filters
• CSV export
• Operational reports remain in your POS — Fooodo does not replace your daily P&L

Permissions

• Role-based access: company admin, restaurant manager, table staff
• Restaurant managers see only their restaurant's data
• Granular per-permission control (who can manage upsell rules, who can flip flows, etc.)

What your POS still does

Fooodo augments the POS; it does not replace it. Your POS continues to:

• Be the menu source of truth. Edits in the POS sync into Fooodo, never the reverse.
• Run the kitchen. Same KDS, same printers, same routing. Your kitchen staff don't learn a new system.
• Handle refunds and reversals. Fooodo records the payment status; the actual refund happens in the POS, as it always did.
• Manage staff and shifts.
• Drive the operational reports. Daily reconciliation, sales reports, P&L — all stay in your POS.

Multi-location

The platform is built for chains, not single sites. The hierarchy is Company → Restaurant → Table → Order. One company admin can:

• Manage every location in the chain from a single panel — without rekeying per site
• Set defaults at the company level and override them per restaurant
• See cross-restaurant data in reports without exporting and merging
• Maintain separate POS credentials per restaurant — useful when sites run different POS instances (or, eventually, different POS systems)

Restaurant managers see only their own restaurant. The tenant separation is enforced by the role layer, not by trust.

What's coming next

Honest read on the active development pipeline:

What's deliberately not in the system

Setting expectations matters. As of today:

• No customer email receipts. Your POS prints receipts at the restaurant; Fooodo does not email a digital receipt to the guest.
• No SMS or push notifications to customers. There is no "your order is ready" text message.
• No public reviews. Guest ratings are captured for the operator's eyes, not displayed to other guests.
• No in-app loyalty points. Loyalty is your existing POS card programme. There is no "earn 1 point per €" mechanic inside Fooodo.
• No reservations / table booking. Models exist, but the booking flow is not built.
• No multi-currency. EUR only.
• No multi-language admin. The operator admin panel is English-only. The customer-facing menu supports multiple languages (see above).
• No autonomous decisions. Fooodo Insights, when it ships, will recommend actions — never execute them autonomously. Anything that affects employees runs through human approval. See Fooodo Insights for the GDPR Article 22 stance.

Where to go next

• Operationally: Getting started walks through onboarding, dry-run, and going live.
• Architecturally: Architecture shows the two-service shape (menu + payments) and where everything lives.
• Flows: Order flows for the Pay-First vs Pay-Later mechanics.
• POS vendors: POS integration requirements — the evaluation spec for a vendor assessing whether their POS can be connected.
• POS: R-Keeper connector — the live reference implementation, with API round-trip details.
• Money: Payments for tips, donations, webhooks, refunds, supported currencies.
• Growth: Discounts, coupons and loyalty — the operator playbook for promotions.
• Integrating: API for partners writing connectors.
• Vision: Fooodo Insights for the EBIT-decision-intelligence layer that's in development.
• For AI clients: Insights MCP server — per-tenant Model Context Protocol endpoint for connecting ChatGPT, Claude, Copilot, or Gemini to your operational analytics.