Searching for venues and choosing how to book

Venue search runs from the Sourcing module on the event record: you search the connected sourcing partner's network from there, shortlist the venues to invite, and choose between instant booking and a venue RFP. The search itself, the result cards, and the ranking are the partner's. Onomi 360 holds the request, the shortlist, the award, and the venue rules the choice is checked against. This guide covers that first half of the flow. Completing and sending the RFP, comparing bids, and awarding the winner are covered in Sending the RFP, comparing bids, and contracting the venue.

Searching for venues

1. In Onomi 360, open the event record and select the Sourcing module. Select Start sourcing. A sourcing request is created in RFP draft status, pre-filled with the event's city or market and its dates.

   Start sourcing is the only action that starts sourcing, and it also takes you to the partner's search. The request's parameters are carried over with you, so the search opens on the market, the dates, and the sizes the request holds. Selecting Start sourcing again on the same event record starts a second request for the other award target. See Group accommodation and room blocks from sourcing.

   

2. Adjust the request parameters where needed: change the city or dates, set the attendee count, and add bedrooms if the event needs accommodation.

   What the request ends up carrying decides its award target. A request completed with the bedroom need and no meeting rooms is the rooms-only request, and it starts on the Accommodation award target. Any request carrying meeting space is the venue request, whether or not it also carries bedrooms. See Group accommodation and room blocks from sourcing.

   With the parameters right, open the search from the request: Start sourcing takes you there the first time, and Open in the sourcing system on the request row returns to it later. The parameters go with you into the connected sourcing partner's search, which runs on the partner's own instance. The results list the venues in the event's market that match your attendee count and dates.

   Where a venue's inventory is connected through its own systems, availability is live. For every other venue, the venue itself confirms availability in its response to your RFP. That response carries the date it was given, so the availability answer on the record shows who confirmed it and when.

   The partner ranks the results rather than returning them flat, and the ranking is AI-assisted. It reads the request's requirements, the location, the budget, and your organization's booking history. The venues most likely to fit the event therefore sit at the top.

3. Read the result cards the partner returns. Each card shows the venue's photos, its venue type and neighborhood, a capacity summary, a style tag (for example modern, boutique, or historic), sustainability accreditations, and its rating. Where a venue's inventory is connected through its own systems, the card carries live availability. Where instant booking also applies, it carries a live, bookable day rate, with any discount visible upfront. See Choosing how to book below.
4. Venues your organization has approved for the market, and venues where it holds preferred terms, are flagged on the partner's results, so the approved option and the negotiated option are visible while you compare. The flags come from the rules described in Setting venue rules in Onomi 360.

   

5. Select a venue to open the partner's profile for it: the description, the address with a map, the facilities list, a meeting-space summary, and the bedroom inventory. The meeting-space summary shows how many spaces the venue has and the guest range they hold. Use the profile to judge fit before you invite the venue to bid.
6. Select Shortlist on a result card or a venue profile. The venue is added to the request's shortlist, the shortlist count in the Sourcing module updates, and you can add or remove venues freely while the request is in RFP draft.

   Shortlisting is also what puts the venue on the event record. Venue entries are read in the Venue section of the event record, which lists them with the booked entry marked. It shows four things per entry:

   • the venue.
   • the kind of Entry it is.
   • the Venue rule result on it, Passed or Refused against the market's approved venue list.
   • when the entry was Last updated.

   An event record carries one venue entry per venue that has reached it. Four things create an entry:

   • the venue is shortlisted on a sourcing request.
   • a confirmed instant booking places the venue on the record.
   • a venue is recorded on the record directly with Add venue, as free text or picked from the market's approved venue list.
   • approval carries the venue a request named onto the record it creates.

   At most one of those entries is marked as the event's booked venue. None is marked until one of four things creates it: an award, a confirmed instant booking, a venue recorded directly on the record, or the venue carried from an approved request. An event whose sourcing request is still at RFP draft, RFP active, or Bids received therefore carries an entry per shortlisted venue and no booked venue at all.

   Recording or replacing the event's booked venue acts on the booked entry, which is what "the event record's venue entry" means in the singular where the documentation names that write. Removing a venue from the shortlist while the request is in RFP draft removes its entry again. Awarding marks the winning venue's entry as booked. The entries of the venues that were compared and not chosen stay compared rather than booked.

   The Venue section sits on the event record itself rather than inside the Sourcing module, so it is there on a record-only event and in an organization that has not enabled sourcing. Recording a venue there is not a sourcing action and needs no Sourcing grant. The grant gates the actions in the Sourcing module, which stays read-only without it.

   A venue is recorded there by the planners of the event's workspace (Manager or Editor), and by holders of the finance role whose scope covers the event. An event created under a record-only category has no workspace and therefore no planner, so there the finance role records it alone. See Role-based access and visibility for internal and external stakeholders.

   The venue rules fire at the points below, where a venue is put on the event record, not while you browse. Search itself is unrestricted, unless Centralized selection is on for the market. Where it is on, the results come from that market's approved venue list only.

   In the RFP flow, shortlisting is the first point at which a rule bites, because it is what puts the venue on the record. A venue recorded on the record directly with Add venue meets Require listed venues the same way. An instant booking is confirmed on the partner's surface and comes back as a status, so no venue rule fires on that route. Centralized selection is what closes it: with the setting on for the market, search returns approved venues only, so there is no off-list venue to book (see Choosing how to book below).

   The venue-type restriction reads the venue type the sourcing partner holds. It has nothing to read on a venue entered as free text, or picked from an approved venue list row. On those paths the people recording the venue apply the market's restriction. See Setting venue rules in Onomi 360.

   An approved venue list on its own flags: the venue is shortlisted and its entry carries the off-list flag. Require listed venues blocks, so shortlisting an off-list venue is refused with "This venue is not on the approved venue list for France. Select a listed venue." That refusal is where it ends. The venue is not shortlisted and nothing is raised for review. The way forward is a listed venue, or an organization administrator adding this one to the market's approved venue list.

   A venue of a restricted type is refused the same way: "Venues of type casino and gaming are restricted for France. Select a venue of a permitted type." Both blocks are checked again when the award returns to the event record. A venue shortlisted before the rule was switched on therefore meets the block at the award. See Setting venue rules in Onomi 360 and its Choosing a venue in a restricted market section.

Choosing how to book

The sourcing engine supports two booking modes, and the search results show which applies to each venue:

• Instant booking covers small, simple meetings without bedrooms, where the venue publishes a live, bookable day rate. Select the rate on the result card and confirm the details. The booking is placed at the displayed price, with no RFP and no waiting for proposals. The venue, date, and cost write back to the event record like any other award.

  Confirming the booking is what places the venue on the event record, so it creates that venue's entry in the Venue section and marks that entry as the event's booked venue.

  An instant booking reaches neither a shortlist nor the award check on a returned bid. Those are the points at which the two blocking venue rules are checked, so neither rule fires on this route. The booking is placed on the partner's surface, and what returns to the event record is its status.

  What keeps an off-list venue off this route is Centralized selection. With the setting on for the market, venue search returns that market's approved venue list only, so there is no off-list venue to instant-book. A market that must not book off-list venues therefore runs both settings. Require listed venues blocks the routes that put a venue on the event record. Centralized selection closes the one route that bypasses them. With Centralized selection off, search is unrestricted, and on this route the market's rules are applied by the people confirming the booking. See Setting venue rules in Onomi 360.

  A confirmed instant booking moves the request from RFP draft straight to RFP awarded, without an RFP being sent or bids returned. A reviewer reading the Sourcing module therefore sees a secured venue the same way for both booking modes.

  An instant booking covers meeting space without bedrooms, so the request behind it is a venue request. Confirming the booking occupies the event's Venue award target exactly as sending an RFP does. That leaves the Accommodation target free for a separate rooms-only request. See Group accommodation and room blocks from sourcing.

  The confirmation awards the request in the same step. Reopen RFP returns only a sent request that has not been awarded, so it does not release that target here. The shortlist you built in search stays on the awarded request as the venues that were compared.

• The RFP flow covers everything else: larger meetings, events with group accommodation, complex room and catering needs, and anywhere you want venues to compete on price and terms. Around compressed congress dates, sourcing always runs as an RFP to the market.

Note: Instant booking is available only where the venue publishes a bookable rate for your size of meeting. The applicable limit depends on the venue and the space. All other venues are invited through the RFP flow, covered in Sending the RFP, comparing bids, and contracting the venue.

Note: Restaurant meetings are not sourced through this flow. A restaurant is captured directly on the meeting request, as free text or picked from the market's approved venue list where one exists. Meal caps and the market's venue rules still apply to the restaurant like any other venue. What a restricted market allows depends on those rules.

See Setting venue rules in Onomi 360 and its Choosing a venue in a restricted market section.

* Onomi 360 MeetingsEQ exclusive capabilities.