Setting up travel and capturing travel needs

Travel for an event starts with setup: the travel step on the event's registration journey and the organization travel policy every event reads. This guide walks through that setup, then the ways each registrant's travel needs are captured, worked, and followed to completeness.

Setting up travel for an event

Enabling the travel step

1. In the workspace main menu, select the Travel module, where the travel step is enabled and configured for this event. The reporting tabs (Requests, Travelers, Manifests, and Room blocks) sit on the event's Travel module in Onomi 360. They are present whether or not the step is enabled. Travelers and Manifests have nothing to list until requests and itineraries arrive.
2. Turn on the travel step. The step is added to the event's registration journey, after the main registration form. Registrants see it as a step of registration, and so do those completing registration on their behalf. From here on, submitted requests appear in the workspace's Registration booking view for the team that books them. They also appear in Travelers on the event in Onomi 360. Registrants can claim rooms from any room block the event holds (see Room blocks).
3. Check the applicable travel policy: the organization travel policy every request from this event is checked against. It is read-only on the event and edited only in Onomi 360 > Policies. See Reviewing the travel policy below.

Note: The travel policy is defined once for the organization, in Onomi 360 > Policies. Every event's requests are checked against it. What you configure per event is the travel step and the fields it asks for.

Choosing the travel fields

The travel step asks for two things, and each is a step of its own on the registration journey. It asks where the registrant stays and how they reach and leave the event. What each one collects:

• Accommodation:
  • Check-in and Check-out, both pre-filled from the event dates and editable. The pre-fill is documented in From approval to execution and auditing requests. A registrant arriving a day early states it in the request.
  • The hotel, chosen from the room blocks the event holds with capacity left for those nights (see Room blocks).
  • Select your room, the room type on the block the registrant claims.

  Where the event holds no block, or every block is full, the registrant states the stay they need. The request then reaches the travel team without a claim attached.

• The nightly rate the policy reads: not a field the registrant types. The rate carried onto the request is the nightly rate of the room the registrant selects. That rate comes from the block's rates, which come in turn from the bid the block was awarded on (see Room blocks). It is what the travel policy's Accommodation cap rule is read against, in the currency those rates are stated in. A request with no room claimed carries no rate, so the cap has nothing to compare. The check records that the cap did not apply, and no flag is raised. The travel team applies the cap when it books.
• Transportation: the method for reaching the event and the method for leaving it, asked separately, each one Airplane, Train, or Other. Where a journey is flown or taken by rail, the registrant states the segments. They state the flight or service number, the departure and arrival locations, and the departure and arrival date and time. Where the journey is not direct, they add a segment for each leg. The reaching half also asks for the Event arrival date and time, when the registrant expects to be at the venue. The arrivals manifest and the transfer schedule are built from that field (see The booking loop, manifests, and travel reporting).
• Preferences and special request: your own additions, for example seating or special assistance. Name the field for what you are asking for, choose the field type, and mark it mandatory where the team needs it on every request. Keep preference fields few. Every extra field costs completion.

To verify the setup, open the registration page preview and walk the journey. The travel step appears after the main form and asks exactly the fields you configured.

Working travel requests

Travel requests are captured with registration, checked against your travel policy, and worked on the event by the people who book. Those people are your own travel team, a local booking team, or your travel management company (TMC) working in the event. Who may work a request is a matter of roles. On an international event, the market on each registration record decides which team the request belongs to.

1. In the event workspace, open Registration booking. It holds the requests submitted for this event, in two lists, Accommodation and Transportation. Quick stats above them read total requests, pending requests, requests done, and requests held for review. Filter to Pending, Done, or Held for review, or search by name.
2. Open a request to see what the registrant asked for, book it in your own systems, and record the result. Mark the request as booked, with what it cost and, where you want the registrant told, a confirmation email. The request then reads Done in both lists and on the event record in Onomi 360.
3. Work the held requests first. A request the policy check flagged is held, reads Held for review, and stays held until the flag is resolved on the event. Resolve it either by adjusting the request with the registrant or by accepting the flag with a reason (see Reviewing the travel policy below). Both paths keep the rule that fired, the reason, and who resolved it on the record.
4. In Onomi 360, open the event and select Travel, then the Requests tab, to read the same requests as a report. One row per submitted request carries the traveler, the market resolved from the country on their registration record, and the team that market maps to. The row also names what the request covers, the date it was submitted, its policy check, and its status. Requests held for review sort first. The totals above the list read requests submitted, requests in policy, requests held for review, and requests booked. The state of the event's travel is one line rather than a count of rows.
5. Select Export requests to download the list as a spreadsheet, for a team that works from a file. Select Open in the event workspace to go from a reported row to the request itself.

The two surfaces divide the work cleanly. The event workspace is where a request is booked, adjusted, or denied. That work belongs to one event and to the team running it. Onomi 360 reports across events: what was requested, whether it is in policy, and where each request stands. Nothing is booked in Onomi 360.

Reviewing the travel policy

Travel policy is not configured per event. It lives in Onomi 360 > Policies, in the Travel policy tab, applies to every event, and is maintained by an organization administrator.

1. In Onomi 360, open Policies, then open the Travel policy tab.
2. Set Travel types allowed: which needs requesters may submit at all. Default: all of them, accommodation, air, rail, and other ground transportation. Narrow it where your policy does not cover a type at all. To drop a type for one event, turn it off on that event's travel step instead. The rule reads what the submitted request covers.
3. Set Cabin and rail class: the maximum class allowed, set per travel type and per journey band.

   The journey band is resolved from the record rather than asked for:

   • domestic: the registrant's country on their registration record and the event country are the same.
   • within market: the two countries sit in the same market on the Markets list.
   • beyond market: the two countries do not sit in the same market.

   Default: no classes set, so class is not checked. Set the maximum flight cabin and the maximum rail class for each band your policy covers.

   The travel step does not ask a registrant for a class, so this rule has no field to read on a request. Your travel team applies the rule when it books, and the check records that it did not apply.

4. Set the Advance booking window: the minimum number of days before departure a request should be submitted, so the team books at reasonable fares. Default: none set, so a late request is not flagged for its timing. Set it to the number of days your travel policy states. The rule reads the departure date on the outbound journey against the date the step was submitted.
5. Set the Accommodation cap for each market your policy caps.

   A market is a named grouping of countries, and each market carries the currency its amounts are set and read in. A country belongs to one market at a time, so every registration record and every request resolves to exactly one market. The list itself is maintained once for the organization in Onomi 360 > Policies > Markets. How a market is added and edited is documented in Maintaining the Markets list, in Setting venue rules in Onomi 360.

   The cap is held per market. The tab shows one row per market taken from the Markets list. So a cap is set by opening that market's row here, rather than by adding a market on this tab.

   Accommodation cap: the maximum nightly rate for a stay, set per market and in that market's currency. Default: no caps.

   The cap read for a request is the one on the market of the event, because the stay is at the event. That cap is compared with the nightly rate the request carries, which is the rate of the room the registrant selected. Nothing is converted for that comparison, so it runs where that rate is stated in the market's currency.

   A rate carried from a room block is stated in the currency the hotel quoted its bid in. A block awarded in another currency carries a figure the cap cannot be read against. The amounts are not compared, the check records that the cap did not apply, and no flag is raised. The travel team applies the cap when it books, the same landing a request with no room claimed gets.

   Where the rate is in the market's currency, it is compared like any other. A block negotiated above the cap on the event's market flags every registrant who claims it.

   The currency the event budget is held in makes no difference here. The cap and the budget are never compared with each other. The cap is a policy limit on a nightly rate, and the budget is where the booked cost lands.

   A cap applies to every country in the market it is set on. A rate that differs country by country needs those countries in markets of their own.

6. Select Save. The policy applies to every event in the organization from then on.
7. Verify the policy: reopen the Travel policy tab and read the rules back. Each rule your travel policy covers shows the value you set. Every market you capped shows its amount on its own row, in that market's currency. A rule you left unset carries no value, and what that means for a submitted request is described below.

The policy ships empty, and an empty policy releases rather than holds. With no field set, a submitted request has nothing to be checked against. It passes the check and is released for booking, and the check is recorded on the request as passed with no rule applied. Set the fields your policy covers before your first event, so the first requests are checked against something.

Travel policy enforcement happens at submission. Every request is checked against the policy when it is submitted, and the result is recorded on the request. Each rule reads a field the travel step collects, as the entries above state. What the check can see is what the step asks for. A rule whose field is empty on a request does not fire. The check records that it did not apply, and the travel team applies that rule when it books.

A request within policy is released for booking. A request outside policy is flagged, neither silently blocked nor silently passed. The flag names the rule, and the request is held from release. The request appears under Flagged in the Travelers tab and as Held for review wherever it is listed.

The travel step is one request covering the stay and both journeys, so a flag holds the whole submission. A nightly rate over the accommodation cap holds the flights on the same request from release until the flag is resolved.

The flag quotes the rule it fired on and the value it read, for example "Nightly rate requested (EUR 320) is above the accommodation cap for France (EUR 250). This request is held until a planner resolves the flag." Adjust the details with the registrant, or accept the flag with a reason. Both are done on the event, in the workspace. Either way the outcome stays on the record and is reported in Onomi 360.

Meetings with no workspace

Your organization maps each request category to what approval creates. The categories mapped to record-only get an event record and no workspace, because the meeting itself is the execution (see Configuring what approval creates in From approval to execution and auditing requests). That lane does not run travel, so check the mapping before you plan a meeting whose attendees need it.

Everything in the sections above rests on the registration journey. The travel step is a step of registration, and each traveler record is attached to a registration record. The Travelers tab, its Completeness view, and Manifests with its Discrepancies view are built from those records. A record-only meeting has no workspace. It therefore has no registration page, no travel step to enable, no registrant to complete one, and no Registration booking view for a team to work. So none of that runs, and nobody claims a room from a block during registration.

The Travel module is still on the event record in Onomi 360, and its tabs are present. On this lane their writes are held by a holder of the finance role whose scope covers the event. There is no workspace planner membership for anyone to hold (see Role-based access and visibility for internal and external stakeholders). There is little in them to work. Travelers and Manifests have nothing to list, and the Requests tab has no requests to report. The travel step and its fields are workspace-side, so on a record-only meeting they do not exist at all.

What does run is the money. On a record-only meeting, travel and accommodation costs are captured as cost lines on the event's Budget module in Onomi 360. A holder of the finance role whose scope covers the event captures them, carrying the budget's writes alone where there is no workspace. They reconcile and close there like any other cost. See How to use the Budget module.

Where group accommodation was sourced for the meeting, the award and the block arrive separately. The award writes the awarded amount into the budget's Committed column by itself, as a platform write. That happens on any event.

The block reaches the Room blocks tab only once someone selects Create room block on the awarded pricing. That person is a holder of the Sourcing grant whose scope covers the event (see Group accommodation and room blocks from sourcing). No notification announces the gap.

That gap bites hardest on this lane. No planner is watching the tab, and the holder of the finance role carrying this module's writes is not the person who holds Create room block.

Neither way of drawing that block down runs here. Claiming needs the travel step on a registration journey, and there is no registration list to assign guests from. So the block records the commitment and its cost rather than filling up. Nothing moves against the pickup schedule either, so no attrition alert is raised on that block. Releasing or renegotiating the commitment is done with the hotel outside the platform.

The decision this points at belongs upstream, at the category. A meeting whose attendees need flights, rail, transfers, or rooms arranged for them belongs in a request category mapped to a workspace-creating behavior. Those behaviors are Create at approval and Create at Start execution, set in Onomi 360 > Policies > Event creation. Keep record-only for the meetings where nobody's travel or accommodation is arranged for them.

Capturing travel needs

Travel request capture is part of registration. The stay and both journeys are captured with the registration journey, structured for the team that books them. There are two ways a travel request reaches the event record, and both are first-class. For HCP events, the person completing registration is often not the attendee, and the flow is built for that.

The registrant completes the travel step

1. During registration, the registrant reaches the travel step after the main form.
2. They complete the accommodation step, choosing their dates, a hotel from the event's blocks, and a room. Then they complete the transportation step, stating how they reach and leave the event and the segments of each journey. They add any preferences, and submit.
3. The request is saved as structured data attached to their registration record. Their row in the Travelers tab shows the travel step as Completed, with the date. Once the policy check passes, the request is released for booking by the team it belongs to.

Completing travel on a registrant's behalf

Whoever registers the attendee, an affiliate, an agency, or an assistant, completes the travel details in the same step as part of on-behalf registration. Details can also be added or corrected on the event afterwards:

1. In the event workspace, open Registration booking and open the registrant's request. You see the same field set the registrant would see in the step, pre-filled with whatever is already on record.
2. Enter the details as they come in by email or phone, and save.
3. The request lands attached to the registrant, tracked the same as one they completed themselves. The record shows who completed it, and Onomi 360 reports it with every other request on the event.

Sending the delegated travel step

When the details will come later, send the registrant a dedicated travel step instead of chasing them by email:

1. In the event workspace, open the registrant and select Send travel step.
2. The registrant receives an email with a link to a standalone travel page. The page holds their travel step only, pre-filled with what is already on record, and needs no workspace access.
3. Their row shows the step as Sent, with the date. When they submit, the status changes to Completed and the request follows the normal path. Every send is recorded on the registrant with its date and sender. Each one is reported on their travel record in Onomi 360.

Note: The delegated travel step sent with Send travel step reaches a registrant in their preferred language where the platform holds one. For a registrant, that is the preferred-language profile field documented in Running multilingual events across global markets. Otherwise it goes out in your organization's default language.

One other send reaches a person outside the travel step: the attendee confirmation link a room-block guest receives. It follows the same rule. The link reaches the guest in their preferred language where the platform holds one for that person, and in your organization's default language otherwise. Neither of these two travel sends carries an editable template on the Notifications tab. So there are no per-language texts for your administrators to supply for them. See Room blocks.

Note: Reminders are manual. To nudge a registrant, open them in the event workspace and select Send travel step again. Each send is recorded on the registrant.

Following completeness

1. In the Travelers tab, select the Completeness view. It lists one row per registrant:
   • Registrant: name and registration status.
   • Market: resolved from the country on their registration record. The class rule's journey band is read against it. On an international event, it decides which team the request belongs to. It is also the market shown on the request report and on the manifests.
   • Travel step: Not started, Sent (with the send date), In progress (with the date the step was last saved), or Completed (with the completion date). In progress is a registrant who opened the step and saved it partly filled. Their row already carries what they entered, and Missing details below shows what is still empty.
   • Missing details: the fields still empty on a started request.
   • Policy: in policy, or flagged with the rule that fired.
   • Booking: whether an itinerary is on record; see The booking loop, manifests, and travel reporting.
2. Filter by travel step status or market, then work the list. Re-send the travel step, or complete the details on the registrant's behalf as they arrive, both in the event workspace. Filtering to In progress separates the registrants who began and stopped from the ones who never started, so follow-up can be aimed at either group.
3. To verify before the booking deadline, filter to every row not Completed. When that filter returns nothing, every registrant's travel need is captured and with the team that books it. The follow-up happened before the deadline, not after it.

* Onomi 360 MeetingsEQ exclusive capabilities.