How to Build — and Audit — a Hotel Rooming List

What goes on a hotel rooming list?

A rooming list is the roster you hand the hotel that turns your room block into named reservations. Until the hotel has it, your rooms are held but empty — reserved inventory with no guest attached. The rooming list is what the front desk checks people in against, so every column earns its place.

For each room, the hotel needs six things:

• Guest name — the full name as it appears on the ID the guest will present, with one lead name per room.
• Arrival and departure dates — the exact nights the room is occupied. This is what drives your room-night count and, in turn, your bill.
• Room type — king, double-double, suite, or whatever room categories your contract actually names. This is the column that decides the bed configuration, so it is the one to get right when two people need two beds.
• Occupancy and sharing — how many people are in the room, and who shares with whom. Single or double occupancy is a headcount, not a bed count: it tells the hotel how many guests to expect, which drives per-person rates, extra-person charges and breakfast counts, and it names the second guest when a room is shared. Two people in a double-occupancy room may still be sold a king unless you asked for a double-double by name, so treat beds as a separate request rather than something the occupancy flag settles for you.
• Billing instructions — who pays for what. Room-and-tax to a master account, incidentals to the guest’s own card, or the whole folio to the individual. Get this wrong and you will spend arrival week untangling charges.
• Special requests — accessibility needs, early check-in, connecting rooms, a high floor away from the elevator. The hotel cannot honor what it never sees.

The list is not a formality. It is the single document where a guest’s stay, your budget, and the hotel’s front desk all have to agree. A clean rooming list prevents the two most expensive arrival-day surprises: a guest with no room, and a room billed to the wrong account.

How do you collect guest names without chaos?

Run every name through one intake path, give each department or team lead ownership of their own slice, and set your internal deadline before the hotel’s cutoff — not on it.

The chaos in rooming lists is almost never the hotel’s fault. It comes from names arriving five different ways: a spreadsheet from one lead, a forwarded email from another, three names texted the night before. Pick one channel and hold the line. Each room request should enter through the same door, so you are never reconciling formats instead of building the list.

Push ownership down. If you are running a block for several departments, teams, or a sub-block per group, the person closest to each set of guests should enter their own names — they know who is actually coming. A department lead submitting through a private request link keeps you out of the transcription business and cuts the error rate at the source.

Set the internal deadline early. Your hotel cutoff date is a contractual deadline, and what happens when you cross it is whatever your contract says happens: unsold rooms usually release back to the hotel, and late additions are often still possible — at the rate the hotel is selling that week, not your block rate, and subject to whatever is left. Plan as though the date is immovable even where it is not, and treat it as the hotel’s deadline rather than yours. Give your leads a due date a week or two ahead so you have room to chase the stragglers, fill gaps, and format the file before you submit.

And plan for the rooms you cannot name yet. A TBD room — allocated but unnamed — usually still counts against the block you committed to, so under most contracts you pay for it whether or not a name ever lands on it; check yours for how unnamed and unused rooms are treated. Either way, do not drop it from the list because you lack a name; hold it as TBD, keep it visible, and swap in the real guest when you have one. Rooms that quietly fall off the list are how you end up under-submitting against a block you have already agreed to pay for.

How should you format the rooming list for the hotel?

One row per room, dates in one unambiguous format, room-type labels that match the contract — and, after the first submission, whichever update format the property asks for: a marked-up change list for most hotels, a complete replacement file for some.

One row per room is the golden rule. A guest staying four nights is still one row, not four. If two people share, that is one row with a primary and a secondary name, not two rows competing for the same bed. The moment your list has more rows than the hotel has rooms held, someone is going to double-book or drop a reservation.

Pick a date format and never vary it. “03/04” is March 4th to an American front desk and April 3rd to half the world; write “Mar 4, 2027” or “2027-03-04” and use it in every cell. Give arrival and departure, not “4 nights” — let the hotel see the exact dates so your room-night math and theirs line up.

Standardize the small stuff too: consistent room-type labels that match the contract, a billing code per row, one column for special requests. The cleaner the file, the fewer questions bounce back to you. If you are starting from a blank sheet, the free rooming list template is an .xlsx workbook with these columns already laid out — one row per room, up to five occupants, arrival and departure, room type and billing — along with a note on what each column is for.

The part teams miss is the update discipline. Your first submission is the baseline; everything after it is an amendment, and the format those amendments should take is worth one question to your hotel contact before the first change goes out. Most properties prefer changes only — “add these three, cancel this one, move this arrival to Mar 5” — clearly marked and dated, because a short change log can be keyed in minutes while a fresh 200-row attachment has to be compared against last week’s version before anyone can act on it. Others run a process, or a system, that expects a complete replacement list every time and will tell you so. Confirm which the property wants, then hold to it.

Keep your own rooming list change log either way — one dated line per change, whatever you send the hotel. It is what lets you answer “did we ever tell them about the Mar 5 arrival?” with a date instead of a guess, and it is the list you work from when you check the hotel’s returned file against yours.

Why should you audit the hotel’s returned list before arrival week?

Because the hotel’s list and yours drift, and the cheapest time to catch a mismatch is while there is still time to fix it — not at the front desk on arrival day.

When you submit names, the hotel keys them into its own system and sends back a confirmed list, usually with a confirmation number for each reservation. That round trip is where errors creep in: a name gets transposed, a date shifts by a night, a room you submitted never made it in. A rooming-list audit is the line-by-line comparison of what came back against what you sent, anchored on the confirmation number — the hotel’s own key for a reservation, and the one field a spelling change cannot break.

The mechanics are a job of their own. Comparing the two lists in Excel walks through the lookup formulas, the discrepancy types and the order to work them in; the free rooming list audit tool does the same comparison in your browser — your file against the hotel’s returned CSV or Excel file, matched by confirmation number, differences listed by type, nothing uploaded and no sign-in.

Do this weeks out, not during arrival week. A name you fix in the system today is a smooth check-in; the same fix attempted at the desk while the guest waits is a bad first impression and, if it is a no-show or a missing room, a billing dispute. Auditing early converts arrival-day fire drills into a quiet email exchange.

What does a rooming-list audit actually look like?

Here is a small one. Say you are running a block at the fictional Meridian Harbor Hotel for a 40-room event, and the hotel returns its confirmed list. You work down it row by row, and three rows do not reconcile.

Discrepancy 1, date drift. You submitted Priya Nadar arriving Mar 4 and departing Mar 8: four nights. The hotel’s confirmed row shows arrival Mar 5 — three nights. That tells you the two records disagree, not which one is wrong: the arrival may have been re-keyed at the hotel, or Priya may have moved her flight and told a lead who never told you. Confirm the intended arrival, then send the hotel the date you want. Unchecked it costs you either way — a night nobody sleeps in, or a guest at the desk on the 4th with no room.

Discrepancy 2, name mismatch. Your list has “Jonathan Reyes”; the confirmed list reads “John Reyes.” The confirmation number is identical, so it is one reservation under two names — and Jonathan and John are far enough apart that nothing should quietly treat them as the same person. A first name shortened over the phone is the likely story, but your own list could as easily be the one carrying the nickname. Ask which name is on the ID he will present, correct the other in one line, and it never becomes a front-desk argument.

Discrepancy 3, missing room. You submitted 40 rooms; the hotel’s list has 39. Matching by confirmation number, the TBD room you were holding for a late addition never got a confirmation — it dropped somewhere between your submission and their system. Under most contracts that room still counts against the block you committed to, so you will likely pay for it either way; what you have lost is the room itself, and whoever you were holding it for. Ask the hotel to add it back, and ask for the confirmation number as proof.

Three rows, three failure modes, all caught with time to spare — and each one checked before a correction went out.

This is the loop Blocks runs for you: it audits the hotel’s returned list against yours, matched by confirmation number first, groups the discrepancies by type, and proposes each correction for you to confirm — nothing changes on a reservation until you say so. It is also built to leave the noise out of your way: it works out what a hotel’s own room codes mean from the rest of the same file instead of filing a mismatch on every row, reads “BRENNAN, TYLER” and “Tyler Brennan” as one person, and accepts a scanned or faxed list with its confirmation numbers marked unverified — never letting them decide which guest is which.

What should you check in the weeks before arrival?

Work a short sequence in order: confirm the hotel has your list in its system, reconcile the counts, check the details on the rows that matched, confirm the billing, chase what has not come back, and agree how corrections get made. Each step has an answer you can point to, which is the difference between a list that is checked and a list that feels fine.

• Confirm the hotel received and keyed it. “Got it, thanks” is not evidence that anything was entered. What you want back is the confirmed list itself, with a confirmation number per reservation, and a date you can put in your change log.
• Reconcile the counts, unnamed rooms included. Three numbers: rooms on your list, rows on theirs, rooms your contract says you are holding for those nights. All three should agree, per night, not just in total. TBD rooms are the usual gap — they are the rows most likely to fall off quietly, and they are still yours.
• Check the matched rows, not just the matched names. For every row that lined up, compare arrival, departure, room type and occupancy, and check the name against the ID the guest will actually present. A single shifted arrival changes the room nights you are billed for and leaves someone without a room on night one.
• Confirm the billing routing per row. Which rooms go to the master account, which folios stay with the guest, and what happens to incidentals. This is the half of the list nobody checks until the final invoice, and it is the more expensive half to fix afterwards.
• Chase what has not come back. Every correction, late addition and cancellation you sent is open until the hotel confirms it in writing. Work from your change log, not from memory, and re-send the ones with no reply rather than assuming they landed.
• Agree the correction route before you need it. One named contact, one thread, one format for changes, and a re-confirmed list once the corrections are keyed. Sorting that out two weeks ahead is cheaper than discovering at 4pm on arrival day that your contact is off that week.

None of this needs software. Two sorted spreadsheets, your change log and an hour will find most of it — the sequence matters more than the tool.