Program

The customer lifecycle. Who to talk to, at what stage, about what — and whether it worked.

What this vertical means here

Program OS is the fourth spoke off Mktg OS on page 1, expanded across the whole of page 2. Where BTL is the plumbing that delivers a message, Program is the decision about which message a given customer should get.

The two are drawn as separate spokes but share page 2, and in practice a program without a channel is a spreadsheet. Read the two docs together.

Workflows

Workflow	Status	Where / ref
Approvals dashboard — team-lead work items	✅ Live	Approvals
Content governance — approval gates for blogs and scripts	✅ Live	Admin-only toggles
RBAC — roles, permissions, per-tenant members	✅ Live	Members
Page visibility — per-tenant nav control	✅ Live	Page Visibility
Compliance review queue — cross-item pending acknowledgements	✅ Live	Compliance Review
Retention program — Active base (`A1`)	⬜ Planned	p2
Retention program — Inactive base (`A2`)	⬜ Planned	p2
Acquisition — Referral / Easy Rewards	⬜ Planned	p2 ACQ
Acquisition — DSA, physical world	⬜ Planned	p2 ACQ
Acquisition — Share & Win, digital world	⬜ Planned	p2 ACQ
Loyalty	⬜ Planned	p2, marked `✗`
Data enrichment	⬜ Planned	p2 target-state
Personalization	⬜ Planned	p2 target-state
NBA — Next Best Action	⬜ Planned	p2 target-state

What's live, in detail

Everything shipped in this vertical is governance — controlling who may approve and publish content. None of it is lifecycle marketing.

That is a real distinction, and worth not blurring: the product can route a blog draft to a team lead for sign-off. It cannot decide that a customer who took a loan eleven months ago should hear about renewal.

Content governance

Admin-only toggles that gate CMS delivery and calendar scheduling behind approval. Enforced server-side, not just in the UI.

Approvals

A team-lead dashboard of work items — the human review layer that content governance routes into.

Compliance review queue

Cross-item view of pending compliance acknowledgements across Discovery, so a reviewer can clear a backlog in one place rather than card by card. Backed by the Compliance Agent.

RBAC

App-owned roles and permissions, per tenant. Every nav page declares the permission it needs, so visibility and access stay in one definition.

The lifecycle programs, as designed

Page 2 splits the base 70/30 — Retention at 70% — and then splits retention by activity:

Retention (70%)
├── Active   (A1) → add-on loan · top up · cross-sell · refer · renew · interest payment
│                    delivered via WA Bot / App Adoption / Digital Web
└── Inactive (A2) → Winback 0–6m · Closure 6–24m · Rechurn >24m
                    Competition Base ("surgical strike") · Referral

ACQ
├── Referral (Easy Rewards) → IIFL BASE → LEAD → allocate to branch → branch to connect
├── DSA — physical world
├── Share & Win — digital world  ─┐
└── Influencer                    ─┴→ NON IIFL BASE

Target-state capabilities listed alongside: data enrichment, onboarding CLCM, personalization, real-time engagement, intelligence agent, NBA.

What's missing

All of it, on the lifecycle side. There is no customer record in the product. No base, no segment, no program, no journey, no trigger.

The specific blockers:

No customer data layer. Page 1 draws IIFL DATA → (CRM) feeding the OS. Not connected. Without it, A1/A2 are definitions with nothing to select from.
No segment engine (A3) — the whiteboard marks micro-segmentation, real-time engagement and intelligence all with ✗.
No measurement of a program. Analytics today measures content (see Analytics); nothing measures a cohort against a target like "add-on loan — 500 cr".
No NBA. Listed as target state; nothing decides a next action for anyone.

Dependencies

Needs	Status
CRM / customer data integration	⬜ Not started — the hard blocker
BTL channel dispatch	⬜ Not started
Segment engine (`A3`)	⬜ Not started
Attribution — tying an outcome back to a program	⬜ Not started, and not on the roadmap
RBAC + governance	✅ Live

The attribution row is a genuine gap in the sketch. Page 2 sets rupee targets per play (Add-on Loan – 500 cr, Refer – 1000) but draws no mechanism for measuring against them. A6 Analytics is drawn as an agent, but its inputs are never specified.

Workflow specs in this folder

Roadmap source

Pages 1 (Program OS spoke), 2 in its entirety. See ../../roadmap_ref_extracted.md.