Availability windows for meetings and the travel gaps nobody declares

The concierge report on the Wednesday after a show has a section nobody enjoys. Meetings placed in slot 1 on day one: 46. Meetings held in slot 1 on day one: 19.

The buyers were not being difficult. Availability windows for meetings had been collected as a tick against each show day, and a tick against Tuesday meant the buyer would be somewhere in the building on Tuesday. It did not mean 09:00. Twenty-seven exhibitors sat at tables while their counterparts were in a transfer from the airport, and every one of those meetings is in your system as a placement that happened.

Why the declaration is not a measurement

Registration asks for availability at the worst possible moment, which is three months out, before flights are booked, before the visa appointment, and before anybody knows which day the client meeting in the same city lands on.

What comes back describes an intention, and nobody has checked it against a flight. The buyer ticks all three days because that is the safe answer and because the form defaults to it. Your solver then receives a participant who is free for 24 slots and it will use all 24, placing meetings into the first and last of them because those are the least contested.

Bofill and colleagues, in the Journal of Artificial Intelligence Research in 2022, define the business to business meeting scheduling problem as assigning meetings between given pairs of participants to slots and locations while taking participants' availability and accommodation capacity into account. Availability sits in the model as a hard input, on the same footing as the table count. A solver treats it as ground truth because that is what a hard constraint means, and if you feed it a default it will build the schedule on the default with complete confidence.

The travel side of this is worse than most organisers assume, because it starts long before the transfer. The US State Department publishes estimated interview appointment wait times for visitor visas at each embassy and consulate, and the table it published on 17 August 2026 showed a next available B1 or B2 appointment of 24 months in Toronto and 18 months in Sydney. A buyer facing that queue is not deciding between slot 2 and slot 5. They are deciding whether they exist in your file at all, and the ones who do get through it often arrive on a routing that lands mid-morning.

Collect arrival and departure at confirmation

Move the question. Ask at confirmation, when the buyer has a booking reference, and ask for four fields: arrival date and time at the destination, departure date and time from the destination, hotel name, and whether they are travelling with anybody whose schedule they share.

That last field catches a surprising number of failures. Two buyers from the same company sharing a car have one arrival time between them, and if you model them separately you will place one of them in a slot the other cannot reach.

Then subtract the buffer. Ninety minutes at each end is a reasonable starting figure for a city venue with an airport transfer, covering the transfer, the hotel drop and the badge collection queue. On a venue with rail access from the airport it is less. On a venue that is 50 kilometres out with one shuttle an hour it is much more, and the honest number is the one you measure.

Measuring it is straightforward and nobody does it. Take last edition's declared arrival times and join them to the first badge scan timestamp for each buyer. The median gap is your real buffer. If the median comes out at 2 hours 40 minutes against your assumed 90 minutes, you have found the reason slot 1 fails, and you found it in a query rather than an argument.

What happens to the slot count?

Take a buyer on a two day programme, 7 slots per day, 14 slots nominally available.

She lands at 09:40 on day one. Apply a 90 minute buffer and she is usable from 11:10. On a grid of 40 minute slots starting at 09:00, slot 1 runs 09:00 to 09:40, slot 2 to 10:20, slot 3 to 11:00, slot 4 to 11:40. She cannot make slot 3, because 11:10 is inside it and a meeting that starts 10 minutes late is a meeting the exhibitor has already given up on. Round inwards: her first usable slot is 4. Day one gives her slots 4 to 7, which is 4 slots.

Her return flight is at 17:30 on day two and the airport is 50 minutes away, so she needs to leave the venue by 15:30 with a 90 minute buffer against a 17:30 departure. Slot 5 on day two ends at 15:40, so her last usable slot is 4. Day two gives her slots 1 to 4, which is 4 slots.

Total usable: 8 slots against 14 declared. She lost 6 slots, which is 42.9 per cent of her nominal availability, and every one of those 6 was a slot your scheduler was free to place a meeting into.

Scale it. If the median buyer loses 4 of 14 slots and you have 200 buyers, that is 800 buyer slots that exist in your model and not in the world. Against a floor of 40 tables and 14 slots, which is 560 places, you have been scheduling against a phantom capacity larger than the hall.

Which end of the day should you protect?

Both, and the answer is asymmetric in a way that matters.

A meeting missed at the start of day one is recoverable. The buyer is in the building by 11:00, the exhibitor is there for two more days, and a standby list can rebook them. A meeting missed at the end of day two is gone, because the buyer is at the airport and the show is over.

So if you have to choose where to be conservative, be conservative at the departure end. Push the last usable slot earlier than the arithmetic suggests and accept the lost capacity. I would take one fewer meeting on the final afternoon over one more no-show at 16:00 on the last day, because the second one costs an exhibitor a staffed table at the moment they are already dismantling.

There is a second asymmetry on the exhibitor side. Exhibitors are present the whole time, so their availability windows are genuinely the show's opening hours minus their own stand duties. That makes buyer windows the binding constraint almost everywhere, and it means the marginal value of collecting one more buyer's real arrival time is higher than anything you can learn about an exhibitor's day.

Where the data actually comes from

Four sources, in descending order of reliability.

The travel booking itself. If your programme books or reimburses flights, you already hold the itinerary. This is the only source that records what was booked instead of what somebody typed, and if the finance team holds it while the matchmaking team does not, that is a plumbing problem worth a week.

Confirmation-stage declaration. The buyer types their arrival time. Reliable enough, wrong for maybe one buyer in six, and the errors are mostly optimistic.

Badge scan at entry. Perfectly accurate and far too late to schedule against, though it is exactly what you need for measuring the buffer for next time.

The hotel list. Tells you the night of arrival without the hour, which is enough to distinguish a buyer who arrives the evening before from one who flies in on the morning. That single bit of information moves more meetings than any refinement of the score.

Once the windows are tightened, the gaps that remain in a buyer's day are the scheduler's doing rather than the airline's, and measuring those internal gaps becomes a question you can answer honestly. It also means your availability table holds real hours, which is what the write-through locking is protecting in the first place.

Where this stops

A tightened window is still a prediction. Flights are delayed, and a buyer whose window you computed carefully from a 09:40 arrival is unreachable all morning when that flight lands at 13:15.

The honest position is that availability windows remove the errors you created and leave the errors the world creates. Removing your own is worth doing because they are systematic: every buyer's window is wrong in the same direction, always too generous, always at both ends. The world's errors are random and roughly half of them work in your favour.

The second limit is that a buffer applied uniformly is wrong for everybody in a different way. Ninety minutes is too long for the local buyer who walked from an office two streets away and too short for the one connecting through a second airport. If you have arrival airports, buffer by origin. If you have nothing, use the median and say so in the report rather than presenting a computed window as a certainty.

The third is that some of what looks like a travel gap is a decision. A buyer who declared availability from 09:00 and turned up at 11:30 may have been in a client meeting they preferred to your slot 1, and no amount of buffer arithmetic distinguishes that case from a delayed train. The split between the two only becomes visible when you ask, which is why what you count as a no-show has to be defined before you start attributing causes to it.

Start by joining last edition's declared availability to the first badge scan per buyer and computing the median gap. If it is more than an hour longer than the buffer you currently apply, your first slot of each day has been selling capacity that was never there, and tightening the window costs nothing except a smaller number in the matchmaking capacity report.