November 11, 2026

Room blocks for company events: how they work and what to check in an offer

When thirty people from your company need to be in the same hotel on the same three nights, booking thirty individual reservations is not the same product as booking a room block. The prices differ, the cancellation rights differ, and — the part that costs money later — the obligations differ. If you have been handed an offer with the words "release date" and "attrition" in it and you are not sure which of them you should be worried about, this is the short version.

What a room block actually is

A room block is an agreement with a hotel to hold a number of rooms, of a stated type, for stated dates, at a stated rate. The hotel takes those rooms off general sale. In exchange you take on some responsibility for filling them.

That exchange is the whole thing. An individual booking is a promise about one room that you can usually cancel under the rate's own rules. A block is a promise about a quantity. The negotiation is about how firm that promise is, and the two terms that define it are release and attrition.

Release is the date when unbooked rooms go back to the hotel with no penalty. Up to that date you are holding more rooms than you have names for, and that is fine; after it, the rooms you have not assigned are simply no longer yours. A block with a generous release date is a block you can plan against before you know who is coming.

Attrition is what happens to rooms you keep past the release date and still do not fill. Under an attrition clause you owe the hotel for part of the unfilled rooms — you have committed to a volume and the hotel has turned away other guests on the strength of it.

The practical difference: release protects you from your own early optimism, attrition is the price of being optimistic too late. An offer can be strong on one and weak on the other, which is why comparing two offers on the nightly rate alone tells you almost nothing.

When you need a block, and when you do not

A block earns its complexity when the group has to be together and the dates are fixed. A sales kickoff where the opening session starts at nine on Tuesday and everyone must be in the room: block. An offsite where the point is that people are in the same building in the evening: block.

It earns nothing when people are arriving on different days from different cities and the "event" is really a shared calendar. Thirty independent bookings inside your normal travel policy will be cheaper to run and far cheaper to cancel. The question is not the headcount, it is whether the group's value depends on being in one place at one time.

Two situations sit in between and are worth naming. First, a city with one realistic hotel near the venue — then you block even for a small group, because the alternative is not a worse rate, it is no rooms. Second, a date that collides with something big in the city: a block is the only way to hold inventory you will not be able to buy later at any price.

How the request works

You do not shop a block the way you shop a room. You describe what you need and let hotels answer. A request a hotel can actually quote contains:

  • the dates, including the nights at the edges — the people who arrive the evening before and leave the morning after are the ones who break a block that was sized to the event days only;
  • the number of rooms and the types, counted in rooms, not in people, because two colleagues sharing a twin is one room and two colleagues who will not share is two;
  • a budget per night you are willing to pay — withholding it does not get you a better price, it gets you offers you have to reject;
  • the date you need offers by, which is the single most useful line in the request: it is what turns an open-ended email thread into a decision;
  • a hotel shortlist, if the venue, the walking distance or an existing relationship narrows it;
  • a note with the things that are not fields: the arrival pattern, a late check-out for the last morning, meeting space, breakfast.

Then the offers come back, and this is where a block goes wrong quietly.

The four things to check in an offer

1. The total, not the nightly rate. A rate per night is not comparable across offers until you multiply it by rooms and nights and add what is and is not included. Breakfast, city tax, resort fees and the cost of a late check-out are the usual difference between the cheaper-looking offer and the cheaper offer.

2. The cancellation terms. What may you cancel, until when, and at what cost — both for the whole block and for an individual room inside it. These are two different rights and an offer can grant one and not the other.

3. The release and attrition terms. How many rooms can you hand back without a penalty, and by when. Then: what do you owe on rooms you keep and do not fill. Read these two together and against your own invitation status — if half your participants have not answered yet, a block whose release date falls before your RSVP deadline is a block that will cost you money for a reason that has nothing to do with the hotel.

4. How long the offer stands. An offer has a validity date, and it is usually short. Two excellent offers you cannot compare because the first expired while you waited for the second is the most common way this process fails.

After you accept

Accepting is not the end of the organizer's work; it is the start of assignment. Rooms exist and people have to be put in them, which means knowing who is actually coming, who is sharing with whom, and who is arriving a night early. The failure here is not dramatic, it is clerical: rooms held in the block while three participants book their own hotels on their own cards, and nobody notices until the invoice and the expense reports disagree.

That is the argument for keeping the block next to the participant list rather than in a separate thread. The block is a number of rooms; the participant list is the names that fill them; the budget is what both cost. Any one of the three in a different system means somebody reconciles them by hand.

How this works in Travel Code

Inside a company event in Travel Code, the organizer requests a block from the event itself: the dates, how many rooms and of what type, the budget per night, the date offers are needed by, an optional hotel shortlist and a note. Travel Code agents collect the offers from hotels.

The offers come back into the event side by side, and the comparison is the one described above: the total, the cancellation terms, the release terms — how many rooms can be given back without a penalty — and how long the offer is valid. The organizer accepts one in a click, the agent books the rooms, and the organizer assigns participants to them from the same participant list that shows who has accepted the invitation and who has not.

Because the event sits inside the platform the company already books and expenses with, the rooms, the flights booked around them and the money all stay in one place: the event's booking list shows every reservation made for it, with a filter for bookings that fall outside the travel window you set, and the budget shows planned, booked and spent, paid and remaining as the block fills.

The short version. Compare offers on the total, the cancellation rights, the release and attrition terms and the validity date — in that order. Size the block in rooms, not people, and include the edge nights. And keep the block, the names and the budget in one place, because the expensive mistakes in room blocks are not negotiated, they are clerical.

More on running company events

The product these articles describe is Company Events in Travel Code: one workspace for the people, the travel rules, the room blocks and the budget of a company trip.

Latest news

Your best journey starts right now!

Travel Code will process your personal data for setting up and managing your account, providing you with the requested travel management services, and as otherwise stated in our Standard Contractual Clauses for Controller/Processor. Travel Code may also process your data as a data controller in accordance with our Data Retention Policy and Cookie Policy.