Should your service use instant booking or requests?

Decide what the visitor can commit to

The key difference is the promise made at submission. An instant-booking flow reserves an available slot and creates a confirmed commitment under stated rules. A request flow records a preferred time or service for review; the appointment exists only after acceptance. A qualified-inquiry flow starts earlier, when the business still needs to learn whether the service, location or timing is suitable.

Use instant booking when the service has predictable duration, visible capacity, known eligibility and no hidden preparation dependency. Use a request when travel, equipment, staffing or case details must be checked. Use an inquiry when the next useful step is a conversation rather than a time selection. Label the action precisely: “Book appointment,” “Request this time,” or “Ask about availability.”

Use this booking-or-request decision tree

Answer each prompt for one service, not for the whole business. Different services may need different entry paths. If a rule changes frequently or depends on judgment, do not hide that uncertainty behind an apparently live calendar. A short request flow can feel faster than letting someone book and then cancelling because an unstated condition was not met.

• Can eligibility be determined from clear, appropriate questions before showing times? If no, begin with an inquiry or reviewed request.
• Are duration, buffers, staff, location and required resources represented accurately? If no, request preferred times for review.
• Can the calendar prevent two confirmed commitments to the same constrained resource? If no, do not promise instant confirmation.
• Can the visitor see the time zone, preparation, price basis if relevant, and change policy before committing? If no, fix the information first.
• Can cancellations and rescheduling update every affected calendar and notification reliably? If no, provide an owner-managed path.
• If all answers are yes, instant booking may fit; otherwise use the earliest honest commitment the workflow can keep.

Map states instead of relying on email threads

Define a small state model such as draft, submitted, awaiting review, offered, confirmed, cancelled, completed and declined. Record which role can cause each transition and which event proves it happened. A submitted request is not a booking. An offered time is not confirmed until the required party accepts it. Messages should describe the stored state rather than create a second, contradictory version of it.

Calendar systems carry structured scheduling data. RFC 5545 defines concepts used in calendaring such as event start and end, status, recurrence and time-zone components. Google Calendar’s event documentation also distinguishes event data such as start, end, attendees and status. Your implementation may use another provider, but it still needs an explicit source of truth and current official documentation for its event behavior.

Plan time zones, changes and owner intervention

Show the time zone beside every proposed or confirmed time and store an unambiguous instant plus the relevant zone. Test daylight-saving changes when the business or visitor may cross regions. Apply buffers, opening hours and lead times before presenting availability. If a service needs travel, model the location and resource constraint rather than assuming an open staff calendar equals a feasible appointment.

State who handles an unavailable resource, a customer request that does not fit the rules, a provider outage and a conflicting manual calendar edit. Give that owner a queue with enough context to decide. Cancellation and rescheduling must update the appointment state before sending confirmation. Prevent a repeated click or retry from creating a second reservation, and make uncertain outcomes visible for review.

Hypothetical example: a site survey request

Consider a hypothetical commercial lighting specialist offering site surveys. Survey duration depends on floor area and access restrictions, and an engineer may need travel time. The website therefore asks for location, approximate size and two preferred windows. Submission creates a request, not a calendar event visible as confirmed to the customer.

A coordinator reviews eligibility, selects an engineer and offers one window in the customer’s displayed time zone. The customer accepts through a time-limited link; only then does the workflow mark the request confirmed and create the calendar event. A cancellation returns the case to an owner queue because the next available slot may require new travel planning. This is a hypothetical workflow example, not a Kinetivy client result.

Complete the state-map worksheet and test it

Create one row per state with: entry event, required data, customer wording, permitted actor, automated action, exit condition, timeout and manual owner. Then add separate rows for cancellation, rescheduling, no response, provider failure and duplicate submission. For a multi-step flow, W3C recommends telling people what is needed, showing progress and letting them review information where appropriate.

Test the workflow with a controlled calendar and labelled contacts. Try an eligible instant booking, an ineligible request, two people choosing the last slot, a daylight-saving boundary, cancellation from each side, rescheduling, a notification failure and a repeated submission. Inspect the stored state and calendar, not only the email. Launch only when every confirmation means what it says and an owner can recover exceptions without editing hidden automation data.