Getting started

This page describes what actually happens during onboarding today. It assumes a Fooodo specialist has set up your company in the back office and connected your R-Keeper instance. If that has not happened yet, write to hello@fooodo.com — onboarding is hands-on, not self-serve.

What you need before day one

• An R-Keeper installation with API access enabled. 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 R-Keeper. 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 R-Keeper, not in Fooodo. Fooodo treats R-Keeper 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.

A daily full menu sync runs at 09:00. Item availability syncs every five minutes. You should not normally need to trigger sync manually after onboarding.

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 (English or Lithuanian today).
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 lets you test the full pipeline without losing meaningful money.
4. Confirm the order arrives in R-Keeper 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 R-Keeper, the kitchen does not need to know Fooodo exists.
5. Close the order in R-Keeper 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 can land in Error state if R-Keeper was unreachable during export or rejected the payload. This is rare but worth monitoring early.
• The Orders → Locked view shows orders that R-Keeper has open (a waiter is editing them). The system retries automatically; persistent locks usually mean an order was left open in R-Keeper and needs to be closed there.
• Tip and bill-split flows are off by default. Enable them per-table once the basic flow is stable.

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