Group accommodation and room blocks from sourcing

An event's bedroom need goes to market through the same sourcing flow as its meeting space. Where the room spend commits depends on how you run the request. This guide covers the rooms-only request, the award targets, and the room block an award creates. The RFP mechanics are covered in Sending the RFP, comparing bids, and contracting the venue.

When an event needs bedrooms, group accommodation is sourced and bid through the same RFP flow. Include the bedroom need 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 where the room spend commits.

A sourcing request that carries both the meeting space and the bedroom need is a venue request. Its whole award commits to the budget category whose Sourcing award target is set to Venue, and it occupies the venue award target rather than a second one. Where 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: 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.

Which award target a request occupies is derived from what the request carries, on the rule above.

• A request carrying the meeting space, with or without the bedroom need, is the venue request. It occupies the Venue award target.
• A request carrying the bedroom need and no meeting space is the room-block request. It occupies the Accommodation award target.

The target is re-derived from what the request carries for as long as the request is in RFP draft. A draft can therefore still be completed either way. A draft that starts with bedrooms alone becomes the venue request the moment meeting space is added to it.

A request holds 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 holds 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. That 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, rather than taken back to market. An instant-booked request carries 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. That leaves the Accommodation target free for a separate rooms-only request, and Start sourcing available to start one.

An event holds 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. That ceiling is enforced in two places rather than as a single refusal at the end of a flow.

• Start sourcing is no longer offered on the event once the event holds two sourcing requests, drafts included. That bounds the number of open requests before any of them has gone to market.
• A draft whose derived target is already held by another request on the event is refused when it is sent.

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, Start sourcing is still offered 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. A draft reduced to bedrooms alone on an event whose room-block request has already gone to market is refused at the same point, naming that request.

A request sent on the wrong target is recovered on the same rule. Where a request carrying both the meeting space and the bedroom need 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 sits in RFP draft it holds no target, so the send-time refusal above is what still holds the ceiling of one request per award target.

Which target each of the event's requests holds follows the derivation above, so check what a draft carries before you send it. Each request carries its own status and its own award. See Following sourcing across your events in How to source a venue from your event for how the two read together. After the award:

1. 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.

   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, and they carry that currency into the travel step where a registrant claims a room from the block. The currency matters for the accommodation cap that reads 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. The block list is empty 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 whose travel step is 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.

2. Rooms are consumed the way every block is consumed. Registrants, or whoever registers on their behalf, claim rooms during registration. You assign guests to rooms or properties from the block view. Claims and assignments count against the same capacity, which both surfaces read live.
3. 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 stay 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.

4. Follow consumption from the block view: claimed and assigned rooms count against the block's capacity, so you always see how much of the commitment is used.

   Attrition alerts also ride on the sourcing connection, and are raised against the contracted attrition schedule for the block. That schedule comes with the award, rather than from a threshold your organization sets. Each alert shows 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 held for a meeting with no workspace takes no claims and no guest assignments, so no attrition alert is raised on it.

   See Room blocks, which documents the alert and the tab. The room-block costs sit on the event record with the rest of the event's financials.

   

For congresses, city-wide accommodation programs can be taken 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, where negotiated group rates and bureau-held inventory dominate, sourcing runs as a structured RFP to the market rather than 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.