Project_Velocity/.Agent Context/Sprint 1/Founder CRM and Platform Delivery Pack/02 - PRD_ Founder CRM and Platform Planning.md

Product Requirements Document (PRD)_ Founder CRM and Platform Planning

Date: 2026-04-18
Status: Draft
Owner: Sagnik
Reviewers: Sayan, Sourik
Scope: Founder planning slice for CRM, client 360, imports, and platform truth consolidation
Purpose: Define the product intent, user outcomes, and release-level planning criteria for the founder-owned Project Velocity convergence work.
Decision Boundary: This PRD defines what the product must become. Engineering implementation is deferred to later approved work.

1. Purpose

This work exists because Project Velocity needs a customer-legible CRM core. The current product already has intelligence, analytics, and infrastructure, but it still lacks the founder-safe answer to “where are my clients and what do I do next?”

2. Background

Current product state:

• Oracle is a real analytical surface
• backend runtime is real
• Sentinel and Catalyst are real modules
• CRM exists in partial backend and frontend forms
• inventory truth is partly in assets and docs, not canonical persistence

Existing flows are insufficient because they do not produce one clear client operating system. A target user like Abantika expects:

• contacts and accounts
• opportunities and activities
• communication history
• reminders and follow-ups
• intelligent suggestions
• a usable client record surface

3. Problem Statement

Operator pain points:

• no canonical contact-list or account-list surface
• client truth is fragmented across partial CRM routes, mock frontend state, Oracle views, and raw intelligence systems
• imports have no formal canonical model
• downstream features have no stable customer graph to attach to

4. Product Goal

The primary product goal is to define and plan a top-level CRM operating model for Velocity that turns every customer into a usable, intelligent Client 360 record while preserving AI-driven enrichment, Oracle insight generation, and multi-source import flexibility.

5. Target Users and Stakeholders

• primary users
  • founders
  • brokers
  • premium real estate sales reps
  • managers
• internal operators
  • product/ops owners
  • future admin users
• reviewers and approvers
  • Sagnik
  • Sayan
  • Sourik
• sales and demo stakeholders
  • prospects evaluating Velocity as a CRM replacement

6. In-Scope Outcomes

• CRM defined as a top-level Velocity module
• contact, account, opportunity, task, and communication surfaces planned
• canonical CRM and interaction domain model defined
• raw-to-canonical import pipeline planned
• Oracle adjacency defined
• infra/operator truth consolidated
• synthetic client graph brief prepared
• monolithic truth artifact initiated

7. Out-of-Scope Items

• full code implementation of the new CRM module
• actual database migration execution
• final UI polish for all future CRM pages
• direct rollout of production connectors beyond CSV-first planning

8. Product Experience

The intended user experience is:

1. a user opens Velocity and sees CRM as a first-class module
2. they can browse contacts, accounts, opportunities, and tasks
3. every client opens into a Client 360 with:
   • communication history
   • property interests
   • QD score trends
   • notes and reminders
   • AI-generated insights
4. imports bring outside data into this same graph after mapping and approval
5. Oracle offers intelligence and review layers beside the operational CRM

9. Functional Requirements

FR-01

• description: Velocity must define CRM as a top-level module
• rationale: operational CRM cannot be hidden inside Oracle
• acceptance signal: architecture docs and module maps place CRM beside existing top-level surfaces

FR-02

• description: Velocity must define a contact-list and account-list operating surface
• rationale: this is the most basic customer expectation
• acceptance signal: CRM IA and module spec explicitly include these pages

FR-03

• description: Velocity must define a canonical Client 360 record
• rationale: all downstream intelligence requires a unified dossier
• acceptance signal: database and interface docs define the aggregate model

FR-04

• description: Velocity must define a schema-agnostic import layer
• rationale: client data will arrive from heterogeneous systems
• acceptance signal: import pipeline and source profile contracts are documented

FR-05

• description: Velocity must define the AI stewardship boundary
• rationale: imported and inferred records cannot be silently rewritten without approval logic
• acceptance signal: role spec and writeback rules are documented

10. System Behavior

Happy path:

• import data
• map it
• enrich it
• approve it
• operate on the resulting client graph

Failure path:

• ambiguous fields remain unresolved
• invalid mappings are flagged
• conflicting identities are escalated for review

Approval path:

• high-risk merges and writebacks require human approval

Audit path:

• source, confidence, and writeback provenance remain attached to the record

11. Success Metrics

• founder can answer “show me all clients” with a clear planned surface
• all major client data classes map into named canonical domains
• the monolithic truth artifact can point to this pack as the CRM authority
• a coding-agent swarm can generate synthetic records from the brief without extra architecture decisions

12. Risks

• scope inflation into full implementation
• confusion between Oracle and CRM ownership
• canonical schema getting too abstract to implement
• under-specifying migration from current tables
• treating imported evidence and normalized projections as the same thing

13. Release Plan

Planning release phases:

1. reconciliation and infra truth
2. CRM + DB architecture
3. execution/backlog and synthetic-data brief
4. monolithic truth artifact consolidation

This is an assisted planning phase, not autonomous implementation.

14. Sales Readiness

For the product to be demo-safe after this planning round:

• CRM navigation must be explainable
• client 360 must be clearly defined
• Oracle’s role relative to CRM must be clear
• infrastructure and routing truth must be operator-safe

15. Dependencies

• Sprint 1 fact table
• current repo and schema state
• Comfy and ingress truth docs
• Sayan pack
• Sourik pack
• Abantika’s CRM recommendation file

16. Acceptance Criteria

• founder pack created and populated
• reconciliation matrix explicitly calls out stale Sprint 1 claims
• CRM top-level module and subnavigation defined
• canonical domain model defined
• import architecture documented
• synthetic-data swarm brief written
• monolithic truth artifact started

17. Bottom Line

This PRD makes CRM the missing center of gravity in Project Velocity. The objective is not to make another feature list. The objective is to define the operational system the rest of Velocity has been implicitly trying to orbit.