Booking HandbookWhen a booking automation goes wrong.
First checks
- Declare the occurrence
Record the booking, version, event type, source, actor, occurrence time, and policy result that allows work to begin.
- Map the minimum destination
Choose the exact customer, staff queue, CRM record, accounting object, marketing workflow, API endpoint, or export target and send only necessary fields.
- Freeze the action contract
Version the template or payload, schedule, time zone, channel, provider, credentials boundary, stop rule, and logical operation identity.
Can this booking-triggered action run once and still be repaired?
Describe one action from booking event to destination, attempt, event callback, recovery, audit, and data exit. The checker exposes stale work, wrong destinations, unsafe retries, silent failures, and incomplete records.
Repair the trigger and action map
The automation cannot safely start from the current booking. Repair the trigger, destination, template, and schedule map before rehearsing an action.
Keep the current booking state and the occurrence that triggered work as separate, versioned facts.
Map the intended person, team, system, or file destination without exposing more booking data than the action needs.
Preserve the template revision, rendered snapshot, time zone, due time, stop rule, and later booking changes.
Give one logical action a stable job identity and keep every provider or worker attempt under it.
Authenticate and deduplicate events, retrieve authoritative state, and never turn an uncertain retry into a second logical action.
Name the recovery owner, preserve failed work, and reconcile the booking, destination, action, export, and audit records.
Keep stable identifiers, field meaning, attempts, outcomes, and limitations available for inspection, backup, and migration.
Understand the recovery rule
Start from one event
Name the exact booking occurrence and version that allows the action.
Create one logical job
Retries and callbacks update one action instead of creating duplicates.
Fail visibly
Unknown or exhausted work enters an owned recovery queue with its evidence.
Keep an exit path
Stable IDs, attempts, outcomes, and field meaning survive export and restore.
Completed is meaningless unless the trigger, destination, and final state agree.
A reminder can go to the wrong address, a background worker can fail silently, a webhook can arrive twice, or a CRM update can succeed after the booking was cancelled. The workflow must preserve the difference between accepted, delivered, completed, failed, unknown, suppressed, and reconciled.
The recovery rule: Recoverable automation = current booking event + mapped destination + versioned job + bounded attempts + visible recovery + reconciled data
BOOKING-A moves from 10:00 to 11:00 after JOB-A was queued. The old job must be suppressed, any provider attempt preserved, a new versioned job created only if policy allows, and the booking, message, audit, and export views reconciled.
Follow the complete event-to-recovery sequence
The booking remains authoritative. Events, jobs, provider attempts, destinations, responses, exports, and backups are linked records with separate owners and outcomes.
- Declare the occurrence
Record the booking, version, event type, source, actor, occurrence time, and policy result that allows work to begin.
- Map the minimum destination
Choose the exact customer, staff queue, CRM record, accounting object, marketing workflow, API endpoint, or export target and send only necessary fields.
- Freeze the action contract
Version the template or payload, schedule, time zone, channel, provider, credentials boundary, stop rule, and logical operation identity.
- Execute and observe
Keep queued, accepted, sent, delivered, completed, failed, unknown, and cancelled states separate with attempt and provider references.
- Deduplicate and recover
Authenticate events, suppress repeats, retrieve authoritative state, limit retries, and move unresolved work to a visible owner instead of dropping it.
- Reconcile and retain an exit
Compare booking, destination, action, message, API, audit, export, and backup records; preserve limitations and test restoration before closure.
Compare six automation boundaries
Native rules, connectors, webhooks, queued workers, batch files, and staffed fallback create different identities, retry behavior, and ownership burdens.
Native booking rule
A scheduler creates a receipt, reminder, staff alert, or follow-up internally.
- Rule
- Keep the native job separate from the booking and preserve its trigger, version, attempts, and stop condition.
- Watch for
- A settings toggle does not prove the background worker runs, the destination is right, or changes suppress stale work.
Connector automation
A booking change starts a workflow in a no-code connector.
- Rule
- Map stable booking and customer references, exact field versions, account scope, replay behavior, limits, and an owner on both sides.
- Watch for
- A successful connector step can still update the wrong contact or continue after the source booking changes.
Signed webhook
A provider posts a booking or delivery event to a receiving endpoint.
- Rule
- Verify origin, store the event before acting, deduplicate its identity, process independently, and retain a replay and incident path.
- Watch for
- A fast 200 response, assumed ordering, or unsigned payload can hide dropped, repeated, forged, or partially processed events.
API worker or queue
A scheduled worker reads pending actions and calls another service.
- Rule
- Use one logical job key, explicit retry limits, backoff, rate handling, a dead-letter state, and final reconciliation.
- Watch for
- Blind retries can create duplicate messages or updates; silent exhaustion can leave the booking and destination permanently different.
Batch export or import
A scheduled file moves bookings or customer updates into another system.
- Rule
- Version the schema, preserve stable IDs and change times, isolate rejected rows, reconcile counts, and retain the original file and manifest.
- Watch for
- A successful file upload can still omit relationships, overwrite newer data, or turn blank values into invented content.
Staffed fallback
A failed action becomes one assigned staff task with evidence and an approved manual path.
- Rule
- Show what already happened, what remains unknown, which action is safe, and how the final manual result will be attributed and reconciled.
- Watch for
- Manual recovery without the attempt history can repeat a successful action or hide the underlying automation failure.
Follow the event-to-reconciliation lifecycle
Preserve the relationship between the booking, event, automated job, destination, callback, retry, recovery, export, and restore record.
- Occurrence
Booking system: Create EVENT-A from one current booking version and preserve source, type, subject, occurrence time, actor, and allowed consequence.
- Decision
Business rule: Decide whether the action is allowed, which destination and minimum fields it needs, when it is due, and which later state must suppress it.
- Job
Automation owner: Create JOB-A once with a versioned payload or template, schedule, operation key, attempt limit, and expected result.
- Provider or destination
External boundary: Record accepted, sent, delivered, completed, rejected, failed, or unknown without treating one provider state as the final business outcome.
- Recovery
Named staff or system queue: Retrieve state, suppress duplicates, retry safely, quarantine exhausted work, or complete a controlled manual alternative without erasing evidence.
- Reconciliation
Business record: Align booking, job, provider, destination, response, audit, export, and backup records and preserve the final decision and limitations.
Review booking, destination, and infrastructure changes
Every change needs an explicit action on stale jobs, prior attempts, duplicate events, failed work, audit records, exports, and restore evidence.
The booking moves or is cancelled
Suppress from the new versionStop future stale work, preserve attempts already made, and create a replacement action only when the final booking and policy permit it.
The recipient or destination changes
Protect history and remapDo not rewrite where earlier data went; stop unsafe work, record the correction, and review possible exposure before retrying.
A template, payload, or schema changes
Create a new versionKeep the rendered or transmitted snapshot and its schema so later failures, exports, and corrections remain explainable.
A worker times out or crashes
Retrieve before replayTreat the outcome as unknown, inspect provider and destination state, then retry under the same logical operation or move to recovery.
An event arrives twice or out of order
Store, deduplicate, and reconcileUse event identity and authoritative current state; do not let delivery order overwrite a newer business result.
The business changes or leaves systems
Export and restore the full chainPreserve IDs, versions, attempts, outcomes, audit entries, failed work, and field meaning; test restore instead of trusting file creation.
Look for warning signs in a software demo
Force one stale trigger, duplicate, and silent failure. Watch the booking version, destination, template, queue, attempts, callbacks, suppression, recovery queue, audit history, export, and restore manifest.
Use EVENT-A, JOB-A, and an invented destination.
An automation-builder screenshot proves little. Follow one synthetic booking change through a queued action, uncertain provider result, duplicate event, exhausted retry, staffed recovery, export, and restore manifest.
- Define a synthetic confirmed BOOKING-A, one EVENT-A, one JOB-A, a versioned payload, an invented destination, a due time, a stop rule, and one expected final record.
- Move and then cancel BOOKING-A while JOB-A is queued; rehearse provider acceptance, timeout, duplicate event, safe retrieval, exhausted retry, and staffed recovery as offline records.
- Reconcile the booking, event, job, provider, destination, response, audit, export, and backup manifest; mark every named-product behavior Unknown until an identical authorized test exists.
Keep the test fair
- Use invented tokens and offline state only until a separately authorized test environment, account, destination, data set, and cleanup plan exist.
- Record the exact trigger, booking version, actor, destination, fields, template or payload version, schedule zone, job ID, event ID, attempts, retry rule, recovery owner, and final reconciliation.
- Treat this guide as preparation, not proof of delivery, product reliability, consent, privacy, security, legal compliance, data portability, or restore success.