How the numbers work

The figures in the event hub follow fixed rules. When a number looks wrong, it is usually one of the rules below at work. Each rule has a short example.

Registered, submitted and booked#

These words mean specific things and are not interchangeable.

For example, an event has 120 attendees. 94 have submitted, and 6 of them were later confirmed. The event overview shows 88 registered, while the Attendee manager and Visa management both show 94 submitted.

Booked counts people, not bookings. An attendee with three matched bookings counts once.

The Attendee manager leaves cancelled attendees out of every card, because their place is free again. Their row stays on the list. The event overview does not take cancelled attendees out of its slots or headcount.

Slots and progress#

Slots allocated is the number of places the event has set aside. Each team counts the size its point of contact (POC) declared for it. A POC who plays in the team uses one of those slots. A POC who does not play adds one more. For crew, talent, influencers and other roles, every person on the list is one slot.

Registration progress is registered divided by slots. Booking progress is booked divided by slots. Both are rounded to a whole number. A team with no slots declared uses the number of people on it, so a bar is never divided by zero.

For example, a team declares 8 slots. 6 have submitted and 5 have a matched booking, so registration progress is 75% and booking progress is 63%.

The colour beside each bar shows how far along the team is.

• Above 75% is green.
• From 50% to 75% is amber.
• Below 50% is red.
• Above 100% is a darker green.

Colour is never the only signal. The percentage is written beside the bar.

A team with more people than slots can go over 100%. That means the declared slots are too few, so ask the POC to correct them. No slots have been declared for this event yet, so progress runs from the registrations. means progress is counted from the people on the list instead.

Rooms needed#

For each room type and each night, HAPR counts the rooms needed. A trip adds a night for every date from check-in up to, but not including, check-out, and only when it has a room type and both dates. People sharing a room count as one room.

For example, four attendees stay in the Deluxe King block from 4 to 7 July.

• Two share a room from 4 to 7 July, so 1 room for 3 nights.
• One stays alone from 4 to 7 July, so 1 room for 3 nights.
• One stays alone from 5 to 6 July, so 1 room for 1 night.

The rooms needed are 2 on 4 July, 3 on 5 July and 2 on 6 July. Against 4 rooms contracted each night, pickup is 7 of 12 room nights, 58%, which shows as an attrition risk.

Room block management reads pickup like this.

• Over block when more rooms are needed than contracted.
• 90% or more is green and reads picked up.
• From 75% is amber and also reads picked up.
• Below 75% shows the percentage with attrition risk.
• No block when nothing is contracted for the room type.

A trip with no room type counts for nothing, however complete its dates are. This is the most common reason for a low figure. A missing check-in or check-out date also leaves the trip out. Importing attendees does not create room demand on its own. Only trips with a room type and both dates do. If you expected two rooms for roommates, check whether room sharing has been applied.

Shuttle vehicle times#

• For an arrival, the vehicle time is the landing time plus 60 minutes, for leaving the plane and collecting bags.
• For a departure, it is the take-off time minus 150 minutes, for check-in.

For example, a flight lands at 14:20, so the vehicle is there at 15:20. A flight leaves at 09:05, so the vehicle is there at 06:35. A very early flight can move the vehicle time to the night before.

The Shuttle report groups legs into one-hour windows by vehicle time, not flight time. A leg is listed only when it lands at or leaves from one of the event's airports. The 60 and 150 minute allowances are the same for every event. Flight times are as booked, and live status is shown separately where it is available.

Which bookings count for an event#

A travel booking counts for an event when both of these are true.

1. 1
   Its cost centre or project code is one of the workspace's project codes.
2. 2
   Its travel date is between 30 days before the start date and 30 days after the end date.

For a hotel, the travel date is the check-in date. Other event costs, such as venue hire, have no usable travel date, so they count by code alone. The rule uses the travel date, not the purchase date, so flights bought months ahead still count.

For example, an event runs from 20 September to 3 October on one project code, so the window runs from 21 August to 2 November. A flight bought in April for 19 September counts. A site visit flight on 15 August does not. A hotel checking in on 2 November counts. A venue hire cost on that code counts on any date.

Travel on the event's code that falls outside the window is left out, even though it is real spend. If a workspace has no project codes, nothing matches and the event shows no spend, so check the Project codes in the event details first. See The event hub.

The Shuttle report counts differently again. It reads the bookings on the event's project codes and lists the legs that touch the event's airports.

How a booking is matched to an attendee#

HAPR links each booking to a person on your attendee list and keeps the strongest match. This drives the booking column in the Attendee manager, Travel booked on the event overview and the traveller details in the Shuttle report.

1. 1
   The booking carries the attendee's ID. This is the strongest match.
2. 2
   The booking carries the event's project code or event ID together with the attendee's email, and has a flight leg at one of the event's airports inside the event window.
3. 3
   The booking's traveller email matches exactly one attendee and the booking is on one of the event's project codes. This weaker match shows with a dotted underline.

Some rules apply on top of these.

• For the third match, the email must belong to one person on your list only, and to fewer than six names in the booking data. If the booking has flight legs, one of them must touch an event airport inside the window. If it has none, the travel date must fall inside the window.
• This airport rule applies to events that end on or after 15 September 2026. Earlier events keep the older rule, which uses the travel date within 30 days of the event.
• An attendee ID that is used by more than five different travellers identifies nobody. Those attendees show a dash instead of a booking.
• A workspace with no airports cannot make the second match for current events, so set the Arrival airports / stations in the event details.

For example, an attendee registers for an event at Paris CDG from 4 to 6 July, on project code 6910. A booking with her attendee ID matches at the first level. A booking with her email and code 6910 and a leg arriving at CDG on 3 July matches at the second level. Another booking on code 6910 that flies Berlin to Munich on 12 July does not match. It has the right code but it is a different trip.

The match is worked out on a schedule, not as you look at the screen. A booking made an hour ago may not show yet.

How soon figures update#

A booking made this morning may not appear until this afternoon. Two people looking at the same dashboard a few minutes apart can see different figures while it refreshes. Reload the page.

Currency#

HAPR does not convert currencies. Amounts are added up as the travel agency sent them, with no exchange rate. A difference against a finance system that converts at a dated rate is expected.