Discounts, coupons and loyalty

This page is for restaurant owners and marketing teams who want to drive traffic, lift average check, and reward returning guests. Everything here runs from the Fooodo admin and shows up in the same guest checkout — no separate growth tool to wire up.

Time-window discounts

The simplest promotion type, and the one most chains start with: a discount that's only live during a specific window. A 20% lunch special, Tuesday-night pizza deal, or weekend brunch upcharge.

Configurable in the admin per discount:

• Day-of-week and hour window — e.g. Mon–Fri, 11:00–14:00.
• Eligible categories — apply only to "Lunch", or "Pizza", or anything else.
• Minimum spend — gate the discount above a threshold so it lifts ticket size rather than just shaving margin off small orders.
• One discount per order — only one code-entered discount applies to an order at a time; entering a new code replaces the previous one. (The automatic day-lunch discount can still apply alongside a coupon.)

Most time-window discounts are redeemed by code: the operator names the discount, and that name is the code a guest enters at checkout — it's only accepted inside the eligible window, so staff don't have to police the rules. The exception is the day-lunch discount, which applies automatically for signed-in guests on lunch items during the active window, with no code to enter. (Happy-hour discounts are validated the same way but are applied through your POS via a configured card code.)

Coupon codes

For email campaigns, social posts, partnership giveaways, or staff-give-this-to-a-disappointed-guest moments. Two shapes exist:

• Single-use codes — each code is consumed by one order. Bulk batches are minted via an operations command (used today for prize-voucher pools), and a per-user code can be auto-issued to eligible registrants.
• Shared campaign codes — for a "WELCOME10" style code that any eligible guest can enter repeatedly, you name a discount and the name is the code. There's no per-code record; the discount's own rules and active window govern it.

Discount mechanics are flexible:

• Percentage off (e.g. 15%) or fixed amount (e.g. €5).
• Per-category scope — the discount applies only to items in the categories you select.
• Minimum spend to redeem.
• Per-user dedupe so a single guest can't drain a per-user campaign.
• Active window — switch a discount off with its enabled flag, or bound it to a recurring day/hour window; single-use codes retire once redeemed. (There's no separate calendar-expiry field.)

Self-serve bulk generation — minting hundreds of unique single-use codes for a CRM blast from the admin UI — is on the roadmap. Today, bulk single-use codes are produced by an operations command and exported to CSV, and shared campaign codes cover the multi-redemption case.

Loyalty cards (POS-driven)

If your POS already runs a member-pricing programme, Fooodo surfaces it directly. The live integration is R-Keeper for the Čili Pizza chain; the connector contract exposes member pricing the same way for any future POS connector.

• On a loyalty-enabled table, a guest who is signed in when the order is created sees member pricing in the menu, not the rack rate.
• The decision is made once, at order creation, and is sticky for the whole visit — everyone seated at that table shares it. There is no per-guest card to bind inside Fooodo.
• Pricing comes from your POS. Fooodo doesn't override; it surfaces what your member programme already says, fetched from the POS loyalty endpoint.

There's no second loyalty engine inside Fooodo. There are no in-app points, no parallel tier system, no "earn 1 point per €" mechanic. The card programme you already run is the loyalty programme — Fooodo plugs into it.

Product preferences (guest filters)

A lightweight tagging surface for organising the menu around how guests choose: Vegan, Gluten-free, Spicy, Featured, Lunch combos — whatever vocabulary fits your audience. Each tag is created once at the company level, gets a translatable name (so the same tag reads correctly in every guest locale), and is then applied to products from the admin.

Guests see preferences as filter chips in the menu — tap "Vegan" and the menu reduces to tagged items. The same tagging is what powers the per-restaurant featured-category surfaces. Tags are operator-controlled and the product list per tag is explicit; nothing here is inferred from the model.

There is no fixed taxonomy — you decide the tags. Restaurants can also carry their own restaurant-specific tags when the menu makeup differs by location.

The homepage menu (Recommended & Popular)

The top of the menu can lead with dishes instead of a flat list, and it adapts to who's looking. Two operator-controlled blocks sit alongside the guest's own favourites:

• Recommended — an operator-curated list, configured per restaurant. Your signatures, current promotions, the dishes you want to push, in the order you choose. Operators can also schedule a deal to weekday/time windows so the block leads with the right items at lunch versus dinner.
• Popular — the genuine best-sellers, computed automatically from completed orders over a configurable window (default 30 days). Operators choose which categories to rank from and how many products per category; the dishes themselves are data-driven and re-rank as sales move, so the block never goes stale.

Above these, a signed-in returning guest also sees their Favourites — their hearted and recently-ordered dishes (see Guest favorites, below) — so a first-time guest and a regular don't meet the same menu. Recommended and Popular are set from the admin; favourites and the history-based personalisation are automatic, with no operator panel. The step-by-step for curating Recommended and configuring Popular lives in the Operator Playbook.

Cross-sell (suggested add-ons)

When a guest adds an item to the cart, Fooodo can surface a short prompt of suggested add-ons — the same nudge a good waiter gives ("something to drink with that?"), delivered consistently at every table without coaching staff.

Cross-sell is operator-configured as flows. Each flow has:

• A trigger — a specific product, or a whole category. When the guest adds a matching item, the flow fires. (This is the "when a Margherita lands in the cart, suggest a Coke" mechanic — it's live, not on the roadmap.)
• One or more suggestion sections, each drawing its products from one of three sources:
  • Manual — a hand-picked list, in the order you set.
  • Category — every active product in a chosen category.
  • Best-sellers — auto-populated from the restaurant's top sellers over the last 30 days, so the list never goes stale.
• A display mode — an overlay over the menu, or an inline block in the flow.

Items whose category is already in the cart, items deactivated at the restaurant, and items missing a price are filtered out automatically — guests never see "out of stock" or duplicate suggestions.

This is distinct from the homepage recommendations described under Recommended & Popular above — that block leads returning guests with their own repeat orders and operator-scheduled deals. Cross-sell is the in-flow, add-triggered layer on top of it.

Image popups

A single promotional image surfaced over the menu — for limited-time deals, partner shout-outs, opening-week announcements, or anything else that's better seen than read. Operators upload the image from the admin; one image is active at a time, scoped either to the whole company or to a specific restaurant. Replacing the image replaces it everywhere it applies; clearing it removes the popup until something new is uploaded.

This is a deliberately small surface — not a campaign management system, not segmented messaging, not A/B testing. The point is to give operators a quick lever for one urgent message without engineering involvement.

Donations

A guest-facing checkout option that routes a donation to a partner organisation — Red Cross is the live reference example. Configurable at the company level:

• Preset amounts (€1, €2, €5) plus a custom amount field.
• Cause description — short copy explaining what the partner does.
• Optional default — opt-in (off until selected) or opt-out (on by default, guest can clear it).

Donations are charged through the same Mollie transaction the guest is already paying for, but the donation portion is routed to the partner organisation's Mollie account. From the guest's perspective: one charge. From the operator's perspective: the donation does not appear in restaurant revenue or in your POS sales reports — it lands cleanly in the partner organisation's books, with the right tax treatment.

It's a guest-trust move with no margin impact on the restaurant.

Tips

Tipping isn't a promotion mechanic per se, but it's adjacent — and it's usually where chains see the fastest revenue lift after rolling out Fooodo. The tipping flow:

• Fixed-percentage presets (5%, 10%, 15%) plus a custom amount.
• Tipping is available wherever the restaurant has a tip revenue code configured; cash payments can't carry a tip.

Tips bundle into the same Mollie charge as the order, then settle in your POS as a tip line — so existing tip-out workflows don't change. The POS code that represents tip revenue is set per-restaurant (in the live R-Keeper connector this is an R-Keeper revenue code; other connectors expose the same setting).

Reviews

A post-payment rating prompt captures guest sentiment for operator review. Ratings are not displayed publicly — they exist for you, not for other guests. The flow:

1. Guest pays.
2. Optional 1-5 rating prompt with a free-text comment field.
3. Captured against the order, the restaurant, and the waiter in scope.

This gives chain managers a per-shift, per-location quality signal that lines up with the actual transaction — useful for surfacing "Tuesday-night service at Location N is consistently underperforming" before it shows up in repeat-visit numbers.

Guest favorites

Signed-in guests can favourite individual products from the menu — a one-tap toggle that persists across visits. There is no per-restaurant scope: a guest who marks the Margherita as a favourite at one Čili Pizza location sees the same favourite the next time they scan a QR at a different location.

Favourites are guest-managed. There is no operator panel for editing what a guest has favourited; favourites are a guest-side affordance for fast re-ordering, not a merchandising lever. They are intentionally separate from cross-sell: the add-triggered cross-sell prompt draws from operator-configured flows (hand-picked, a category, or best-sellers), not a guest's explicit favourites. (A guest's own repeat-purchase history is used to personalise the homepage, not the cross-sell prompt.) A guest who isn't signed in can browse the menu normally; favourites simply aren't available.

What's intentionally not in the system

• No public reviews. Guest ratings are operator-visible, not surfaced to other guests. If you want public reviews, that's Google, TripAdvisor, or Wolt — Fooodo doesn't compete with them.
• No referral rewards. No "give your friend €5, get €5" mechanic today.
• No tier-based loyalty. Your POS card programme is the only loyalty surface; no parallel Bronze/Silver/Gold inside Fooodo.
• No automated email blasts from Fooodo. Coupon code generation lives here; the actual send happens in your CRM.

Where to go next

• Day-to-day operations: Getting started for onboarding and the dry run.
• The order side: Order flows for how Pay-First and Pay-Later interact with promotions (e.g. coupon codes can apply on either flow).
• The money side: Payments for tipping, donations, and refund mechanics in detail.