GIGA CRM Phase 1 — Product Requirements Document (PRD)

Organization: INTUS Document Status: Draft v0.2 (Revised based on charter original text) Created: 2026-07-10 Revised: 2026-07-11 Project Charter Approval: 2026-06-23 (Approved), 2026-06-29 (Date Approved) Charter Revision: Rev.1 — 2026-07-09 (Timeline shortened) Charter Reference: https://chatgpt.com/share/e/6a3a7106-6070-8000-ba0f-51d1f37b67c9 Document Owner: [TBD] Approver: [TBD]

Revision History

Table of Contents

1. Project Overview
2. Business Background & Problem Statement
3. Project Goals & Success Criteria
4. Scope Definition
5. Stakeholders & User Roles
6. Functional Requirements
7. Non-Functional Requirements
8. System Architecture Overview
9. Data Requirements
10. AI / Agent Requirements
11. Integration Requirements
12. Deliverables Mapping
13. Milestones & Timeline
14. Assumptions, Constraints & Risks
15. Financial Information
16. Acceptance Criteria
17. SOX / Internal Control Impact
18. Glossary
19. Appendix

1. Project Overview

1.1 Project Name

GIGA CRM — AI Opportunity Platform (Phase 1)

1.2 Organization

INTUS

1.3 Project Positioning

GIGA CRM is part of a broader multi-phase roadmap to consolidate commercial workflows and build an agent-first CRM foundation. Phase 1 is limited to the AI Opportunity Platform, focused on agent-assisted and agent-operated workflows for Schedulers and Researchers.

Key Positioning Statement (from Charter Assumption #1): GIGA CRM is expected to replace or consolidate fragmented commercial systems over multiple phases, rather than add another standalone CRM, and will become the primary system for managing customer information and commercial activities.

Key Positioning Statement (from Charter Business Need #3): Phase 1 creates reusable foundations for future CRM phases, while not replacing the full CRM platform in Phase 1.

1.4 Document Purpose

This document is based on the approved Project Charter (Approved 2026-06-23, Rev.1 2026-07-09). It decomposes the Phase 1 scope defined in the charter into executable functional and non-functional requirements, serving as the basis for solution design, development, and acceptance testing.

1.5 Target Audience

• Product Managers & Business Analysts
• Solution Architects & Development Team
• Testing Team (UAT)
• Project Sponsors & Business Owners

2. Business Background & Problem Statement

2.1 Business Need (from Charter)

INTUS currently relies on disconnected systems and manual processes for opportunity research, scheduling, and commercial workflow coordination. This creates:

2.2 Phase 1 Solution

Phase 1 will establish an AI Opportunity Platform for Researchers and Schedulers to improve: - Opportunity intake - Research - Scheduling coordination - Structured handoffs - Workflow visibility

2.3 Phase 1 Intent

• Deliver near-term efficiency, consistency, and quality improvements
• Validate AI-assisted workflows, human-review controls, and decision traceability
• Create reusable foundations for future CRM phases
• Not replace the full CRM platform

3. Project Goals & Success Criteria

3.1 Phase 1 Goal

Establish an AI Opportunity Platform serving Researchers and Schedulers, implementing agent-assisted and agent-operated workflows, validating reusable workflow, data, AI governance, access control, and decision-traceability patterns.

3.2 Success Criteria (from Charter, 9 Quantifiable KPIs)

4. Scope Definition

4.1 Phase 1 In-Scope (from Charter)

• Opportunity intake workflows
• Researcher workflow automation and support with standardized output
• Scheduler workflow automation and support with standardized output
• AI-generated research summaries
• AI-assisted scheduling recommendations
• Human review and exception management
• Agent task management
• Workflow status tracking with reminders
• Initial reporting and dashboards
• Role-based access controls

4.2 Phase 1 Out-of-Scope (from Charter)

4.3 Data Source Scope

• Phase 1 data sources: Dodge and ConstructConnect
• Other data sources (other websites, scraping, broader commercial data) are explicitly excluded unless formally changed and approved

4.4 Future Roadmap Note

From Charter: Future CRM roadmap items are directional only and NOT approved deliverables under this Phase 1 charter. Future phases require separate scope approval, prioritization, timeline confirmation, and funding review.

4.5 Scope Boundary Diagram

┌──────────────────────────────────────────────────────────────┐
│                   GIGA CRM Phase 1 Scope                       │
│              AI Opportunity Platform                          │
│                                                              │
│  ┌───────────┐    ┌───────────┐    ┌───────────┐           │
│  │ Data      │───▶│ Researcher │───▶│ Scheduler │           │
│  │ Intake    │    │ Workflow   │    │ Workflow  │           │
│  │ Dodge/CC  │    │ AI-assisted│    │ AI-advised│           │
│  └───────────┘    └─────┬─────┘    └─────┬─────┘           │
│                         │                │                    │
│                         ▼                ▼                    │
│                  ┌────────────┐  ┌─────────────┐             │
│                  │ Human      │  │ Structured  │             │
│                  │ Review Gate│  │ Handoff Pkg │             │
│                  └────────────┘  └──────┬──────┘             │
│                                        │                     │
│                         ┌──────────────▼──────────────┐      │
│                         │ Status Tracking + Dashboard  │      │
│                         │ + Notifications              │      │
│                         └─────────────────────────────┘      │
│                                                              │
│  ──────────── Phase 1 Boundary ────────────                  │
│  ✅ Researchers + Schedulers workflows                        │
│  ✅ Agent-assisted + Agent-operated modes                     │
│  ❌ Full CRM / Quotes / Pipeline / CS / ERP                  │
│  ❌ External customer-facing AI / Autonomous sales            │
│  ❌ L0 Reviewer (Phase II) / Deal Coach (Phase III)         │
└──────────────────────────────────────────────────────────────┘
     Data Sources: Dodge | ConstructConnect (only)

5. Stakeholders & User Roles

5.1 Project Stakeholders (from Charter)

5.2 User Role Definitions (from Charter)

Researcher

Users responsible for opportunity background research

Scheduler

Users responsible for meeting coordination, reminders, follow-up, and related scheduling workflows

Manager

Admin

5.3 Role Access Control Matrix

6. Functional Requirements

6.1 Module Overview

6.2 F-01: AI Opportunity Platform Foundation

Goal: Establish initial platform workspace for managing opportunity-related research and scheduling workflows with basic access controls.

6.3 F-02: Data Ingestion

Goal: Import Dodge and ConstructConnect project data, normalize into a unified structure, deduplicate records, and store for downstream processing.

Data Ingestion Flow:

Dodge API ──┐
             ├──▶ Field Mapping/Normalize ──▶ Deduplicate ──▶ Store ──▶ Downstream
ConstructConnect API ──┘                          │
                                                   ├── Error? ──▶ Alert Admin
                                                   └── Success? ──▶ Log Record

6.4 F-03: Opportunity Filtering

Goal: Apply agreed business criteria to filter opportunities before AI enrichment and evaluation.

6.5 F-04: Opportunity Enrichment & Evaluation Review

Goal: Review and correction loop for AI-prepared opportunity enrichment, qualification context, product fit, confidence indicators, and recommended next actions. Researchers can adjust instructions or criteria and re-trigger AI processing.

6.6 F-05: Communication Plan Review

Goal: Workflow for Schedulers to review and adjust AI-prepared communication plans, including email drafts, voice call plans, timing, follow-up sequence, and escalation notes.

6.7 F-06: Human Review Gate

Goal: Required review step before customer-facing communication is sent or initiated.

Review Gate Nodes:

AI Enrichment/Evaluation ──▶ [Gate] Researcher Review (can adjust/re-trigger)
                                        │
AI Communication Plan ────▶ [Gate] Scheduler Review (email/voice/timing/follow-up/escalation)
                                        │
Customer-facing Comm ────▶ [Gate] Human Review Gate (required before sending)
                                        │
Handoff Package ─────────▶ [Gate] Confirm handoff package completeness

6.8 F-07: Structured Handoff Package

Goal: Track approved email and voice communications, generate structured handoff packages for Sales.

Handoff Package Structure (from Charter):

┌──────────────────────────────────────────┐
│       Structured Handoff Package          │
├──────────────────────────────────────────┤
│ 1. Project Context                        │
│    - Project name, address, type           │
│    - Owner/GC information                  │
│                                          │
│ 2. Enrichment                             │
│    - AI enrichment + Researcher edits      │
│    - Contacts, company information        │
│                                          │
│ 3. Qualification Result                   │
│    - Qualification context                │
│    - Product fit                          │
│    - Confidence indicators                │
│    - Priority                             │
│                                          │
│ 4. Outreach Activity                      │
│    - Approved email/voice communication   │
│    - Communication plan & execution status│
│                                          │
│ 5. Response Status                        │
│    - Customer response records            │
│    - Follow-up status                     │
│                                          │
│ 6. Scheduling Status                      │
│    - Meeting arrangement status           │
│    - Follow-up sequence progress          │
│                                          │
│ 7. Open Questions                         │
│    - Items to be confirmed                │
│    - Risk alerts                          │
└──────────────────────────────────────────┘

6.9 F-08: Reporting & Visibility

Goal: Initial dashboard showing opportunity volume, workflow status, cycle time, blocked items, completed tasks, and human review rate.

6.10 F-09: Pilot Enablement

Goal: Training and feedback loop for initial Researcher and Scheduler users.

6.11 F-10: Workflow Status Tracking

Goal: Track research and scheduling work statuses with audit traceability.

Workflow Statuses (from Charter):

6.12 F-11: Notifications & Reminders

Goal: Basic notifications for overdue tasks, pending reviews, scheduling conflicts, and required human approvals.

7. Non-Functional Requirements

7.1 Performance

7.2 Availability

7.3 Security

7.4 Scalability

7.5 Compatibility

8. System Architecture Overview

8.1 Architecture Overview (from Charter)

┌─────────────────────────────────────────────────────────────────┐
│                        User Layer                                │
│    Researchers  |  Schedulers  |  Inside Sales Rep  |  PMs      │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────────────┐
│                   AI-first CRM Platform                          │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │              AI Agent Runtime                               │ │
│  │        (Isolated Docker Sandboxes)                          │ │
│  │   ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐        │ │
│  │   │ Data    │ │ Eval    │ │ Corres  │ │ Research│  ...    │ │
│  │   │ Ingest  │ │ Agent   │ │ pondence│ │ Agent   │        │ │
│  │   └─────────┘ └─────────┘ └─────────┘ └─────────┘        │ │
│  └──────────────────────────┬─────────────────────────────────┘ │
│                             │                                    │
│  ┌──────────────────────────▼─────────────────────────────────┐ │
│  │          CRM Core Operational Database                      │ │
│  │             (System of Record)                              │ │
│  └──────────────────────────┬─────────────────────────────────┘ │
│                             │                                    │
│  ┌──────────────────────────▼─────────────────────────────────┐ │
│  │              Operational Modules                            │ │
│  │   ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐          │ │
│  │   │Import│ │Filter│ │Enrich│ │Handoff│ │Report│          │ │
│  │   └──────┘ └──────┘ └──────┘ └──────┘ └──────┘          │ │
│  └──────────────────────────┬─────────────────────────────────┘ │
│                             │                                    │
│  ┌──────────────────────────▼─────────────────────────────────┐ │
│  │                    Data Layer                               │ │
│  │   Low Level Adapters | Data Warehousing | Analytics         │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │              Data Governance Layer                          │ │
│  │   Users | Accounts | Permissions | Standard Ingestion       │ │
│  │   Common API | Middleware | Analytics                       │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │              Agent Governance                               │ │
│  │      Agent lifecycle, behavior, and safety                  │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
│  ┌─────────────────┐  ┌─────────────────────────────────────┐  │
│  │ Phase 1 Scope   │  │ Future Phases (Not Yet in Phase)    │  │
│  │ (This Phase)    │  │ L0 Reviewer, Deal Coach, etc.       │  │
│  └─────────────────┘  └─────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

8.2 Architecture Layer Description

8.3 Architecture Principles

• AI-first — AI Agents drive workflows, humans make gating decisions
• Agent-assisted first — Phase 1 uses AI-assisted mode first, AI operates within working boundaries
• Security — Security across all layers
• Reusability — Phase 1 creates reusable workflow, data, and AI governance patterns
• Decision traceability — All Agent actions include decision trace and confidence indicators

8.4 Key Architecture Decisions (TBD in Solution Design)

9. Data Requirements

9.1 Core Data Entities

9.2 Data Retention Policy

10. AI / Agent Requirements

10.1 AI Agent Definitions

10.2 Agent Operating Modes (from Charter)

┌─────────────────────────────────────────────────┐
│         Agent-assisted Mode (Phase 1 Priority)   │
│  AI operates within working boundaries            │
│  AI provides suggestions/drafts → Human review    │
│  External communication requires approval         │
│  Humans handle exceptions, approvals, high-value  │
│  decisions                                        │
│  Applicable: Enrichment, evaluation, summaries,   │
│  communication plans, scheduling recommendations   │
├─────────────────────────────────────────────────┤
│         Agent-operated Mode                       │
│  AI executes autonomously → Notifies human        │
│  Applicable: Data import, filtering, enrichment,  │
│  status transitions                               │
├─────────────────────────────────────────────────┤
│         Human-gated Mode                          │
│  AI prepares → Human approval required to proceed │
│  Customer-facing communication must be reviewed   │
│  before sending                                   │
│  Applicable: Handoff package, customer-facing com │
└─────────────────────────────────────────────────┘

10.3 Agent Governance (from Charter)

• Agent lifecycle management — Creation, activation, suspension, termination
• Agent behavior management — Behavior boundary definition and monitoring
• Agent safety management — Security controls for Agent operations

10.4 Agent Authority Expansion Conditions (from Charter)

Agent authority will not expand unless quality, traceability, and review thresholds are documented and met.

10.5 AI Quality Requirements

10.6 AI Feedback Loop

AI Output ──▶ Human Review ──▶ Review Result
                                 │
                          ┌──────┴──────┐
                          │ Accept       │ Reject/Modify
                          │              │
                          ▼              ▼
                    Record positive  Record negative + correction
                          │              │
                          └──────┬───────┘
                                 │
                          Periodic model retraining / Prompt optimization

11. Integration Requirements

11.1 External System Integrations

11.2 Integration Constraints

From Charter: Integration feasibility and pilot readiness depend on source system capability, API maturity, and data quality.

From Charter: Existing source systems are expected to contain sufficient data quality for meaningful AI-assisted research outputs.

11.3 Integration Interface Specification

Dodge API Integration
├── Endpoint: [TBD]
├── Authentication: API Key
├── Frequency: Daily 02:00 UTC
├── Data Format: JSON
├── Error Handling: Retry 3 times, 5-minute interval
└── Alerting: Notify admin on 2 consecutive failures

ConstructConnect API Integration
├── Endpoint: [TBD]
├── Authentication: API Key
├── Frequency: Daily 03:00 UTC
├── Data Format: JSON
├── Error Handling: Retry 3 times, 5-minute interval
└── Alerting: Notify admin on 2 consecutive failures

12. Deliverables Mapping

12.1 Charter Deliverables to PRD Requirements Mapping (from Charter)

13. Milestones & Timeline

13.1 Milestone Overview (from Charter)

⚠️ Note: Charter Rev.1 (2026-07-09) has shortened the timeline. Specific shortened dates need to be confirmed with the latest charter version.

13.2 Phase 1 Module-Milestone Mapping

Jul (M2)          Aug (M3)           Sep (M4-M5)        Oct (M6-M7)
─────────────────────────────────────────────────────────────────────
F-01 Platform    ████████
F-02 Data Ingest ████████
F-10 Status Trk  ████████
F-03 Filtering             ████████
F-04 Enrich/Eval           ████████
F-05 Comm Plan             ████████
F-06 Human Gate            ████████
F-07 Handoff Pkg           ████████
F-08 Reporting                       ████████
F-09 Pilot Enable                    ████████
F-11 Notifications                   ████████
                                     UAT        Pilot     Stabilize

13.3 Dependencies (from Charter)

The project depends on: - Dodge and ConstructConnect data being available - Required system connections working - Right user access setup - AI outputs being tested before launch - Researchers and Schedulers completing testing and training

14. Assumptions, Constraints & Risks

14.1 Assumptions (from Charter, 12 items)

14.2 Constraints (from Charter, 7 items)

14.3 Risk Register (from Charter, 7 items)

15. Financial Information (from Charter)

15.1 Financial Assumptions

• Phase 1 expected to be delivered primarily using internal resources
• No additional external vendor or consultant support anticipated

15.2 Cost Estimate

15.3 Budget Approval

Budget approved by Director of Finance.

16. Acceptance Criteria

16.1 Functional Acceptance Criteria

Acceptance criteria for each functional requirement are defined in Section 6. Overall functional acceptance requires:

• All P0 requirements 100% implemented and tested
• All P1 requirements ≥ 90% implemented and tested
• P2 requirements delivered as feasible, not blocking go-live

16.2 UAT Acceptance Criteria

16.3 Go-Live Checklist

• [ ] All P0 functions passed UAT
• [ ] Performance metrics met (Section 7.1)
• [ ] Security review passed
• [ ] Data backup and recovery process verified
• [ ] Operations monitoring and alerting configured
• [ ] User manual and training materials ready
• [ ] Pilot user training completed
• [ ] Rollback plan ready
• [ ] End-to-end testing completed
• [ ] Defects addressed
• [ ] Go-live approval received

17. SOX / Internal Control Impact (from Charter)

17.1 Preliminary Classification

• Preliminary SOX/Internal Control Classification: No direct SOX, ERP replacement, revenue recognition, financial reporting, or financial close impact.

17.2 Control-Relevant Elements

Although no direct SOX impact, the project includes control-relevant elements:

17.3 Reassessment Conditions

If the project later expands to the following scope, SOX/control-impact classification must be reassessed: - Quote management - Revenue forecasting - ERP integration - Customer master data - Financial reporting - Automated commercial commitments

18. Glossary

19. Appendix

Appendix A: Charter Summary

• Organization: INTUS
• Project Name: GIGA CRM Phase I
• Approval Status: Approved (Evaluated 2026-06-23, Approved 2026-06-29)
• Revision: Rev.1 — 2026-07-09 (Timeline shortened)
• Product: AI Opportunity Platform
• Core Users: Researchers, Schedulers
• Data Sources: Dodge, ConstructConnect (only)
• Architecture: AI-first CRM (multi-phase roadmap, Phase 1 does not replace full CRM)
• Deliverables: 11 items (D-01 ~ D-11)
• Budget: $26,600 - $41,800 (internal resources)
• Charter Reference: https://chatgpt.com/share/e/6a3a7106-6070-8000-ba0f-51d1f37b67c9

Appendix B: Open Items

Appendix C: Requirements Traceability Matrix Template

End of Document

This PRD is Draft v0.2, revised based on verbatim reading of the charter images. It requires the following process before finalization: 1. Business review — Confirm scope and priorities 2. Architect review — Confirm technical feasibility 3. Development team review — Confirm implementation approach 4. Project manager approval — Confirm schedule and resources 5. Final release — v1.0 Baseline

Generated from GIGA_CRM_PRD_Framework_v0.1_EN.md — Deployed on Cloudflare Pages