Define when a reminder is still useful
Synthetic policy: a queued reminder is due at 16:00 for an 18:00 session. A known failure may receive one further attempt before 17:30; after that it closes as missed. Unknown outcomes require checking the delivery record before retrying. Accepted delivery is not proof that the customer read the message. No provider retry guarantee is assumed.
| Reminder | Latest evidence | Attempts | Next action |
|---|---|---|---|
| N-F1 | Known failure at 16:00 | 1 | Retry once before 17:30 |
| N-F2 | Timeout; outcome unknown | 1 | Check delivery evidence |
| N-F3 | Accepted at 16:01 | 1 | No resend; retain outcome |
Resolve delivery state before retry
- Recheck booking is active, schedule unchanged and useful window still open.
- Resolve unknown delivery using available evidence; keep it unresolved if no reliable result exists.
- Retry a known failure at most once, record the outcome, and close missed reminders at 17:30.
Do not send repeatedly to settle an unknown result. A manual communication task may be needed under the agreed channel policy.
N-F1 fails its second attempt at 17:00. Should it try a third time at 17:10?
Show the worked answer
No. The two-attempt budget is exhausted even though time remains. Record failure and route to the agreed follow-up; N-F2 still requires evidence, not a blind second send.
Keep delivery state distinct from attendance. A missed reminder neither proves absence nor changes entitlement.