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.
• Stackable or exclusive — choose whether time-window discounts can combine with coupon codes.

Discounts are applied automatically during the eligible window — guests don't need to enter a code, and you don't need to push staff to remember the rules.

Coupon codes

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

• Single-use codes — each code is consumed by one order. Generated in batches and tied to a campaign so you can track which channel converted.
• Multi-use codes — one code, many orders. Typical for "WELCOME10" style campaigns.

Discount mechanics are flexible:

• Percentage off (e.g. 15%) or fixed amount (e.g. €5).
• Per-product whitelist — discount only applies to specific items.
• Minimum spend to redeem.
• Per-user dedupe so a single guest can't drain a campaign.
• Expiry date — codes age out automatically.

Bulk generation for email campaigns — generating hundreds of unique single-use codes for a CRM blast — is in active development. Today, multi-use coupons cover most needs; bulk single-use is the gap we're closing next.

Loyalty cards (POS-driven)

If your POS already runs a personal-card programme, Fooodo binds to it directly. Today's R-Keeper-specific reference is Vilniaus Šeima for Čili Pizza; other POS connectors expose loyalty pricing the same way through the connector contract.

• A guest who has linked a loyalty card sees the loyalty pricing in the menu, not the rack rate.
• Card binding happens once, in the guest's profile, and persists across visits.
• Pricing comes from your POS. Fooodo doesn't override; it surfaces what your card programme already says.

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. The same list also backs the checkout "anything missing?" prompt as a fallback.
• 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 at checkout (scheduled upsells)

When a guest opens checkout, Fooodo asks for up to five recommended items to surface alongside the cart. The recommendations resolve through three layers, in order:

1. What this guest tends to order. If the guest is signed in and has a 30-day repeat-purchase history at this restaurant, those products are surfaced first.
2. An operator-configured scheduled deal. If no personal history applies, Fooodo selects the active scheduled deal for the current weekday and time window at this restaurant.
3. Top sellers as the floor. If nothing else applies, the recommendation list falls back to the restaurant's current best-sellers.

Scheduled deals are configured per restaurant from the admin. Each deal carries:

• Weekday and time window — e.g. Mon–Fri, 11:30–14:00. Times are interpreted in the restaurant's local time zone.
• Eligible categories — pin the deal to "Drinks", "Desserts", a custom "Lunch add-ons" group, or any other category — so the lunchtime upsell isn't a wine recommendation.
• Product list with explicit ordering — operators decide which products show, in what order, and at what price.

Items 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 recommendations.

The point isn't AI — it's giving the operator the same upsell prompt a good waiter would deliver, but consistently, at every table, without coaching staff. The history layer is opt-in personalisation on top, not the primary mechanic.

Per-cart-item triggers — "when a Margherita lands in the cart, suggest a Coke at €X" — are on the roadmap as a complement to the scheduled-deal model, not a replacement for 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 (10%, 15%, 20%) plus a custom amount.
• Per-table on/off — keep tipping disabled at the takeaway counter, on at dine-in tables.
• Default percentage configurable at the restaurant level.

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 table, and the staff/shift 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 the recommender — the checkout cross-sell layer surfaces a guest's 30-day repeat purchases, not their explicit favourites. 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.