A room block is hotel inventory reserved for your event.
Those are rooms your organization has committed to, offered during registration and drawn down as they are consumed. Room blocks and allotments name the same thing here.
The allotment is the block's room inventory: the reserved rooms that its capacity counts and that its claims and assignments draw down.
There is one room-block entity, whichever way a block is created. This section defines its fields, its two creation paths, and its consumption model.
The Room blocks tab is present on the event's Travel module in Onomi 360 whenever the travel tabs are. The list remains empty until the event has a block.
The block can come from a sourcing award or be added manually. The travel step is the condition for claiming, not for the tab: it is what lets registrants claim rooms during registration.
On an event with a workspace, a block still exists and you can manage it in Onomi 360 even if the travel step is off. Planner assignments alone draw down that block.
A record-only meeting has neither claiming nor a registration list to assign guests from.
Its block records the commitment and its cost only (see Meetings with no workspace in Setting up travel and capturing travel needs).
Creating and editing a block
Defining a block
A block is created in one of two ways. Both land in the same Room blocks tab on the event in Onomi 360, and you get the same entity either way:
-
From a sourcing award. When group accommodation is sourced and bid through the sourcing flow, the block is created from the awarded pricing, at the bid's rates.
It can span one or more hotels, and lands in this tab as a platform write attributed to the award.
The block's rates are stated in the currency the hotel quoted its bid in. That currency comes with the rate into Nightly rate requested when a registrant claims a room from the block.
That currency decides whether the accommodation cap can be checked against that rate. See Choosing the travel fields and Reviewing the travel policy in Setting up travel and capturing travel needs.
Creating the block from an award is sourcing-side work. The person working the awarded pricing, a holder of the Sourcing role with a scope that covers the event, selects Create room block.
The block it creates is then worked in the Room blocks tab.
Two groups can edit that tab and add blocks manually: the planners of the event's workspace, and holders of the finance role with a scope that covers the event.
See Role-based access and visibility for internal and external stakeholders. See Group accommodation and room blocks from sourcing for the sourcing steps.
-
Added manually. For rooms negotiated outside the sourcing flow, open the event's Travel module in Onomi 360. Select the Room blocks tab, then select Add a room block, and complete the fields:
- Block name: how the block appears in the accommodation section of the travel step, for example "Congress hotel".
- Hotel: the property the rooms are reserved at. A manually added block is for one property. Blocks spanning several hotels come from sourcing awards.
- Stay window: the first and last night of the block. Pre-filled with the event dates, and editable for blocks that cover early arrivals.
- Capacity: the number of rooms reserved. Claims and assignments are counted against this number. You can raise capacity at any time; lowering it below what is already taken is refused, for example "Capacity cannot be set below the 24 rooms already claimed."
A manually added block has no rate information. Rates belong to blocks created from a sourcing award and flow from the bid.
Select Save. The block is offered in the travel step for as long as capacity remains. You can define several blocks for one event, for example two hotels at different distances from the venue.
A block is edited in place. No control here removes or retires one. To take a block out of use, you set Capacity down to the rooms already claimed or assigned.
Going down to that number is permitted and makes the block full, so it is no longer offered in the travel step.
The block remains on the Room blocks tab with its record and its claims.
A block with nothing claimed goes to zero capacity the same way. Plan the blocks on an event as an additive set.
Consumption and pickup
How rooms are claimed and assigned
However a block was created, its rooms are consumed in the same two ways, and both count against the same capacity:
-
Registrants claim rooms during registration. A registrant who requests accommodation within a block's stay window is offered the blocks with remaining capacity, and claims a room, as does whoever registers on their behalf.
The claim is recorded on their registrant record, and the block's uptake count increases by one.
When a block is full it is no longer offered, and the accommodation request goes to the event's travel team like any other.
A registrant who reaches the accommodation section as the last room goes sees "The Congress hotel room block is fully claimed. Your accommodation request will be sent to the event's travel team instead." and completes registration without losing what they entered.
-
The planner assigns guests from the block view. In the Room blocks tab, allocate a guest to a room or, in a multi-hotel block, to a property.
Assignments draw down the same remaining capacity as registration claims.
When a registration with a claimed or assigned room is cancelled, the room returns to the block's remaining capacity.
Two further features come with the sourcing connection on blocks created from a sourcing award: attendee confirmation links and attrition alerts.
Confirmation links for guests
A confirmation link lets a guest confirm their stay and requirements directly, and you see the block update as confirmations come in.
On a block created from a sourcing award, each guest receives the confirmation link automatically on the sourcing connection.
The send happens when their room is claimed during registration or assigned to them by a planner.
There is therefore no control for it on the Room blocks tab and no holder for it, unlike the attrition alert beside it; the alert's readers are named below.
A guest is therefore someone who already holds a room in the block. A block on a record-only meeting sends no confirmation link.
A record-only meeting has neither claiming nor a registration list to assign guests from. The block therefore has no guests (see Meetings with no workspace in Setting up travel and capturing travel needs).
The guest receives the link in their preferred language if the platform has one recorded for them, and in your organization's default language otherwise.
It is the same rule the delegated travel step follows (see Sending the delegated travel step in Setting up travel and capturing travel needs).
The link is neither a lifecycle notification nor a budget-policy notification.
It has no template on the Notifications tab (see Configuring notifications for requests and approvals). It adds no per-language text for your administrators to supply.
A confirmation records the guest's confirmation against a room they have already claimed, or that a planner has already assigned to them.
The confirmation consumes no further capacity. It updates that room's confirmation state, and the Claimed and Remaining figures on the block's row are unchanged by it.
The block's rooming list
A block's rooming list, whichever way the block was created, is its own claim list. It lists the guests with a claimed or assigned room, and the nights they stay.
In a block spanning several hotels, it also names the property of each room. You see it on the block's row in the Room blocks tab (see Following uptake below).
Who holds which room is therefore on the event record, not in a spreadsheet kept beside it. A block on a record-only meeting has no guests.
Its claim list therefore has no rows (see Meetings with no workspace in Setting up travel and capturing travel needs).
Attrition alerts
The attrition alert follows the contracted attrition schedule for the block. The schedule comes with the award, not from a threshold your organization sets. A block with pickup behind that schedule is flagged.
The alert names the block, its pickup against capacity, and the next release date on the contract. It identifies the block to act on, not the event.
The alert is an on-screen flag, not a notification, and nothing is sent.
It shows on the block's row in the Room blocks tab, beside that block's Claimed, Capacity, and Remaining figures (see Following uptake below). The event's Travel module header continues to show remaining capacity only.
The alert's readers are the people who can edit that tab: the planners of the event's workspace and holders of the finance role with the event in their scope.
A block reserved for a meeting with no workspace has neither claiming nor a registration list to assign guests from.
No pickup moves against it, and no attrition alert is triggered there. The block records the commitment and its cost only.
Releasing or renegotiating that commitment is done with the hotel outside the platform (see Meetings with no workspace in Setting up travel and capturing travel needs). See Group accommodation and room blocks from sourcing.
Shared block inventory
The block inventory is shared between the two surfaces. Blocks are defined and managed in Onomi 360, beside the sourcing awards and costs they came from.
The registration journey in the event workspace uses their live availability and records claims back. The travel team and the registration list always see the same remaining capacity.
Following uptake
- In the Room blocks tab, you see each block's Claimed, Capacity, and Remaining figures as registrations come in.
The block's rooming list is below it: the guests holding a claim or an assignment, each with their room and the nights they stay.
Remaining capacity also shows on the event's Travel module header, so you can see a block filling up from any of the travel tabs, not only inside this one.
- Follow uptake from here, on the same event record as the registration list. You see a block that is filling too slowly while there is still time to act.
For congress accommodation beyond your own blocks, city-wide hotel programs can be sourced and bid through the integrated sourcing engine. See Group accommodation and room blocks from sourcing.
* Onomi 360 MeetingsEQ exclusive capabilities.
Comments
0 comments
Please sign in to leave a comment.