Pooled Loyalty

Pooled loyalty lets guests accumulate points and achieve tier statuses across multiple member restaurants in the chain – instead of separate loyalty profiles per unit. The feature is live: you activate it from the chain's Loyalty page (/chain/:slug/lojalitet).

How to activate it

Without shared loyalty, each restaurant has its own member list and points history. When you activate shared loyalty, existing points are summed per customer across all the chain's restaurants (the customer never loses points). After that, the guest earns, redeems, and is tier-assessed at chain level – across all the chain's restaurants.

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)

Parts of the feature

How it works

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

• /chain/:slug/lojalitet – chain-level loyalty page (tiers, program settings, member list)
• POS shows tier badge and balance when the customer is identified

What happens when you activate shared loyalty?

When you click "Activate shared loyalty" on the Loyalty page:

• Existing points are summed per customer across the chain's restaurants (the customer never loses points)
• The chain's tiers are set up
• The guest then earns, redeems, and is tier-assessed at chain level
• On a later deactivation, chain points are paused (they aren't returned per restaurant)

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.

Complements to pooled loyalty

Other chain features that reinforce a unified guest experience:

1. Chain gift cards – guests can have a chain-scoped card usable everywhere
2. Shared CRM – customer records are per-restaurant, but guest intel aggregates by same phone number

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