Can the Bot Just Check the Calendar? Availability Questions for Attractions

Attractions ask a different first question than hotels do.

A hotel wants to know whether the assistant can answer about check-in times, parking and breakfast. An attraction - a park, an activity centre, a ranch, a climbing venue - almost always opens with a version of this:

Do I enter availability manually, or does it go and check the calendar?

It is the right question, and the answer determines how much value the whole deployment produces.

Why availability is the hard part

Most guest questions have stable answers. Opening hours, prices, age limits, what to bring, where to park. These change rarely, they live comfortably in a knowledge base, and an assistant answers them well from day one.

Availability is different in three ways:

• It changes constantly, sometimes hour to hour on a busy weekend.
• It is the question that converts. Nobody abandons a booking over parking directions. They abandon over not knowing whether Saturday at 2pm is free.
• A wrong answer has real consequences. Telling a guest a slot is open when it is not produces an angry arrival, which is worse than the phone call you avoided.

So availability is simultaneously the most valuable thing to automate and the one with the least tolerance for approximation.

Manual entry is a trap

The instinct is often to enter availability into the assistant directly, because it feels controllable. Resist it, unless the thing genuinely does not change.

A manually maintained availability list is a second source of truth. It is accurate on the day it is written, and it drifts from that point on. It drifts fastest during exactly the periods where accuracy matters most - school holidays, long weekends, the run-up to a busy season - because that is when nobody has time to update it.

A stale availability answer is worse than no answer at all. I do not have that to hand, let me connect you to the team costs a guest thirty seconds. Yes, Saturday at 2pm is available when it is not costs you a complaint, a refund conversation, and a review.

The exception is genuinely static information. Standard opening hours, closed days, seasonal schedules set months ahead - those are fine as knowledge base entries.

What connecting a calendar actually requires

Less than people expect, but it does need decisions rather than just access.

An account the assistant can be granted access to. Usually a calendar account created for the purpose rather than a personal one, so access survives staff changes.

A decision about structure. This is the real question, and it is worth thinking through before anyone connects anything: one calendar per activity area, or one calendar for the whole site with everything on it?

Both work. They suit different operations:

• Separate calendars per area are better when areas have independent capacity - when a guest could book the climbing wall while the party room is full. The assistant can then answer precisely about each activity rather than giving a blurred site-wide answer.
• A single shared calendar is simpler to administer and easier for a small team to keep honest, but it relies on discipline about how entries are made, and it makes per-activity answers harder.

There is no universally correct choice. There is only a choice that matches how you actually take bookings, and it is much cheaper to make before go-live than to restructure afterwards.

Say what you want to happen, in plain words

The most useful thing an operator can do at this stage is write down, in ordinary language, what should happen. Not configuration - a description.

Something like:

A guest asks about a birthday party on a Saturday. The assistant checks the party room calendar for that date. If there is a free slot it offers the times. If the day is full it says so and offers the two nearest dates that are free. If the guest asks about group sizes above twenty, it does not quote availability at all - it takes their details and tells them someone will call.

That paragraph is worth more than an hour of settings discussion. It contains the branches, and the branches are what matter.

Very often a good part of it is already configured, because availability logic tends to be built generically and then pointed at specific cases. Writing the description reveals both what already works and what genuinely needs building.

Simulate before you go live

Availability logic is the one area where testing with real dates against the real calendar is non-negotiable. Not a demo. The actual connected calendar, on dates that include a full day, a partly-full day and an edge case like a day the venue is closed.

What you are checking is not whether the assistant can read a calendar. It is what it says on the awkward cases - the full day, the half-hour that is technically free but useless, the request that falls outside what you offer. Those responses are what guests will remember, and they are the ones nobody thinks to specify.

The pattern underneath

Automate the answer that changes constantly by connecting it to the system that already knows. Keep in the knowledge base the answers that genuinely do not change. And be explicit, in advance, about what happens when the answer is no - because that branch is the one guests test hardest, and the one operators most often leave undefined.