02 — User Personas (CRM Module)

• 1. Priya — Receptionist / Front Desk
• 2. Aditi — Admissions Officer / Counselor
• 3. Kabir — Campaign / Marketing Manager
• 4. Rohan — Org Admin / Principal
• 5. Sam — Applicant Parent (portal, (planned))
• 6. Permission matrix (source of truth: permissions.constants.ts:34-36)

Who uses the CRM, what they need, and which permissions map to them. Permissions taken verbatim from permissions.constants.ts:34-36: crm.read, crm.lead.manage, crm.campaign.manage. Enforcement is (planned) — endpoints are JWT-gated only today (crm.controller.ts:29); UI gates on these permission strings in the meantime.

1. Priya — Receptionist / Front Desk

• Context: first point of contact for walk-ins and phone calls. Time-poor, interrupted constantly, often mid-conversation with a parent.
• Goals:
  • Capture a lead while the parent is on the phone: name, contact, source, grade interest — nothing more.
  • Never re-key the same parent (duplicate-email 409 path).
• Needs: a capture form with the minimum required fields (firstName, lastName, email — create-lead.dto.ts:12-27), everything else optional; source defaulted to walk_in/phone per screen entry.
• Pain points: long forms; having to know grade/class codes; no delete button (good); uncertainty about "what happens next" after capture.
• Permissions: crm.read, crm.lead.manage.
• Success measure: capture < 60 s; zero abandoned captures.

2. Aditi — Admissions Officer / Counselor

• Context: owns the nurture pipeline. Works a queue of leads by status, does follow-up calls, qualifies, and converts. Runs the admission funnel for applicants.
• Goals:
  • See "my leads" (assignedTo) and the next follow-up due per lead (followUps[].scheduledAt, lead.schema.ts:28-31).
  • Move status forward deliberately: contacted → qualified → converted; close uninterested leads with a reason.
  • Convert in one action once grade/academicYear/class are set (crm.service.ts:145-149) — the student record appears automatically.
  • For admissions: upload documents, schedule interviews with panel + mode, decide approve/reject/waitlist with a comment.
• Pain points: a converted or closed lead cannot be re-converted (crm.service.ts:120-125); a closed admission is immutable (admission.service.ts:257-269) — decisions must be deliberate.
• Permissions: crm.read, crm.lead.manage (+ crm.campaign.manage if also running campaigns).
• Success measure: time from first contact to conversion visible and shrinking; no follow-up overdue.

3. Kabir — Campaign / Marketing Manager

• Context: runs open-house events, ads, referral drives; wants to know which source yields converts.
• Goals:
  • Register campaigns (type: email/sms/social/print/other; status: draft/active/paused/completed — campaign.schema.ts:7-20) with dates.
  • See lead intake attributed to source: campaign and per-campaign metrics (metrics.leadsGenerated/converted/sent/opened/clicked, campaign.schema.ts:45-52).
• Needs: campaign create form; no lead-source breakdown endpoint exists yet (list is the only campaign read — crm.controller.ts:77-81) → funnel attribution by source is (planned)/aggregation gap.
• Permissions: crm.campaign.manage, crm.read.
• Success measure: every marketing initiative is a campaign record with dates.

4. Rohan — Org Admin / Principal

• Context: accountable for enrollment numbers; approves nothing day-to-day but watches the funnel.
• Goals:
  • One screen of pipeline health: counts per admission status + conversion rate (GET /crm/admissions/stats, admission.service.ts:227-237).
  • Assurance that decisions carry approver + comment (workflow[].approver, admission.schema.ts:59-60).
• Needs: read-only funnel tiles; audit of workflow history on any admission.
• Permissions: crm.read (broad); write perms delegated to staff.
• Success measure: funnel reviewed weekly; no surprises at enrollment time.

5. Sam — Applicant Parent (portal, (planned))

• Context: submitted an application; wants status without calling the office.
• Goals: see application status, submit required documents, see interview slot.
• Note: parent-portal read access to admissions is not in the API surface (all routes are staff-facing under JWT) — portal experience is (planned).

6. Permission matrix (source of truth: permissions.constants.ts:34-36)

• Gap: no crm.admission.* / crm.lead.delete / crm.followup.* permission strings exist; admission endpoints share the generic crm.* set. Flag for RBAC design ((planned), IMPLEMENTATION_PLAN.md §5.1).
• Enforcement (planned): today any authenticated user can call every route.