Room blocks

A room block is held hotel inventory 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 held rooms its capacity counts and 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 stays 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 whose travel step is off still exists and is managed in Onomi 360. 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).

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, as the same entity:

• 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. They carry that currency into Nightly rate requested when a registrant claims a room from the block. That currency decides whether the accommodation cap can be read 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, meaning a holder of the Sourcing grant whose scope covers the event, selects Create room block.

  The block it creates is then worked in the Room blocks tab. Two groups hold that tab's writes and add blocks manually: the planners of the event's workspace, and holders of the finance role whose scope 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 held at. A manually added block covers one property. Blocks spanning several hotels come from sourcing awards.
  • Stay window: the first and last night the block covers. Pre-filled with the event dates, and editable for blocks that cover early arrivals.
  • Capacity: the number of rooms held. Claims and assignments are counted against this number. Capacity can be raised 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 carries no rate information. Rates belong to blocks created from a sourcing award, where they 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, so a block taken out of use is handled on the block itself. Lower Capacity to the rooms already claimed or assigned. That is permitted and makes the block full, so it is no longer offered in the travel step. It stays 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.

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. So is 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 reaches 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 apply to blocks created from a sourcing award, riding on the sourcing connection: attendee confirmation links and attrition alerts. A confirmation link lets a guest confirm their stay and requirements directly, and the block updates 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. So there is no control for it on the Room blocks tab and no holder for it, unlike the attrition alert beside it, whose 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. That lane 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 link reaches the guest in their preferred language where the platform holds one for that person, and in your organization's default language otherwise. That is the 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 carries 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.

A block's rooming list, whichever way the block was created, is its own claim list. It holds the guests with a claimed or assigned room, with their stay dates. In a block spanning several hotels, it also names the property each room sits at. It reads on the block's row in the Room blocks tab (see Following uptake below). Who holds which room therefore sits on the event record, rather than in a spreadsheet kept beside it. A block on a record-only meeting has no guests. Its claim list therefore carries no rows (see Meetings with no workspace in Setting up travel and capturing travel needs).

An attrition alert is raised against the contracted attrition schedule for the block. That schedule comes with the award, rather than from a threshold your organization sets. A block whose pickup is 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, rather than the event.

The alert is an on-screen flag rather than 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 people who read it are the holders of that tab's writes, the planners of the event's workspace and holders of the finance role whose scope covers the event.

A block held for a meeting with no workspace has neither claiming nor a registration list to assign guests from. So no pickup moves against it, and no attrition alert is raised 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.

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 reads their live availability and writes claims back. The travel team and the registration list always see the same remaining capacity.

Following uptake

1. In the Room blocks tab, each block shows Claimed, Capacity, and Remaining as registrations come in. The block's rooming list sits below it: the guests holding a claim or an assignment, each with their stay dates and room. Remaining capacity also shows on the event's Travel module header. A block filling up is visible from any of the travel tabs, not only inside this one.
2. Follow uptake from here, on the same event record as the registration list. A block that is filling too slowly is visible 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.