What
The past-due alert pipeline fires three escalation slots (1 day, 7 days, 14 days past due) on independent context keys (`past_due_1` / `_2` / `_3`), but all three render identical subject + body to the recipient. A recipient receiving three nudges over two weeks can't tell from the mail whether this is the first follow-up or the third.
Defeats the purpose of having a graduated three-slot schedule — the system tracks escalation internally but never surfaces it to the recipient who's supposed to act on it.
Where
- `resources/views/mail/invoice-past-due-client.blade.php`
- `resources/views/mail/invoice-past-due-issuer.blade.php`
- `app/Mail/InvoicePastDueClientMail.php` (subject line)
- `app/Mail/InvoicePastDueIssuerMail.php` (subject line)
Slot number is available via `$delivery->context_key` (one of `past_due_1` / `past_due_2` / `past_due_3`) on the constructor's `InvoiceDelivery` argument.
Fix direction
Differentiate slots 1/2/3 in the rendered mail. Open candidates to settle before implementation:
- Numeric notice count — "1st notice" / "2nd notice" / "3rd notice." Clear escalation arc, but carries collections / legal vibes that may not fit CryptoZing's tone.
- Days-overdue framing — "Past due 1 day" / "Past due 1 week" / "Past due 2 weeks." Conveys the same urgency through time context; less confrontational.
- Tone escalation — "Friendly reminder" → "Following up" → "Urgent: still past due." Differentiates by verb/adjective shift without counting.
- Hybrid — e.g., count for issuer (workflow-tracking aid), days-overdue for client (urgency without pressure).
Final direction to be settled in #84-style discussion before shipping the copy work.
Test plan
- Re-fire all three slots against a fresh past-due invoice; rendered subject + body should clearly differentiate slot 1 vs slot 2 vs slot 3 across both client and issuer audiences.
- Eyeball QA: three slots side-by-side read as a clear escalation arc, not three identical mails.
Tracked in
`docs/strategies/19.1_NOTIFICATION_COVERAGE_AUDIT.md` §5.7.
What
The past-due alert pipeline fires three escalation slots (1 day, 7 days, 14 days past due) on independent context keys (`past_due_1` / `_2` / `_3`), but all three render identical subject + body to the recipient. A recipient receiving three nudges over two weeks can't tell from the mail whether this is the first follow-up or the third.
Defeats the purpose of having a graduated three-slot schedule — the system tracks escalation internally but never surfaces it to the recipient who's supposed to act on it.
Where
Slot number is available via `$delivery->context_key` (one of `past_due_1` / `past_due_2` / `past_due_3`) on the constructor's `InvoiceDelivery` argument.
Fix direction
Differentiate slots 1/2/3 in the rendered mail. Open candidates to settle before implementation:
Final direction to be settled in #84-style discussion before shipping the copy work.
Test plan
Tracked in
`docs/strategies/19.1_NOTIFICATION_COVERAGE_AUDIT.md` §5.7.