The booking loop, manifests, and travel reporting

This guide explains the return half of the travel loop: how booked results land on the event record, and the manifests and reporting built from them.

The booking loop

Capturing the request is one direction of the loop. The other is the booked result landing back on the event record.

Booked results reach the record two ways: delivered by a connected travel system, or recorded by hand for a booking made outside one.

Both produce the same kind of travel record on the registrant. The Manifests tab and its Discrepancies view are views over the travel records on the event, whichever way each one arrived.

Neither view books anything, and neither connects to a reservation system directly. What you see is exactly what your team and your connections have put on the record.

If you have no connection, the event still gets both views, built from the bookings you record manually.

Connecting your travel system

Through a travel-system connection (Concur is a common pattern), booked itineraries flow from your TMC or travel system into the event record and are matched to the registrant.

Travel-system connections are configured for your environment. Contact your SpotMe Account Manager to plan the connection. Prepare four things for that conversation:

• The system and its owner: which travel system or TMC the itineraries come from, and the contact who administers it on your side.
• The teams that book: which of your travel teams or agencies book for your events, so the connection includes every one of them.
• The event identifier: the reference the booking team attaches to each booking, so itineraries land on the right event.
• The traveler and source identifiers: the traveler reference used for matching and the source record ID kept with the itinerary. The source record ID lets a later change update the existing itinerary instead of creating another one.
• The field mapping: which itinerary fields flow. Typically the traveler, the segments (flight or rail) with dates and times, and accommodation confirmations with check-in and check-out.

Once connected, itineraries are matched to registrant records as they arrive, and you see who holds a booking, who does not, and what changed.

Itineraries are matched on the traveler and the event reference the booking team attaches.

Keep the event identifier on every booking. A booking sent without it cannot be matched to a registration, and does not reach the event record at all.

If Concur also returns expense records, the implementation can match an expense to an existing budget line or create a new line where the agreed mapping allows it. Concur remains the system of record for the travel or expense transaction. See Connecting finance, procurement, travel, and transparency systems.

Recording an out-of-loop booking

Bookings made outside connected systems, for example by a local agency, are recorded on the event so the picture remains complete:

1. In the event workspace, open Registration booking and open the request the booking was made against.
2. Record the itinerary as received:
   • Who booked it.
   • The segments (type, date, time, from, and to).
   • The accommodation with its check-in and check-out, if a room was booked.
   • The reference as received from the agency.
   • What it cost.

   Mark the request as booked.

3. The recorded booking is stored on the registrant alongside itineraries from connected systems, and it counts in the same views, manifests and discrepancies included.

   The request shows Done on the event record in Onomi 360.

Pulling manifests

Travel manifests and reporting work from the itineraries on record: the arrivals and departures manifests below, the Discrepancies view, and the spreadsheet export you can download from any filtered view.

1. In the Manifests tab, choose Arrivals or Departures. Each lists every registrant with an itinerary on record for your event dates. A row shows:
   • Name.
   • The Market on their registration record, resolved from its country. It is the same market the Completeness view shows and the filter in step 2 uses.
   • Date and time.
   • Origin or destination.
   • Segment details.
   • Who put the itinerary on the record: the registrant on their own transportation request, or the travel team recording a booking it made.
2. Filter by day, market, or travel type, then select Export. You get the current view as a spreadsheet for the transfer provider or the on-site team.
3. Build the transfer schedule from the arrivals manifest by grouping arrivals into time windows for ground transportation.

Working the discrepancy view

1. In the Manifests tab, open the Discrepancies view. It compares the itineraries on record with the registration list and flags the mismatches.

   Those are a registrant with no itinerary on record as the event approaches, and an itinerary for an attendee who cancelled after their trip was booked.

2. Work each flag on the event, in the workspace: chase the missing booking with the team that books, or tell that team about the cancellation.

   The view reports what needs attention. It changes no booking itself.

3. Check the view again in the days before the event. When it is clean, you have the verification that the travel picture and the registration list agree.

When an event is cancelled

If the event itself is cancelled, booked travel and accommodation are cancelled through the processes that booked them.

Tell the team that booked each one, and your connected travel system or agency handles its own cancellations.

On the event record, the travel records are marked cancelled. Any cancellation fees are captured as actuals on the event budget through reconciliation (see How to use the Budget module).

Rooms claimed against a room block return to the block, and the block's own cancellation runs under the terms of its award (see How to source a venue from your event).

A manually added block has no award terms to cancel under, because its rooms were negotiated with the hotel outside the sourcing flow.

The rooms claimed against it return to the block in the same way.

The commitment, with any cancellation cost attached, is settled with the hotel through the process that negotiated it, then recorded and reconciled as an actual on the event budget. See How to use the Budget module.

Whichever way the block was created, it remains on the record with its capacity and its claims. No control removes or retires a block, and a cancellation changes no field on it.

The cancelled event keeps its full travel picture: what was requested, what was booked, what was cancelled, and what it cost.

* Onomi 360 MeetingsEQ exclusive capabilities.