Offer real times without pretending an external calendar changed. In manual mode the customer makes a request; in automatic mode Tephlo confirms only a slot the database can commit without overlap.
Authorized team members configure the calendar in Business → Appointments → Booking setup. Scheduling is disabled until the workspace has deliberately supplied the parts below and enabled it. Enabling the feature or switching to automatic confirmation requires a currently MFA-authenticated session with configuration access; disabling it remains available to authorized members during an incident.
Start with the guided setup to define what customers can book, who or what provides it, booking hours and booking rules. Review the preview before applying. Existing entries are matched when you continue setup, and the readiness checklist shows what remains before bookings can be offered.
Booking hours and the business hours used for customer handoff are separate. Use the booking-hours sync preview and apply the proposed change when you want them aligned. Maintain time off for holidays, closures and other unavailable periods.
Availability is derived from active services, assigned resources, local weekly rules, notice and advance policy, time-off blocks, service buffers and confirmed appointments. Daylight-saving gaps and ambiguous local wall times are omitted rather than guessed.
The customer sees a bounded set of offered times. Each offer carries a short-lived opaque, encrypted token bound to the tenant, subject, service, resource, start, end and timezone. The token is not readable business data and is never accepted as proof on its own: the service re-reads current state at confirmation.
REQUESTED appointment. The reply says the request was recorded and does not call the time booked. An authorized team member reviews and confirms or declines it.CONFIRMED appointment. The reply calls it booked only after that write commits successfully.The model cannot choose the mode, invent a time or turn a request into a confirmation. Booking mode is re-read from workspace configuration at the write boundary.
When a team member confirms, declines, cancels or reschedules an appointment from the console, the customer is told automatically on their channel, in their language, with the time in the workspace’s own time zone, as soon as the messaging window allows. Each appointment shows whether the customer has been told. Booking requests that the assistant could not turn into a calendar entry — appointments, viewings, test drives and other visits — are listed on the Appointments page as well, not under Customer requests. If the customer changes their mind before anyone picks the request up — a different day, a different service, a corrected name — the existing request is updated rather than a second one added, so the list holds one row per thing asked for. If they cancel, the request is closed and leaves the list, and the customer is told it is cancelled. Once a team member is assigned to a request, neither happens: a later change or cancellation arrives as a new request instead, the customer is told a person will confirm rather than that it is cancelled, and the person working it reads the change rather than having the row rewritten or closed underneath them. Complaints and refund requests are never changed or closed this way, because each is a case somebody may already be working.
On each of those requests, Book a time lists the open times for a service. Choose the one the customer asked for and select Book & confirm: the appointment is created on the customer’s own conversation, confirmed, the customer is told, and the request is marked done, all in one step. Book, confirm later holds the time without telling the customer yet. Booking from a request needs bookings turned on and uses only times the calendar offers. If two team members book the same request at once, only the first booking is kept. A request filed under Customer requests can be moved to Appointments with Move to Appointments.
REQUESTED → CONFIRMED / DECLINED / CANCELLED
CONFIRMED → COMPLETED / NO_SHOW / CANCELLED / RESCHEDULEDEvery transition is version-checked. Rescheduling is not a loose status edit: the old confirmed record is retired and its replacement is committed in the same transaction. The console distinguishes a request from a confirmation and shows the source, time, workspace timezone and committed state.
Application checks make the common path clear, but PostgreSQL is the final authority. A database exclusion constraint rejects overlapping confirmed occupancy for one resource, including the service’s before-and-after buffers. This still holds when two workers try to confirm the same last slot concurrently.
When the active workspace profile and current setup permit them, the assistant can search exact service availability, record or confirm a selected offered slot, find the current customer’s appointment, and cancel or reschedule an appointment the same customer owns. It cannot use a customer-supplied database id to cross that ownership boundary.
Every assistant read or write re-checks the exact scheduling tool against the immutable workspace policy at execution time. Missing provenance, a revoked capability, lost data readiness, a suspended tenant or a cross-tenant identity refuses before the calendar is touched. Console operations require the relevant appointment access, current tenant scope and version checks; sensitive enablement also requires MFA.
Appointment rows store a canonical customer digest rather than a raw phone number or email. They participate in privacy export and erasure. Lifecycle events are append-only and content-free: closed action, reason, version and time codes, not message text. The appointment and all configuration rows are tenant-scoped at the database and service boundaries.
External calendar and payment adapters are future work. If added, they must be server-owned tools with explicit workspace authorization and delivery evidence; a link or instruction in Knowledge cannot claim an external calendar was updated today.