Group loyalty

One programme. Every property in the group.

A guest who earns at your city hotel should be recognised the moment they arrive at your resort. One identity, one balance, one programme, across every property you operate.

The problem

A loyal guest at one hotel is a stranger at the next

Most groups grew property by property, and the guest data grew the same way. The result is a portfolio of programmes rather than a programme, and a member whose standing stops at the door of the hotel that issued it.

The second stay leaks

A guest who would happily have stayed within the group books elsewhere, because nothing followed them from the first stay.

Each property pays twice

Two properties acquire the same guest separately, and both pay commission to do it.

The group cannot see itself

Nobody can answer how many members the group actually has, because the answer lives in several systems that do not agree.

Cross-property earn and redeem

Earn at one property, spend at the next

One member, one balance, wherever they stay with you. The property that earns it and the property that honours it both see the same record.

  1. Property one

    Three nights, city hotel

    +1,200 points

    Earned on a direct booking

  2. One group wallet

    Same member, same balance

    3,850 points

    Available at every property in the group

  3. Property two

    Two nights, resort

    −2,000 points

    Redeemed against the booking

Or run it the other way: no wallet at all, and tier-based member rates recognised across every property instead. Groups choose one shape and we configure it.

Group and property

Central where it has to be, local where it should be

The question every group asks second, once the wallet makes sense. A programme that takes everything away from the property does not get used by the property.

DecisionHead officeThe property
Member identity and balanceGroupReads it
Tier thresholds and namesGroupReads it
Earn rateSets the defaultCan vary its own
Redemption valueSets the defaultCan vary its own
Member perks at the propertySets a floorAdds its own
Campaigns to membersGroup-wideIts own guests
ReportingEvery propertyIts own

Rollout

Designed once, inherited by every property

The programme is agreed at group level and each property inherits it. Sequencing is yours to decide.

  1. One

    Design the programme

    Tiers, earn, redemption and perks, agreed once at group level.

  2. Two

    Launch the first properties

    Live within 48 hours of the design being agreed. Existing member data comes with you.

  3. Three

    Add the rest

    Each property inherits the programme. Balances earned earlier are honoured the day it joins.

Groups we run this for

Multi-property, in production

7M

Loyalty members

Swiss-Belhotel International

as at Aug 2026

+42%

Direct bookings

MGM Muthu Hotels

group of 40+ properties, alongside −38% OTA commission

+195%

Revenue increase

R Hotels Dubai

group of 8 properties, 68% of bookings via the website

45%

Direct revenue

City Blue Hotels

from zero, in 6 months

Works with your existing hotel technology

Works with every major PMS, Channel Manager, OTA, and Payment Provider

OracleOpera CloudMewsCloudBedsSiteminderD-EdgeDerbySoftShijiRateGainTravelClickFidelioHotelogixIDS NextLittle HotelierRMSOracleOpera CloudMewsCloudBedsSiteminderD-EdgeDerbySoftShijiRateGainTravelClickFidelioHotelogixIDS NextLittle HotelierRMS
150+ PMS Systems40+ Channel ManagersOTA ConnectivityPayment ProvidersRevenue Management

What groups ask us first

Does it connect to the PMS we already run?
Tell us which PMS each property runs and we will confirm the connection on the call. We connect to the major platforms and add new ones, and a group rarely runs the same PMS everywhere, so we treat it property by property rather than as one switch.
How does it work with the CRM?
Loyalty and CRM are one motion, not two products. Loyalty creates the known guest, the CRM turns that into the next stay. Membership, tier and balance sit on the same guest record the campaigns are sent from.
What happens to the guest data we already hold?
It comes in with you. Existing members, balances and tier positions are imported rather than reset, and duplicate records for the same guest across properties are merged into one.
Who owns the guest, the group or the property?
The group owns the member record and the balance. The property sees its own guests, runs its own campaigns and adds its own perks on top of the group floor.
How do we know it is producing repeat bookings?
Repeat stays are attributed at group and property level, so you can see what a member is worth against a non-member, and which property earned the stay against which one honoured it.

Show us your properties, we will show you the programme

Bring your portfolio and the programme you run today. We will walk you through what one programme across all of it would look like.