When an appointment search completes without a match, the booking tool should return a clear no-availability result, the criteria it actually searched, an empty exact-match list and a next step the user can choose. Keep alternatives separate from exact matches. A failed lookup means availability is unknown, not that the calendar is full.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. Its organic-growth marketing team has years of experience and undertakes pioneering AEO/GEO technology work for artificial intelligence (AI) assistants. For booking recovery, its relevant capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting. WebMCP is an interface for exposing web application functions as tools to agents. The practical work is to define the result states, test the calendar conditions and check that an assistant can offer a choice without changing the appointment request silently.
Preserve the criteria before explaining the empty result
A bare empty list leaves important questions unanswered. Was the search completed? Which service, location, provider, duration and time window did it cover? Is the absence of results a known business outcome or a technical failure? Return the interpreted criteria alongside the result so the caller does not have to reconstruct them from a conversation.
Illustrative fictional case: a workshop customer wants a 30-minute repair introduction with provider P1 at the north workshop on 20 October 2026, starting no earlier than 09:00 and finishing by 10:00 Coordinated Universal Time (UTC). The prepared calendar has two eligible starts in that window, 09:00 and 09:30, both occupied. There is a free P1 appointment at 10:00 that day and another at 09:00 the next day. A free 10:00 appointment with P2 must not become a P1 result.
The distinction changes the next action. The customer may accept a later appointment, but has not agreed to a different provider. An alternative search can widen the time window while retaining service, location, provider and duration. If no wider window was authorized, the tool should ask whether to change the search rather than choosing the change itself.
A no-availability response contract
The following application-level contract was exercised in the fictional calendar demonstration. These field names describe this example, not a booking-platform standard. The lookup is read-only: returning an option does not reserve it.
- status: available, no_availability, lookup_failed or invalid_request. Use no_availability only after a completed search finds no exact matches.
- request: the unchanged interpreted service, location, provider, duration, window start, window end and time zone. In the example, the original window remains 20 October, 09:00 to 10:00 UTC even when later options are returned.
- search_complete: true for a completed lookup; false for a failed lookup or rejected input. Define which calendars and booking rules must be checked before setting it to true.
- snapshot_at: the time of the data snapshot used for the answer. The fictional fixture uses 17 October 2026 at 00:00 UTC. This timestamp describes data age, not a promise that a slot remains available.
- slots: exact-match slot identifiers. Return an empty list for a known empty search and null when a failed lookup leaves availability unknown.
- alternatives: a separate list of slot identifiers and changed_fields. The demonstration marks window_start and window_end as changed, while keeping the original request intact.
- next_action: choose_slot, choose_alternative, ask_to_change_search, retry_lookup or correct_request. The action must agree with the result state.
- reservation_created: false throughout this lookup contract. Booking requires a separate operation; a suggested time is not a confirmed appointment.
The distinction between data and failure is not merely a wording preference. Google’s Calendar Freebusy query reference documents busy intervals separately from per-calendar errors. Its busy ranges are not themselves a complete appointment-slot service. The application still needs its own service duration, provider and booking rules. An error from a required calendar therefore cannot justify a confident empty appointment result. The reference is available at https://developers.google.com/workspace/calendar/api/v3/reference/freebusy/query.
In a real response, provide displayable start and end times with the slot identifier, plus the relevant time zone and the changes from the request. The local demonstration resolves its identifiers against a fixed inventory. That shortcut is sufficient for its comparisons, but an assistant should not need to invent a time from an opaque identifier.
What the fictional calendar returned
A deterministic local demonstration on 17 October 2026 used Python 3.12.14 and a prepared five-slot inventory. Inputs and literal expected outcomes were declared before implementation. A separate evaluator compared the complete returned objects with that literal oracle, including the unchanged request. This was a UTC-only, discrete-slot test, not a live calendar, native browser or assistant session.
With no alternative window authorized, the occupied 09:00 to 10:00 window returned status no_availability, search_complete true, slots as an empty list, alternatives as an empty list and next_action ask_to_change_search. Nothing was reserved. The result describes the searched window, not every future date or every provider.
When the input authorized an alternative window from 20 October at 10:00 through 21 October at 09:30 UTC, the original result stayed no_availability. The separate alternatives list contained s3, the 10:00 appointment on 20 October, and s4, the 09:00 appointment on 21 October. Each entry identified the changed window fields. The P2 appointment was excluded. The next action became choose_alternative, not book_appointment.
Four further cases checked the boundaries. An alternative window containing only the occupied original times returned no alternatives. Making the original 09:30 slot free produced available with s2 as the exact match. An incomplete lookup produced lookup_failed, null slots and retry_lookup. Reversing the requested time window produced invalid_request and correct_request. All six outputs matched the predeclared expectations, and replay produced identical output.
Two negative controls checked whether the evaluator would notice a consequential defect. It rejected a changed output that described the failed lookup as confirmed no availability. It also rejected an output that marked a reservation as created after merely returning alternatives. Those checks establish the distinctions within this demonstration; they do not establish production reliability, daylight-saving behavior or safe handling of simultaneous bookings.
Offer the alternative, then let the user choose
The customer-facing summary should preserve the same distinction: no P1 repair-introduction appointment fits 09:00 to 10:00 UTC on 20 October; the later options are 10:00 that day or 09:00 the next day; neither has been reserved. If the customer declines both, ask which constraint may change. Do not infer permission to shorten the service, switch workshops or substitute P2.
Before a production booking operation commits a selected alternative, recheck that the slot remains eligible and available. A snapshot can become stale between lookup and selection. If the slot has gone, return to the choice step with the new facts instead of reporting a booking that did not happen. That recheck is a production requirement proposed here, not behavior tested by the fixed-inventory demonstration.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in WebMCP Made Simple Complete Edition, Chapter 09, The Eight-Step Tracking Framework: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.” They also co-authored The Discovery Reset.
For this case, the quotation’s practical consequence is to measure recovery separately from booking. Record whether the lookup completed, whether it found an exact match, whether alternatives were offered and whether a later booking operation actually succeeded. A known empty search is not a technical error, and an offered alternative is not a conversion. Keeping those outcomes distinct makes it possible to investigate where the task stopped without counting suggestions as appointments.
ScaleGrowth Digital publishes this article and provides the related implementation services. Its AI Native capability covers prompt discovery and answer measurement across multiple large language models (LLMs). That capability is relevant to a subsequent check of how assistants explain these result states, separate from the local contract test. No AI Native measurement or automatic integration was exercised here. The useful handoff is a response contract whose empty, alternative and failure states can be reproduced, followed by a user-choice test before any booking action is enabled. Related implementation scope: https://scalegrowth.digital/services/webmcp/.
References
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Google Calendar Freebusy: query
https://developers.google.com/workspace/calendar/api/v3/reference/freebusy/query
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/