How to manage travel and accommodation for your event

Getting an attendee to an event takes a working loop. Capture what each registrant needs. Get the request to the team that books it, then land the booked result back on the event record. The guides in this series walk through setting up and running that loop with the Travel module.

Overview

Travel for an event involves three parties. The registrant states what they need: where they stay, and how they reach and leave the event. So does whoever completes registration on their behalf. You, the planner, enable the travel step, follow completeness, and keep the event record whole. The travel team, your own booking team or your travel management company (TMC), works the submitted requests on the event. It books them in its own systems.

Travel spans both surfaces. In the event workspace, the travel step is part of the registration journey. The submitted requests are worked in Registration booking: the accommodation and transportation requests for that event. The booking, the spend, and any confirmation to the registrant are recorded there.

The reporting runs in Onomi 360: open the event and select Travel to reach four tabs.

• Requests reports the travel requests captured with registration, their policy result, and their status.
• Travelers lists each registrant's travel record and carries the Completeness view for follow-up.
• Manifests holds arrivals, departures, and the Discrepancies view.
• Room blocks holds the event's room-block inventory, created from sourcing awards or added manually.

Captured requests flow from the registration journey into these views. Booked results land back on the registrant's record. The registration list and the travel picture stay on one event record.

Before you start

• Roles. Enabling the travel step, choosing its fields, and working the submitted requests in Registration booking are all workspace work. Each takes a Manager or Editor role on the event's workspace.

  Two assignments hold the work on the event's Travel module in Onomi 360: the planners of the event's workspace (workspace Manager or Editor), and holders of the finance role whose scope covers the event. That work covers the request report, the traveler records, the corrections you make on a registrant's behalf, the manifests, and the room blocks.

  Any organization Member who joins or is added to the event's workspace holds those planner writes on that path, whatever their strategic meetings management scope. Organization members work with Editor permissions in the workspaces they access. See Role-based access and visibility for internal and external stakeholders for the containment guidance.

  An Approver, Compliance reviewer, Sourcing, or Program lead assignment covering the event opens the event's travel records read-only.

  Creating a room block from a sourcing award is the one write that reaches this module from outside it, and it is made on the sourcing side. A holder of the Sourcing grant whose scope covers the event selects Create room block. The block then lands in Room blocks, where the two assignments above work it (see Room blocks).

  An organization administrator maintains the travel policy in Onomi 360 > Policies, and the Markets list with it. The policy's per-market accommodation cap is set on that list. See Reviewing the travel policy in Setting up travel and capturing travel needs.

  The role registry's per-role write column and the full precedence rule are documented in Role-based access and visibility for internal and external stakeholders.

• Registration. The travel step is a step of the registration journey, so the event's registration page must be configured first. Travel details are always attached to a registration record.
• Approval. Travel capture follows event approval. Registration, and with it the travel step, exists only once the meeting request is approved. So no travel need is captured before approval clears, and nothing is booked for an event that has not been approved. See How to set up and use meeting requests and approvals. The travel-policy check gates a captured request before it is booked. See Reviewing the travel policy in Setting up travel and capturing travel needs.
• Travel-system connection (optional). If booked itineraries should flow back automatically, the connection to your TMC or travel system is configured for your environment before the event. See The booking loop, manifests, and travel reporting for what to prepare.

The guides in this series

• Setting up travel and capturing travel needs: enabling the travel step, choosing its fields, and the organization travel policy every request is checked against. It also covers how submitted requests are worked on the event and reported in Onomi 360, meetings with no workspace, and how each registrant's travel needs are captured and followed to completeness.
• The booking loop, manifests, and travel reporting: how booked itineraries reach the event record, through a connected travel system or recorded manually. It also covers the arrivals and departures manifests, the discrepancy view, and the exports built from them, plus what happens when an event is cancelled.
• Room blocks: the room-block entity end to end. The guide covers defining blocks from a sourcing award or manually, registration claims and planner assignments, the block's rooming list, confirmation links, attrition alerts, and following uptake.

For what the module does and where its boundaries are, see the Travel release notes.

* Onomi 360 MeetingsEQ exclusive capabilities.