AI Booking Assistants: An Empty Calendar Slot Is Only the First Check

A photography studio has an empty hour from 2 pm to 3 pm. An AI booking assistant offers it for a portrait session. The photographer really is free. But the studio needs fifteen minutes to reset the lighting after the previous client, and the only room suitable for portraits is booked by another team until 2.30. The calendar search was right about one person. The promise to the customer was wrong.

Before putting an AI assistant in charge of booking, write down what makes a time usable for each service. A calendar can tell you where it sees an occupied interval. It cannot decide on your behalf whether a particular job fits the room, equipment, preparation time and people available. Those conditions belong in a rule the business can inspect and test.

Know what the calendar actually said

The Google Calendar Freebusy reference is a useful example of what a calendar lookup returns. For each requested calendar, it can return intervals marked busy and can report errors. A busy interval includes its start and excludes its end. So an event ending at 2 pm does not, by itself, block a new event starting exactly then. That leaves the question of whether your business needs a gap between them.

A visible event does not necessarily block time either. The iCalendar specification’s time transparency property lets an event be marked so that it does not count as busy. A reminder to send a client a contact sheet and a commitment to take their portrait can both appear on a calendar, yet only one may reserve the period. Check how your team records holds, travel and other obligations before relying on what a lookup returns.

Distinguish an empty busy list for a calendar that was checked from a missing or errored result. If the room calendar could not be read, you do not know whether the room is free. In that case the assistant can offer to check with a person, or show the time as provisional. It should reserve a confirmed response for a time that has passed the required checks.

Write the rules around the work

Start with a service you actually sell. Suppose the portrait session takes forty-five minutes, the lighting setup takes fifteen, and the room needs ten minutes to reset afterwards. The customer sees a forty-five-minute appointment. The room may need seventy minutes, depending on whether setup and reset happen in that room. Identify whose time each stage uses. If an assistant can set the room up while the photographer finishes elsewhere, only the assistant and room need to be free for setup.

Set a rule for each resource that can stop the service. A portrait session might require one qualified photographer, one suitable room and one lighting kit. The rule might accept either of two rooms but insist that the selected room and kit are both free for the right intervals. An equipment calendar can make sense for a shared kit. A team using a paper log instead might need a human check until that information is available to the booking system.

Put the business constraints beside the resource rules. Consider opening hours, how much notice you need and whether a service can start at any minute or only at agreed times. Make the time zone explicit when the customer and business are in different places. Then decide how the assistant should explain a rejection. “That time is unavailable for a portrait session; the next option is 3.15” may be enough. The customer does not need to see a colleague’s appointment details.

Separate offering a time from securing it

A slot can pass the checks when offered and become unavailable before the customer accepts. Define when the assistant should check again and what counts as a commitment. If simultaneous requests matter, ask whoever builds or supplies the booking system how it prevents two confirmations for the same scarce resource. Rechecking immediately before a separate save still leaves room for another booking to intervene. An enforced reservation or conflict check at the point of commitment is stronger.

Tell the customer whether the time is suggested, temporarily held or confirmed. If you use a hold, define when it expires and what happens when someone accepts late. Once the reservation is secured, the confirmation still has to reach the customer. Our guide to saving a booking handoff alongside the commitment covers that separate step.

Test the awkward gaps first

Give the assistant a small set of fictional bookings and decide the expected outcome for each before running the test. Choose examples in which a quick glance at the diary gives the wrong answer. A colleague who takes bookings can often identify the cases that a software demonstration misses.

• Back-to-back events: A session fits between two events only when you omit the room reset. Expect an alternative.
• Missing resource: The photographer is free but the room lookup errors. Expect a provisional reply or a handoff for checking.
• Alternative resource: The preferred room is busy and an equivalent room is available. Confirm only if it satisfies the service rules.
• Simultaneous requests: Two customers accept the last valid slot. Expect at most one confirmation and a clear next option for the other customer.

Use the result to decide which promises the assistant can make on its own. A simpler service might be ready for automatic confirmation. A job that needs an untracked resource can stay provisional. The useful boundary is where the assistant has enough evidence to make a promise the team can keep.

Sources

• Google for Developers, Calendar API: Freebusy query, updated 12 May 2026.
• RFC Editor, iCalendar specification, time transparency, RFC 5545, September 2009.