A Booking Reminder Regenerated Its Recipient Map After Send: Verify Who Was Actually Notified

Start with the booking ID, calendar event ID, reminder ID, content hash, and the recipient binding that existed when the reminder was created. A regenerated map is a later state. It does not rewrite the send record.

Build one ledger before sending any follow-up. The ledger separates people who have a recorded notification trail from people whose status needs one controlled confirmation.

For message providers that expose individual message records, capture the provider message ID, destination, send timestamp, and final status. Twilio's Message resource includes a recipient, message identifier, sent timestamp, and status for an outbound message.

• Freeze the original send record and its content hash.
• Export provider receipts before changing attendee status.
• Compare by stable attendee identifier or canonical address, not display name.
• Record every decision in the reconciliation ledger.

Which record decides who was actually targeted?

Use the send record to determine targeting. It should show the reminder identifier, the recipient binding resolved for that send, and the content version. Use the provider record to confirm that the system created or dispatched the message for each destination.

A regenerated recipient map is useful for finding a mismatch. It cannot establish that a new attendee received an earlier reminder. Conversely, removing an attendee from the new map does not erase their earlier provider receipt.

For email delivery status, keep the meaning narrow. RFC 3464 defines delivery-status notifications with per-message and per-recipient fields, including original and final recipient information. That makes per-recipient evidence more useful than a single booking-level status.

How do you compare the old and new recipient maps?

Normalize each recipient to the stable identifier available in the booking system. If the provider only returns an address, record the address used for that send and retain the provider message ID beside it.

Split the comparison into three sets: present in both maps, present only in the send-time map, and present only in the regenerated map. Then attach a provider outcome to every send-time recipient before deciding whether anyone needs a confirmation.

A later map can surface a real operational change, such as an attendee added after the reminder. It is a review signal, not a reason to replay the original reminder to the whole group.

• Present in both maps: verify the original receipt, then suppress a duplicate.
• Only in the send-time map: preserve the receipt and check whether the attendee is still relevant to the booking.

• Only in the regenerated map: check whether the attendee requires notice and whether a separate message already exists.

Who needs one controlled confirmation?

Send one controlled confirmation when a required attendee has no matched send record, no provider receipt, or an unresolved identity match. State that it confirms the booking details. Do not frame it as a replacement for a reminder you cannot prove was missing.

A reviewer should approve the exception when the attendee role, booking state, or address match is unclear. The reviewer needs the booking and event IDs, both recipient bindings, provider evidence, and the proposed destination before the confirmation is sent.

Provider status events can arrive out of order. Twilio's outbound-status guide says status callbacks may not arrive in the order they were sent. Store the events with their timestamps and resolve the final state deliberately rather than assuming callback order.

• Required attendee with no matched notification evidence: one controlled confirmation after review.
• Required attendee with a failed or undelivered record: follow the booking's approved recovery process, with the failure recorded.
• Optional attendee, internal observer, or attendee with a matching sent or delivered record: no duplicate notice.

Who must not receive a duplicate notice?

Suppress a duplicate for any attendee with a matching reminder ID or content hash and a provider record showing that the message was sent or delivered (or otherwise conclusively processed) for the intended destination. Keep the raw provider status in the ledger because each provider defines its events differently.

For email, do not turn an open event into a required condition for closure. Twilio SendGrid documents delivery events separately from engagement events such as opens and clicks. Delivery evidence answers the notification question more directly than engagement evidence.

Also suppress any automatic replay while the recipient identity is unresolved. A duplicate guard should key on the booking, event, recipient, reminder purpose, content hash, and the relevant reminder window.

• Do not resend to all attendees because one new-map entry changed.
• Do not treat a read receipt as mandatory evidence of notification.
• Do not combine provider receipts from different reminder versions.
• Do not send a follow-up while the recipient match is unresolved.

What closes the reconciliation?

Close the ledger when every affected attendee has one documented outcome: either documented resolution (recorded notification evidence or a reviewer-approved exclusion) or one controlled confirmation. Retain the old and new bindings, provider receipts, decision, reviewer, and closure time.

If evidence conflicts, leave the booking open for manual review instead of guessing. The operational goal is a defensible recipient decision for each attendee, not a clean-looking recipient map.