AI promised an appointment. Was a booking actually made?

A customer tells the chat they would like to visit on Tuesday at ten. The assistant replies that it looks forward to seeing them. Reception knows nothing about the visit. This is a fictional example, not an account of a particular Informio customer. It exposes a problem to solve before connecting AI to a calendar: what exactly must happen before we can say an appointment is confirmed?

For a repair appointment, a consultation or a visit to a municipal office, that sentence has practical consequences. Someone plans a journey and sets aside time. The assistant's reply must therefore reflect the actual status in the system staff use to manage bookings.

Opening hours are not an available appointment

A knowledge base may contain working hours, service duration and booking instructions. These details do not establish that a particular employee or room is available. Even checking a calendar does not reserve the slot.

Google Calendar exposes this distinction in its API: Freebusy: query returns availability information. A separate operation, Events: insert, creates an event.

This is a technical example, not a recommendation of a particular supplier. A created event may still fail to satisfy your booking rules: staff approval, equipment or a required deposit might be missing. Choose the status that actually governs your day-to-day operations as the deciding factor.

Describe the status without ambiguity

Before designing an integration, agree on the language of its replies. The following examples must be adapted to the real process:

• Suggestion: “You can request Tuesday at 10:00. Availability has not been checked yet.”
• Awaiting approval: “Your request has been recorded and is awaiting staff confirmation.” Use this only after verifying that the record exists.
• Confirmation: “Your booking is confirmed.” Include the exact date, time, location, service and verified booking reference, if the system uses one.
• Uncertain outcome: “We could not verify the booking confirmation. A staff member will check its status.” Do not label the booking successful or cancelled.

Avoid “done” or “we'll see you then” on their own. Customers cannot tell whether they have merely expressed interest or actually secured a slot.

What the integration must do before confirming

1. Clarify the service, location and exact date. Include the time zone for a remote meeting.
2. Check capacity against operational rules, including service duration, the required staff member and the gap between appointments.
3. Show a summary before making a binding booking and obtain the customer's agreement to the details and time.
4. Write the request to the correct system and check the result, including the booking status.
5. Only then send the appropriate confirmation with instructions for changing or cancelling the appointment.

Checking availability and saving a booking happen at different moments. Someone else may take the slot in between. The integration must handle a rejected booking and offer a next step; asking the language model the same question again will not resolve the conflict.

Do not retry a booking blindly after a failure

After sending a write request, the connection may fail before the reply arrives. The booking may already exist. Sending the same write again could create a duplicate.

Google's event creation guide describes custom event IDs as a way to prevent duplicates after a successful write followed by a failure.

The specific mechanism depends on the booking system. Ask the supplier how repeated attempts are recognised and how the original result can be retrieved. Until the outcome is clear, keep an “under review” status and assign a staff member to resolve it. Also distinguish a successful booking from delivery of the confirmation email.

Test more than one successful conversation

During a trial, compare the chat reply with the record visible to reception. Use test data for these scenarios:

• Two customers choose the same last available slot.
• The booking is saved, but the system reply is delayed or lost.
• The customer sends the same request again or refreshes the page.
• They change the date, location or time zone before giving final agreement.
• The booking is awaiting approval or the notification cannot be delivered.

A test passes when the status is explained truthfully, no unwanted duplicate is created and staff can find an unresolved case. A friendly tone alone is not an acceptance criterion.

Where to start with Informio

Informio chat can answer from approved information, direct visitors to a booking page and let an operator take over the conversation. Do not assume that automatically writing to your booking system is a ready-made part of the standard chat. It requires a separately agreed integration, permissions and end-to-end verification.

Start with one service and define exactly who or what can give binding confirmation. To review this process for your business or municipality, arrange an Informio consultation about bookings and AI. Bring an example of your current confirmation and your booking rules; these provide a basis for deciding how much to automate.