PM Transition Case Study · Hoozing

From operational chaos to product clarity

I designed a complete lead management system for a real estate marketplace — translating ambiguous business needs into structured workflows, decision logic, and a delivery-ready PRD that aligned engineering, operations, and QA.

Company Hoozing · Real Estate PropTech
My Role Growth Hacker / Business Analyst
Core PM Skills
Product Thinking PRD Writing System Design Stakeholder Alignment
Outcome Full product specification covering 8 user roles, 20+ features, scoring algorithm, and phased implementation roadmap

01 — Context & Ownership

Why this project strengthens my PM narrative

At Hoozing, lead handling involved multiple teams, inconsistent follow-up, unclear ownership, and too much manual judgment. I approached it not as a coordination problem alone, but as a product problem: where decisions break down, what rules should be standardized, and how the system can guide better execution.

My role went beyond documenting requests. I framed the problem, mapped the lead lifecycle end-to-end, defined user interactions and permissions, and translated business complexity into clear logic that engineering and QA could confidently implement.

This project shows how I work in a PM capacity: connecting business goals, user needs, operational realities, and execution detail into one coherent system.

The PM challenge I solved

Reducing lead chaos without sacrificing conversion quality

The system had to balance automation with human judgment: deduplicating leads, prioritising follow-up by urgency, matching agents intelligently, and making status transitions reliable enough for reporting and cross-team coordination.


02 — Product Decisions

The product decisions behind the PRD

I turned a broad business request into a decision framework. The PRD clarified what should be automated, what required human confirmation, and what should remain manual because of business risk, timing, or operational edge cases.

Instead of only describing screens, I defined the logic that drives the product: lead status transitions, follow-up cadence, ranking rules for agent matching, and operational guardrails to ensure teams make consistent decisions at scale.

My PM lens

Designing the decision logic behind the workflow

The real value of this work was not only documenting requirements, but shaping how the system should think: when to trigger, when to escalate, how to rank, and how to remove ambiguity across operations, sales, engineering, and QA.


03 — Core Features

What I defined in the PRD

Each feature was designed with clear business logic, edge case handling, and cross-functional requirements for engineering, operations, and QA.

F-01
🔗

Smart Lead Deduplication

Inbound form submissions are combined automatically when the same phone number appears within a 5-hour window. All duplicates are flagged with status "Duplicate" and linked to the canonical lead record.

F-02
🤖

Intelligent Agent Matching

Top-30 suggested agents are ranked by matching demand (project → district fallback) combined with a weighted behavioral + performance score. Overloaded agents are surfaced with a tag rather than hidden.

F-03
📅

Visit Calendar & Lifecycle

Each lead has its own visit calendar with full CRUD, status tracking (Scheduled / Visited / Canceled), and a survey-on-completion flow. Cancellation and visited events feed directly into agent scoring.

F-04
📋

Kanban CS Dashboard

A daily Kanban board for Customer Service with cards sorted by lead priority, move-in urgency, and pending follow-up count. Cards appear at the cadence defined by status (daily → every 5 days).

F-05
📣

Push Notification & SMS

One-click notification dispatch to matched agents with auto-generated Vietnamese templates populated from lead demand data. SMS enforces a 150-character hard limit with Zalo deep-link routing.

F-06
🏆

Weighted Agent Scoring

A 20-event scoring engine across Behavior (30%), Performance (60%), and Listing Quality (10%) produces a balanced score used to rank agents in the suggestion list and manage overload thresholds.


04 — Business Logic

Designing a reliable lead lifecycle

Lead Status States

New Default on creation. Auto-assigns Following Priority 1 if lead age ≤ 7 days.
Following Priority 1 / 2 / 3 Time-based: P1 = move-in <20 days, P2 = 20–40 days, P3 = >40 days.
Visiting Auto-applied for 4-day window around scheduled visit. Event-driven + cron.
Negotiating Triggered when any Agent Assignment moves to Negotiating status.
Customer No Reply After 3 confirmed "no reply" checkboxes by CS. Confirmation dialog required.
Customer Drop Manual with mandatory drop reason and drop date captured for reporting.
Cannot Serve Triggered when ≥3 agents change to Cannot Serve, or manually by CS.
Closed Deal Manual. Deal details form creates a Deal record in background automatically.

Status Automation Type

Status How it's set
NewAuto
Following P1Auto Timeline
Following P2 / P3Auto Timeline
VisitingAuto Event Manual
NegotiatingEvent (agent trigger)
Customer No ReplyEvent (3× checkbox)
Customer DropManual
Cannot ServeEvent Manual
Closed DealManual

CS Dashboard Follow-up Cadence

Lead StatusCard Frequency
NewEvery day
Following Priority 1Every day
Following Priority 2Every 3rd day
Following Priority 3Every 5th day
VisitingEvery day
NegotiatingEvery 2nd (Rent) / 5th (Buy)
Closed / DroppedRemoved from board

05 — Scoring Engine

A weighted model for agent quality

I designed a scoring system that evaluates agents across behavior, performance, and listing quality. Scores use time-bounded windows (30–90 days) to prevent permanent penalties and reward sustained improvement.

30%
Behavior
Poor communication rating (<3★): −1
3× no-reply in one lead: −4
Poor visit quality (<3★): −2
Property mismatch on photos: −2
Post-deal poor support: −4.5 max
60%
Performance
Visit cancel (personal): −1 per event
Mismatched properties sent: −0.25
Visit rate below 50%: −0.5/1%
Negotiation rate below 75%: −0.25/1%
5+ unaccepted target popups: −2 each
10%
Listing Quality
50%+ reminders ignored: −0.05/1%
No listing updates in 10 days: −0.25

Final balanced score = Σ (Metric Score × Weighting), normalized against worst/best case across all agents in the system.


06 — Scope & Scale

The breadth of this specification

8
Lead status states with defined automation triggers
20+
Agent scoring events across 3 weighted categories
12
Pop-up UI interactions fully specified with field-level logic
5
Core modules: Leads, Visits, Dashboard, Scoring, Notifications

What this project demonstrates about how I work

Complex Workflow Decomposition

Broke down an intricate state machine (lead status ↔ agent status ↔ visit status) into clear, testable rules distinguishing automatic, event-driven, and manual transitions.

Algorithm Design for Ranking

Designed a multi-criteria agent scoring and ranking algorithm with time-decay windows, balanced weighting, and fallback logic for district/project matching.

Edge Case Thinking

Explicitly documented all "does not allow" cases (e.g. agent assignment blocked when lead is Closed/Dropped), preventing ambiguous developer interpretation and QA gaps.

Cross-functional Specification

PRD covers UI interactions, backend business rules, cron job logic, database migration fields, and SMS character limits — bridging product, engineering, and QA in one document.

Localization & Market Context

Notification and SMS templates written in Vietnamese with dynamic field injection. Understood local real estate conventions (VND/USD pricing, 6-month minimum rental policy).

User Role & Permission Design

Defined role-specific views (Customer Service vs CS Leader vs Admin) with conditional display logic for dashboards and appropriate action permissions per role.