Signing a hotel group is the deal every vendor wants. Delivering it is where many vendors lose the expansion they priced in. A group contract usually starts with a handful of properties and a promise of more. Whether the rest follow depends less on the sales team than on how the first months of the rollout go.

This post sets out a rollout timeline for a multi-property group, phase by phase, with the decisions that belong in each week. It is written for founders, customer success and implementation leads at hotel tech companies. The week numbers assume a mid-sized group of roughly 10 to 50 properties and a product that touches daily operations; compress or stretch them to fit.

What real group rollouts look like

Public examples show the range. Shiji's case study describes moving a European group of 110+ properties and 10,000+ rooms onto Daylight PMS between late October and mid December, with an average of seven go-lives a day and up to nine on peak days. At the other end, Oracle's September 2025 announcement says Accor is "currently moving" its global properties to OPERA Cloud across 110 countries, with a footnote that Accor selected the system in Q1 FY24.

Most vendors reading this will sell to groups far smaller than Accor or Hyatt, whose 2024 selection of OPERA Cloud covered more than 1,000 hotels and all-inclusive properties. A closer comparison is Lark Hotels choosing Mews for a portfolio of more than 50 properties, with a stated target of adding 6 to 12 new properties each year. That last detail matters: a group rollout is never really finished, because new properties keep arriving.

The rollout timeline at a glance

Phase 0, weeks 1 to 2: handover and mobilisation

Everything sales learned must reach the implementation team before the first kickoff: who signed, who uses the product, what was promised and which properties come first. The sales to onboarding handoff is where group deals most often lose context, because the buyer at head office is rarely the person who will use the product at property level.

• Name one programme lead on your side and one owner at the group's head office.

• Get the full property list with PMS, room count, integrations and local language for each.

• Agree which properties are in scope now and which are "later", in writing.

• Book the kickoff with the agenda covered in our onboarding kickoff agenda.

Phase 1, weeks 2 to 5: discovery and template design

The single biggest decision in a group rollout is how much is standard and how much is local. A template that tries to please every property turns into thirty separate projects. A template imposed from head office with no local input fails at the front desk.

Shiji's team is explicit about where the risk sits. Its case study quotes a senior project manager saying that "at this scale, data migration becomes the critical path", because inventory, integrations and financials all depend on it. In this phase, build the data mapping tables once and agree which fields every property must use.

Phase 2, weeks 5 to 10: the pilot

Pick one or two pilot properties that look like the rest of the portfolio, not the newest hotel with the most enthusiastic general manager. The pilot exists to break the template while the cost of fixing it is low.

• Run the pilot through a full operating cycle, including month-end reporting.

• Log every manual workaround and decide whether it becomes a template change or a training point.

• Measure time to first value at the pilot, using the approach in reducing time to first value.

• Ask the pilot general manager to present results to the other properties. Peers convince peers faster than vendors do.

Phase 3, weeks 10 to 26: wave rollout

Group the remaining properties into waves by region, PMS or integration set, so each wave repeats the same work. Shiji's rollout shows what discipline makes possible: tasks split between finance teams for ledger balancing, consultants for data migration and revenue teams for distribution interfaces, with a migration checklist per property and dedicated "war room" channels for issues.

Two practices from that case study apply at any scale. First, a train-the-trainer model, where internal champions guide local teams. This matters in hotels, where staff turnover means the person trained in March may have left by June; see front desk turnover and software adoption. Second, continuous improvement between waves: Shiji describes expanding mapping tables and adding validation checks as recurring issues appeared.

• Keep waves small enough that your team can support every property in its first week live.

• Avoid scheduling waves in a property's peak season.

• Hold a short retrospective after each wave and update the template before the next.

• Track adoption per property, not just go-live dates, with the events described in instrumenting activation.

Phase 4, weeks 26 to 30: stabilise and hand over

A rollout ends when the group is using the product, not when the last property goes live. Set an adoption baseline for each property, move support from the project team to the normal support model, and run the first group-level review with head office. Bring a property-by-property view: which hotels are active, which are lagging and what the group gained.

This review is also the start of expansion. The account plan for the hotel group should now list the properties still out of scope, the next modules and the people at head office who decide on them.

Phase 5, ongoing: the new-property playbook

Groups grow, rebrand and sell properties. Lark's target of 6 to 12 new properties a year is typical of an expanding management company. Turn the template, mapping tables and training pack into a standard playbook so a new property goes live without reopening the project, and agree in the contract how new properties are priced; our post on multi-property pricing covers the options.

Warning signs during a group rollout

• The template keeps changing after the pilot. Discovery was too shallow, and every wave will slow down.

• Head office stops attending reviews. The sponsor has moved on and property managers will treat the product as optional.

• Go-live dates hold but logins fall. Properties are live on paper only.

• Each property asks for its own integration. Scope is drifting and the margin on the deal with it.

Group rollouts are where customer success and expansion meet in the GTM system described in our hotel tech GTM strategy guide. If your group accounts stall after the first few properties and you are not sure why, the free GTM leak audit will show where the expansion is leaking.

Frequently Asked Questions