--- title: "Appointments: states that avoid double promises | Atiende" description: "The difference between browsing, holding, confirming and canceling availability. Atiende guide to AI agents in fitness and wellness, with human review." url: https://useatiende.ai/en/blog/citas-reservaciones-estados lang: en alternates: es: https://useatiende.ai/es/blog/citas-reservaciones-estados en: https://useatiende.ai/en/blog/citas-reservaciones-estados updated: 2026-09-30 --- # Appointments and reservations: states that prevent double promises *Published: 2026-09-16 · Updated: 2026-09-30 · 2 min* The difference between browsing, holding, confirming and canceling availability. ## A conversation is not the calendar A chat user may accept a time while another channel books it. Acceptance messages are not authoritative availability. The scheduling system confirms results. Separate displayed options, user choice and registered booking so conflicts produce explanations and alternatives instead of duplicate promises. The interface can remain simple while the process keeps these distinctions explicit. Tell the person when a selection is being checked and when it has actually been registered. If availability changes during that check, explain the conflict and present current alternatives rather than silently substituting another time or leaving the customer with an uncertain result. ## States with concrete meaning A minimal catalog may include requested, awaiting condition, confirmed, rescheduling and canceled. Define transitions and owners. Temporary holds need actual supported duration and expiry behavior; do not invent them. Messages must distinguish receipt from a successfully booked service. ## Reschedule without losing the booking Operation order matters. Canceling first can leave no booking if replacement fails. Recovery depends on system capabilities. Preserve the original reference, verify modification results and communicate the valid appointment. Review uncertain states before retrying actions that could duplicate bookings. Keep change and requester history. The recovery policy should account for notifications separately from scheduling changes. A booking may be valid even if its confirmation message failed to send. Repeating the booking action to recover a message can create duplicates. Instead, inspect the recorded result and decide whether to retry communication or request operational review. ## Consistent reminders Reminders must use current booking versions and contact preferences. Scheduled messages can become wrong after cancellation. Check status shortly before sending, include clear confirmation or change instructions, and record notification success or failure without equating sending with reading or attendance. Changes to location, service or participants may also affect a reminder even when the appointment time remains unchanged. Use the current booking reference to retrieve those details and include an accessible way to request help. During testing, follow both the calendar record and the outgoing message so the team can distinguish a scheduling defect from a communication defect. ## Essential tests Test simultaneous requests, cancellation near a reminder, interrupted rescheduling and late acceptance of an expired option. These reveal more than a single uninterrupted booking demonstration. ## Illustrative example: two people ask for the same slot As a hypothetical case, two people write almost at the same moment about a five o’clock slot. The agent checks the calendar and both receive the option. The first replies “yes, that one”; the agent requests the hold from the scheduling system and receives the confirmation. When the second person answers seconds later, the agent checks again before replying and finds it is gone. Instead of confirming out of inertia, it offers two real nearby times. The lesson is the order: offering is querying, accepting is requesting, and confirming is what the responsible system returns. A message saying “your appointment is set” without that third step is a promise that can break. Record each transition on the case so you can later explain what each person saw and when. ## Channel design: messaging, voice and web On WhatsApp, offer two or three slots in a short message and wait for a simple reply; avoid long availability tables. Confirm with date, time, place and how to change the booking. If the person sends a document or a photo, such as a prescription or a reference, acknowledge it and link it to the booking. Proactive reminders depend on the provider’s rules about approved templates and reply windows; check current conditions before promising them. On voice, dictated dates are easy to confuse: repeat day, time and name before confirming and offer to send the summary in writing. On the web, a form can show availability in real time, but the conflict notice must be as clear as in chat. In all three channels the source of truth is the same calendar, and the message only reflects its state. ## Common mistakes and how to spot them in the calendar These symptoms show up first in operational data, before the customer complains. - Duplicated or overlapping appointments: usually means a booking was confirmed from the chat without checking the responsible system. - People arriving for an appointment already cancelled: check that reminders consult the current state before sending. - Reschedules that leave the user with no appointment: the cancellation happened before the new slot was secured. - States nobody can explain, such as pending with no expiry: define who resolves them and when they lapse. ## Key takeaways - Confirmation must come from the responsible system. - Plan recovery for incomplete changes. - Offering, requesting and confirming are three separate steps; only the last comes from the system. - Each channel communicates the same calendar at a different pace. --- Book a demo: https://useatiende.ai/en/demo Contact: ventas@useatiende.ai · https://useatiende.ai/en/contacto Sitemap: https://useatiende.ai/sitemap.xml · llms.txt: https://useatiende.ai/llms.txt