Travel for an event starts with setup: the travel step on the event's registration journey and the organization travel policy that applies to every event.
This guide explains 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
- In the workspace main menu, select the Travel module. You set up and configure the travel step for this event here.
The reporting tabs (Requests, Travelers, Manifests, and Room blocks) are 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.
- 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 has (see Room blocks).
- 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 only an organization administrator can edit it 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 set 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 is staying 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 event's room blocks with capacity left for those nights (see Room blocks).
- Select your room, the room type on the block the registrant claims.
If the event has no block, or every block is full, the registrant states the accommodation they need. The request then goes to the travel team without a claim attached.
-
The nightly rate the policy checks: not a field the registrant types. The rate on 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).
The travel policy's Accommodation cap rule is checked against it, in the currency those rates are stated in. A request with no room claimed has 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.
If 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.
If 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 if 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. You see the travel step after the main form, asking exactly the fields you set.
After accommodation, the transportation step collects the method and journey segments configured for the event.
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.
- In the event workspace, open Registration booking. You see the requests submitted for this event, in two lists, Accommodation and Transportation.
Quick stats above them show total requests, pending requests, requests done, and requests held for review. You can filter to Pending, Done, or Held for review, or search by name.
- 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, if the registrant should be told, you can add a confirmation email.
The request then shows Done in both lists and on the event record in Onomi 360.
- Work the flagged requests first. A request the policy check flagged shows Held for review and waits 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.
- In Onomi 360, open the event and select Travel, then the Requests tab. You see the same requests as a report.
One row per submitted request shows 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 is for, the date it was submitted, its policy check, and its status. Requests held for review sort first.
The totals above the list show requests submitted, requests in policy, requests held for review, and requests booked. The state of the event's travel is one line, not a count of rows.
- 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. A request is booked, adjusted, or denied in the event workspace. 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 the status of each request. Nothing is booked in Onomi 360.
The event workspace is where the booking team works each request. Onomi 360 reports those requests across events with their assigned market team, policy result, and current status.
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.
- In Onomi 360, open Policies, then open the Travel policy tab.
- Set Travel types allowed: which needs requesters may submit at all. The default is all of them: accommodation, air, rail, and other ground transportation.
You can narrow it if 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 checks which travel types the submitted request includes.
- 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, and the registrant is not asked for it:
- domestic: the registrant's country on their registration record and the event country are the same.
- within market: the two countries are in the same market on the Markets list.
- beyond market: the two countries are not in the same market.
By default no classes are set, so class is not checked. Set the maximum flight cabin and the maximum rail class for each band in your policy.
The travel step does not ask a registrant for a class, so this rule has no field to check on a request.
Your travel team applies the rule when it books, and the check records that it did not apply.
- Set the Advance booking window: the minimum number of days before departure a request should be submitted, so the team books at reasonable fares.
By default none is set, so a late request is not flagged for its timing.
Set it to the number of days your travel policy states. The rule compares the departure date on the outbound journey with the date the step was submitted.
- Set the Accommodation cap for each market your policy caps.
A market is a named grouping of countries, and each market has a 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 you add and edit a market is documented in Maintaining the Markets list, in Setting venue rules in Onomi 360.
The cap is stored per market. The tab shows one row per market taken from the Markets list.
You set a cap by opening that market's row here. Markets are not added on this tab.
Accommodation cap: the maximum nightly rate. You set it per market, in that market's currency. By default there are no caps.
The cap checked for a request is the one on the event's market, because the room is at the event.
That cap is compared with the nightly rate on the request, which is the rate of the room the registrant selected.
Nothing is converted for that comparison, so it runs only when that rate is stated in the market's currency.
A rate taken from a room block is stated in the currency the hotel quoted its bid in. A block awarded in another currency has a figure the cap cannot be checked 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, as it does for a request with no room claimed.
When 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 event budget's currency 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; the booked cost lands in the budget.
A cap applies to every country in the market it is set on. If your policy caps countries differently, you need those countries in markets of their own.
- Select Save. The policy applies to every event in the organization from then on.
- Verify the policy: reopen the Travel policy tab and read the rules back. Each rule you set shows its value.
Every market you capped shows its amount on its own row, in that market's currency. A rule you left unset has no value, and what that means for a submitted request is described below.
The policy ships empty, and an empty policy releases everything. 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 needs 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 checks a field the travel step collects, as the entries above state.
What the check can see is what the step asks for. A rule with an empty field on the 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 not released. The request appears under Flagged in the Travelers tab and as Held for review wherever it is listed.
The travel step is one request that includes the accommodation and both journeys, so a flag keeps the whole submission from release.
A nightly rate over the accommodation cap keeps 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 checked, 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." You can 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 remains 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).
Record-only meetings do not run travel, so check the mapping before you plan a meeting with attendees who 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.
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 a record-only meeting, only a holder of the finance role with the event in their scope can edit them.
Workspace planner membership does not exist here, because there is no workspace (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 with the event in their scope captures them. With no workspace, that holder alone can edit the budget.
They reconcile and close there like any other cost. See How to use the Budget module.
If group accommodation was sourced for the meeting, the award and the block arrive separately.
Onomi posts the awarded amount to the budget's Committed column by itself, as a platform write. The platform write happens on any event.
The block appears in the Room blocks tab only once someone selects Create room block on the awarded pricing.
The person working the awarded pricing is a holder of the Sourcing role with the event in their scope (see Group accommodation and room blocks from sourcing). No notification announces the gap.
The gap bites hardest on record-only meetings. No planner is watching the tab, and the finance-role holder who edits this module 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.
The block records the commitment and its cost, and does not fill up.
Nothing moves against the pickup schedule either, so no attrition alert is triggered 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 with attendees who 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 that need nobody's travel or accommodation arranged.
Capturing travel needs
Travel request capture is part of registration. The accommodation and both journeys are captured with the registration journey, structured for the team that books them.
A travel request arrives on the event record in two ways, 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
- During registration, the registrant gets to the travel step after the main form.
- 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.
- 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.
You can also add or correct details on the event afterwards:
- 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.
- Enter the details as they come in by email or phone, and save.
- 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 are still to come, you can send the registrant a dedicated travel step instead of chasing them by email:
- In the event workspace, open the registrant and select Send travel step.
- The registrant receives an email with a link to a standalone travel page. The page shows their travel step only, pre-filled with what is already on record, and needs no workspace access.
- 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 goes out in the registrant's preferred language if the platform has one recorded for them.
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 goes to a person outside the travel step: the attendee confirmation link a room-block guest receives. It follows the same rule.
The guest receives the link in their preferred language if the platform has one recorded for them, and in your organization's default language otherwise.
Neither of these two travel sends has 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
- 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 checked 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 shows what they entered, and Missing details below lists 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.
- Filter by travel step status or market, then work the list. You can 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.
- 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.
Comments
0 comments
Please sign in to leave a comment.