Wrong-Time Booking Agent: Availability Triage Playbook

A booking agent that quotes the wrong slot is almost never a model problem. It is a pipeline problem: two systems answering the same question, a timezone block that shifts by an hour, a post-processing node that rewrites a correct answer, a missing lock that lets two requests grab one slot, or a platform that cannot answer in real time at all. This playbook triages those causes in order and gives you a mitigation menu from least to most invasive.

Typical triggers:

• A customer is told a slot is free that is actually taken, or told a free slot is busy.
• The same request returns different availability on repeat attempts.
• Booked times are consistently one hour off the intended time.
• Two customers are confirmed into the same resource or window.

Classify before you touch anything. The blast radius differs sharply by cause.

Keep roles generic and named up front so escalation is not improvised.

• Booking / on-call owner: runs this triage, owns the decision to disable auto-booking.
• Calendar / integration escalation: owns the calendar API and the availability integrations; called when the fault is in the source of truth.
• Comms lead: owns customer-facing messaging and the fallback to human confirmation.

Work read-only first. Do not change any workflow until you have read what actually happened.

[ ] 1. Read the LIVE executions, not the chat surface. The chat view
       hides pipeline issues; the executions show what each node
       actually returned. [1530][1526]
[ ] 2. Check for MORE THAN ONE availability implementation answering.
       Look for a duplicate MCP check-availability tool AND a
       webhook-based availability function both live. [199]
[ ] 3. Check timezone / DST handling. Confirm the requested time maps
       to the intended fixed block; a wrong offset shows up as
       off-by-an-hour. [1594]
[ ] 4. Check whether a post-processing node rewrote a correct answer.
       Validators and JSON-parser nodes can silently alter approved
       output. [1526]
[ ] 5. Check whether concurrent requests can race the same slot. Fire
       two simultaneous requests and watch the executions. [1597]
[ ] 6. Confirm the platform can return a live SYNCHRONOUS response at
       all. A fire-and-forget flow cannot quote availability in the
       moment. [1589]

Match the symptom to the cause. Each branch points to one mitigation.

Apply the least invasive fix that resolves the diagnosed branch. Do not stack fixes you have not diagnosed.

1. Retire the duplicate availability path. When two implementations answer, keep one source of truth and delete the other. Apply every future fix to that single remaining path so the two can never diverge again. [199]
2. Correct the timezone block logic. Convert the requested time into the intended fixed block with explicit DST-safe handling, then live-test across a daylight-saving boundary. [1594]
3. Stop the post-processing node from altering approved content. Ensure validators and parser nodes cannot drop required elements or rewrite the answer the model already got right. [1526]
4. Add a shared lock. Use n8n Data Tables to lock a slot so two concurrent requests cannot both book it, and verify the lock under simultaneous attempts. [1597]
5. Move to a synchronous platform. If the flow cannot return a live response, move it to a platform that can — a six-step Zap that only fires and forgets is the wrong tool when a real-time answer is required. [1589]

Escalate to the calendar / API owner when:

• The fault sits inside the calendar or field-service API rather than the workflow.
• Retiring a duplicate path risks removing the only working source of truth.
• A double-booking has already reached a customer.

Verify against the live executions, never the chat surface alone.

• Live-test working-hours versus weekend handover and confirm the agent hands off correctly out of hours. [1530]
• Fire concurrent booking attempts at the same slot and confirm the lock holds. [1597]
• Confirm no raw technical error reaches the customer; front-end error catching should intercept every failure. [1530]

Recovery is complete only when the executions show correct behavior under load, not when the chat looks right.

Capture, in the incident record:

• The execution trace for the failing request.
• The two divergent answers, side by side, when duplicate paths were the cause.
• The timezone inputs and the block they produced, when off-by-an-hour was the cause.

Customer comms template:

We found a booking issue affecting some appointment times and have corrected it. If your appointment was affected, we will confirm the correct time directly. No action is needed on your side.

Run a retro and link it from the incident record. Lock in prevention:

• One availability source of truth. Never let two implementations answer the same question. [199]
• DST-safe timezone logic, tested across a daylight-saving boundary. [1594]
• A shared lock on every resource two runs can race for. [1597]
• Verification against live executions, not the chat surface. [1530][1526]
• The right platform for the job — synchronous when a live answer is required. [1589]