How does loyalty for a chain differ from loyalty for a single venue?

A chain programme is not a bigger single-venue programme. The mechanic — earn, reward, expiry — should be identical, and copying it across sites is the easy part. What actually changes is the plumbing underneath, and it changes in three specific ways that are painful to retrofit.

Shared identity. A customer who visits your city-centre site on weekdays and your suburban site on weekends is one person with double the value. If each site holds its own customer table, that person appears as two mediocre customers, both of whom look like churn risks in the other's data. Worse, they get two welcome messages and two birthday offers. Unified identity keyed on phone number or platform ID is the single most important architectural decision in a multi-site rollout, and it is far cheaper to do before launch than after.

Reward liability between sites. When points are earned at a busy flagship and redeemed at a quiet suburban store, the suburban P&L absorbs the cost of a reward the flagship generated. At two or three sites nobody notices. At ten, managers notice and start discouraging redemptions, which quietly kills the programme. Settle it explicitly: either head office carries reward cost centrally, or you run an internal transfer at food cost. Both work; ambiguity does not.

Reporting for two audiences. Store managers need one screen: how many members, how many visits this week, who is at risk right now, what to do today. Head office needs the opposite — cohort curves compared across sites, so that a site with a structurally worse repeat rate is visible before the annual review. Giving managers the head-office dashboard is the classic mistake; they stop opening it within a fortnight.

Access control. Once you have more than a handful of staff touching the system, role-based permissions stop being a compliance checkbox. A store manager needs to see and act on their own venue's at-risk list; they should not be able to export the group's entire customer database on their last day. Set this at rollout, not after an incident.

What deliberately stays the same: the earn rate, the reward structure and the expiry rules. Local variation should be limited to which items the reward can be redeemed against, so a seafood-heavy coastal site and a city breakfast site can each offer something relevant without fragmenting the programme customers think they joined.

Rollout order matters too. Pilot on two sites that differ from each other — your best and a middling one — for six to eight weeks before group rollout. A pilot on two strong sites teaches you nothing about the sites that need the programme most.