# Customer Success Platform (CSP) 需求分析总纲

| 项目 | 内容 |
|---|---|
| 文档名称 | CSP 需求分析总纲（Index） |
| 版本 | v3.0（Draft） |
| 作者 | jinchun.chen |
| 创建/更新 | 2026-07-21 |
| 状态 | 结构已对齐，逐模块深挖中 |
| 前置资料 | Feishu Wiki：《系统需求》草稿；《Customer Success Hub》及其子文档——Roles & Responsibilities、Overall Workflow、SOP、Service Packages、TAM vs PS、APAC PS/CSM/Alliance Sales、Premium Support Kick-Off、Onboarding、Sales & PS Collaboration Guide、TAM Owner Handover 模板、Project Management / FRM·Bug / Incident（多维表格） |

> **本文档为总纲/索引**：仅保留平台定位、角色、模块地图与各模块概要信息。
> **文档分层约定（四层，英文缩写对齐）**：
> - **PRD**（`requirements/Mx-*.md`）= 产品需求，What/Why：目标/规则/FR/验收。
> - **FSD**（`fsd/Mx-*-FSD.md`）= 功能设计，功能如何运转：页面/字段级/交互/异常/权限/用例（见 [FSD 模板](fsd/FSD-模板.md)）。
> - **LDD**（`ldd/Mx-*.md`）= **逻辑设计（Logical Design，数据与机制，逻辑层非物理）**：数据模型/状态机/机制/算法口径/默认配置/集成映射 + `ldd/数据字典.md`（字段单一事实源）。
> - **SDD**（技术设计，Software/System Design：架构/物理库表 DDL/API 契约/部署/安全）——**留待将来另开 `docs/sdd/`，本仓库尚未开始**。
>
> 链路 **PRD → FSD → LDD → SDD**；FSD/LDD 均为"How"但切面不同（FSD=功能面、LDD=数据机制面），FSD 引用 LDD 与数据字典、不复制。各层互链，改单模块只改对应文档。

**修订记录**

| 版本 | 日期 | 说明 |
|---|---|---|
| v0.1–v1.1 | 2026-07-20/21 | 初稿演进至 5 域 10 模块总纲；确立合同/订单模型 |
| v1.2 | 2026-07-21 | 文档解耦：总纲保留模块地图与索引，模块详情拆至 `requirements/`，统一归入 `docs/` |
| v1.3 | 2026-07-21 | 术语与角色规范化：域名采用 TAM/CSM/PS 国际标准；新增 TAM Leader，Resident Engineer 并入 PSE；M3 更名为客户生命周期管理 |
| v1.4 | 2026-07-21 | 对齐 CS 内部 Wiki：新增 M11 客户之声与满意度、M12 支持与研发协同；确认上游为 Nexus CRM；支持/事故/FRM/Bug/知识库定为集成聚合；纳入 Region、客户分层、Customer Stage 维度 |
| v1.5 | 2026-07-21 | 业界标准化：新增 Customer Success Director；规范 TAM 职责；M3 采用标准生命周期阶段；PS 补齐标准交付链路（范围界定、变更控制、知识移交） |
| v1.6 | 2026-07-21 | 明确系统上下文集成数据源（Nexus CRM / TiDB Support / Ops）；重排集成表 |
| v1.7 | 2026-07-21 | 工作类型改按对客形式划分；访问端扩为多端 + 开放 API；细化 AI Agent 用途；M11 归为平台级；PS 域补范围界定与 burn 跟踪 |
| v1.8 | 2026-07-21 | 业界对标补缺：干系人图谱、用量/采用、Success Plan、留存分析、技能派单、RAID、KPI 体系、用户供给、全局搜索、客户门户；PS 财务列为后期 |
| v1.9 | 2026-07-21 | 前置资料补全；背景痛点结构化（信息碎片化、缺统一流程管控等）；范围分域分行对齐模块；系统上下文修正（"触达"改为发送通知/消息、AI Agent 重定位为未来协作而非下游）；模块地图"目标"纳入新增能力；数据模型对齐 TAM Scope 与新增实体；Ops 明确为读+动作双向、新增动作类集成（INT-10）；补 OQ-S8/S9 |
| v2.0 | 2026-07-21 | 逐项处理待确认：关闭 13 项（含 Nexus 无事件推送→定时轮询、交付 CSP 自建 Jira 只读、多角色并集、逻辑隔离等）；新增 FR-ENG-10 主动观测/纳管提醒、FR-SUP-08 代客建单、NFR-11 模块化/可插拔；M5 起草续约流程与 CSM 职责草案；OQ-S8/S9 出讨论稿（docs/ldd/）；剩余项均标注处置 |
| v2.1 | 2026-07-21 | 剩余项二次梳理：Alliance Sales/SOP 移出范围；新增 FR-APR-05 权益审批 ARR 驱动核定；M3 默认 Onboarding 清单、M4 默认 Playbook 清单起草；OQ-P7/S3 标注进详设对接、OQ-S8/S9 挂起待专题 |
| v2.2 | 2026-07-21 | RE 区分（RE 工程师随付费 Package 保留，仅去掉 ARR>5M 自动赠送权益）；引用块统一分行；M4 新增 FR-ENG-11 风险登记册（竞品/价格/负面声音等）与 FR-ENG-12 自动风险线索；新增 §2.4 架构原则（模块解耦 + 平台共有服务清单），强化 NFR-11 |
| v2.3 | 2026-07-22 | M3 新增 **TAM 交接（Handover）编排**（FR-LC-06）与**可配交接 Checklist**（FR-LC-07，含双方签字，源自 TAM Owner Handover 模板）；数据模型加 Handover 实体 |
| v2.4 | 2026-07-22 | 新增 §2.5 需求建模四维（实体·事件·流程·结果），作为各模块深挖的统一分析视角 |
| v2.5 | 2026-07-22 | 新增 §2.6 需求完整性检查 5W2H（映射到已有要素）；与 2.5 互补；点明 Why/How much 最易缺，评审重点核对 |
| v2.6 | 2026-07-22 | 移除 §2.5 四维 / §2.6 5W2H 方法论小节——二者作为**内部分析纪律**（保证需求严谨、不漏 Why/度量），不作为文档内容；文档只留需求 |
| v2.7 | 2026-07-22 | 新增 **M13 流程与资源中心**（域 E）：汇总 CS 常用的非 CS 公司流程/资源（Training/Exam Voucher 等），指向飞书 Wiki + 引导式申请，可持续加条目；模块数 12→13 |
| v2.8 | 2026-07-22 | M6 交付工作流重构为 **Milestone 关卡链**（核心模型）：每关卡=模板文档+Signoff+进出条件、驳回返工（D-P11/FR-PROJ-15/16）；签署分内审/客户可配（D-P12/FR-PROJ-17）；补 Kickoff 关卡、端到端流程表 |
| v2.9 | 2026-07-27 | **需求/设计分离**：全部 13 模块拆为 `requirements/`（What：目标/规则/FR/验收）+ `ldd/`（How：数据模型/状态机/机制/默认配置/集成映射），两侧互链、各需求文档补验收标准；§6 保留为概念级 ER；确立文档分层约定 |
| v3.0 | 2026-07-27 | **PS 交付集群深挖收口**：M6 定 依赖仅项目内/挂起规则(PM·PS Leader+归因+停表)/Jira 历史一次性迁移；M7 定 技能画像CSP内维护/产能可配默认/预测源=Sales pipeline+backlog；M8 定 客户签署可配(默认轻量·重要第三方)/归档集成飞书 Wiki；M7、M8 升 ✅ |
| v2.9 | 2026-07-27 | M6 行业对标补全：**两种交付模式**（项目型/持续型 Assurance，D-P13/FR-PROJ-18）；六个 Package **预设 Milestone 链草案**；新增 项目健康 RAG+状态报告、EAC 完工预测+基线、客户协作/门户、交付后 CSAT（FR-PROJ-19~22）；加交付流程图 |
| v4.0 | 2026-09-07 | **Order 实体退场、以 Contract 为主**：立项授权单位 = **PS_Service 合同**（Paid 真实 / Sponsored·Dedicated·Exceptional 虚拟）；**不再出 Order / Virtual Order**。立项 = **选客户 + 绑定其一份 `remaining>0` 的 Quota**（Dedicated `unlimited` 恒满足）；一份合同可含多个 Service Package，**范围由 SOW 约定、不独立切预算**、共用合同 Quota 池；Service Package 降为**项目的服务类型属性**、不出订单；Nexus 同步 Order → 同步 Contract。正文/术语/约束/DFD 等**现行表述**同步改为 Contract/Quota 口径（历史 changelog 事实保留原文、靠本条纠正）。基准见 M1 D-C11/FR-CUST-08a、数据字典 Project/Quota |
| v3.9 | 2026-09-07 | **统一 PS 项目/额度模型（修正 T1、"Free Quota"改名）**：**任何 PS 工作都基于项目、每项目都有 Quota**；Quota = `source`（Paid/Sponsored/Dedicated）× `amount`（finite/unlimited）；项目工时**一律 draw-down**——finite 跟踪 remaining+预警、**unlimited(Dedicated) 照记 used 不预警**（取消原"持续型无池不扣"特例）。TimeEntry 挂载简化为 项目/经营/内部（工时记在实际做的事上；去掉 T1 一度多造的"Dedicated Support"类）。Order：Paid/Sponsored 出、**Dedicated 虚拟合同+triage 不出**。**"Free Quota"全库改名 Sponsored（赠予：免费+Justification+酌情核定）**；Dedicated 无正式 PS Contract → 虚拟合同兜底 + `pending_formalization` 提醒补签、不阻断交付（M1 D-C11/D-C13、数据字典 Quota/Contract、M6/M7、总纲 §2/§6） |
| v3.8 | 2026-09-07 | **需求回归评审修复（T1–T8 收口）**：① 工时/额度 `billable`(计投入=项目/Dedicated/经营) 与 **Man-days 消耗(仅挂载=项目;Sponsored=免费 Man-days)** 两维正交、工时=平台级 Plugin/工时挂载(项目/经营/内部)；② 数据字典补 SuccessPlan/OnboardingChecklist/ARRSnapshot/Review/TimeEntry.activity_type/Contract.amount·arr 等（决策：资源协调走 M9 Request、各模块自建轻量 todo、ARR 周期快照）；③ M2 权限基座落地（角色对齐 §1.4、PM=项目指派/Manager=Leader+Region、RBAC 动作字典+基线矩阵、ABAC 补全、权限每请求解析）；④ M11 问卷=全自建引擎、M4 健康度降级策略、M12 OQ-S3 进详设分期；⑤ OQ-S4/OQ-C2 状态同步 + level≠tier；⑥ 单一「平台通知服务」；⑦ M10 草稿本期=模板槽位填充(非 AI)；⑧ 触达率→系统触发率+回执、360° 8/8 固定、入库 5/5、arr_input 防套利。详见 [回归评审发现](回归评审发现.md) |
| v3.7 | 2026-09-01 | **命名理顺**：`design/` 正名为 **LDD 逻辑设计**（Logical Design，数据与机制层）并**物理重命名文件夹 `design/`→`ldd/`**（全库链接与 13 份文档头部同步）；"**SDD**" 词专留给将来的**技术设计层**（架构/物理库表/API/部署，`docs/sdd/`，尚未开始）；四层链路明确为 **PRD → FSD → LDD → SDD** |
| v3.6 | 2026-09-01 | **启动 FSD 层**：确立四层文档（PRD→FSD→设计→数据字典）；[FSD 模板](fsd/FSD-模板.md) 对标 BlueprintOS 示例的**逐功能颗粒度**（每功能 7 小节：功能说明/业务流程/界面/字段定义(校验+来源+可编辑)/业务规则/异常(带文案)/权限）；**每模块三件套**：`Mx-*-FSD.md` + `业务流程图-Mx.txt`(状态流转+泳道) + `测试用例-Mx.md`(正常/边界/异常)；**M1 完整样板**已出（7 功能全 + 流程图 + 用例）。字段用逻辑类型，物理类型留待 SDD |
| v3.5 | 2026-09-01 | **吸收同事《Premium Support 交付流程平台化》MVP 文档**（比对确认绝大部分已覆盖，且更全）：新增 M1 FR-CUST-14 **Cluster 一等对象**、M4 FR-ENG-13 **客户事项采集与证据链（Issue/Todo，并入经营活动，本期手动+手工贴源）**、M4 FR-ENG-11 加 **风险客户可见标记**、M10 FR-RPT-09 扩到 **Kickoff/RCA/QBR 草稿生成**；M3 §2 标注为 Premium 专属 Onboarding+支持通道预设；数据字典补 Cluster、Risk.is_customer_visible、Issue/Todo |
| v3.4 | 2026-07-27 | **交付连续性/备份**：M6 每项目**必配 Secondary（备份负责人）**（D-P15/FR-PROJ-25）——Secondary 自立项起为参与者、订阅周 Check-in 保持"热备"，休假经 coverage 委托、计划外由 PS Leader 改派；M9 新增 **缺席委托 FR-APR-06（Out-of-Office，共有能力）**；数据字典补 Project.secondary_owner/coverage、Delegation 实体 |
| v3.3 | 2026-07-27 | **M6 持续型管控 + 项目周更**：D-P14 持续型立项由 **TAM/PS Leader 经 Engagement Request triage** 把关（需求驱动、工程师无立项权）；FR-PROJ-23 立项把关 + 通用桶窄化/侦测兜底、M7 FR-RES-10 工时活动分流（运维型/交付型必挂项目）；FR-PROJ-24 **项目周期状态更新（Check-in）**——每周期一条结构化记录替代单字段累积、cadence 自动待办+提醒、周会看板/报表；数据字典补 StatusUpdate/EngagementRequest |
| v3.2 | 2026-07-27 | **M6 立项准入松绑**：硬约束由「必须有 Order」改为「必须绑定**额度/授权来源**（项目型=Order；持续型/Dedicated=既有 retainer 合同）」；持续型固定 retainer **只记工时不做 Man-days draw-down 结算**、同一 retainer 可派生多个 Service Package 项目、超范围触发扩购（D-P1/FR-PROJ-01/18、总纲 §6 与关键约束、M6 设计同步） |
| v3.1 | 2026-07-27 | **方法论补强**：新增 §4.1 需求追溯（痛点→模块→验收/设计）、§4.2 多维优先级（价值/难度/风险，BABOK 视角）、§6.1 Level-0 DFD 数据流图、§10 需求变更管理；新建集中**数据字典**（`ldd/数据字典.md`，28 实体）；13 模块验收标准全部改为**可度量/可判定**（具体数值统一标"待业务确认"） |

---

## 1. 引言

### 1.1 目的
定义 CSP 的功能与非功能需求基线。本文档为**总纲**，负责平台定位、角色、模块划分与索引；细粒度需求在各模块文档中固化。

### 1.2 背景与痛点
PingCAP 的 **Customer Success（CS）组织**（含 **TAM、PS、CSM** 三个部门）当前主要痛点：
- **信息碎片化**：客户信息、事件、项目、交付物散落在 CRM、表格、文档与多个工具中，无统一客户视图。
- **缺少统一流程管控**：Onboarding、交付、审批、续约等流程无系统承载，依赖人工，难以标准化与追踪。
- **额度与投入不透明**：PS 项目与 Man-days 消耗、团队投入难以实时归集。
- **交付与签署难追溯**：交付物版本与客户签署缺乏留痕。
- **风险与续约靠人脑**：健康度、风险、续约到期缺乏预警。

CSP 目标：**以「客户」为主线，把三个角色的工作收拢到统一平台**——TAM 经营客户、PS 交付项目、CSM 管合同续约，管理层一屏掌握状态。品类为 **Customer Success 平台 + PSA 融合**。

### 1.3 范围

**In Scope（本期）** —— 对应 6 域 12 模块：
- 域 A 基座：客户主数据与 360°（M1）、用户/角色/权限（M2）
- 域 B TAM：客户生命周期管理（M3）、经营活动/健康度/风险（M4）
- 域 C CSM：合同与续约（M5）
- 域 D PS：Service Package 交付（M6）、工时与资源（M7）、交付物与签署（M8）
- 域 E 平台通用：审批与流程引擎（M9）、Dashboard 与报表（M10）、客户之声与满意度（M11）
- 域 F 客户支持：支持与研发协同（集成聚合）（M12）

**Out of Scope（本期）**：
- Nexus CRM 反向写入
- 替代 IM / 邮件
- Slack 多 IM、BI/数仓导出（后续按需）
- **Alliance Sales、SOP**（不在本平台范围）
- **ARR>5M 自动赠送/配备专属 Resident Engineer 的权益场景**（暂不做；RE 工程师仍可随付费 Service Package #6 提供）

**记录需求、后期开发**：
- PS 项目财务（成本/毛利/收入确认/开票）

### 1.4 角色（Persona）与职责
> 依据《TAM vs PS》文档 + CSM 补充。

| 角色 | 定位 | 核心职责 |
|---|---|---|
| **Customer Success Director** | CS 组织负责人 | 统管 TAM/PS/CSM，主导 CSC 治理、资源与优先级决策、整体客户成功目标与度量 |
| **TAM** | 客户的**指定技术顾问、技术成功单一责任人** | 拥有技术关系与客户架构认知（可信顾问）；主动指导（架构评审/健康检查/优化）；升级管理（协调 Support/Eng）；驱动采用与价值实现；QBR/EBR 业务评审；内部编排 + 客户代言；路线图对齐与需求反哺；风险/流失防控（**不亲自交付、不拥有商务**） |
| **TAM Leader** | TAM 负责人 | TAM 团队管理、客户分配、经营质量把关、跨团队协调 |
| **PSE** | Professional Service Engineer，产品交付专家 | 实施部署、性能调优、迁移升级、培训、咨询、疑难排查；PS_Service 合同（Quota）驱动的 Service Package 交付（含**驻场 Resident Engineer** 工作模式，随付费 Service Package 提供） |
| **PS Leader** | PS 负责人 | 定人天/报价、派单、把关交付 |
| **CSM** | 客户成功经理 | 客户关系、**合同与续约（Renewal）** |
| **Sales** | 客户全生命周期 owner | 驱动 CSG 组建、ARR/续约/扩展目标、发起 Sponsored/立项 |
| **SA / Presale** | 方案工程师 | PoC/benchmark、架构评审 |
| **Admin / Ops** | 平台治理 / 下游运营 | 角色权限、模板、流程配置 / 消费 CSP 数据 |
| **Customer（External）** | 客户侧 | 受限只读、交付物签署 |

> **角色不写死**：以上为主要角色；系统须支持**角色随时新增、权限可配**（见 M2）。其余组织角色作为**预留/可配示例**，非本期主建模：Global Support（GS L1/L2/OnCall）、Engineering/PM（EG）、Advocate、CSC 客户成功委员会（治理层）。Resident Engineer 是 PSE 的一种工作模式（随付费 Service Package 提供），非独立角色。**PM = 项目级负责人指派（非全局角色）；Manager = Leader 角色（TAM Leader/PS Leader/CS Director）+ Region 属性**（M2 T3）。（Alliance Sales、SOP 不在本平台范围。）

### 1.5 术语
| 术语 | 说明 |
|---|---|
| Customer Success (CS) | PingCAP 客户成功**组织**总称，含 TAM/PS/CSM 三部门；CSP 服务整个 CS 组织 |
| Nexus CRM | PingCAP 自研 CRM，上游客户/合同数据来源 |
| Level / Technical Support Level | CRM 字段：**Level** = 战略分层（KA/SKA…）；**Technical Support Level** = 服务等级（= Support Plan，如 Premium） |
| JSM Org ID | CRM 字段：关联 TiDB Support（Jira/JSM）的组织键，用于聚合该客户工单（M12） |
| Service Package | 标准化 PS 交付包（6 类，见 M6），交付项目的类型 |
| ~~Order~~（已废除）/ SOW | **Order 实体已退场**——立项授权单位改为 **PS_Service 合同**（见 Contract、Quota 词条）；**SOW** = 工作说明书，约定一份合同下各 Service Package 的交付范围（不独立切预算、共用合同 Quota 池） |
| Contract | 三类：Product（CSM）/ Premium_Support（TAM）/ PS_Service（PS，带 Man-days Quota）；source=nexus/virtual |
| Quota / Man-days | PS 项目的人天额度池（挂 PS_Service 合同、工时消耗）。**统一模型：任何 PS 工作都基于项目、都有人天额度**；差别只在额度的**来源**与**量** |
| Quota 来源 (source) | `Paid`（付费购买）/ `Sponsored`（赠予）/ `Dedicated`（大客户专属 PS retainer） |
| Quota 量 (amount) | 有限人天数，或 **Unlimited**（仅 Dedicated） |
| Sponsored（赞助额度） | **由 Sales/内部出资买单**（相当于 Sales 向 PS "采购"人天）、**赠予客户**；对客免费，但需 Sales/SA 出具 **Justification**、经**酌情审批核定**（原"Free Quota"，用词已更正为 Sponsored 以体现"内部赞助/买单"本质）；有限量、经虚拟 PS_Service 合同（Virtual Contract）授权发放 Quota |
| Dedicated PS / Regular Support | 大客户专属 PS（retainer，无正式 PS Contract 时用**虚拟合同**兜底、标 `pending_formalization`）；日常小问题 = **Regular Support**（对应 Service Package #6 Assurance/Resilience）；额度 source=Dedicated、amount=**Unlimited** |
| Engagement Activity | 客户经营活动（TAM/CSM 的持续性客户经营记录，如触点/答疑/Review） |
| Technical Account Management (TAM) | 技术客户经营职能（关系、健康度、生命周期照护），对应域 B |
| SuccessPlan / Playbook | 客户成功计划 / 可复用照护剧本 |
| Health Score / Renewal | 客户健康度评分 / 合同续约 |
| RBAC / ABAC | 基于角色 / 基于属性的访问控制 |

### 1.6 参考
- 内部：《系统需求》草稿、《Service Packages》及子文档、《TAM vs PS》
- 业界：Customer Success（Gainsight、Totango、Catalyst）；PSA（Kantata、Certinia）；PM（ClickUp、Jira、Asana/Monday）；工时（Harvest、Tempo）；知识（Confluence）

---

## 2. 系统概述

### 2.1 三条业务主线（都挂在同一「客户」上）
- **Technical Account Management（TAM）线**：贯穿**客户生命周期管理**——Onboarding（Kickoff/Success Plan/干系人梳理/建沟通渠道）→ Adoption（采用与赋能）→ Value Realization（价值实现/QBR）→ Renewal（续约准备）→ Expansion/Advocacy（增长/倡导）；全程健康度监控、风险与升级管理、技术评审与内部资源协调（Support/PS/SA/Product/Eng）、需求反哺产品。
- **Professional Service（PS）交付线**（标准 PSA 交付生命周期）：需求与范围界定 → 估算 & SOW/报价 → PS_Service 合同 + Quota（准入门禁：立项 = 选客户 + 绑定其一份 `remaining>0` 的 Quota）→ 资源配置/派单 → Kickoff/项目启动 → 执行与活动化工时 → 监控与变更控制（Change Request/进度/burn）→ 交付物验收/客户签署 → 项目关闭（结项报告）→ **知识沉淀与移交**（复盘入知识库 + 移交回 TAM/Support 持续经营）。
- **Customer Success Management（CSM）线**：合同管理 → 续约管道与预测 → 权益/扩购跟踪。

> PS 交付是客户生命周期中的一段**有界工程**，交付关闭后闭环回 TAM 线继续经营。

### 2.2 工作类型
工作类型按 **Customer Success 主要对客形式**划分为两类（工作性质划分，非组织分层；同一客户、同一人可同时涉及两类）：
- **经营（Engagement）**：TAM/CSM 的持续性客户经营（关系、健康度、QBR、生命周期管理、续约）。记工时但**不消耗 PS Man-days 额度**。
- **交付（Delivery）**：PS 的 Service Package 交付。**任何 PS 工作都基于项目、每项目都有人天额度（Quota）**；差别只在额度**来源**（Paid 付费 / Sponsored 赠予 / Dedicated 专属）与**量**（有限 / Unlimited）。记工时（billable，计投入）且**一律 draw-down 项目额度**——有限额度跟踪 used/remaining + 超支预警；**Dedicated 的 Unlimited 额度照记 used（成本）、不预警超支**。授权：立项单位 = **PS_Service 合同**（Paid 真实合同 / Sponsored·Dedicated 虚拟合同）；**立项 = 选客户 + 绑定其一份 `remaining>0` 的 Quota**（Dedicated `unlimited` 恒满足），不再出 Order。

### 2.3 系统上下文
CSP 从多个系统集成数据、以客户为主线聚合；通过多端供用户使用；经飞书向用户/客户发送通知与消息。与 AI Agent 的协作为未来方向（定位为协作方、非下游；思路待完善，另行讨论）。

```
┌──────────────── 集成数据源（读入 / 聚合）────────────────┐
│  Nexus CRM          → 客户基础数据（Account / Contact / Contract）
│  TiDB Support (Jira)→ 客户 Ticket、FRM、Bug 记录
│  Ops (ops.tidbcloud)→ 客户 Orgs、Clusters 信息
└───────────────────────────┬─────────────────────────────┘
                             │ 集成 / 同步 / 聚合
  访问端（统一 SSO）          │                         ┌─▶ 飞书 IM / 邮件（发送通知与消息）
   Web / 移动 App /          ┌┴───────────┐            │    · 通知/提醒：SLA/逾期/超支/缺报/续约临近 → M4·M7·M10
   飞书 App / 开放 API ◀交互▶│    CSP     │ ─发送──────┤    · 建群/日程：Onboarding 自动建客户群 → M3
                            └┬───────────┘            │    · 审批待办/加急：审批流、事故升级催办 → M9·M12
                             ┆                         └─▶ 飞书 Wiki（知识关联/索引）→ M8
                             ┆ 未来协作（待评估，非 CSP 下游）
                             ┄┄┄▶ AI Agent（设想，思路待完善，另行讨论）
                                   · Ticket 同步 → 智能分析、报告与建议
                                   · 新 Engagement 需求 → 流程/实施建议
```

> **集成定位**：客户基础数据以 **Nexus CRM** 为准；Ticket/FRM/Bug 真源在 **TiDB Support/Jira**；Orgs/Clusters 真源在 **Ops**。CSP 做集成聚合与统一呈现，不复制/替代这些系统；部分系统（如 Ops）支持 CSP **发起动作请求**（见 §7）。
>
> **访问端**：Web、移动 App、飞书 App、开放 API，统一走 SSO。
>
> **AI Agent（未来协作，非 CSP 下游）**：设想在 Ticket 同步、Engagement 需求等场景提供智能分析与建议；协作方式与可行性**另行讨论**，本期不落地。

### 2.4 架构原则：模块解耦与平台共有服务
- **高内聚、低耦合**：各功能模块尽量自治，模块间通过明确接口/事件协作，便于未来独立增改需求。
- **跨模块功能处理**：需求分析时**"该聚合聚合、该拆分拆分"**——单一职责能力归属唯一模块；被多模块复用的能力**沉淀为平台共有服务（Shared Services）**，业务模块通过接口消费，不各自重复实现。
- **平台共有服务（初步清单，随深挖细化）**：

| 共有服务 | 被谁复用 |
|---|---|
| 工作流/状态机引擎（可配） | M3 生命周期、M5 续约、M6 交付、M9 审批 |
| 审批中心 + Automations 规则引擎 | 全模块（M9 承载） |
| 通知/提醒服务（飞书/邮件） | 多模块触发（SLA/逾期/超支/续约…） |
| 事件/时间线服务 | 各模块事件 → M1 客户 360° |
| 配置中心（模板/自定义字段/角色/健康度模型/生命周期阶段/权益规则…） | 全模块（配置化基座） |
| 签署/文档服务（e-Signature） | M8 交付物、M1 虚拟合同、M6 报告 |
| 集成层（Nexus/Jira/Ops/飞书/Clinic/GitHub） | 全模块（见 §7） |
| 权益/资格引擎（ARR 驱动核定） | M1/M5/M7/M9 |
| 身份与权限（RBAC/ABAC）、全局搜索、审计 | 全模块（M2 + 平台） |

- **开放接口**：共有服务对内被模块复用、对外提供 API（NFR-09），支撑未来集成与 AI Agent 协作。
- **应用于后续**：每个模块深挖时，先判断某能力是"模块专有"还是"共有服务"，共有的归位到上表对应服务，避免重复与耦合。

---

## 3. 模块地图（6 域 · 13 模块）

| 域 | 模块 | 目标 | 主要角色 | 成熟度 | 详细文档 |
|---|---|---|---|---|---|
| **A 基座** | **M1 客户 360° 与主数据** | 统一客户档案与 360°；收口信息/事件/项目/交付物、干系人图谱、用量与采用 | 全员 | ✅ | [M1](requirements/M1-客户360与主数据.md) |
| | **M2 用户、角色与权限** | SSO、动态角色 + 可配数据可见性、用户供给 | Admin/全员 | 🟡 | [M2](requirements/M2-用户角色与权限.md) |
| **B Technical Account Management（TAM）** | **M3 客户生命周期管理** | 生命周期阶段编排（Onboarding 首阶段）+ TAM 交接（Handover） | TAM | ⚪ | [M3](requirements/M3-客户生命周期管理.md) |
| | **M4 经营活动、健康度与风险** | 触点/QBR、健康度、**风险登记与升级**、Success Plan、采用度、干系人经营、促活/资源协调 | TAM | ⚪ | [M4](requirements/M4-经营活动健康度与风险.md) |
| **C Customer Success Management（CSM）** | **M5 合同与续约（Renewal）** | 合同、续约管道与预测、留存（NRR/GRR）、白空间扩购 | CSM | ⚪ | [M5](requirements/M5-合同与续约.md) |
| **D Professional Service（PS）** | **M6 交付项目管理** | 两种模式：**项目型**（Milestone 关卡链，文档+签署门控）/ **持续型**（Assurance retainer） | PSE/PS Leader | ✅ | [M6](requirements/M6-交付项目管理.md) |
| | **M7 工时与资源管理** | 活动化工时、额度消耗、burn、产能/利用率、技能派单、需求预测 | PSE/PS Leader | ✅ | [M7](requirements/M7-工时与资源管理.md) |
| | **M8 交付物与签署** | 模板/版本/客户签署(可配)/归档(飞书Wiki) | PSE | ✅ | [M8](requirements/M8-交付物与签署.md) |
| **E 平台通用** | **M9 审批与流程引擎** | 统一 Request + Automations | 全员 | 🟡 | [M9](requirements/M9-审批与流程引擎.md) |
| | **M10 Dashboard 与报表** | 客户/项目/额度/续约/健康度看板、KPI 指标体系、高管视图、通知/定时报告 | 管理层/全员 | 🟡 | [M10](requirements/M10-Dashboard与报表.md) |
| | **M11 客户之声与满意度（NPS/CSAT）** | 满意度调研/机密结果/单一满意度视图（**自建，平台级**） | 全员 | ⚪ | [M11](requirements/M11-客户之声与满意度.md) |
| | **M13 流程与资源中心** | 汇总 CS 常用公司流程/资源，指向飞书 Wiki + 引导式申请（Voucher 等） | 全员/Admin | ⚪ | [M13](requirements/M13-流程与资源中心.md) |
| **F 客户支持（集成聚合）** | **M12 支持与研发协同** | Incident/SLA/FRM/Bug **集成聚合**到 360 与看板、喂健康度 | GS/EG/TAM | ⚪ | [M12](requirements/M12-客户支持与研发协同.md) |

> **成熟度**：✅ 已敲定关键决策｜🟡 已起草待细化｜⚪ 待专题深挖。
>
> **业界补充能力（已纳入）**：健康度评分（M4）、Playbook/成功计划（M3/M4）、续约管道与预测（M5）、风险/升级管理（M4）、满意度调研（M11）。
>
> **集成聚合原则**：M12 的支持/事故/FRM/Bug 与 M8 的知识库，系统真源在外部（tidb.support / Jira / GitHub / 飞书 Wiki），CSP 只做**集成 + 聚合呈现 + 联动**，不自建系统。
>
> **横切能力**：① 权益/资格引擎（ARR 门槛、Sponsored 分档，跨 M1/M5/M7）——配置化承载；例外（Exceptional Premium / Sponsored）走审批、**ARR 驱动核定上限**（M9 FR-APR-05）；数值待业务确认；② 外部集成层（见 §7）；③ CSG 虚拟团队 + CSC 治理（M2/M9）；④ **全局搜索**（跨客户/项目/工单/文档）；⑤ **客户门户**（外部自助：项目进度/签署/工单/满意度）。
>
> **一等维度**（贯穿主数据与权限）：**Region/APAC**（驱动数据范围）、**客户分层**（CRM 的 **Level**：KA/SKA…）**+ ARR 阈值**（驱动服务级别/Free 天数/是否配 TAM、组 CSG）、**Customer Stage**（生命周期阶段，原定义文档已失效需重建）；客户数据可见性**按情况可配**（ABAC）。

---

## 4. 模块信息（概要）

> 详细决策与功能需求见各模块文档。此处仅概要。

- **[M1 客户 360° 与主数据](requirements/M1-客户360与主数据.md)** ✅ — Nexus 单向同步、入库五触发、Contact CSP 维护、三类 Contract（Product/Premium_Support/PS_Service）+ 独立 Quota（Contract source: nexus/virtual）、虚拟合同可配置签署、客户 360° 与统一事件时间线。
- **[M2 用户、角色与权限](requirements/M2-用户角色与权限.md)** 🟡 — SSO（email 合并）、**角色动态可加、权限可配**（不写死）、RBAC（功能）+ ABAC（**数据可见性按情况可配**）；支撑 CSG 虚拟团队与 Region 维度。
- **[M3 客户生命周期管理](requirements/M3-客户生命周期管理.md)** ⚪ — 生命周期阶段编排（Onboarding 首阶段 → Adoption → Value → Renewal → …）；**TAM 交接（Handover）**：归属变更触发流程 + 可配 Checklist + 双方签字。
- **[M4 经营活动、健康度与风险](requirements/M4-经营活动健康度与风险.md)** ⚪ — 经营活动、QBR、健康度评分、风险/升级、Playbook、促活/资源协调。
- **[M5 合同与续约](requirements/M5-合同与续约.md)** ⚪ — Product Contract 视图、续约管道与预测、续约提醒。
- **[M6 交付项目管理](requirements/M6-交付项目管理.md)** ✅ — 交付须绑定 PS_Service 合同的一份 `remaining>0` Quota（立项 = 选客户 + 绑定 Quota；持续型 Dedicated = `unlimited` 虚拟合同池）、6 类 Service Package；**两种模式**：项目型（**Milestone 关卡链**：模板文档+Signoff+进出条件、驳回返工、签署分内审/客户）与持续型（Assurance retainer+事件工单+周期报告）；含 SOW、派单/Kickoff、变更控制、RAID、健康 RAG/状态报告、EAC/基线、客户协作、交付后 CSAT、CLOSED、移交回 TAM。
- **[M7 工时与资源管理](requirements/M7-工时与资源管理.md)** ✅ — 平台级工时（Plugin）、工时挂载(项目/经营/内部)、billable 计投入、项目 Man-days 消耗、1 人天=8h、超支软预警、产能/利用率/Workload、技能派单（CSP 内维护）、需求预测（Sales pipeline + backlog）。
- **[M8 交付物与签署](requirements/M8-交付物与签署.md)** ✅ — 模板、版本、审核流、**客户签署（可配：默认平台内轻量 / 重要可第三方电子签名）**、归档到**飞书 Wiki**、Proofing。
- **[M9 审批与流程引擎](requirements/M9-审批与流程引擎.md)** 🟡 — 统一 Request、可配审批链、Automations。
- **[M10 Dashboard 与报表](requirements/M10-Dashboard与报表.md)** 🟡 — 客户/项目/额度/续约看板、风险池、可配 Dashboard、通知/SLA。
- **[M11 客户之声与满意度](requirements/M11-客户之声与满意度.md)** ⚪ — **平台级、自建** NPS/CSAT 调研：问卷发放/回收/分析、机密结果字段级可见性、单一满意度视图；喂 M4 健康度。
- **[M12 支持与研发协同](requirements/M12-客户支持与研发协同.md)** ⚪ — **集成聚合**（不自建）：tidb.support 的 Incident/SLA、Jira 的 FRM/工单、GitHub 的 Bug、告警 bot；聚合到客户 360/看板并作为健康度风险输入。
- **[M13 流程与资源中心](requirements/M13-流程与资源中心.md)** ⚪ — 汇总 CS 员工常用的**公司流程/资源**（非 CS 业务，如 Training/Exam Voucher），指向飞书 Wiki 说明 + **引导式申请**；可持续加条目。

### 4.1 需求追溯（痛点 → 模块 → 验收/设计）
> 建立自上而下的可追溯链：**痛点（§1.2）→ 承载模块与关键 FR → 验收标准 → 设计文档**。逐条 FR 的「需求→验收→设计」追溯由各模块文档结构保证（FR 与验收标准同文、设计文档反链）；本表给出痛点到模块的顶层映射。

| 痛点（§1.2） | 主要承载模块 | 关键 FR（示例） |
|---|---|---|
| 信息碎片化 | M1 客户360/时间线、M12 支持聚合、M13 资源中心 | FR-CUST-09/10、FR-SUP-01~04、FR-HUB-01 |
| 缺少统一流程管控 | M3 生命周期/Onboarding、M6 交付、M9 审批、M5 续约 | FR-LC-01/02/06、FR-PROJ 全流程、FR-APR-01/02、FR-REN-08 |
| 额度与投入不透明 | M1 Quota、M7 工时、M10 报表 | FR-CUST-08、FR-RES-02/03/08、FR-RPT-03 |
| 交付与签署难追溯 | M8 交付物签署、M6 关卡签署 | FR-DEL-02/03/04、FR-PROJ 关卡签署 |
| 风险与续约靠人脑 | M4 健康度/风险、M5 续约、M10 预警看板 | FR-ENG-03/04/11/12、FR-REN-03/04、FR-RPT-01/06 |

### 4.2 优先级（P 级 + 价值/难度/风险，BABOK 视角）
> 各模块文档 FR 表已标 **P0/P1/P2**（交付优先级）。此处补**模块级多维初评**（价值/实施难度/交付风险，高/中/低），支撑排期与分批。**为初评，待业务校准**。

| 模块 | 业务价值 | 实施难度 | 交付风险 | 建议批次 |
|---|---|---|---|---|
| M1 客户360与主数据 | 高 | 中 | 中 | 1（基座） |
| M2 用户角色与权限 | 高 | 中 | 中 | 1（基座） |
| M9 审批与流程引擎 | 高 | 中 | 中 | 1（共有服务） |
| M6 交付项目管理 | 高 | 高 | 中 | 1–2 |
| M7 工时与资源管理 | 高 | 中 | 中 | 2 |
| M8 交付物与签署 | 中 | 中 | 低 | 2 |
| M3 客户生命周期管理 | 高 | 中 | 中 | 2 |
| M4 经营活动、健康度与风险 | 高 | 高 | 中 | 2–3 |
| M5 合同与续约 | 高 | 中 | 中 | 2–3 |
| M10 Dashboard 与报表 | 中 | 中 | 低 | 3（依赖各模块数据） |
| M11 客户之声与满意度 | 中 | 中 | 低 | 3 |
| M12 支持与研发协同 | 中 | 高 | 高（外部集成依赖） | 3 |
| M13 流程与资源中心 | 中 | 低 | 低 | 3 |

---

## 5. 非功能需求（NFR）
| 编号 | 类别 | 需求 |
|---|---|---|
| NFR-01 | 性能 | 常用页面 P95 < 2s；额度/工时汇总延迟 < 1 天。 |
| NFR-02 | 可用性 | 核心服务 ≥ 99.5%；关键写操作幂等。 |
| NFR-03 | 安全 | 全站 HTTPS；敏感字段加密；最小权限；越权拦截。 |
| NFR-04 | 审计 | 工时修改、依赖 override、状态流转、权限变更、审批、签署全量审计。 |
| NFR-05 | 可扩展 | 模板、工作流、审批链、权限策略、健康度模型均**配置化**。 |
| NFR-06 | 集成 | Nexus CRM、SSO、飞书、Jira、OPS 集成具备失败重试与告警。 |
| NFR-07 | 数据一致性 | 工时→Man-days→额度 口径唯一、可对账。 |
| NFR-08 | 国际化 | 中英文；时区按用户设置（Service Package 工作时段 9:00–18:00 本地）。 |
| NFR-09 | 多端与开放性 | 支持 Web、移动 App、飞书 App 多端访问（统一 SSO）；提供**开放 API**，供集成与未来 AI Agent 调用。 |
| NFR-10 | 合规/数据驻留 | 本期采用**逻辑隔离**（单实例 + Region 字段 + ABAC）实现按区域数据可见性；物理分区域部署列为后续。 |
| NFR-11 | 模块化/解耦/可插拔 | 模块高内聚低耦合、经接口/事件协作；共性能力沉淀为**平台共有服务**（见 2.4）；部分功能（如工时/Time）可**解耦为独立 App/Plugin**（类比 Tempo），支持独立演进与集成。 |

---

## 6. 数据模型（全局概念，随模块深挖细化）
> 此处为概念级 ER；**字段级明细汇总见集中[数据字典](ldd/数据字典.md)**（单一事实源，随各模块设计细化）。
```
== 基座（M1/M2）==
Customer 1──* Contact（含 影响力/态度/关系 → 干系人图谱）
Customer *──* User(TAM/CSM)
Customer 1──* Contract(type:Product|Premium_Support|PS_Service; source:nexus|virtual)
Contract(PS_Service) 1──* Quota                       （合同发额度池；一份合同可含多个 Service Package，范围由 SOW 约定、共用 Quota 池）
Contract ──▶ signed_by_contact_id → Contact          （虚拟合同签署，可配置）
Customer 1──* UsageMetric(orgs/clusters/adoption)     （用量/采用，来自 Ops/遥测）

== TAM 经营（M3/M4，无交付合同/额度）==
Customer 1──* LifecycleStage(Onboarding→Adoption→Value Realization→Renewal→Expansion→Advocacy)
Customer 1──* EngagementActivity *──1 User            （记工时，不耗额度）
Customer 1──1 HealthScore(inputs: 用量/支持/满意度/参与)
Customer 1──* Risk(type:竞品/价格/负面声音/…; 缓解措施; 状态) → Escalation（严重时）
Customer 1──* SuccessPlan ；SuccessPlan 1──* Objective ；SuccessPlan 1──* PlaybookTask
Customer 1──* ResourceCoordinationRequest → (Support/PS/SA/Product/Eng)   （内部协调）
Customer 1──* ProductFeedback → 产品/研发             （需求反哺）
Customer 1──* Handover(checklist, from_TAM, to_TAM, signoff)   （TAM 归属变更触发，M3）

== CSM 商业（M5）==
Contract(Product) 1──* Renewal ；Customer ── RetentionMetric(NRR/GRR/churn)

== PS 交付（M6/M7/M8，绑 PS_Service 合同的 Quota）==
Contract(PS_Service) 1──* Quota *──* Project(service_package, mode)   （ProjectQuota M:N 限同客户；立项 = 选客户 + 绑定其一份 remaining>0 的 Quota；Dedicated=unlimited 虚拟合同池）
Project 1──* Milestone 1──* Task 1──* Sub-task        （严格三层）
Project 1──* RAID(Risk/Issue/Assumption/Dependency)
TimeEntry *──1 User(skill) ；TimeEntry ──▶ (Task|Project) [billable?]   （活动化，消耗 Quota）
Project 1──* Deliverable 1──* DeliverableVersion       （含客户签署 Report）

== 平台通用（M9/M10/M11/M12）==
User *──* Role *──* Permission（RBAC）；User/Role ── DataScopePolicy（ABAC）
Request *──1 (任意业务对象) 1──* ApprovalStep
Customer 1──* Survey 1──* SurveyResponse(NPS/CSAT)     （M11 客户之声，机密可见性）
Customer ◀─聚合─ Ticket/Incident/FRM/Bug（外部真源）   （M12 集成聚合）
```
**关键约束**：**每个 PS 项目都有人天额度（Quota：来源 Paid/Sponsored/Dedicated × 量 有限/Unlimited）+ 一个 Service Package**；经营工时不消耗额度；**项目工时一律 draw-down 项目额度（消耗=Σ项目 TimeEntry、单向汇总不可手改）——有限额度跟踪 used/remaining，Dedicated 的 Unlimited 照记 used 不预警**；Contract 有 source（nexus/virtual），无正式 PS Contract 的 Dedicated 用虚拟合同兜底（标 pending_formalization）；授权：立项单位 = PS_Service 合同（Paid 真实 / Sponsored·Dedicated 虚拟）、立项 = 选客户 + 绑定其一份 remaining>0 的 Quota（Dedicated unlimited 恒满足）、不再出 Order；DAG 禁环；签署版本不可变；Nexus 失效不删仅提醒；User 以 email 跨 SSO 合并。

### 6.1 数据流图（DFD, Level-0）
> 从数据流视角刻画 CSP 与外部真源、核心处理过程、数据存储、使用者之间的流动（ER 描述"数据长什么样"，DFD 描述"数据怎么流"）。外部系统均为**只读来源**，仅 INT-02/INT-10 有受控写路径（代客建单 / Ops 动作）。

```mermaid
flowchart LR
  Nexus[Nexus CRM]:::ext
  Ops[Ops / Clinic 遥测]:::ext
  Jira["tidb.support(Jira) / GitHub"]:::ext
  Lark[飞书 Wiki / 通知]:::ext
  Users((TAM/PS/CSM/管理层/客户)):::actor

  Nexus -->|轮询·变化检测·对账| P1[P1 主数据同步收口]
  Ops -->|Orgs/Clusters·用量| P1
  P1 --> D1[(D1 客户主数据/合同/额度)]

  Users -->|立项·工时·交付·续约| P2[P2 交付与经营编排]
  P2 --> D2[(D2 项目/工时/交付物)]
  D1 -->|合同/Quota 立项准入| P2
  P2 -->|消耗汇总| D1

  Jira -->|Incident/FRM/Bug 聚合| P3[P3 健康度与风险]
  D1 --> P3
  D2 --> P3
  P3 --> D3[(D3 健康/风险/满意度)]

  Users -->|Request| P4[P4 审批与自动化]
  P4 --> D5[(D5 Request/审批)]
  P4 -->|核定→虚拟合同/额度| D1

  D1 & D2 & D3 --> P5[P5 报表与通知]
  P5 -->|看板/预警/周月报| Users
  P5 -->|通知/加急/建群| Lark
  P2 -->|归档/签署| Lark

  P1 & P2 & P3 & P4 -->|事件| D4[(D4 事件时间线)]
  D4 --> P5

  classDef ext fill:#eee,stroke:#999;
  classDef actor fill:#dff,stroke:#3a9;
```

**处理过程**：P1 主数据同步收口 · P2 交付与经营编排（M3/M6/M7/M8）· P3 健康度与风险（M4/M11/M12 输入）· P4 审批与自动化（M9）· P5 报表与通知（M10）。**数据存储**：D1 客户主数据/合同/额度 · D2 项目/工时/交付物 · D3 健康/风险/满意度 · D4 事件时间线 · D5 Request/审批。关键子流程（如交付关卡链、ARR 核定）DFD 下钻见对应模块设计文档。

---

## 7. 系统集成
| 编号 | 对象 | 需求 |
|---|---|---|
| INT-01 | **Nexus CRM** | 客户基础数据来源（Account/Contact/Contract）；单向只读同步；**定时轮询 + 变化检测**（Nexus 无事件推送）+ 每日对账；失败告警可重放。 |
| INT-02 | **TiDB Support（Jira）** | 客户 **Ticket / FRM / Bug** 真源；经 **JSM Org ID**（来自 Nexus）关联客户工单，集成聚合到客户 360/看板（M12，只读）；**唯一写路径**：从 CSP 或飞书 Bot **代客创建 Support 工单**（M12 FR-SUP-08）。交付项目在 CSP 自建、运行期不回写 Jira；但**上线时将历史交付工单一次性迁移入 CSP**（OQ-P6）。 |
| INT-03 | **Ops（ops.tidbcloud）** | 双向：① **读**——客户 Orgs/Clusters 信息，补全技术画像（M1/M12）；② **动作/写**——CSP 内可**发起 Ops 请求**（如重启集群），见 INT-10。 |
| INT-04 | Google + 飞书 SSO | 统一登录；按 email 合并。 |
| INT-05 | 飞书 | 通知/加急/审批；自动建群/日程（M3 Onboarding）；**Wiki 知识库**关联与索引（M8），CSP 不自建知识库。 |
| INT-06 | 合同来源 | 三类合同优先从 Nexus 同步（同步 Contract，不再单列 Order）；无则 CSP 审批生成虚拟合同（Virtual Contract）（字段映射见 OQ-P7）。 |
| INT-07 | GitHub（可选） | Bug/Issue 关联与状态聚合（M12），如未统一走 Jira。 |
| INT-08 | 告警/监控 | 告警 docking（Lark/Slack）、Quick Ticket Bot、Clinic、TIDB.AI 等接入与聚合（M12/M4）。 |
| INT-09 | **AI Agent（未来协作，非下游）** | 设想在 Ticket 同步、Engagement 需求等场景提供智能分析与建议；定位为协作方而非 CSP 下游，协作方式与可行性**另行讨论**，本期不落地。 |
| INT-10 | **动作类集成（CSP → 外部系统发起请求）** | 客户提出需求时在 CSP 内一键发起操作请求（首例：Ops 重启集群等）；需含**权限校验 + 审计**；除 Ops 外的同类目标系统清单待梳理（OQ-S8）。 |
| INT-11 | 产品用量/遥测 | 数据源：**Clinic**（QPS/Connections 等）+ **Ops**（Billing、新建集群信息）；供 M1 360°、M4 健康度/采用度与主动观测。 |
| INT-12 | 日历（飞书） | 会议排期**双向同步**（QBR/周会），不止 Onboarding 建日程。 |
| INT-13 | HR/IdP（SCIM） | 用户供给：入离职自动开通/回收（M2 FR-IAM-06）。 |

---

## 8. 约束、假设与依赖
- **假设**：Nexus CRM 为客户/合同权威来源；Sponsored/特批可由 CSP 建虚拟 Contract。
- **假设**：内部用户均可 Google/飞书 SSO，email 唯一一致。
- **约束**：本期不做财务结算与 CRM 回写。
- **依赖**：飞书开放能力（通知/加急/审批/建群/日程/Wiki/Bot）、Nexus 读取接口（**无事件推送，定时轮询**）、TiDB Support(Jira) 与 Ops(ops.tidbcloud) 的读写接口。
- **未来**：与 AI Agent 的协作（Ticket 分析、Engagement 建议）为协作模式而非下游，可行性另行讨论。

---

## 9. 待确认问题（跨模块汇总）
| 编号 | 问题 | 归属 |
|---|---|---|
| OQ-P7 | 三类合同在 Nexus 的对象/字段映射（账户字段已明确；**合同字段 → 进详设阶段对接 Nexus 团队**） | M1 |
| — | Onboarding/Playbook 清单**草案已起**（M3/M4），细化待与 TAM 团队共创 | M3/M4 |
| OQ-S1 | Renewal 流程 + CSM 职责已在 **M5 起草草案待业务确认**（Customer Stage 已由 M3 可配生命周期覆盖） | M5/组织 |
| OQ-S2 | 权益引擎逻辑已定（**ARR 驱动核定**，M9 FR-APR-05、配置化）；仅**具体数值**（ARR 档/Free 天数）待业务确认 | M1/M5/M7/M9 |
| OQ-S3 | M12 集成聚合字段映射与联动 → **进详设对接各系统**（关联键 JSM Org ID 已明确） | M12 |
| OQ-S8 | **动作类集成**范围/权限/审计——**讨论稿已备**（[ldd/OQ-S8](ldd/OQ-S8-动作类集成-讨论稿.md)），待专题定 | INT-10 |
| OQ-S9 | **AI Agent 协作模式**（非下游）——**讨论稿已备**（[ldd/OQ-S9](ldd/OQ-S9-AI-Agent协作-讨论稿.md)），待专题定 | INT-09 |

> 已关闭：OQ-P5（立项授权来源；Order 退场后 = PS_Service 合同 nexus/virtual）、OQ-C4（虚拟合同签署）、OQ-C3（多 TAM/CSM）、CRM 真源（**Nexus 已取代 SFDC**）、OQ-C2（**Customer.level** = CRM Level 字段，取值 KA/SKA/…；support_plan = **Technical Support Level**；**≠ Cluster.tier 集群等级**，二者不同字段）、OQ-S4（满意度→角色级可配可见性）、OQ-S5（用量源 Clinic+Ops）、OQ-P6（交付在 CSP 自建、Jira 只读、唯一写=代客建单；**历史交付数据一次性迁移入 CSP**）、OQ-C1（Nexus 无事件推送 → 定时轮询 + 变化检测）、OQ-S6（内部时间纳入、标非项目）、OQ-S7（逻辑隔离：单实例+ABAC）、M2（多角色并集、外部账号 TAM 邀请仅见自己项目）。
>
> M7（工时平台级 Plugin/工时挂载(项目/经营/内部)、billable 计投入、项目 Man-days 消耗、换算 8h/可配、超支软预警、人力至产能+负载）与 M3 阶段、M4 健康度/风险均已敲定（多为配置化，数值/清单待校准或共创）。
>
> **记录待后期**：PS 项目财务（成本/毛利/收入确认/开票）。

---

## 10. 需求变更管理
> 需求随业务演进，变更需**可控、可追溯**。

- **提出**：变更来源为新痛点、业务校准（如数值/清单）、OQ 关闭结论或范围调整；由 PM 记录。
- **评审**：影响单模块的由 PM + 对应域 Leader 确认；**跨模块或改变范围/优先级**的需相关域 Leader 共评。
- **记录**：① 本总纲**修订记录**表登记版本与摘要；② 相应模块文档更新 FR/验收/决策，并在「已敲定 / 遗留待确认」留痕；③ 保留追溯链：**动因（痛点/OQ）→ 影响模块与 FR → 版本**。
- **配置类变更**（阈值、档位、清单、权重等标「待业务确认」项）走业务校准/配置，不视为需求范围变更，不单独走评审。