📋 SMS Strategy v2.0 — QA Audit Workspace

Requested by Senyo (Kennedy) · Produced by Roger · Source: sms-strategy-2026-03.md

📄 Doc Version: 2.0 (2026-03-20) 🔍 Audit Date: 2026-03-21 📊 921 lines analyzed ⚠️ 14 duplicates · 11 conflicts · 18 fix steps

Executive Summary

High-level audit findings across the SMS strategy v2.0 document.

Duplicate Issues

Conflicts Found

Fix Steps

Unique Templates

Sections Clean

Top 5 Risks (if shipped as-is)

#	Risk	Impact	Severity
1	APP+MAMBU duplication not enforced by doc structure — §5 says "disable Mambu DPD" but §6/§16 still list templates that could fire from either source	20K+ customers/day double-messaged until engineering confirms kill switch	P0
2	Frequency caps mathematically exceeded by scheduled plan — DPD 1-7 cap = 2/day, 4/week, 8/month. But DPD schedule + post-call + salary week + PTP can stack to 4/day	Stacking 960 → 0 goal impossible without hard priority/preemption logic	P0
3	DPD messages defined in 4 separate sections (§6, §7, §15, §16) with inconsistent copy/timing	Implementation will pick one — which is canonical? Confusion → wrong templates deployed	P1
4	PTP lifecycle overlaps DPD schedule with no preemption rule — borrower at DPD 3 with a PTP gets DPD_3 + PTP_REMIND on same day	PTP should suppress DPD during active promise window	P1
5	Salary-week overlay creates uncapped burst — SAL_* fires on 22nd for ALL DPD 1+ borrowers, ON TOP of their regular DPD schedule	22nd of month = worst stacking day. Caps must account for overlay.	P1

Section 1: Duplicate SMS Inventory

Every instance where the same message concept appears in multiple places, creating implementation ambiguity or actual customer duplication.

ID	Type	Tags Involved	Where in Doc	What's Duplicated	Keep	Remove/Merge
DUP-01	System Duplication	MAMBU DPD + APP DPD	§2.3 vs §5	APP+MAMBU fire same DPD reminders. §2.3 shows MAMBU sends 868K/mo including DPD reminders. §5 says disable but no enforcement mechanism in doc.	APP (Communication Service)	Remove: All MAMBU DPD triggers. §5.2 Step 1 must be gated before ANY new templates go live.
DUP-02	Template Duplication	DPD_0 through DPD_90	§6 vs §15 vs §16	DPD templates defined 3 times: §6 (interaction plan), §15 (message templates), §16 (full table). Copy is identical but if one section is edited and others aren't → drift.	§16 as canonical (full table)	Merge: §6 and §15 should reference §16. Remove inline copy from §6, make §15 a copy-paste appendix that's auto-generated from §16.
DUP-03	Template Duplication	POSTCALL_ANS, POSTCALL_NA, POSTCALL_NA_WA	§7 vs §9 vs §15.5 vs §16.2	Post-call templates in 4 places. §7 (event table), §9 (dedicated section), §15.5 (template list), §16.2 (full event table).	§16.2 as canonical	Merge: §9 keeps logic/rules. §7 and §15.5 reference §16.2 for copy. Remove inline templates from §7.
DUP-04	Template Duplication	PTP_CONFIRM, PTP_REMIND, PTP_BROKEN, PTP_BROKEN_ESC	§7 vs §8 vs §15.6 vs §16.2	PTP templates in 4 places. Same pattern as post-call.	§16.2 as canonical	Merge: §8 keeps lifecycle logic. Templates reference §16.2.
DUP-05	Template Duplication	SAL_EARLY, SAL_MID, SAL_LEGAL, SAL_DEEP	§3.2 vs §15.7 vs §16.2	Salary templates in 3 places. §3.2 defines them inline with rules. §15.7 repeats copy. §16.2 repeats again.	§16.2 as canonical	Merge: §3.2 keeps rules only, references §16.2 for copy.
DUP-06	Concept Overlap	DPD_3 vs DPD_3_EDU	§6.3 vs §12.4	Two DPD 3 messages. `DPD_3` (standard) and `DPD_3_EDU` (with landing page link). Which fires? Both? A/B test? Unclear.	DPD_3_EDU (richer)	Resolve: Either replace DPD_3 with DPD_3_EDU, or explicitly state DPD_3_EDU is an A/B variant. Don't ship both to same borrower.
DUP-07	Concept Overlap	DPD_14 vs DPD_14_EDU	§6.4 vs §12.4	Two DPD 14 SMS messages. Same issue as DUP-06. Plus DPD_14_EMAIL = 3 touchpoints at DPD 14.	DPD_14_EDU + DPD_14_EMAIL	Resolve: DPD_14_EDU replaces DPD_14 for SMS. Email is supplementary (OK). Remove vanilla DPD_14 SMS.
DUP-08	Concept Overlap	DPD_28 vs DPD_28_EDU	§6.4 vs §12.4	Two DPD 28 SMS messages. Same pattern.	DPD_28_EDU (includes link)	Resolve: Replace DPD_28 with DPD_28_EDU once short links are live. Until then, keep DPD_28.
DUP-09	Concept Overlap	POSTCALL_NA vs POSTCALL_NA_WA vs POSTCALL_NA_EVE	§9.2 vs §16.2	Three "not answered" variants. NA (DPD 1-13), NA_WA (DPD 14+), NA_EVE (evening). Can a DPD 14+ not-answered borrower get both NA_WA at 17:00 AND NA_EVE at 18:00?	POSTCALL_NA (DPD 1-13), POSTCALL_NA_WA (DPD 14+)	Remove: POSTCALL_NA_EVE — redundant with NA/NA_WA. The 17:00 send covers evening already.
DUP-10	Channel Overlap	PREDUE_25 (push) + PREDUE_15 (push→SMS)	§6.2	DPD -25 and -15 both go push→SMS. §6.2 says -25 = push only, -15 = push→SMS. But "changes from current" says -15 LN<3 duplicate was "merged." Into what? Clarification needed.	Both (different intent)	Clarify: Add explicit rule — what happens to LN<3 cohort? Is DPD -15 now universal regardless of loan number?
DUP-11	Section Duplication	Architecture diagram	§5.3 vs Appendix B	Target architecture drawn twice — §5.3 (ASCII) and Appendix B (ASCII). Different level of detail but could diverge.	Appendix B (more complete)	Merge: §5.3 references Appendix B. Remove inline diagram from §5.3.
DUP-12	Data Duplication	Send time specs	§6 (per DPD) vs §13 (by slot)	Send times specified twice — per-DPD in §6 tables and summarized in §13. If §6 changes a time, §13 must update too.	§6 as source of truth	Merge: §13 should be auto-derivable from §6. Add note: "This section summarizes §6 — do not edit independently."
DUP-13	Suppression Logic	Suppression rules	§10.4 vs §14.3 vs §14.4	Suppression/dedup logic in 3 places: §10.4 (reference number suppression), §14.3 (Senyo alignment), §14.4 (pre-send checks). Rules are consistent but spread across sections.	§14.4 as canonical engine spec	Merge: §10.4 and §14.3 reference §14.4. One dedup spec to implement.
DUP-14	Compliance Rules	BoG language guardrails	§11.3 vs Appendix D	Compliance do/don't lists in 2 places. §11.3 (BoG-specific) and Appendix D (full checklist). Overlap on BoG assertion language rules.	Appendix D as master checklist	Merge: §11.3 is narrative context. Appendix D is the executable checklist. Cross-reference, don't duplicate rules.

Section 2: Conflict Inventory

Contradictions, logical impossibilities, and specification gaps that would break implementation.

ID	Conflict Type	Where	What It Says	Why It's a Problem	Recommended Fix
CON-01	Frequency Cap vs Actual Touchpoints	§14.1 vs §6+§7+§3.2	§14.1: Early Due max = 2 SMS/day, 4/week, 8/month. But a DPD 3 borrower on salary week with a PTP could get: DPD_3 (06:30) + SAL_EARLY (06:30) + PTP_REMIND (event) + POSTCALL_NA (17:00) = 4 SMS in one day.	§14.2 says post-call and PTP are "separate from DPD cap" — so they DON'T count toward 2/day. This means the 2/day cap is misleading. Actual max = 2 (DPD) + 1 (post-call) + 1 (PTP) = 4/day.	Define a GLOBAL hard ceiling of 3 SMS/day regardless of type. DPD cap = 2, post-call = 1, PTP = 1 — but if any 2 fire, suppress the lowest priority. Add priority order: PTP > post-call > salary > DPD.
CON-02	Salary Week vs DPD Schedule	§3.2 vs §6 vs §14	§3.2: SAL_* fires on 22nd "in addition to regular schedule." §6: regular DPD fires daily. §14.1: SAL counts toward cap. But §3.2 says it's sent "once at start of salary week."	On the 22nd, a DPD 5 borrower gets: DPD_5 (12:00) + SAL_EARLY (06:30) = 2 SMS. Fine. But if DPD 5 falls on 22nd AND they have a PTP AND weren't answered → 4 SMS. Cap says 2/day for DPD bucket.	*SAL_ replaces the regular DPD SMS on the 22nd, doesn't add to it.** Or: SAL_* counts as the DPD slot for that day (preempts, not supplements).
CON-03	PTP vs DPD Timing Clash	§8 vs §6	§8: PTP lifecycle fires on promise date ±1d. §6: DPD schedule fires regardless. No preemption rule exists.	Borrower at DPD 7 with PTP for tomorrow: gets DPD_7 (12:00) + PTP_REMIND (event). If PTP is broken next day: DPD_8 (no template but salary week could fire) + PTP_BROKEN. PTP should be the priority — it's a live commitment.	Add rule: Active PTP suppresses DPD SMS from PTP_CONFIRM until PTP_BROKEN + 24h. PTP is a higher-signal interaction. Let it run its course.
CON-04	Post-Call Timing vs DPD Schedule	§9.3 vs §6	§9.3: "Post-call SMS does NOT count against DPD-trigger frequency cap." §14.2: "Max SMS/borrower/day = 2" (global). These contradict.	Is the global cap of 2/day absolute? Or are post-call and PTP exempt? If exempt, the "global cap" isn't global. If not exempt, §9.3 is wrong.	Rewrite §14.2: "Max DPD-scheduled SMS = 2/day. Max total SMS (all types) = 3/day. Priority: PTP > post-call > DPD." Remove "separate from cap" language in §9.3.
CON-05	DPD -1 and DPD 0 Same-Day Collision	§6.2 + §6.3	PREDUE_1 fires at 06:30 on the day before due. DPD_0 fires at 06:30 on the due date. But a borrower whose loan was due "today" gets PREDUE_1 yesterday + DPD_0 today = fine. HOWEVER, what if payment processing delays make a borrower show as DPD -1 AND DPD 0 on the same snapshot?	Edge case: loan due date straddles midnight UTC. Mambu/APP might fire both on same calendar day depending on timezone handling (Ghana = UTC, so less risky, but not impossible with batch timing).	Add dedup rule: If PREDUE_1 sent in last 24h, suppress DPD_0. Same-message cooldown should catch this if MESSAGE_TAG dedup is tight enough. Verify batch timing in Communication Service.
CON-06	§14.1 Caps vs §17.3 Volume Projections	§14.1 vs §17.3	§14.1: Pre-Due max = 5 SMS/month. §6.2: 6 pre-due touchpoints (DPD -25, -15, -9, -5, -3, -1). That's 6 messages in ~25 days if the loan is active the whole period.	6 scheduled touchpoints > 5/month cap. At least one will be suppressed. Which one? No priority order defined for pre-due.	Either increase pre-due cap to 6, or drop one touchpoint. Recommend dropping PREDUE_25 (push-only, awareness, lowest value). That gives exactly 5: -15, -9, -5, -3, -1.
CON-07	Written-Off "1 SMS/month" Cap vs Template Count	§14.1 vs §6.8	§14.1: Written-Off cap = 1 SMS/month. §6.8: WO has monthly cadence (M1, M2, M3) then quarterly. But also SAL_DEEP fires during salary week for DPD 91-150.	Written-off accounts (DPD 150+) shouldn't get SAL_DEEP (which is DPD 91-150). But the boundary is fuzzy — does "Legal_3 DPD 91-150" include written-off? §6.7 says "DPD 91-150, IVR-only outside salary week."	Clarify DPD boundary: Written-off = DPD 150+ OR account_state = WRITTEN_OFF (whichever comes first). SAL_DEEP stops at write-off. WO_* templates are the only channel for written-off accounts.
CON-08	Quiet Hours vs Salary Week Rules	§13.4 vs §13.5	§13.4: "No SMS between 20:00 and 06:30." §13.5: Saturday/Sunday = no SMS unless salary week. §3.2: Salary week "includes weekends." But 06:30 Saturday SMS during salary week — is that OK?	The rules don't explicitly say salary week overrides quiet hours on weekends. 06:30 could be seen as respecting the 06:30 boundary. But should Saturday/Sunday morning SMS exist at all outside urgency?	Add explicit rule: "Salary week enables Saturday 08:30–18:00 only. Sunday remains suppressed. Quiet hours (20:00–06:30) are NEVER overridden."
CON-09	Education Links Before Infrastructure	§12.1 vs §12.4 vs §15.12	§12.1 lists 5 landing pages as "TO BUILD." §12.4 and §15.12 define templates with `fido.link/*` URLs. §19 says "Phase 4: Short Link Tracking (Day 4-5)."	Templates reference infrastructure that doesn't exist yet. If DPD_3_EDU fires before `fido.link/penalties` is built, borrowers click a dead link. Worse than no link.	Gate EDU templates behind infrastructure readiness. Phase 1-3 use standard templates (no links). Phase 4+ switches to EDU variants. Add explicit dependency in §19.
CON-10	Suppression Stream vs Frequency Caps	§14.3 vs §15.8	§14.3: Temp suppression = "1 SMS/week." §15.8: SUPP_ENTRY, SUPP_W1, SUPP_W2, SUPP_W3 = 4 templates over ~3 weeks. That's ~1.3/week. OK. But SUPP_ENTRY fires "on event" and SUPP_W1 could be in the same week if suppression entered on day 5.	If borrower enters suppression on a Thursday, SUPP_ENTRY fires Thursday. SUPP_W1 is "Week 1" — does that mean next Thursday? Or the following Monday? Ambiguous timing.	Define suppression stream timing explicitly: SUPP_ENTRY = day 0, SUPP_W1 = day 7, SUPP_W2 = day 14, SUPP_W3 = day 21. Not "week 1/2/3" — absolute days from entry.
CON-11	Compliance Wording Inconsistency	§11.2 vs §15.4	§11.2: DPD 35 language = "may be classified as wilful defaulter." §15.4 DPD_35 template: "under BoG rules you may be classified as wilful defaulter." These match. BUT §15.4 DPD_42: "Wilful default = public naming + credit ban" — this is an assertion ("="), not a "may."	DPD_42 template violates §11.3 compliance guardrails which say "never assert." The "=" framing implies certainty about classification.	Rewrite DPD_42: "{name}, final warning. Continued non-payment may result in public naming under BoG rules. Resolve now: {wa}" — keeps "may" framing.

Section 3: Step-by-Step Fix Manual

Ordered by priority. Each step has an owner, validation criteria, and dependency chain.

Step 1 — Kill MAMBU DPD Before Anything Else P0 Engineering

Action: Disable LoanReminderService in production. Set configuration.setEnabled(false) or empty the reminders list. MAMBU queue continues for transactional SMS (OTP, receipt, disbursement) only.
Refs: DUP-01, §5.2 Step 1
Depends on: Nothing — do this first.
Risk if skipped: Every subsequent change adds messages ON TOP of existing MAMBU duplicates.

✅ Validation: Query

SELECT COUNT(*) FROM COMMUNICATION_RESULT WHERE SOURCE='MAMBU' AND MESSAGE_TAG LIKE 'DPD%' AND CREATED_AT > NOW() - INTERVAL '24h'

→ must return 0 for 3 consecutive days.

Step 2 — Define Global Priority & Preemption Engine P0 Engineering + Senyo

Action: Add a message priority field + preemption logic to Communication Service. When daily cap is hit, the lowest-priority message is suppressed, not the latest.
Priority order (highest → lowest):
1. PTP_CONFIRM / PTP_REMIND / PTP_BROKEN (live commitment)
2. POSTCALL_ANS (just spoke to borrower)
3. POSTCALL_NA (attempted contact)
4. SAL_* (salary week — time-sensitive)
5. DPD_* scheduled (background cadence)
6. EDU / PROGRESS (nice-to-have)
Global ceiling: 3 SMS/day absolute. No exceptions. No "separate cap" loopholes.
Refs: CON-01, CON-02, CON-03, CON-04

✅ Validation: Simulate 1 week of messages for 100 test borrowers with overlapping events. Zero borrowers should exceed 3 SMS/day. Log suppressions with reason.

Step 3 — Add PTP Suppression Window P0 Engineering

Action: When PTP_CONFIRM is sent, suppress ALL DPD-scheduled SMS for that borrower until PTP_BROKEN + 24h (or payment received). PTP lifecycle owns the communication.
Refs: CON-03
Depends on: Step 2 (priority engine). Can be implemented as a suppression flag: PTP_ACTIVE = true → skip DPD triggers.

✅ Validation: Borrower with active PTP receives zero DPD_* tags during PTP window. PTP_REMIND and PTP_BROKEN still fire normally.

Step 4 — Salary Week = DPD Replacement, Not Addition P0 Senyo + Doc Owner

Action: Rewrite §3.2 rule: "SAL_* replaces the regular DPD SMS on the 22nd. Borrower receives SAL_* instead of their scheduled DPD message, not in addition to it."
Update §16.1: Add column "Salary week override" — on 22nd, SAL_* takes the DPD slot. Days 23-EOM revert to normal DPD schedule.
Refs: CON-02

✅ Validation: On the 22nd, zero borrowers receive both SAL_* and a DPD_* message on the same day.

Step 5 — Consolidate Templates to Single Source P1 Doc Owner

Action: Make §16 (Full Interaction Plan Table) the SINGLE canonical template source. All other sections (§6, §7, §8, §9, §15) reference §16 for copy. Remove inline template text from:
— §6.2–6.8 (keep DPD logic, timing, goals — remove "Template" column)
— §7 event table (keep trigger/source — remove template copy)
— §8.2 (keep PTP lifecycle diagram — remove templates)
— §15 entirely (becomes "See §16")
Refs: DUP-02, DUP-03, DUP-04, DUP-05

✅ Validation: grep -c "≤160 chars" sms-strategy.md → templates appear in only 2 places: §16.1 and §16.2.

Step 6 — Resolve _EDU Template Conflicts P1 Senyo + Doc Owner

Action: For DPD 3, 14, and 28 — decide: are _EDU variants replacements or A/B variants?
Recommendation: Phase 1 (no links) → use standard DPD_3/14/28. Phase 4+ (short links live) → EDU replaces standard. Delete standard variants. Never ship both to same borrower.
Update §16.1: Add "Phase" column. Mark EDU variants as "Phase 4+." Mark standard as "Phase 1-3 only."
Refs: DUP-06, DUP-07, DUP-08, CON-09

✅ Validation: In §16, every DPD day has exactly 1 SMS template (not 2 competing variants). Phase column disambiguates.

Step 7 — Remove POSTCALL_NA_EVE P1 Doc Owner

Action: Delete POSTCALL_NA_EVE from §9.2, §15.5, §16.2. The 17:00 send of POSTCALL_NA / POSTCALL_NA_WA already covers evening. A second "evening reminder" adds nothing and risks stacking.
Also: Remove §13.3 row for "Not-answered + salary week → next morning 06:30" — that's a second post-call follow-up on day 2, which is a DPD message's job, not post-call's.
Refs: DUP-09

✅ Validation: grep "POSTCALL_NA_EVE" sms-strategy.md → 0 results.

Step 8 — Fix Pre-Due Cap Math P1 Doc Owner

Action: §14.1 says 5 SMS/month for pre-due. §6.2 lists 6 touchpoints. Two options:
Option A (recommended): PREDUE_25 is push-only and doesn't count toward SMS cap → 5 SMS touchpoints remain. Clarify that push doesn't count toward SMS cap (it shouldn't — it's free and different channel).
Option B: Drop PREDUE_9 (least differentiated from PREDUE_15 and PREDUE_5).
Refs: CON-06

✅ Validation: Count SMS-channel pre-due touchpoints. Must be ≤ cap. Push-only touchpoints labeled explicitly as "(push, does not count toward SMS cap)."

Step 9 — Fix DPD_42 Compliance Language P1 Compliance + Doc Owner

Action: Rewrite DPD_42 template. Current: "Wilful default = public naming + credit ban." The "=" is an assertion. Replace with:
{name}, continued non-payment may result in public naming under BoG directive. Resolve now: {wa}
Refs: CON-11

✅ Validation: All templates DPD 35+ use "may" or "could" language. Zero templates use "=", "is", or "will" when referencing wilful defaulter classification.

Step 10 — Rewrite §14.2 Global Cap Section P1 Doc Owner

Action: Replace current §14.2 with a clearer structure:
Tiered caps:
— DPD-scheduled SMS: max 2/day, follows §14.1 bucket caps
— Event-driven SMS: max 1/day (post-call OR PTP, not both)
— GLOBAL CEILING: max 3 SMS/day, 15/month. Includes all types. No exceptions.
— Post-payment cooldown: 48h — suppresses DPD and salary, does NOT suppress PTP_CONFIRM (if they pay partially, PTP for remainder is still valid)
Remove: "Post-call SMS cap: 1/day — separate from DPD cap" and "PTP SMS cap: 1/day — separate from DPD cap" — replaced by event-driven tier above.

✅ Validation: §14.2 has no "separate from" language. All caps are additive within the global ceiling.

Step 11 — Clarify PREDUE_15 LN<3 Rule P2 Senyo

Action: §6.2 "Changes from current" says "Remove DPD -15 LN<3 duplicate (122K SMS merged into single trigger)." But doesn't specify: is PREDUE_15 now sent to ALL borrowers regardless of loan number? Or is LN<3 segment dropped entirely?
Refs: DUP-10
Decision needed from Senyo: Should first-time/new borrowers (LN 1-2) get PREDUE_15 the same as repeat borrowers? Or different copy?

✅ Validation: §6.2 explicitly states audience for PREDUE_15 (all vs LN-based segment).

Step 12 — Define Suppression Stream Timing P2 Doc Owner

Action: Replace "SUPP_W1, W2, W3" with absolute day offsets from suppression entry:
— SUPP_ENTRY: Day 0 (on event)
— SUPP_W1: Day 7 from entry
— SUPP_W2: Day 14 from entry
— SUPP_W3: Day 21 from entry
Refs: CON-10

✅ Validation: §15.8 tags use day offsets, not "week" labels.

Step 13 — Clarify Weekend Rules During Salary Week P2 Senyo + Doc Owner

Action: Add to §13.5:
"During salary week: Saturday SMS allowed 08:30–18:00. Sunday remains fully suppressed. Quiet hours (20:00–06:30) are never overridden, regardless of salary week."
Refs: CON-08

✅ Validation: §13.5 has explicit Saturday/Sunday rules for salary week. No ambiguity.

Step 14 — Clarify Written-Off vs DPD 91-150 Boundary P2 Doc Owner

Action: Add definition: "Written-off = account_state = WRITTEN_OFF OR DPD > 150, whichever occurs first. SAL_DEEP (DPD 91-150) does NOT apply to written-off accounts. Once written off, only WO_* templates apply."
Refs: CON-07

✅ Validation: §6.7 and §6.8 have a clear boundary statement. SAL_DEEP range explicitly excludes written-off.

Step 15 — Merge Architecture Diagrams P2 Doc Owner

Action: Remove §5.3 inline diagram. Replace with: "See Appendix B for target architecture." Appendix B is the single architecture reference.
Refs: DUP-11

✅ Validation: Only 1 architecture diagram in the doc (Appendix B).

Step 16 — Consolidate Suppression Logic P2 Doc Owner

Action: §14.4 becomes the canonical pre-send check specification. §10.4 and §14.3 reference it. Remove duplicated suppression rules from §10.4 (keep the reference-number-specific outcomes only). §14.3 becomes a mapping table only: "suppression state → see §14.4 check #X."
Refs: DUP-13

✅ Validation: Suppression logic is defined in exactly 1 place (§14.4). Other sections cross-reference.

Step 17 — Add DPD -1/DPD 0 Same-Day Dedup P3 Engineering

Action: Add to §14.4 dedup checks: "If PREDUE_1 was sent in the last 20 hours, suppress DPD_0." This covers timezone edge cases where batch runs for DPD -1 and DPD 0 overlap.
Refs: CON-05

✅ Validation: Test with loan due dates at midnight UTC boundary. Zero borrowers receive both PREDUE_1 and DPD_0 in 24h window.

Step 18 — Merge Compliance Checklists P3 Doc Owner

Action: §11.3 keeps narrative context about BoG directive. Appendix D is the executable checklist. Add to §11.3: "For the full compliance checklist, see Appendix D." Remove the ✅/❌ table from §11.3 (it's duplicated in Appendix D).
Refs: DUP-14

✅ Validation: BoG compliance do/don't rules appear in exactly 1 place (Appendix D).

Section 4: Final Clean-State Recommendation

For every major component of the doc — keep as-is, merge, remove, or rewrite.

Document Sections

KEEP

§1 Design Principles — Clean, well-structured. No changes needed.

KEEP

§2 Current State Baseline — Solid data foundation. SQL queries are reusable.

REWRITE

§3 Salary Cycle — Rules are good. Rewrite §3.2 to say SAL_* replaces DPD (not adds). Remove inline templates → reference §16. Add Saturday/Sunday rules.

KEEP

§4 Channel Hierarchy — Sound logic. No conflicts found.

MERGE

§5 Mambu Migration — Keep §5.1 and §5.2. Remove §5.3 diagram → reference Appendix B.

REWRITE

§6 DPD Interaction Plan — Remove "Template" column from all tables. Keep DPD, Channel, Send Time, Tag, Goal columns. Add "Phase" column. Reference §16 for copy.

REWRITE

§7 Event-Driven — Remove template copy column. Keep trigger/source/channel/tag. Reference §16.2.

MERGE

§8 PTP Campaign — Keep lifecycle diagram and rules. Remove §8.2 template table → reference §16.2. Keep §8.3 SQL and §8.4 tech spec.

REWRITE

§9 Post-Call — Remove POSTCALL_NA_EVE. Remove templates → reference §16.2. Rewrite §9.3 to remove "separate from cap" language.

MERGE

§10 Reference Number — Keep compliance rules (§10.2) and templates. Merge §10.4 suppression triggers into §14.4.

REWRITE

§11 BoG Framework — Keep §11.1 and §11.2. Remove §11.3 do/don't table → reference Appendix D.

REWRITE

§12 Landing Pages — Add infrastructure dependency gates. EDU templates are Phase 4+ only.

MERGE

§13 Send Time Optimization — Add "derived from §6" note. Add explicit weekend/salary rules. Remove §13.3 "next morning 06:30" post-call row.

REWRITE

§14 Frequency Caps — Major rewrite. New tiered cap structure (DPD / event / global ceiling). Remove "separate" language. Add priority/preemption spec.

REMOVE

§15 Message Templates — Entire section is duplicated by §16. Replace with: "All templates are defined in §16 (Full Interaction Plan Table)."

KEEP

§16 Full Interaction Plan — This is the canonical source. Add "Phase" column. Fix DPD_42 compliance language.

KEEP

§17 Volume & Cost — Numbers are directional but internally consistent. No issues found.

KEEP

§18 A/B Test Plan — Well-designed. No conflicts.

REWRITE

§19 Implementation Roadmap — Add EDU template dependency on Phase 4 short links. Gate specific templates to phases.

KEEP

§20 Success Metrics — Clean. No issues.

KEEP

Appendix A Tone Ladder — Well-structured reference.

KEEP

Appendix B Architecture — Make this the single architecture reference.

KEEP

Appendix C Glossary — Complete and useful.

REWRITE

Appendix D Compliance — Absorb §11.3 do/don't table. Become the single compliance checklist.

Template Inventory — Keep / Merge / Remove

Tag	Action	Reason
PREDUE_25	KEEP	Push-only. Low cost. Good awareness.
PREDUE_15	KEEP	Clarify LN<3 audience rule.
PREDUE_9	KEEP	Differentiated timing. Within cap if PREDUE_25 is push-only.
PREDUE_5	KEEP	Core pre-due touchpoint.
PREDUE_3	KEEP	Push-only. Educational.
PREDUE_1	KEEP	Final reminder. High value. Add DPD_0 dedup guard.
DPD_0 through DPD_90	KEEP	Core schedule. Fix DPD_42 compliance wording.
DPD_3_EDU, DPD_14_EDU, DPD_28_EDU	MERGE → Phase 4	Replace standard variants once short links are live.
DPD_14_EMAIL	KEEP	Supplementary channel. No conflict.
POSTCALL_ANS	KEEP	High-value event-driven touchpoint.
POSTCALL_NA	KEEP	DPD 1-13 not-answered. Core.
POSTCALL_NA_WA	KEEP	DPD 14+ not-answered. Adds WhatsApp CTA.
POSTCALL_NA_EVE	REMOVE	Redundant with NA/NA_WA at 17:00. Stacking risk.
PTP_CONFIRM/REMIND/BROKEN	KEEP	Core PTP lifecycle.
PTP_BROKEN_ESC	KEEP	DPD 31+ escalation after broken PTP.
SAL_EARLY/MID/LEGAL/DEEP	REWRITE	Keep templates. Rewrite rules: replaces DPD, doesn't add.
PAY_PARTIAL/FULL/PROGRESS_50/75	KEEP	Positive reinforcement. No conflicts.
SUPP_ENTRY/W1/W2/W3	REWRITE	Keep copy. Rewrite timing to absolute day offsets.
REF_POLITE/FOLLOWUP	KEEP	Compliance-safe. Well-defined.
WO_M1/M2/M3/QUARTERLY	KEEP	New revenue channel. Properly capped.
DISC_OFFER/7D/14D	KEEP	Discount lifecycle. Clean.
LEGAL3_MONTHLY	KEEP	IVR primer. Low volume.
APP_INSTALL	KEEP	Push-only re-engagement.

Implementation Sequence (Post-Audit)

Order	Action	Blocks	Owner
1	Kill MAMBU DPD (Step 1)	Everything	Engineering
2	Doc cleanup: consolidate templates, fix caps (Steps 5, 7, 8, 10)	Implementation	Doc Owner (Roger)
3	Build priority/preemption engine (Step 2)	New campaigns	Engineering
4	Add PTP suppression window (Step 3)	PTP launch	Engineering
5	Salary week replacement rule (Step 4)	22nd testing	Senyo confirms
6	Fix DPD_42 compliance (Step 9)	Template deployment	Compliance review
7	Remaining P2/P3 fixes (Steps 11-18)	Nothing critical	Doc Owner

SMS Strategy v2.0 QA Audit · Roger × Senyo · 2026-03-21 · Source: sms-strategy-2026-03.md