# WDF National Operations Platform — System Specification (v1, concept) *Prepared by Soulune for World Development Fund. Working draft to drive the conceptualisation workshop.* --- ## 1. Purpose A single platform that lets WDF run its multi-programme rollout — with a deep workflow for the **church wing** — and answer, at any moment: *which churches applied, who paid, who's in the 14-day window, what's compliant, who's blocked, what support is due, and how each province/officer is performing.* Built **on Twenty** (data + roles + workflow + AI), with small integrations only where Twenty genuinely can't reach (payments, provisioning, map). --- ## 2. The operating model — three linked lanes | Lane | What it covers | |---|---| | **1. Programme delivery** | All WDF support across SME, pre-school, NPO/NGO, church, ESD: applications, compliance, systems setup, funding readiness. | | **2. Church network** | Province → Region → Ward → Church → Pastor → Member → Household; onboarding, member capture, bursaries, clinics, milestone-gated support. | | **3. Cover & products** | Funeral/medical/finance cover (Monarch, Sacred Life, Episodic Health); cover-gated funding; subscriptions. *(How deep Soulune builds this = open decision.)* | Keep the lanes **linked but not mixed.** --- ## 3. Roles & visibility (the organogram — who sees what) | Role | Sees | Acts on | |---|---|---| | **National Admin (HQ)** | Everything, all provinces | Oversight, release big funding, unblock | | **Provincial Liaison Officer** | Only their province | Drive province, chase regions | | **Regional Liaison Officer** | Only their region/ward | Push community officers | | **Community Liaison Officer** | Only their churches | Collect proof, capture members, complete tasks | | **Church Leader / Pastor** | Only their own church + members | Complete their steps, submit evidence *(via WhatsApp/AI or light portal — not a Twenty login)* | | **Finance / Verifier** | Payments & evidence only | Verify payments, release funding | **Enforcement:** Twenty 2.x **row-level permissions (RLS)** scope each internal login to their own records (e.g. Province = Eastern Cape). **RLS is a Twenty *Enterprise* feature** — the engine supports it on self-host, but the rule editor is gated behind the Enterprise entitlement. ⇒ **Cost line: WDF licenses Twenty Enterprise** for row-level scoping. Object-level + field-level permissions work without it. Pastors/members are *external* and come in via WhatsApp + the AI, not Twenty seats. --- ## 4. The 8-stage process engine For each stage: **what happens · who acts · Twenty-native or companion · the gate to advance.** | # | Stage | What happens | Who acts | Twenty-native? | Gate to advance | |---|---|---|---|---|---| | 1 | **Application & Onboarding** | Multi-programme form, docs, applicant + church record created, province/officer auto-assigned | Applicant / Officer | ✅ Native (objects, relations) + companion form | Application submitted | | 2 | **R350 ACPN Payment** | Payment link, confirm, receipt, start 14-day clock, open Phase-1 tasks | Church → Finance | ⚙️ Companion (payment gateway) → Twenty records result | R350 verified | | 3 | **Registration & Compliance** | NPC name, CIPC prep, NPO/PBO/SARS/UIF/COIDA tracking + expiry alerts, doc checklist | Officer / Verifier | ✅ Native tracking; ⚙️ CIPC has no API (officer submits, system tracks; RPA later) | Required docs verified | | 4 | **R3,500 WDF Membership** | Link pushed, countdown (day 7/12/13 reminders), unlock Phase 2, extension exception flow | Church → Finance | ⚙️ Companion (gateway + SLA timer) → Twenty records | R3,500 paid in window | | 5 | **Provisioning** | Subdomain, SSL, church workspace, AI-generated website, emails, VoIP, storage | System | ⚙️ Companion (our provisioning kit — already proven) | Church system live | | 6 | **Member & Data Capture** | Members, households, bursary candidates, attendance; rolls up the hierarchy | Church / Officer | ✅ Native (Members object + rollup) | Members captured | | 7 | **Cover & Eligibility** | Funeral + medical cover check; hard gate; external-cover upload + verify; expiry alerts | Officer / Verifier | ✅ Native gate; ⚙️ product status (manual/integration) | Cover verified | | 8 | **Support Released** | Stipends, equipment, renovations, clinics released; funder reporting & audit | Finance / HQ | ✅ Native tracking; ⚙️ payouts = bank export (we don't move money) | Approved + evidence logged | --- ## 5. Data model (entities) **Built already:** Province, Officer (role + phone), Church (province, officer, status, journey stage, R350/R3,500/cover gates, deadline, proof, payment due, member count), Member (role, cover, household). **To add for the full spec:** Application (programme type, status), Payment (type, amount, ref, proof, verified_by), Milestone (phase, task, due, evidence, approver), Document (type, file, expiry, verification), Product/Cover (plan, fee, active, expiry), Stipend (person, period, rule, approval), Audit Log. *(Most are custom objects in Twenty.)* --- ## 6. What's Twenty-native vs companion (the build map) | ✅ Twenty does natively (configure) | ⚙️ Needs a small companion (integrate) | |---|---| | Data model (all objects + relations) | Payment collection (R350 / R3,500 / subscriptions) | | Role logins + **row-level scoping** | National **map** view | | 8-stage Kanban journey board | Per-church **provisioning** (subdomain/site/email/VoIP) | | Tasks per officer | External **pastor/member self-service** at scale → WhatsApp/AI | | Dashboards & charts (funnel, per-province) | Heavy **SLA timers** / multi-step orchestration | | The AI command centre | CIPC/SARS automation (workflow-assisted, RPA later) | **Principle:** Twenty is ~80% of the platform. The rest are *integrations around it*, not a parallel system. --- ## 7. Payments model - **R350 (ACPN)** — initial activation; starts Phase 1; opens the 14-day clock. - **R3,500 (WDF)** — membership; unlocks Phase 2 + provisioning. *Confirm who legally receives each.* - **Products** — monthly cover subscriptions (Monarch/Sacred Life/Episodic Health). - **Payouts (stipends/equipment)** — money *out*; system tracks + gates on proof + **exports a bank file**; WDF pays via bank. (Soulune does not move the money.) --- ## 8. Cover & eligibility (the funding gate) **No funding released without verified funeral + medical cover.** Open question: must applicants use WDF partner products, or can they show *existing external cover*? This decides how much of the product/MLM engine we build. --- ## 9. Provisioning (per church) — later phase Subdomain + SSL + church workspace + AI website + email + VoIP + storage, on a **shared multi-tenant model** (NOT one server per church). We've already proven subdomain + SSL + isolated workspace provisioning. Recommend **Caddy + Docker + wildcard DNS**, not Kubernetes. --- ## 10. Phasing — recommended - **Phase 1 (the spine):** Application intake → R350/R3,500 payments + 14-day gate → compliance/ milestone tracker with evidence → member capture → rollup dashboards + role logins + the AI. *80% of the felt value; mostly Twenty-native.* - **Phase 2:** Provisioning engine (church subdomains/sites/emails), the national map, deeper SLA automation. - **Phase 3:** Cover/products engine + commissions, funder reporting, scale hardening. --- ## 11. Open questions for WDF (decisions only they can make) 1. Payment gateway, and **who receives R350 (ACPN) vs R3,500 (WDF)?** 2. External cover allowed, or must use WDF partner products? 3. How deep do we build the **product/commission (MLM) layer** vs WDF running it themselves? 4. Realistic **church count in the first 6 months** (sizing)? 5. Day-one **users & roles** — who logs in first? 6. Which **programmes** go live first — church only, or SME/pre-school/NPO too? 7. CIPC/compliance — who actually submits (WDF staff vs automated)?