An event's accommodation requirements goes to market through the same sourcing flow as its meeting space. Which budget category the room spend commits to depends on how you run the request.
This guide explains the rooms-only request, the award targets, and the room block an award creates. For the RFP mechanics, see Sending the RFP, comparing bids, and contracting the venue.
The rooms-only request
When an event needs bedrooms, group accommodation is sourced and bid through the same RFP flow. You can include the accommodation requirements in the venue request, or run a rooms-only request.
Hotels bid on the block the way venues bid on meeting space. Which of the two you run decides which category the room spend commits to.
A sourcing request that includes both the meeting space and the accommodation requirements is a venue request.
Its whole award commits to the budget category with Sourcing award target set to Venue, and it occupies the venue award target.
If your organization wants the room spend in the category set to Accommodation, run the bedrooms as a rooms-only request instead.
A rooms-only request is a second sourcing request on the same event, beside the venue request.
It is started the same way as the first: you open the event record's Sourcing module and select Start sourcing again.
The second request is created in RFP draft status like any other, and it is worked through the same steps.
Award targets
Which award target a request occupies is derived from what the request includes, on the rule above.
- A request that includes the meeting space, with or without the accommodation requirements, is the venue request. It occupies the Venue award target.
- A request that includes the accommodation requirements and no meeting space is the room-block request. It occupies the Accommodation award target.
The target is re-derived from what the request includes for as long as the request is in RFP draft.
You can therefore still complete a draft either way. A draft that starts with bedrooms alone becomes the venue request the moment meeting space is added to it.
A request has its award target from the moment it goes to market: the send on the RFP route, and the confirmation of the booking on the instant-booking route.
It keeps that target until the event is cancelled, or until Reopen RFP returns it to RFP draft.
On a reopened request the derivation rule applies again, exactly as it does to a request that has never been sent. The target is re-fixed when the request is sent again.
An award settles the target on that request for the life of the event. The settled target is why Reopen RFP does not return an awarded request.
It is also why a replacement venue is agreed with the venue directly and recorded on the event record, not taken back to market.
An instant-booked request includes meeting space and no bedrooms, so the rule above makes it a venue request.
Confirming the booking occupies the Venue award target exactly as sending an RFP does. The Accommodation target is then free for a separate rooms-only request, with Start sourcing available to start one.
One request per award target
An event has at most one request per award target, so at most one venue request and one room-block request, and at most two sourcing requests in total. The limit is enforced in two places.
- Start sourcing is no longer offered on the event once the event has two sourcing requests, drafts included. This keeps the number of open requests bounded before any of them has gone to market.
- A draft is refused when it is sent if its derived target already belongs to another request on the event.
The second case is reachable because the target is re-derived for as long as the request is in RFP draft.
With the venue request already sent, you can still select Start sourcing for the rooms-only request. Adding meeting space to that draft makes it a venue request on the rule above.
Selecting Send RFP then returns "This event already holds a venue sourcing request. Remove the meeting space from this request to send it as an accommodation request, or work the existing venue request." and leaves the request in RFP draft.
On an event with a room-block request already sent, a draft reduced to bedrooms alone is refused at the same point, naming that request.
Recovering a request sent on the wrong target
You can recover a request sent on the wrong target on the same rule.
If a request that includes both the meeting space and the accommodation requirements went to market as the venue request, select Reopen RFP.
Remove the meeting space, and send it again as the accommodation request.
While that reopened request is in RFP draft it has no target, so the send-time refusal above is what still enforces the limit of one request per award target.
Which target each of the event's requests has follows the derivation above, so check what a draft includes before you send it. Each request has its own status and its own award.
The room block an award creates
See Following sourcing across your events in How to source a venue from your event for how the two read together. After the award:
- 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.
The block is created at the bid's rates, and can span one or more hotels.
It lands in the event's Room blocks tab in Onomi 360, beside the award it came from, as a platform write attributed to the award.
Those rates are stated in the currency the hotel quoted its bid in. The travel step keeps that currency when a registrant claims a room from the block.
The currency matters for the accommodation cap, which is compared against the claimed rate. See Setting up travel and capturing travel needs.
It is the same room-block entity as a manually added block, with the bid's rates attached. The block fields and the consumption model are defined once, in Room blocks.
The Room blocks tab is present on the event's Travel module in Onomi 360 whenever the travel tabs are.
You see an empty block list until the event has a block, whether that block was created from a sourcing award or 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 with its travel step off still exists, is managed in Onomi 360, and is drawn down by planner assignment alone.
On a record-only meeting there is neither claiming nor a registration list to assign guests from, so the block records the commitment and its cost only.
To enable the travel step, see Setting up travel and capturing travel needs.
- Rooms are consumed the way every block is consumed. Registrants, or whoever registers on their behalf, claim rooms during registration.
You can assign guests to rooms or properties from the block view. Claims and assignments count against the same capacity, and both views show it live.
- Guests receive their confirmation link. On a block created from a sourcing award, each guest receives it automatically on the sourcing connection.
The link goes out 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. The link confirms their room and requirements directly, and the block updates as confirmations come in.
A block on a record-only meeting has neither claiming nor a registration list to assign guests from, so it has no guests and no confirmation link is sent there.
Confirmation links ride on the sourcing connection and apply to blocks created from an award. The send and the language it goes out in are documented in Room blocks.
- Follow consumption from the block view: claimed and assigned rooms count against the block's capacity, so you see how much of the commitment is used at any time.
Attrition alerts also ride on the sourcing connection, and come from the contracted attrition schedule for the block. The schedule comes with the award, not from a threshold your organization sets.
You see each alert as an on-screen flag on that block's row, in the Room blocks tab of the event's Travel module, beside the block's claimed, capacity, and remaining figures.
A block created for a meeting with no workspace takes no claims and no guest assignments, so no attrition alert appears on it.
See Room blocks, which documents the alert and the tab. The room-block costs are on the event record with the rest of the event's financial records.
City-wide accommodation for congresses
For congresses, you can take city-wide accommodation programs to the market through the same RFP flow. The awarded blocks and their costs land on the event record like any other award.
Around compressed congress dates, when negotiated group rates and housing-bureau inventory dominate, sourcing runs as a structured RFP to the market, not an instant rate lookup.
For what this module does and where its boundaries are, see How to source a venue from your event.
* Onomi 360 MeetingsEQ exclusive capabilities.
Comments
0 comments
Please sign in to leave a comment.