Build a supervised appointment assistant

Who would use this?

A service team with a shared calendar and appointment enquiries.

Scheduling replies take time, and a slot can disappear between the first lookup and confirmation.

A concrete pilot offer

An appointment-drafting assistant that suggests valid slots, checks again at confirmation and prevents duplicate bookings.

Build the workflow

1. Parse the requested service, duration and explicit time zone.
2. Fetch allowed availability from the calendar without exposing other customers.
3. Offer a small set of slots and wait for the customer’s choice.
4. Recheck the chosen slot, use a stable booking key and confirm only after a successful write.

Walk through the example

The full prompt

Replace the bracketed inputs. Use synthetic or appropriately permitted data. The prompt drafts a result; the surrounding application must enforce permissions, checks and approvals.

Draft scheduling messages using the supplied SERVICE RULES and AVAILABLE SLOTS only. Preserve the explicit time zone. Do not invent availability, expose other customers or claim a booking is confirmed. If the user has not chosen a valid slot, ask one clarifying question. Confirmation belongs to the application after the calendar write succeeds.

REQUEST: [redacted enquiry]
SERVICE RULES: [duration, hours and zone]
AVAILABLE SLOTS: [approved timestamps]
OUTPUT: proposed_slots, time_zone, reply_draft, missing_information

Test before delivery

• The time zone is explicit in every offer.
• A lost write response does not create a second booking.
• A newly occupied slot returns alternatives.

Measure: Scheduling exchanges and duplicate-booking rate.

Is the workflow worth a pilot?

Replace these sample assumptions with the buyer’s figures. Time capacity is not automatically cash savings or revenue.

Delivery effort, setup fees, error costs and demand are not included. Validate the assumptions during the pilot before using them in a proposal.

Scope the service before quoting

Agree the input volume, exact output, integration access, human reviewer, acceptance tests and handover owner. Quote implementation effort separately from ongoing software, API usage and support. Validate customer demand through real conversations.

These examples demonstrate a possible service. They do not report client results or establish an income expectation.

Keep the guide

Go deeper into the engineering

The linked note includes additional examples and primary documentation. Provider capabilities change; check the relevant docs before implementation.