Timed Entry, Open Dated or All Day: Choosing the Right Availability Model

This looks like a configuration detail. It is actually the decision that determines how your product appears in every search result, how a date picker behaves, whether you can oversell, and how many people turn up at the wrong time.

There are three models. Most products are obviously one of them, a few are genuinely ambiguous, and getting an ambiguous one wrong is expensive.

Start times

The traveller picks a specific departure. Each departure has its own capacity and its own cutoff.

This covers most guided products: walking tours, boat trips, cooking classes, timed museum entry, scheduled day trips. If a guide has to be somewhere at a particular moment, you are almost certainly here.

What to get right

Capacity is per departure, not per day. A tour running at 09:00 and 14:00 with twelve seats each has twenty four seats that day, but selling thirteen into the morning departure is an oversell even though the day has room.

The cutoff is relative to the departure, not to the date. "Bookings close 4 hours before" means the 09:00 closes at 05:00 and the 14:00 closes at 10:00. Systems that apply a single daily cutoff will either close your afternoon departure too early or let someone book the morning one after it left.

And the times are local to the product. A traveller in London booking a Bangkok tour at 22:00 their time is booking for tomorrow morning there. Store and display local time, convert only when comparing against the actual moment of cutoff.

Opening hours

The traveller picks a date. They arrive whenever they like within your opening hours.

This is general admission territory: museums without timed slots, hop-on hop-off buses, bike rentals, gardens, viewpoints. The date is the unit of sale.

What to get right

Capacity is per day, and it is often much larger than a start-time product, sometimes effectively unlimited. If it is genuinely unlimited, say so explicitly rather than setting an arbitrary high number, because "freesale" lets a reseller skip the availability check entirely and their search page gets faster.

Publish the opening hours as structured ranges, and remember they vary. Summer and winter hours differ, weekends differ, and public holidays differ from both. A single pair of times for the whole year will be wrong for a third of it.

Last admission is not closing time and travellers assume otherwise. If you close at 18:00 but stop admitting at 17:00, that hour is the source of a steady trickle of complaints. Put it on the ticket.

Open dated

No date at checkout at all. The traveller buys, receives a voucher, and uses it any time within a validity window.

City passes, gift vouchers, eSIMs, flexible attraction tickets. Anyone buying before they have planned their trip.

What to get right

Decide what starts the clock. There are two options and they are commercially very different.

First-use activation is worth the extra work. A traveller in February booking a pass for a trip they have not scheduled yet will buy a pass that starts when they scan it. They will hesitate over one that starts today.

The other thing to be explicit about is whether capacity applies at all. Usually it does not, which is exactly what makes these products good to sell. But if the pass includes an attraction that does require a reservation, say which ones on the product page, because the traveller will otherwise assume none of them do.

The awkward cases

Multi-day tours

A start-time product with a long duration. The departure date is the start time; the duration carries the rest.

Two flavours. Fixed departures mean specific dates you publish and sell seats on, which is the classic small-group model. Any-start means the traveller picks any date and the itinerary runs from there, which suits self-guided trips and lodge-based stays.

Fixed departures are start times with sparse availability. Any-start behaves more like opening hours with a long duration. Model them accordingly rather than forcing both into the same shape.

Rentals

Genuinely different, because the traveller is buying a duration rather than a departure. They collect at 10:00 and return at 16:00, and what you are really tracking is whether a bike is out.

The workable approximation is opening hours for the collection date, with the duration as a separate priced choice, and capacity counted against the physical fleet rather than against the date.

Private charters and shared resources

The hardest case, and the one most systems handle badly.

You have one boat. It runs a morning snorkel trip, an afternoon cruise, and can be chartered privately for the whole day. Selling the private charter has to make both scheduled departures unavailable, and selling either departure has to make the charter unavailable.

Availability here is not a property of the product. It is a property of the resource, and the products draw against it. If your system cannot express that, the honest workaround is to block manually and accept that you will occasionally forget, which is not a great plan for a boat .

Choosing, quickly

Three questions resolve almost every product.

1. Does a member of staff have to be somewhere at a specific moment? If yes, start times.
2. If no, does the traveller have to commit to a date? If yes, opening hours. If no, open dated.
3. Is the capacity shared with another product? If yes, you need resource-level availability regardless of which of the three you picked.

Cutoffs, which apply to all three

Whatever model you choose, the cutoff is what stops a booking arriving after you can act on it. Two numbers, not one.

The booking cutoff is how late someone can buy. Set it to the point at which you can still tell the guide, print the ticket and get the traveller the information they need.

The cancellation cutoff is how late someone can cancel with a refund. It is usually earlier than the booking cutoff, which surprises people but is correct: you may be happy to sell a seat four hours out and unwilling to refund one at the same moment.

Both are relative to the departure or the opening, both are in the product's local timezone, and both should be enforced in the system rather than remembered by a person.