agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

TL;DR

Before the agent sends any booking confirmation, it must check whether a booking already exists for that lead and thread. One lookup, keyed on the lead's email plus a recent time window, prevents the double confirmation. Make the confirmation send idempotent so a retry can never create a second one.

agent replied to a thread where the lead had already booked via the calendar link - two booking confirmations went out

Steps

1. Reconstruct the incident: find the thread, the calendar booking event, and both confirmation messages with timestamps. Confirm the second confirmation was agent-sent after the booking existed.

Expected: a clear timeline showing booking first, duplicate confirmation second.

1. Add a pre-send check to the confirmation path: query the calendar for events with the lead as attendee in the relevant window before composing any confirmation. If one exists, skip the send and log "booking already confirmed".

Expected: the duplicate send becomes impossible on the normal path.

1. Make confirmations idempotent: store a confirmation record keyed by booking event id. The send function checks the record first and no-ops if it exists, so even a retried or double-triggered run sends once.

Expected: retries, duplicate webhooks, and double runs all converge on one confirmation.

1. Handle the race: the lead can book while the agent is mid-reply. Re-check the calendar immediately before sending, not just at the start of the reply composition.

Expected: the check-then-send gap is as small as possible.

1. Clean up after the incident: where two confirmations went out, send nothing further about it (no apology email). If the lead asks, the rep answers once. Log the incident for the confirmation-path review.

Expected: no extra noise to the lead; the fix is in the code path.

Use this when

• Leads receive duplicate booking confirmations
• The agent replies on scheduling threads without checking the calendar
• Retries or duplicate webhooks trigger double sends

Not for this skill when

• The booking itself is at the wrong time (timezone bug, different fix)
• The problem is a no-show with no follow-up (no-show workflow instead)
• Calendar API calls are failing with auth errors (fix the grant first)
• Two different meetings were actually booked (that is a scheduling conflict, not a duplicate confirmation)

Variant phrasings

• "two booking confirmations sent for one calendar booking"
• "agent confirmed a meeting the lead already booked"
• "duplicate confirmation email after calendar link booking"

Why it happens

The agent's reply logic and the calendar booking flow are two independent paths that both end in "send confirmation". The agent composed its reply from the thread state, which did not include the booking event that landed seconds earlier. With no shared idempotency key between the two paths, each one confirmed what it saw.

Edge cases

• The lead books, cancels, and rebooks. Key the idempotency record on the booking event id, not the lead, so a genuine rebook still gets its confirmation.
• Bookings made by the rep manually in the calendar bypass the link flow. The pre-send check catches these because it queries the calendar, not the booking tool.
• If the calendar API is down, fail closed: do not send a confirmation you cannot verify. Queue it for retry instead.
• Timezone differences can make "the relevant window" fuzzy. Search a wide window (plus or minus 7 days) by attendee email to be safe.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstud3jfoG3L2u-FvEL_2-mQ