Published On:
October 22, 2026Last Updated:
October 22, 2026
The first rooming list for a group is rarely the problem. Your team builds it, checks it and sends it to the hotel. The problem starts with the second version, and gets worse with the fifth.
By the time a large group reaches departure, the rooming list may have been edited dozens of times. Travellers cancel, share partners drop out, late sign-ups need a bed, and hotels change their room mix. Each change is small. Together they create a question many operators can't answer with confidence: which version of the rooming list does each hotel have right now, and did they confirm it?
Below: why rooming lists break down, how to keep them under control, and how to run rooming from one system.
Most tour operators know how to build a rooming list. Lists break down for three reasons, none of which is the list itself.
The result shows up at check-in, when a traveller has no room and nobody can say what was sent, when, to whom, or who changed that line.
A multi-city tour may use three to five hotels, each with its own list. One cancellation from a twin share on a three-hotel tour means:
In a manual process, steps 1 and 6 usually happen. Steps 2 to 5 are where things get missed, especially when several changes arrive in the same week. Room changes also move the price; see how room changes move the group price.
The updated list is emailed to a general reservations address. Nobody asks for written confirmation, and nobody records which version the hotel acknowledged. The hotel may have loaded an earlier version, applied only some of the changes, or confirmed the previous list, which then got filed as "confirmed." Many hotels also re-key your list into their own system, and errors in that step stay invisible until check-in.
An Excel export doesn't prove what was sent or confirmed. It only proves a file existed.
Keep one master rooming record per group, with one named owner. Every hotel's list is produced from that record, never edited separately, so lists for different hotels can't drift apart.
Never overwrite a version. Save each version with a date, and log every change: what changed, who changed it and when.
Run the full check on every change. For each cancellation, swap or addition, work through the room partner, the room type, the block count at every hotel and the other manifests before sending anything.
Send to a named hotel contact, and show what changed. Highlight the rows that differ from the last version, so the hotel isn't left to spot changes in a 90-room list.
Get written confirmation tied to that version. A reply that says which version the hotel loaded is your evidence; "let me know if there's a problem" isn't. Confirmation applies to every supplier, and the general method is in how to manage supplier confirmations; for hotels, it has to name the exact version.
Track unconfirmed lists against each hotel's cut-off. A hotel still unconfirmed a week before its release date needs a call, not another email. Put those dates in the same calendar as your other supplier deadlines.
Share only what each hotel needs. Rooming lists often carry accessibility and medical details. Sending full lists repeatedly as attachments is a privacy risk as well as an accuracy risk.
With one group at a time and a disciplined owner, a spreadsheet can follow that method. It gets fragile when:
At that point the spreadsheet isn't the issue. The process relies on people remembering to record what the file can't record for them: what was sent, to whom, and what came back.
A group travel management system holds rooming as data linked to the group and its travellers, rather than as files:
| Question at check-in | Spreadsheet + email | Structured rooming record |
| What is this traveller's current room? | Depends which file you open | One current record |
| What did we last send this hotel? | Search the inbox for the right attachment | Stored against the hotel |
| When was it sent, and to whom? | Check the email thread, if you can find it | Logged with each send |
| Did the hotel confirm that version? | Often unclear | Confirmation linked to the version |
| Who changed this line, and when? | Only if the change log was kept | Recorded automatically |
For an established operator, this doesn't mean replacing the booking platform. Rooming can read traveller records from the system you already run, so names aren't keyed in again. Confirmations still arrive by email and are recorded against the right version. No system can control a hotel's own inventory or stop errors when a hotel re-keys your list; what it gives you is a clear record of what you sent and what they confirmed. Rooming can be built as part of a custom group travel management solution that works with your current platform. For a worked example, see how one operator added group management, including versioned rooming lists, without replacing its core booking system.
Your hotel contract sets it, usually at or before the group’s cut-off date, after which unreserved rooms return to the hotel. Many group contracts ask for the list a week or two before arrival; one PMS vendor’s rooming list template, for example, puts it at 7 to 14 days. Check each hotel’s contract, because a multi-hotel tour can have a different date at every property.
There’s no fixed rule. Most operators send an initial list, updated lists as significant changes happen, and a final list by the hotel’s agreed cut-off. What matters more than frequency is that every version sent is saved and confirmed.
Their room partner needs a decision: re-pair them with another traveller, move them to a single, or leave the twin with one occupant. Each option can change the room count, the supplement and every hotel list on the itinerary, so the change should be recorded and sent to all of them.
Yes. Rooming can be built as a module or connected layer that reads traveller data from your current platform, generates hotel-specific lists and records every send and confirmation, without replacing your core booking system.
Read more on:
Industries