Case 03 / 12
Sanan Corporation · Requirement analysis · CRM
Leads · Kizna CRM
A lightweight lead record and screen, so raw inbound contacts get screened before anyone creates a full family profile.
- What it shows
- Requirement analysis
- My role
- Product Owner · requirement analysis
- When
- 09/2026 (KIZUNA-007)
- Company
- Sanan Corporation
01 · The problem
Leads · Kizna CRM
Context
Admissions teams take in raw contacts from Facebook, Zalo, the hotline, walk-ins, and events. The request arrived as “we need a leads screen”.
The CRM had nowhere to put a contact that hadn't been checked yet. Every new phone number went through the 3-step “Add family” wizard, which creates a family, a student, and an enrollment opportunity. Spam and wrong numbers sat in the family list next to real customers, logging one number meant filling a heavy form, and nobody could measure how many raw contacts actually became families.
02 · What I did
Leads · Kizna CRM
- 01Looked past the request to the root cause. It read as “add a leads screen”, but the real gap was a missing record between a raw contact and a family profile. The existing “lead overview” was really an enrollment pipeline for students who already had profiles.
- 02Checked the codebase before promising reuse. The B2B lead object and the grouped-by-stage view existed only in planning docs, not in the preschool product, so this was a new build rather than a port.
- 03Wrote the PRD: context, in and out of scope, use cases for counsellors, team leads, and marketing, four user flows, Given/When/Then acceptance criteria, data model, business rules, edge cases, permissions, and tracking events.
- 04Defined a 5-state lifecycle (New → Verified → Nurturing → Profile created / Disqualified) and mapped it onto the existing B2B statuses, so reporting stays consistent across products.
- 05Closed the four blocking questions with the developer the same day, then carried it into the design doc and a 12-group dev plan.
03 · Decisions & trade-offs
Leads · Kizna CRM
No “Profile created” without a profile
Moving a lead to Profile created opens the Add family wizard first, and the status only changes after it saves. The server also rejects that status without a linked family, so the rule holds through the API, not just the UI.
Warn on duplicates, don't block
Phone and email are checked against existing leads and families. Staff see a link to the match and can still continue, because one number can belong to a different parent.
Converting keeps the lead
The lead stays as the record of where the family came from, linked both ways, so source quality and time-to-convert can be reported later.
Phase 2, on purpose
Excel import, merging duplicates, lead scoring, and auto-creating an enrollment opportunity were scoped out. Phase 1 adds the screening step without touching the live enrollment funnel or its reports.
04 · What I produced
Leads · Kizna CRM
Primary admissions counsellor / telesales: screens raw contacts
Secondary team lead (KPIs, assigns owners) · marketing (source quality)
• Log a new number from Facebook / hotline / inbox in 10 seconds,
without creating a family profile
• Call to verify → New → Verified, or Disqualified if wrong or spam
• Nurture with a follow-up date and notes
• Parent is really interested → Profile created; the system makes
you create or link a family profile first
1 Staff drags the card to “Profile created”
2 The status does NOT change yet. The Add family wizard opens,
prefilled from the lead: name, phone, email, source, branch, owner
3 Phone or email matches an existing family → offer “Link existing”
4 Saved → status = Profile created, linked family, convertedAt
5 Cancelled → status unchanged, card goes back to its column
Given a client calls updateOneLead with status = Profile created
and no linked family
When the request is processed
Then the server rejects it with a clear error
(checked in the query hook, not only in the UI)
Given the Add family wizard was opened from the convert flow
When the user cancels or the save fails
Then the lead keeps its previous status and the card returns
1 New raw contact, not called yet
2 Verified reached; right person, real need
3 Nurturing interested, not ready yet
4 Profile created terminal · success
5 Disqualified terminal · wrong number, spam, no need
BL-1 Profile created ⇔ a family profile is linked
BL-4 Disqualified ⇒ a disqualify reason is required
BL-5 duplicates: warn on normalised phone + email, never hard-block
OQ-1 Route and menu label?
→ its own screen, placed above the enrollment overview
OQ-3 Does converting also create a student + opportunity?
→ No. Only the family profile is required
OQ-4 Which working fields in phase 1?
→ owner, branch, channel, follow-up date, notes, reason
OQ-7 Can a lead move back out of Profile created?
→ Blocked until the family profile is unlinked
Blocking questions were settled with the developer on 2026-09-04. The rest went to design with a recommendation attached.
05 · Before / after
Leads · Kizna CRM
Drag the divider to compare
06 · What I achieved
Leads · Kizna CRM
What changed
- PRD approved for design the day it was written, with all four blocking questions resolved.
- One document that design and development worked from: scope, flows, rules, and testable acceptance criteria, followed by a design doc and a 12-group dev plan.
- Non-blocking questions recorded with a recommended answer instead of being left vague.
What I'd keep doing
- “The first request is usually a solution. The work is finding the missing concept behind it.”
- “A rule that only the UI enforces isn't a rule.”
Next case study · Sanan
Corporate & Marketing Websites