Booking Cut-Off Times and Allotments Explained
Two settings most operators fill in once and never look at again.
A cut-off time is the point before a departure when you stop accepting bookings. An allotment is a fixed number of places set aside for one sales channel.
Both get configured during setup, usually with a round number chosen quickly, and then never revisited. Both are quietly costing most operators bookings.
Cut-off times, and what they cost
The need is real. Somewhere before a departure you have to know your numbers, tell whoever is running it, and produce a list. A booking arriving while the guide is already walking to the meeting point helps nobody.
But a cut-off is also a standing instruction to refuse business. Every hour of it is time during which somebody wanting to book your tour is told no — and late bookings are exactly the ones you were not going to get any other way.
A quick diagnostic on your own data: what share of your bookings arrive in the final seventy-two hours? Whatever that number is, it is roughly what a seventy-two-hour cut-off would be turning away. Most operators have never looked, and most are surprised.
Setting one that is not costing you
Work backwards from what you genuinely have to do, rather than from a number that felt safe.
- List what must happen between the last booking and the start: telling a guide, generating a manifest, buying tickets, ordering food, confirming a vehicle.
- Time the slowest of those honestly, including whether it can happen at nine at night or only during business hours.
- Set it per product. A city walk needing a guide told and a list produced is a different problem from a boat trip requiring catering and a permit. One global setting means every product carries the constraints of your most complicated one.
- Check your channels' own minimums. Platforms sometimes impose their own, and yours cannot be shorter than theirs on that channel.
The frequent finding is that a two-day cut-off exists on a tour needing two hours of preparation, because somebody picked forty-eight hours during setup and nobody questioned it since.
Allotments and where they came from
An allotment gives a channel a fixed slice of your capacity: four of your twelve seats belong to this platform, four to that one, four to your own website.
This made complete sense before systems could keep availability synchronised in real time. If a platform could not be told instantly that a seat had gone, handing it a fixed allocation was the only safe way to sell in more than one place at once. That constraint has mostly gone — which is what a channel manager removed — but the habit remains.
What splitting costs, worked through
The problem with allotments is that demand does not arrive evenly. Take a twelve-seat departure, three channels, and ten booking requests that land six, three and one.
- Split four each: the busy channel sells its four and turns away two people. The others sell three and one. You sell eight — having refused two customers while four seats sat empty.
- Pooled: every channel sells from all twelve. You sell ten, refuse nobody, and finish with two spare.
Two extra bookings on the same departure from identical demand — 25% more revenue, without any additional marketing.
And the failure is invisible. The refused customers do not tell you, and you see a departure that ran two-thirds full rather than one that turned business away. Managing capacity across channels goes into the wider picture.
When an allotment still makes sense
Not never — but as a commercial decision rather than a technical necessity.
- A partner needing guaranteed places. A hotel with a standing arrangement, or an operator committing to a series, may reasonably want certainty rather than whatever is left. That guarantee is worth something and should be priced accordingly.
- Capping exposure to one channel. If you are deliberately limiting how much of a departure a single marketplace can fill, an allotment is the mechanism — managing channel dependence covers when that is worth doing.
- Holding places for direct bookings on departures that reliably sell out, so your own customers are not locked out of your best dates.
In each case you are accepting fewer total bookings in exchange for something else. That is a fine trade when made deliberately, and an expensive accident when it is just how the system was configured.
Sensible defaults
- Pool availability by default. Use allotments only where you have a specific reason, and write the reason down.
- Set cut-offs per product, derived from actual preparation time rather than a single global number.
- Shorten cut-offs in peak season where you can — that is when late demand is highest and when the refused bookings cost most.
- Review both once a year, ideally before your season starts. Ten minutes, and it is the cheapest revenue available to you.
- Whatever you set, make sure availability syncs, since pooling capacity without real-time updates is how overbookings happen.
That last point is the honest caveat to everything above. Pooled availability is better than allotments only when the pool is genuinely shared in real time — otherwise you have removed the safety net that allotments were providing.
How Travelity handles it
Availability is pooled by default and shared live across connected channels and your own booking widget, so every channel sells from the same real-time pool rather than a slice of it — with cut-off times set per product rather than globally.
Frequently asked questions
What is a booking cut-off time?
The point before a departure at which you stop accepting bookings, so you can finalise numbers, brief whoever is running it and prepare a manifest. It is a genuine operational need, and it is also a decision to refuse every booking that would have arrived after it.
How long should my booking cut-off be?
Work backwards from what you actually have to do rather than picking a round number. A walking tour needing only a guide told and a list generated might justify two hours; one requiring permits, catering or equipment hire needs considerably longer. Set it per product rather than once for everything.
What is an allotment in tour bookings?
A fixed number of places set aside for one sales channel — twelve seats divided into three allocations of four, for example. It was the standard approach before systems could keep availability synchronised in real time, and in most cases it now sells fewer seats than pooling capacity does.
Why are allotments worse than pooled availability?
Because demand does not arrive evenly across channels. If one platform gets six requests for its four allocated seats while another gets one for its four, you turn away two customers while four seats stay empty. Pooling the same twelve seats would have sold ten instead of eight.
When does an allotment still make sense?
When a partner needs guaranteed places rather than whatever is left — a hotel with a standing arrangement, or a group buyer committing in advance — or when you deliberately want to cap how much of a departure one channel can take. Both are commercial decisions rather than technical limitations.
In short
Pool your availability unless you have a written reason not to, because splitting twelve seats three ways can sell eight where pooling sells ten. Then check your cut-off against what preparation genuinely takes, per product — a great many operators are refusing two days of demand to protect two hours of work.
Related guides
See Travelity in action. Book a Personalized Demo.
30 minutes that can completely change the way you run your travel business. See how Travelity can help you work smarter, sell more, and operate with less stress.