Getting started with Fooodo

This page describes what actually happens during onboarding today. It assumes a Fooodo team member has provisioned your company in the back office and connected your POS through the live R-Keeper connector (other connectors land on the same contract — see the R-Keeper connector page for the reference implementation). If that has not happened yet, write to hello@fooodo.com — onboarding is hands-on, not self-serve. A typical first-location go-live takes one focused day, with someone from our team on the call from sync through dry-run.

What you need before day one

• A supported POS installation with API access enabled. R-Keeper is the live reference connector today; other POS connectors are scoped per-customer when a chain commits to one. Fooodo needs the API endpoint URL, the restaurant ID, and an account that can read the menu and write orders.
• A Mollie account (for production) or test credentials. Payments route through a separate Fooodo payment service — you do not interact with Mollie directly during operation, but the account must exist and be linked.
• A device that prints QR codes. Any office printer works; the back office generates A4 sheets, table tents, and stickers.
• One or two test tables you can keep offline for the first hour of service.

The first sync

Once the restaurant is configured, the first task is the menu sync.

1. From the admin panel, trigger Menu → Sync from POS. The first sync is the only slow one — it pulls every product, category, modifier, and ingredient. After that, syncs are incremental.
2. Open the synced menu in preview. Pick one category that is small and easy to verify (drinks usually). Confirm prices, modifiers, and tax flags match the POS exactly.
3. If anything is wrong, fix it in the POS, not in Fooodo. Fooodo treats your POS as the source of truth. The next sync will pick up the change. You can re-trigger sync manually from the admin panel.
4. Once a category is verified, the rest of the menu is generally fine — issues tend to be category-level (tax flags, modifier groups) rather than per-item.

Syncs run automatically after onboarding (full menu daily at 09:00, item availability every five minutes); you don't need to trigger them manually.

QR codes and tables

Tables in Fooodo are addressable: every QR code maps to a specific table number, which maps to a specific restaurant. There is no shared "scan to order" QR — every guest is implicitly seated at a known table.

1. Configure tables in the admin panel. For each table, pick a flow: Pay-First or Pay-Later. (See Order flows for the difference.) The flow can be set per-table, or as a default at the restaurant level.
2. Generate and print QR codes from Tables → Print.
3. Stick the QR codes on two test tables. Keep the rest of the floor offline for the first hour.

The dry run

Before going live across the floor:

1. Scan a test QR with a phone. Confirm the menu loads in the language you expect.
2. Add the cheapest item from your test category to the cart. Place the order.
3. Pay with a real card — production routes through Mollie. The cheapest item exercises the full payment path with minimal exposure.
4. Confirm the order arrives in the POS exactly as if it had been entered manually at a terminal — at the kitchen printer, on the KDS, in reports. This is the contract: if the order shows up correctly in the POS, the kitchen doesn't need to know Fooodo exists.
5. Close the order in the POS as you would any other order.

Going live

If the dry run is clean, print and stick QR codes on the rest of the floor. Service continues as normal — the staff workflow does not change.

In the first week:

• Watch the Orders → Errors view. Orders land in Error state if the POS was unreachable during export or rejected the payload — rare, but worth monitoring early.
• The Orders → Locked view shows orders that the POS has open (a waiter is editing them). The system retries automatically; persistent locks almost always mean an order was left open in the POS and needs to be closed there.
• Bill-split and custom tip flows are disabled by default to keep the first-week dry run focused on basic ordering. Enable them per-table once you're comfortable.

After the first week, Fooodo becomes invisible. Most operators only open the admin panel for menu changes, weekly reports, and the occasional stuck order.