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, or whoever completes registration on their behalf, states what they need: where they stay, and how they reach and leave the event.

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, and you see four tabs.

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

The request view brings market routing, policy results, and booking status together so the event team can follow exceptions without working in the booking system.

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

  For each of them you need a Manager or Editor role on the event's workspace.

  Two groups work 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 with the event in their scope.

  The work spans 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 gains those planner edits 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 with the event in its scope opens the event's travel records read-only.

  Creating a room block from a sourcing award is the one write that comes into this module from outside, and it is made on the sourcing side.

  A holder of the Sourcing role with the event in their scope selects Create room block. The block then lands in Room blocks, and the two groups 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.

  What each role can change, 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.

  No travel need is captured until approval, 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, you need a connection to your TMC or travel system.

  Have it 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 explains how submitted requests are worked on the event and reported in Onomi 360. Two more sections handle meetings with no workspace and following each registrant's travel needs 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 explains 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 explains defining blocks from a sourcing award or manually, and registration claims and planner assignments.

  It then walks through 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.