Booking Flows

ChatIQ booking flows are guided, multi-step conversations that can run in chat, in webview/form mode, or both.

Core Model

• One booking flow definition (steps + prompts + validation)
• Two interaction modes:
  • Chat-native answers
  • Structured webview inputs (pickers/selectors/forms)

Users can switch between these modes during the same booking session.

Chat-First, Webview-Optional

A booking can be completed fully in chat, with no webview required.

Example:

1. User asks to book
2. Bot asks each step question
3. User replies in natural language
4. Bot validates and advances
5. Bot confirms booking

Webview is optional and mainly improves UX for structured steps (date, room/service selection, etc.).

Webview Behavior

When webview is used:

• users can complete the full booking in one webview session, or
• leave and return later, resuming from saved state.

After a webview step is submitted, ChatIQ should send a resume-style message in chat:

• acknowledge what was saved
• immediately prompt the next step

Booking Guidance Improvements

Booking flows support guided behavior, including:

• clarification handling (user asks step-related questions)
• off-topic recovery prompts
• exit confirmation (avoid accidental cancellation)
• resume/re-entry options when returning to an unfinished booking
• existing-bookings pre-check (manage existing vs start new)

Channel Notes

Channel UX differs by platform.

• Web widget: smoothest experience because ChatIQ controls the full surface.
• LINE: strong fit for in-app webview flows; when a step routes to handoff, ChatIQ sends a Continue Booking quick reply.
• Other social channels: may rely more on link-out behavior; fallback UX should always support save/resume.

When a booking is completed in web handoff, ChatIQ also attempts to mirror the completion confirmation back to the channel conversation history (for example, LINE) so users see a completion result when they return.

Routing Baseline (v1)

ChatIQ uses deterministic routing rules for booking turns:

• info_read (low risk + channel-level assurance): stay in channel.
• structured_capture (date/gallery/selectors): route to booking handoff surface.
• mutation (edit/cancel): route to booking handoff surface.
• payment: route to booking handoff surface unless a channel has trusted secure payment UX.
• If required assurance is higher than current channel assurance, ChatIQ routes to handoff and performs step-up there.

Per-Step Channel Handoff Mode

Each booking workflow step includes a Channel handoff setting:

• Auto (structured steps): default behavior. Non-web channels are handed off when that step needs structured web capture.
• Force (always handoff): always send handoff for that step in non-web channels, even when the step could be answered in plain text.
• Off (never handoff): keep that step in-channel and do not add booking handoff CTA/link for the step.

You can also set a workflow-level handoff instruction message in booking setup. This controls the text shown before the handoff CTA/link when handoff is triggered.

You can set the workflow-level handoff label as well. This controls the quick-reply/link button text (default: Continue Booking).

Existing Bookings Gate

When a user starts a booking and ChatIQ finds active upcoming bookings, ChatIQ first asks whether they want to:

• Manage Bookings
• New Booking

If they choose manage, they can select a booking by:

• list number (1, 2, ...)
• short client code (DDMMYYNN)
• full booking reference number

This reduces accidental duplicate booking requests and supports faster edits.

Cancellation Confirmation

Booking setup includes configurable cancel-confirmation text shown before canceling an in-progress booking (exit_confirm_message).

The yes/no reply behavior uses your configured workflow keyword lists:

• Resume yes keywords = confirm cancellation
• Resume no keywords = continue booking

Validation Setup (Steps)

Step validation now follows a validator-first model:

• built-in validators: None, Phone, Email, Number, Date
• advanced regex (optional) for custom constraints

When you change step type, ChatIQ auto-selects the matching default validator unless you already manually set a validator for that step.

Availability-Aware Time Choices (Baseline)

If your workflow config includes per-item availability profiles (bookable_items), ChatIQ can generate deterministic time choices from:

• availability_mode
• slot_interval_minutes
• default_duration_minutes
• timezone
• resource_policy
• calendar_binding

When slot data is available for the selected item/date, the time step shows only available times and validates user input against that generated list.

The time step also includes a deterministic Change Date control so users can return to date selection and refresh available times.

At final confirm/submit, ChatIQ revalidates the selected slot. If the slot was taken in the meantime, ChatIQ returns a deterministic conflict response and prompts the user to pick another available time (or choose Change Date).

In team language, this is often described as:

• Manual handoff = Force
• Block handoff = Off

Important:

• This setting controls step-level routing UX.
• It does not override payment confirmation rules (webhook-authoritative) or protected-action verification requirements.

Payment Return Behavior

When payment is required, ChatIQ keeps booking confirmation webhook-driven:

• chat/web handoff surfaces can show a checkout CTA
• after checkout return, chat shows a pending state (pending_confirmation)
• booking is only marked confirmed after trusted payment webhook success
• redirect-only signals never confirm a booking

Protected Booking Reads

For sensitive booking reads/actions, ChatIQ may require step-up verification before returning protected details.

• if step-up is required, chat returns deterministic verification guidance
• after successful verification, user can repeat the protected request

Security and Identity

For simple booking creation, channel identity can be enough.

For protected booking info/actions (for example, room number, modifications, payment-sensitive actions), organizations should require stronger verification based on their policy (for example: booking reference + personal verifier, plus OTP when needed).

Related Docs

• Integrations
• Website Integration
• API