Pooled Loyalty (Planned)

Pooled loyalty is a planned feature for chains with "Shared loyalty" enabled in chain settings. It lets guests accumulate points and achieve tier statuses across multiple member restaurants in the chain – instead of separate loyalty profiles per unit. Status: architecture ready, under development. Planned release: Q2-Q3 2026.

Current state (April 2026)

Loyalty today exists per-restaurant – each restaurant has its own member list and points history. When you enable "Shared loyalty" in chain settings (e.g. in holding type), consolidation to chain level is planned. In MVP: the flag can be enabled, but consolidation isn't active yet – local loyalty continues as today.

Target: global customer identity

A single customer profile for the guest across the chain:

• Pooled points (points shared across all units)
• Pooled tier (Bronze/Silver/Gold based on total chain spend)
• Shared customer history (visits, favorite restaurant, top products)

What's planned

Planned logic

Earning:

• Guest pays order at Restaurant A → points calculated per chain's program settings
• Points added to guest's balance (with restaurant A tagged for traceability)
• Guest's balance updated
• Future point expiry set (e.g. 24 months forward)

Tier recomputation:

• Nightly run recalculates tier per member based on 12-month rolling spend
• Example: Guest has spent 12,500 SEK last year → Gold tier
• New tier applies from next order

Redemption:

• Guest at Restaurant B shows phone → system finds chain membership
• Can use points for discount per tier rules
• Redemption recorded (with restaurant B tagged)

Economic allocation (under investigation)

Question: when points are earned at A and redeemed at B – whose revenue is recognized?

Planned approach:

• Points earned at A → 100% allocated to A (A's revenue)
• Points redeemed at B → B recognizes full revenue minus discount, no intercompany allocation
• Month-end: if net allocation needed → intra-company revenue-share voucher

Alternative approach (under discussion):

• Reserve account for unused points
• On redemption: portion moves from reserve to unit where redeemed

Decision made by Mikael and CPA with pilot customers.

Challenges

• Data sync: nightly tier recompute for all members (heavy at large chains)
• Per-restaurant analytics: how to allocate pooled revenue in unit reports?
• Edge case: guest qualified Gold in chain, chain dissolves → what happens to tier?
• Migration: existing per-restaurant loyalty must migrate to pooled without data loss

UI changes (planned)

• /chain/:slug/lojalitet – chain-level loyalty page (tiers, settings, members)
• Regular restaurant admin shows only local members if chain doesn't have pooled on
• POS shows tier badge and balance when customer identified

What happens when flag is enabled in MVP?

In current MVP (April 2026) when "Shared loyalty" is enabled:

• Flag is on
• Loyalty page visible in navigation but shows placeholder "Coming soon"
• Local loyalty continues unchanged
• No migration happens until feature is live

Nothing breaks – it's a future upgrade added without disruption.

Compare with other systems

Large chains (Starbucks, McDonald's) have built custom loyalty programs in-house. Vendion's goal: give franchises and holdings the same powerful tools "out of the box" without custom development.

Fallback until pooled ships

If you have a chain and want unified customer experience before pooled loyalty launches:

1. Chain gift cards (works today) – guests can have a chain-scoped card usable everywhere
2. Shared CRM – customer records are per-restaurant today, but guest intel aggregates by same phone number
3. Manual tier management – chain admin can mark VIPs manually via tags

Next step: Read about consolidated analytics – the feature already live.