L2C 业务流程图

L2C 端到端业务流程权威基线 · 更新至 2026-08-19 业务确认版本 · 分模块待办见第八部分 · 已确认规则见附录 A

目录
  1. 三大业务域总览 — CRM / PMO / 采购域划分及交互
  2. CRM 域实体关系 — 线索→客户→商机→报价→订单→合同→回款
  3. 主链路跨职能流程（Lead to Order） — 10 个阶段独立成图
    1. 线索获取与分配
    2. 线索跟进
    3. 联系人创建
    4. 客户创建
    5. 产品试用申请
    6. 商机创建与跟进
    7. 报价
    8. 赢单
    9. 订单
    10. 合同
  4. 交付与采购链路（Order to Cash） — PMO 手动管理的项目、交付与采购待办范围
  5. AI 辅助链路 — AI 草稿生成与人工确认流程
  6. AI 工作台系统集成架构 — 统一入口与各系统数据交互全景
  7. 业务角色表 — 各业务角色职责
  8. 分模块待办 — 按模块、优先级整理的待确认事项
  9. 附录 A：已确认规则 — 已写入正文的确认结论

一、三大业务域总览

流程图 · 领域划分与交互
flowchart TB subgraph AIWB["AI 工作台 (统一入口 + 经营看板)"] direction TB ai1["经营看板 · AI 动作建议"] ai2["审批中心 · 数据聚合"] ai3["数据接入 & 反写"] ai1 --- ai2 --- ai3 end subgraph CRM["CRM 域 (Lead to Order)"] direction TB crm1["线索 → 客户 → 商机"] crm2["报价 → 订单 → 合同"] crm3["回款"] crm1 --> crm2 --> crm3 end subgraph PMO["PMO 域 (Order to Cash)"] direction TB pmo1["项目/交付"] pmo2["验收"] pmo3["收入确认"] pmo1 --> pmo2 --> pmo3 end subgraph PROC["采购域 (Procurement)"] direction TB proc1["供应商"] proc2["采购单 → 采购明细"] proc1 --> proc2 end subgraph FIN["财务域 (Finance)"] direction TB fin1["金蝶系统"] fin2["应收应付 / 发票 / 支付"] fin1 --> fin2 end AIWB -->|"读取全量数据"| CRM AIWB -->|"读取全量数据"| PMO AIWB -->|"读取全量数据"| PROC AIWB -->|"读取全量数据"| FIN CRM -->|"审批结果反写"| AIWB PMO -->|"审批结果反写"| AIWB CRM -->|"提供订单、合同与回款计划"| PMO PMO -->|"交付需要外采时 发起采购申请"| PROC PROC -->|"采购成本回流"| PMO PMO -->|"验收结果回流"| CRM CRM -->|"仅在提交开票申请时同步数据"| FIN

说明

域核心职责聚合根（核心实体）说明
AI 工作台 统一入口，聚合全链路数据，提供经营看板和 AI 动作建议 —（聚合层，不持有业务事实） 建在 navy 平台，集成 CRM/PMO/采购/金蝶数据，提供审批中心、经营看板、AI 主动指导；不替代现有系统，通过接口读写
CRM 域 管理客户关系、销售过程和交易事实 线索、客户、商机、报价、订单 覆盖从市场线索到签订订单的完整销售链路，包含合同管理和回款跟踪
PMO 域 管理交付执行、验收和收入确认 项目 项目由 PMO 手动创建和管理，订单确认或合同审批通过均不自动生成项目；手动立项条件、关联规则和后续管理细节列入 C-08、C-11 至 C-22
采购域 管理供应商和采购执行 供应商、采购单 当交付需要外部采购时，由 PMO 发起采购申请；采购完成后成本回流至项目；供应商合同归口及验收职责待 C-17、C-20 确认
财务域 金蝶系统对接，管理应收应付和发票 —（外部系统，按需调用） 采购付款、供应商发票、履约支付及应收应付由财务系统承载；CRM 当前仅在提交开票申请时将申请数据直接同步金蝶，其他 CRM 与财务/金蝶的协同暂不在本版界定

业务规则

  1. 各域独立演进，通过领域事件异步通信
  2. 每个事实只有一个域能写入，其他域只读引用
  3. AI 工作台是聚合展示层，不持有业务事实
  4. 审批结果通过各域系统反写回工作台

二、CRM 域实体关系总览

流程图 · 实体关系
flowchart LR Lead["线索 (Lead)"] -->|"转换"| Customer["客户 (Customer)"] Customer -->|"1:N"| Contact["联系人 (Contact)"] Customer -->|"1:N"| Opportunity["商机 (Opportunity)"] Opportunity -->|"1:N 业务线拆分"| SplitLine["业务线拆分 (SplitLine)"] SplitLine -->|"带入报价"| Quote["报价 (Quote)"] Quote -->|"1:N 产品拆分"| QuoteLine["产品明细 (QuoteLine)"] QuoteLine -->|"N:1"| Product["产品 (Product)
业务场景为产品字段"] QuoteLine -->|"关联带入产品明细"| Order["订单 (Order)"] Opportunity -->|"赢单后关联"| Order Order -->|"1:N"| SplitAssignment["业绩归属明细 (SplitAssignment)"] Order -->|"N:M"| Contract["合同 (Contract)"] Contract -->|"1:N 初始计划"| PaymentPlan["回款计划 (PaymentPlan)"] Order -->|"1:N"| InvoiceApplication["开票申请 (InvoiceApplication)"] Contract -->|"1:N"| InvoiceApplication

关键关系说明

关系说明
线索 → 客户线索经销售跟进并判定为"有效"后，执行"转客户"操作，生成客户记录，同时可创建关联商机
客户 → 商机（1:N）一个客户下可以有多个商机，每个商机按业务线（如雷达/数据智能/AI）拆分金额
商机业务拆分 → 报价产品拆分商机先按业务线做业务拆分；进入报价后，再在各业务线下细化到具体产品，形成产品拆分和产品明细（QuoteLine）。两者是不同层级的明细；报价总金额及各业务线产品汇总必须与商机业务拆分金额一致
报价产品明细 → 产品（N:1）报价明细引用产品主数据；「业务场景」是产品的普通属性字段，与名称、分类等字段一并维护，不单独建模为业务实体
商机/报价 → 订单商机赢单后，系统自动从报价带入产品明细和预算毛利率生成订单（状态：草稿），销售确认订单信息后提交订单审批
订单 ↔ 合同（N:M）时序上先有订单、后有合同；合同创建时必须选择一个或多个已存在订单（订单可仍处于审批中）并建立关联。一个订单可被后续多份合同引用，一个合同也可关联多个订单。订单不直接关联项目，合同与项目的归属关系由 PMO 后续手动管理
合同 → 回款计划（1:N）合同审批通过后可生成初始回款计划并在 CRM 可见；最终回款计划以 PMO 维护结果为准
订单/合同 → 开票申请（1:N）销售提交开票申请时关联既有合同及其上游订单；申请数据在提交动作发生时直接同步金蝶。除此以外，本版不预设 CRM 与财务/金蝶的其他协同
订单 → 业绩提成比例划分（1:N）销售提报订单时只填写产品明细和业绩提成比例划分；订单进入审批后，由销管调整金额并补录提成信息，最终审批通过后形成固定事实

业务规则

  1. 赢单是商机的状态属性（商机阶段 = "赢单"），不是独立实体
  2. 三类拆分独立建模：商机业务线拆分、报价产品拆分、订单业绩提成比例划分不得复用同一明细或同一字段
  3. 全链路审批校验：商机 → 最新有效报价（last）→ 订单必须保持关联、内容和版本一致；不一致时阻断并提示修改，修改后重新审批

三、主链路跨职能流程（Lead to Order）

从市场线索到合同完成共 10 个阶段，每阶段独立成图，形成从线索到回款的结构化业务链路。

业务规则

  1. LTC 全流程按统一实体关系和领域事件串联，实现从线索到回款的数据结构化闭环
  2. 各业务系统保留事实写入职责，通过标准接口向 AI 工作台同步状态和审批结果
  3. 组织架构采用"新薪人薪事"结果，变更后，需要有一个缓冲机制，避免立马影响审链路

阶段一：线索获取与分配

时序图 · 线索来源分流与分配
sequenceDiagram participant Mkt as 市场 participant Sales as 销售 participant XM as 销管运营 participant Sys as 系统 Note over Mkt,Sys: ① 线索进入：两类来源分流 Mkt->>Sys: 批量导入市场线索 Sys->>Sys: 市场线索进入「部门线索池」待分配 Sales->>Sys: 手工录入销售线索 Sys->>Sys: 销售线索进入「销售拓展池」并默认归属本人 Note over XM,Sales: ② 市场线索由销管运营分配 XM->>Sales: 从「部门线索池」分配市场线索，指派给销售 Sys->>Sys: 记录领取时间 Note over Sales,Sys: ③ 拿到线索后 24h 内须完成首次跟进（时长可配置，暂定 24H）（见阶段二） Note over XM,Sales: ④ 回收线索：销管运营再分配或暂时搁置 XM->>Sales: 从「回收线索池」重新指派给销售 XM->>XM: 或暂时搁置（搁置待激活）
步骤角色动作
1市场 / 销售线索进入：市场批量导入的线索进入「部门线索池」待分配；销售手工录入的线索进入「销售拓展池」并默认归属本人
2销管运营从「部门线索池」中把市场线索分配给对应销售，记录领取时间
3销售拿到线索后 24 小时内（时长可配置，暂定 24H）必须录入首次跟进记录（销售线索与市场线索均适用）
4销管运营对「回收线索池」中的回收线索重新分配给销售，或暂时搁置待激活

业务规则

  1. 线索池分层管理：市场线索进入部门线索池，由销管运营分配；销售自建线索进入销售拓展池并默认归属本人，两类池不合并
  2. 各池参数独立：部门线索池和销售拓展池的保有期可独立配置，部门线索池定义14天，销售拓展池可以不限期
  3. 拿到线索后 24 小时内必须完成首次跟进（时长可配置，暂定 24H），否则线索收回
  4. 被回收的线索统一进入回收线索池，由销管运营重新分配或暂时搁置，避免线索沉没

阶段二：线索跟进

时序图 · 首次跟进 + 持续跟进 + AI 判断 + 回收
sequenceDiagram participant Sales as 销售 participant Sys as 系统 participant AI as AI participant XM as 销管运营 Note over Sales,XM: ① 首次跟进（时长可配置，暂定 24H） Sales->>Sys: 录入首次跟进记录 alt 24h 内完成首次跟进 Sys->>Sys: 归属权保留，进入持续跟进 else 超 24h 未跟进 Sys->>XM: 线索收回，调入回收线索池 end Note over Sales,AI: ② 持续跟进 + AI 有效性判断 Sales->>Sys: 持续录入跟进活动（电话/拜访/会议） Sys->>AI: 推送跟进数据 AI->>AI: 判断跟进有效性（反馈/需求/证据） alt 跟进有效 AI->>Sys: 回写「有效」 else 跟进无效 AI->>Sales: 提醒销售更正（并给出调整建议） AI->>Sys: 回写「无效」，标记异常 end Note over Sys,XM: ③ 定时推送销管运营 + 人工判定调出 Sys->>XM: 定时推送异常线索汇总（无效/超时/长期未跟进） XM->>XM: 人工核验后决定调出/干预/保留 Note over Sales,XM: ④ 归属权保有期（可配置，暂定 14 天） alt 14 天内有跟进记录 Sys->>Sys: 归属权保留，保有期滚动顺延 else 14 天无跟进 Sys->>XM: 触发回收，线索调入回收线索池 end Note over XM: 回收线索池 → 重新分配或暂时搁置（见阶段一）
步骤角色动作
1销售首次跟进：拿到线索后 24 小时内必须录入首次跟进记录（时长可配置，暂定 24H）；超时线索收回至回收线索池
2销售持续跟进：首次跟进完成后持续每天跟进，记录电话/拜访/会议等销售活动
3AI判断跟进有效性（是否获取客户反馈、明确需求、有证据支撑）；判定无效时提醒销售更正并给出调整建议，销售可提出异议申诉
4系统 → 销管运营定时推送异常线索汇总（无效/超时/长期未跟进）给销管运营
5销管运营人工判定调出：AI 的无效标记只作提示；销管核验后决定调出、干预或保留，不因「无效」标签自动回收
6系统归属权保有期：保有期支持按线索池独立配置，当前统一暂定 14 天；14 天内有跟进记录即滚动顺延，14 天无跟进触发回收至回收线索池

注意：AI 判断仅做提示（提醒更正、标记异常），不做硬性阻断，也不直接触发回收；销售可提出异议，是否调出由销管运营人工判定。14 天无跟进的保有期回收是独立规则。"转客户"是销售在线索成熟后的独立操作，不属于本阶段流程。

业务规则

  1. 首次跟进：拿到线索后 24 小时内必须完成首次跟进记录（时长可配置，暂定 24H），超时线索收回至回收线索池
  2. 持续跟进保有期可配置，暂定 14 天：部门线索池和销售拓展池可独立配置，当前统一按 14 天执行；周期内有跟进记录即滚动顺延，无跟进则触发回收
  3. AI 判断跟进有效性并提醒更正：AI 基于销售反馈字段（是否获取客户反馈、明确需求、证据）组合条件判断跟进是否有效；判定无效时提醒销售更正并给出调整建议；销售可提出异议申诉；AI 不做硬性阻断
  4. 无效线索人工调出：系统定时推送异常线索汇总（无效/超时/长期未跟进）给销管运营；AI 的「无效」仅为提示信号，销管人工核验后决定调出、干预或保留
  5. 仅文本记录不算有效跟进，虚假拜访触发高压线扣分
  6. 被回收的线索统一进入回收线索池，由销管运营重新分配或暂时搁置
  7. "转客户"是独立操作，由销售在认为线索成熟后主动执行，不在此阶段流程内

销售记录关联：销售记录（销售活动/跟进记录）可关联商机、联系人、客户；线索可直接挂销售记录。

阶段三：联系人创建

时序图
sequenceDiagram participant Sales as 销售 participant Sys as 系统 participant AI as AI Sales->>Sys: 创建联系人（基于线索 / 直接新建） Sys->>Sys: 查重（名称 + 电话） alt 查重命中（联系人已存在） Sys->>Sales: 展示已有联系人，可关联已有或取消新建 alt 确认为已有联系人 Sales->>Sys: 关联已有联系人并补充缺失信息 else 信息录入有误 Sales->>Sys: 取消新建，不产生重复联系人 end else 查重通过 Sales->>Sys: 录入联系人信息（姓名/职务/电话/邮件等）并提交 end opt AI 上传生成草稿 Sales->>Sys: 上传名片 / 会议录音 Sys->>AI: AI 提取联系人信息 AI->>Sys: 生成联系人草稿 Sales->>Sys: 人工确认草稿后提交 end
步骤角色动作
1销售创建联系人：可基于线索创建，或直接新建
2系统 / 销售按名称 + 电话查重；命中时展示已有联系人，销售可选择关联已有联系人并补充缺失信息，或确认录入有误后取消新建
3销售未命中时录入联系人信息（姓名/职务/电话/邮件等）并提交
4（可选）AI销售上传名片/会议录音，AI 提取信息生成联系人草稿，人工确认后提交

业务规则

  1. 联系人可由线索转化或直接新建，创建时按名称 + 电话查重；命中后可关联已有联系人并补充缺失信息，不创建重复记录
  2. AI 上传生成联系人草稿，最终仍需人工确认后提交
  3. 联系人可后续在创建客户时被关联

阶段四：客户创建

时序图
sequenceDiagram participant Sales as 销售 participant Sys as 系统 participant XM as 销管运营 Sales->>Sys: 搜索查重（名称/信用代码/集团/子公司） alt 查重命中（客户已存在） Sys->>Sales: 展示已有客户，不重复新建 else 查重通过（新主体） Sales->>Sys: 新建客户：录入客户信息（含工商信息）并关联已有联系人 Sys->>Sys: 校验必填字段（联系人必填） Sales->>XM: 提交客户创建审批 alt 审批通过 XM->>Sys: 审批通过，客户生效 else 审批驳回 XM->>Sales: 驳回修改，补充后重新提交 end end
步骤角色动作
1销售搜索查重（名称/信用代码/集团/子公司），命中则展示已有客户，不重复新建
2销售查重通过后新建客户：录入客户信息（含工商信息），并关联已有联系人
3销售 → 销管运营提交客户创建审批，通过则客户生效，驳回则补充后重新提交

业务规则

  1. 先搜索查重，命中（含子公司/集团）不重复新建
  2. 录入客户信息可包含工商信息，创建时关联已有联系人
  3. 客户创建走审批流，通过后生效；首次分配给谁，该人员即成为客户责任人（见下方「客户创建完成后」）

客户创建审批流（详细）

节点审批人/角色审批内容通过条件驳回处理
第1级CRM管理员客户名称、销售记录、联系人、客户是否重复① 客户名称和统一信用代码与企查查一致；② 近期有效的销售记录（有需求推进中）；③ 有创建联系人；④ 新建客户在系统内不重复（母公司和子公司只能存在一个，不可多建）驳回后提交人可重新修改，满足条件后通过
第2级 / 第3级无

触发条件：① 新建客户；② 客户审批通过后修改客户里的任一内容；③ 作废客户。

免审批特例：销管运营角色提交的客户可不经过审批。

特殊规则：工作日 24 小时内未审批则提醒 CRM 管理员；审批人不在时可转交给其他销管审批；无金额或其他维度分支。

客户标签（新老客户）：新客户 = 一个自然年内无实际赢单或回款；老客户 = 一年内有赢单或回款。

客户创建完成后：归属与团队管理

时序图
sequenceDiagram participant Owner as 客户责任人 participant Member as 团队成员 participant Sys as 系统 Note over Owner,Sys: 首次分配对象成为客户责任人，不代表管理层级或领导关系 Owner->>Sys: 添加客户团队成员并分配业务角色 Owner->>Sys: 配置操作权限（读写 / 只读） Owner->>Sys: 配置关联对象可见范围（线索 / 商机 / 订单等） Sys->>Member: 按角色、操作权限和对象范围授予客户协作权限 Note over Owner,Sys: 客户连续无有效跟进（可配置，暂定 30 天） Sys->>Owner: 调出前提醒负责人及时跟进 alt 负责人本人补充有效跟进记录 Owner->>Sys: 记录有效跟进，继续保留客户归属 else 提醒后仍无有效跟进 Sys->>Sys: 触发客户调出流程并记录原因 end
步骤角色动作
1系统 / 分配人客户首次分配给某位人员后，该人员成为唯一的当前客户责任人；责任人是业务归属概念，不是领导层级
2客户责任人在客户后台添加团队成员，并为每位成员分配客户协作中的业务角色
3客户责任人为成员配置操作权限：读写或只读
4客户责任人配置成员可以查看的客户关联业务对象范围，包括该客户关联的线索、商机、订单等
5系统 / 客户责任人客户连续无有效跟进达到配置时长（暂定 30 天）时，系统先提醒责任人；提醒后仍无有效跟进则触发客户调出流程

业务规则

  1. 责任人不是领导：客户首次分配对象即为客户责任人，责任人表示当前业务归属和跟进责任，不表示直属上级、销售 Leader 或审批领导
  2. 历史上位负责人：旧字段若继续保留，只表示历史曾负责该客户的前责任人，属于责任转移记录，不授予当前归属、团队管理或审批权限
  3. 单一责任人：一个客户同一时点只有一个当前责任人；转移责任后，新接收人成为责任人，原责任人进入历史记录
  4. 团队授权：客户责任人可添加团队成员并分配业务角色；团队成员不因加入团队而成为客户责任人
  5. 权限双维度：每位团队成员分别配置操作权限（读写 / 只读）和关联业务对象可见范围（线索、商机、订单等），实际权限取两者交集
  6. 客户团队及权限在客户后台维护，独立于客户创建审批；新增、调整和移除成员均需记录操作人、时间及变更内容
  7. 客户跟进与调出：客户连续无有效跟进的判断时长可配置，当前暂定 30 天；调出前必须先提醒，提醒后仍未有效跟进才触发调出流程
  8. 有效跟进口径：仅客户责任人本人填写的记录计入客户保有判断，团队成员或其他非负责人填写的记录不替代责任人的有效跟进

阶段四-b：产品试用申请

时序图
sequenceDiagram participant Sales as 销售 participant Sys as 系统 participant Biz as 业务部门 Note over Sales,Sys: 基于客户发起独立试用申请 Sales->>Sys: 基于客户发起产品试用申请 Sales->>Biz: 提交试用申请 alt 审批通过 Biz->>Sys: 业务部门审批通过 Sys->>Sales: 直接下发试用账号密码 Sales->>Sales: 开始产品试用 else 审批驳回 Biz->>Sales: 驳回 end
步骤角色动作
1销售基于已创建客户，发起产品试用申请
2销售 → 业务部门提交试用申请，由业务部门审批（独立申请，不走销售审批链）
3系统审批通过后，直接下发试用账号密码，销售开始试用

业务规则

  1. 产品试用申请是独立申请，位于客户与商机之间
  2. 由销售发起、业务部门审批，审批通过后直接下发账号密码试用
  3. 试用申请以客户为前置条件

支线说明：客户试用（产品试用）为独立支线流程，位于客户与商机之间，不进主销售审批链，业务部门审批通过后下发账号即可，属轻量环节。

阶段五：商机创建与跟进

时序图
sequenceDiagram participant Sales as 销售 participant Approver as 审批人 participant XM as 销管运营 participant Sys as 系统 participant AI as AI participant XM as 销管运营 Sales->>Sys: 创建商机 关联客户，按业务线拆分金额并填销售赢单率 Sys->>Sys: 校验：Σ 业务线金额 = 商机总金额 Sales->>Approver: 提交商机创建审批 alt 审批通过 Approver->>Sys: 审批通过 Sys->>Sys: 商机阶段 → 推进中 Sys->>AI: 推送商机与跟进数据 AI->>Sys: 计算并写入独立的 AI 赢单率字段 Sys->>Sys: 销管赢单率为空时 默认引用 AI 赢单率 XM->>Sys: 填写销管赢单率后 改用销管值 else 审批驳回 Approver->>Sales: 驳回修改 end Note over Sales,Sys: 商机连续未填写销售记录（可配置，暂定 30 天） Sys->>Sales: 提醒商机负责人及时更新 Sales->>Sys: 负责人本人补充销售记录
步骤角色动作
1销售创建商机，关联客户和联系人，按业务线（如雷达/数据智能/AI等）拆分金额，并在提交审批前填好销售赢单率；Σ 业务线金额必须等于总金额
2审批人审批商机创建：通过 → 商机进入"推进中"；驳回 → 销售修改后重新提交
3AI / 销管运营审批通过后，AI 自动计算并保存独立的AI 赢单率字段；销管赢单率为空时先默认引用 AI 赢单率，销管填写自己的赢单率后改用销管值，AI 赢单率仍保留
4系统 / 销售商机连续未填写销售记录达到配置时长（暂定 30 天）时，系统提醒商机负责人及时更新，不自动回收商机

业务规则

  1. 商机按业务线（雷达/数据智能/AI等）拆分金额，Σ 必须等于商机总金额
  2. 商机审批后可形成多个报价轮次，但只有最新一版报价是当前有效报价（last）；历史报价保留追溯，后续订单只能引用最新有效报价
  3. 商机变更后按字段判断：与报价无关的字段不影响报价；金额、产品或其他指定字段发生变化时，当前最新报价立即失效，销售必须重新提报价。具体影响字段清单列入 C-07
  4. 销售赢单率时序：销售创建商机时填报，并在提交商机创建审批前完成
  5. 三类赢单率字段：销售赢单率、AI 赢单率、销管赢单率分别保存，互不覆盖
  6. AI 赢单率：审批通过后由 AI 自动计算并写入独立字段，该字段持续保留，不因销管填写而被覆盖或删除
  7. 销管赢单率时序：销管未填写时，业务计算默认引用 AI 赢单率；销管填写后，以销管赢单率为准
  8. 业绩预测公式 = Σ(各业务线拆分金额 × 有效赢单率)，其中有效赢单率 = 销管赢单率（有值时）/ AI 赢单率（销管未填时）
  9. 商机跟进提醒：连续未填写销售记录的提醒时长可配置，当前暂定 30 天；仅负责人本人填写的记录计入判断，非负责人记录不替代负责人跟进；该规则只提醒，不自动回收

商机创建审批流（详细）

节点审批人/角色审批内容通过条件驳回处理
第1级销售总监 / 销售leader商机金额、业务线、需求背景金额无错误（单位易写错）；业务线选择正确；需求背景填详实驳回至销售修改重新提交
第2级售前总监 / 售前leader（可选）商机金额、业务线、需求背景金额无错误；业务线选择正确；需求背景填详实驳回至销售修改重新提交
第3级销管 / CRM观察者商机名称、商机金额、业务线、需求背景、是否续单商机名称 = 客户简称 + 售卖产品；金额无错误；业务线正确；需求背景详实；是否续单按实际情况选择（新/老客户、续约/增量）驳回至销售修改重新提交；重新提交直接到销管审批，不经过前面 2 级

触发条件：新建商机。免审批：销管创建可不经过审批，其他均需审批。

特殊规则：不同业务线（雷达/数据智能/AI）及不同金额区间的审批链无差异；工作日 24 小时内未审批提醒审批人及时审批。

商机变更规则：① 商机没有后续报价时可按现有权限修改；② 已有报价时先判断变更字段，与报价无关则报价不变，涉及金额、产品或配置的指定字段时，当前最新报价标记失效并重新提报；③ 具体哪些字段影响报价列入 C-07；④ 商机背景信息（竞对等）可由录音识别结果回写表单字段。

阶段六：报价

时序图 · 报价流程（线下填表 + 上传 + AI 识别）
sequenceDiagram participant Sales as 销售 participant Sys as 报价系统 participant AI as AI participant Approver as 审批人 Sales->>Sales: 线下填写报价 Excel 表 （按产品分类填列） Sales->>Sys: 上传报价表至 OA 报价系统 Sys->>AI: 推送上传文件 AI->>AI: AI 自动识别提取 （产品/金额/成本/业务线） AI->>Sys: 回填结构化数据到表单台账 Sys->>Sys: 与产品清单匹配校验 （产品名称归一 / 归入类目） Sales->>Sys: 确认并提交报价 Sys->>Sys: 校验关联商机为最新审批版本 且金额/产品/业务线一致 alt 校验一致 Sales->>Approver: 提交报价审批 alt 审批通过 Approver->>Sys: 业务线负责人审批通过 Sys->>Sys: 报价 → 已审批，标记为最新有效报价（last） Sys->>Sys: 既往报价轮次转为历史版本 else 审批驳回 Approver->>Sales: 驳回修改 end else 校验不一致 Sys->>Sales: 阻断提交 要求返回修改商机或报价表 end
步骤角色动作
1销售线下填 Excel 报价表，按产品分类填列，包含产品、对客报价、成本、交付方式（自有/外包）
2销售 → 系统上传报价表至 OA 报价系统
3AIAI 自动识别提取 Excel 内容，结构化填入系统表单台账（减少销售重复填报）
4系统与产品清单匹配校验：产品名称归一、归入类目，不匹配则提示补录
5系统销售确认提交时先检查所关联商机是否为最新审批版本，并校验报价金额、产品和业务线与商机一致；任一不一致则阻断提交
6销售 → 审批人销售确认后提交审批；审批流按业务线配置，各业务线负责人分别审批
7系统审批通过 → 本轮报价标记为最新有效报价（last），既往轮次保留为历史版本；创建订单时只允许带入最新有效报价

业务规则

  1. 表单按"产品"分类
  2. 商机按业务线形成业务拆分；报价在对应业务线下继续细化到具体产品，形成独立的产品拆分
  3. 「业务场景」是产品主数据上的普通字段，与产品名称、分类等属性一并记录；报价产品明细通过产品引用取得该字段
  4. 销售线下填 Excel → 上传 → AI 自动识别提取到表单台账
  5. 产品清单单独维护；AI 识别后与产品清单匹配校验（名称归一、归入类目），不匹配则提示补录
  6. 提交报价审批时必须关联商机的最新审批版本，并校验金额、产品和业务线一致性；不一致则阻断提交
  7. 审批流按业务线配置，各业务线负责人分别审批
  8. 同一商机可产生多个报价轮次，但只保留最新一版为当前有效报价（last）；订单只能引用最新有效报价，历史轮次仅供追溯
  9. 商机金额、产品或指定字段变化时，最新报价失效并需重新提报；与报价无关的商机字段变化不影响报价，影响字段清单见 C-07

报价审批流（详细）

节点审批人/角色审批内容通过条件
第1级售前人员（可选）对客报价金额、预计成本、自有/外包投入成本、交付团队金额无错误；业务线正确；产品线毛利率情况
第2级销售总监对客报价金额、预计成本、自有/外包投入成本、交付团队金额无错误；业务线正确；产品线毛利率情况
第3级运营审批（吴淼梅）对客报价金额、预计成本、自有/外包投入成本、交付团队金额无错误；业务线正确；产品线毛利率情况；外包交付的合理性
第4级销售团队的最高负责人整体项目毛利率、产品线毛利率项目整体毛利率
第5级产品总监产品线执行金额、对应投入成本及毛利率产品线金额无错误；业务线正确；产品线毛利率情况
第6级财务BP（可配置）对客报价金额、预计成本、自有/外包投入成本、交付团队报价 Excel 金额与表单金额及产品线一致；产品线毛利率低于考核毛利率的原因考量；外包交付合理性及考量
第7级产品VP（可配置）产品线执行金额、对应投入成本及毛利率产品线金额无错误；业务线正确；产品线毛利率情况
第8级结束

驳回处理：各节点驳回均至销售修改重新提交。

触发条件：定制项目，或标品产品低于 ratecard 的情况。

审批关系：审批节点、顺序、并行关系和必经性均可配置；同一项目涉及多个产品线时，可配置多个产品线审批人并行审批。

金额 / 折扣：金额、毛利率、折扣和产品类型均可作为审批路由条件，不在流程中写死固定分支。

高价格标品规则：高价格标品满足既定适用条件时，由销售发起后直接流转至产品总监审核，中间节点跳过；路由条件和产品总监节点均由配置管理。

阶段七：赢单

时序图
sequenceDiagram participant Sales as 销售 participant Approver as 审批人 participant Sys as 系统 Sales->>Sys: 商机推至赢单 上传客户确认凭证 Sys->>Sys: 校验：最新报价（last）的业务线、金额、产品 与商机最新审批版本一致 alt 校验不一致 Sys->>Sales: 阻断提交 需先调整报价或商机 end Sales->>Approver: 校验通过后 提交赢单审批 alt 赢单审批通过 Approver->>Sys: 审批通过 Sys->>Sys: 商机 → 赢单，数据锁定 opt 商机来源于线索 Sys->>Sys: 回写线索转换状态 end Sys->>Sys: 自动从报价带入产品明细和毛利率 生成订单（草稿） Sys->>Sales: 提醒确认订单草稿并提交订单审批 else 赢单审批驳回 Approver->>Sales: 驳回 end
步骤角色动作
1销售商机推至赢单，上传客户确认凭证
2系统提交前校验：必须引用最新有效报价（last），且报价业务线、金额、产品与商机最新审批版本一致，否则阻断提交赢单
3销售 → 审批人校验通过后提交赢单审批；审批通过 → 商机状态锁定为"赢单"（若商机来源于线索，则回写线索转换状态，非必须）；驳回则销售继续跟进或修改
4系统赢单审批通过后，系统自动从报价带入产品明细和预算毛利率生成订单（状态：草稿），并提醒销售确认后提交订单审批

业务规则

  1. 赢单是独立审批流程，商机推至赢单需上传客户确认凭证
  2. 提交赢单前必须校验：引用的是最新有效报价（last），且报价业务线、金额、产品与商机最新审批版本一致；不一致则无法提交赢单
  3. 赢单审批通过后商机数据锁定，后续修改需走「赢单后修改」审批
  4. 赢单审批通过后，系统自动从报价带入产品明细和预算毛利率生成订单（状态：草稿），并提醒销售确认提交；手动创建仅作为异常补充路径
  5. 订单审批时填写的是业绩提成比例划分；实际提成金额在审批通过后结合合同回款和业绩完成情况补录，二者必须区分
  6. 赢单审批与订单审批不可合并

商机赢单审批流（详细）

节点审批人/角色审批内容通过条件驳回处理
第1级销管 / CRM观察者赢单凭证赢单凭证需为以下其中一种：① 双方盖章的合同/po；② 中标通知书；③ 双方公司邮箱发出的合作确认邮件（明确回复确认）驳回至销售修改重新提交
第2级 / 第3级无

触发条件：销售提交赢单审批。特殊规则：驳回后商机回到上一个阶段状态（进行中）；赢单审批和订单审批不可以合并。

商机输单审批（独立路径）

节点审批人/角色审批内容通过条件驳回处理
销售发起销管 / CRM观察者输单原因、输单详情从输单专属原因库选择并填写详情：价格原因、方案竞争力、客情问题、战略放弃等驳回至销售修改重新提交，商机保持进行中
销管直接调整销管管理员输单原因、输单详情管理员确认后直接调整，无需审批；完整记录操作者、原因和时间不适用

触发条件：销售将商机调整为输单时提交输单审批。输单原因只使用输单专属原因库，不与无效原因混用。

商机无效审批（独立路径）

节点审批人/角色审批内容通过条件驳回处理
销售发起销管 / CRM观察者无效原因、无效详情从无效专属原因库选择并填写详情：项目消失、需求合并、虚假、重复等驳回至销售修改重新提交，商机保持进行中
销管直接调整销管管理员无效原因、无效详情管理员确认后直接调整，无需审批；完整记录操作者、原因和时间不适用

触发条件：销售将商机调整为无效时提交无效审批。无效原因只使用无效专属原因库，不与输单原因混用。听记中的「零单」暂不固化为独立状态，待业务另行确认。

商机赢单后修改审批

节点审批人/角色审批内容通过条件驳回处理
第1级销管 / CRM观察者修改内容修改的内容符合实际情况驳回至销售修改审批；在销售不再提交的情况下，修改内容不变
第2级 / 第3级无

触发条件：商机赢单后修改商机内容（无免审批情况）。特殊规则：不同业务线、不同金额区间审批链无差异；工作日 24 小时内未审批提醒审批人及时审批。

阶段八：订单

时序图
sequenceDiagram participant Sales as 销售 participant Approver as 审批人 participant Sys as 系统 Sys->>Sys: 赢单通过后 自动生成订单草稿并带入产品明细/毛利率 Sys->>Sales: 提醒确认订单草稿并提交 opt 自动创建异常时手动补充 Sales->>Sys: 手动创建订单并关联赢单商机/报价 end Sales->>Sys: 确认产品明细 填报业绩提成比例划分 Sales->>Approver: 提交订单审批（仅产品明细 + 比例划分） Sys->>Sys: 订单 → 审批中 Sys->>Sys: 反向追溯 商机 → 最新报价（last）→ 订单 alt 关联、内容或版本不一致 Sys->>Sales: 报错提醒 返回修改上游数据 Sales->>Approver: 修改完成后重新提交审批 else 一致且均为最新版本 Approver->>XM: 业务初审通过 进入销管审批 XM->>Sys: 审批中调整订单/执行金额 填写标准提成信息 Note over XM,Sys: 等待合同返回及提成依据期间，订单保持「审批中」（可能 2-3 个月） XM->>Sys: 合同返回后补齐实际提成等信息 alt 销管确认信息完整且一致 XM->>Sys: 最终审批通过 Sys->>Sys: 订单 → 已确认 全部审批事实固定 else 信息不完整或不一致 XM->>Sales: 直接驳回 修改后重新审批 end end
步骤角色动作
1系统赢单审批通过后自动生成订单草稿，从报价带入产品明细和预算毛利率，并提醒销售确认提交；手动创建仅用于自动创建异常等补充场景
2销售确认订单产品明细，并填报业绩提成比例划分（如 30% / 70%）；销售提报阶段不填写标准提成、实际提成或其他后置提成信息
3销售 → 审批人提交订单审批，提交内容仅包括报价带入的产品明细和业绩提成比例划分；订单状态进入「审批中」
4系统按「先有商机、后有报价、最后有订单」反向追溯，检查关联对象、内容和版本是否一致且均为最新；不一致则报错并要求修改后重新审批
5销管运营在审批过程中调整订单金额、执行金额并填写标准提成信息；合同未返回、提成依据不完整时，订单继续保持「审批中」
6销管运营合同返回后补齐实际提成等信息；信息完整且一致才最终通过，否则直接驳回。最终通过后，金额、比例和提成信息均成为固定事实

业务规则

  1. 自动创建为主路径：赢单通过后系统自动生成订单草稿并提醒销售确认提交；销售手动创建仅作为异常补充路径
  2. 拆分概念严格分开：商机的业务线拆分描述卖到哪些业务线；报价的产品拆分描述各业务线下具体卖哪些产品；订单的业绩提成比例划分描述该笔订单按什么比例分配给各销售或团队
  3. 销售提报范围：销售只提交产品明细和业绩提成比例划分，标准提成、实际提成及相关金额不由销售在提交时填写
  4. 销管审批职责：销管必须在审批过程中完成订单/执行金额调整和提成信息补录；信息完整且一致才最终通过，否则直接驳回
  5. 长审批周期：订单需要等待合同返回后才能补齐相关提成信息，因此可保持「审批中」两至三个月；最终审批通过之前不视为闭环
  6. 最终事实：订单最终通过后，审批确认的产品、金额、比例和提成信息全部固化；后续如需修改，必须产生新版本并重新审批
  7. 链路一致性：审批时按「商机 → 最新有效报价（last）→ 订单」反向追溯，核对关联、内容和版本；一致且为最新版本才继续审批，不一致则报错提醒，修改后重新审批

订单审批流（详细，含业绩归属拆分）

节点审批人/角色审批内容通过条件驳回处理
第1级产品线负责人 / 售前leader产品线、产品线金额按项目实际情况的产品线和金额进行审批驳回至销售修改重新提交
第2级销管 / CRM观察者订单金额、执行金额、业绩核算季度、业绩提成比例划分、标准提成信息核对比例合计为 100%，在审批中完成金额调整并填写标准提成信息；不满足条件直接驳回驳回至销售修改重新提交；重新提交直接到销管审批，不经过前面 1 级
第3级（最终节点）销管 / CRM观察者合同返回后的实际提成等补充信息、商机/报价/订单最新版本一致性合同及提成依据已具备，补充信息完整，且商机 → 最新报价 → 订单关联、内容和版本一致；最终通过后全部字段固化任一条件不满足即直接驳回，修改后重新审批

特殊规则：不同金额区间的审批链无差异。等待合同和提成依据期间订单保持「审批中」，可能持续两至三个月；最终节点通过后才形成固定订单事实。

阶段九：合同

已确认边界：时序上先有订单、后有合同；合同创建时必须关联一个或多个上游订单，与订单为 N:M。为支持订单等待合同返回后补录提成，合同可关联仍处于「审批中」的订单。当前与金蝶唯一明确的动作是「提交开票申请时同步申请数据」，其他财务协同暂不在本版界定。

时序图
sequenceDiagram participant Sales as 销售 participant Sys as 系统 participant AI as AI participant Approver as 审批人 participant PMO as PMO participant Kingdee as 金蝶 Sales->>Sys: 发起合同 关联订单（一个或多个） Sys->>Sys: 建立合同 ↔ 订单关联关系 Sales->>Sys: 上传合同文件 Sys->>AI: AI 识别金额、回款计划、开票计划等关键字段 AI->>Sys: 回填识别结果 Sales->>Sys: 人工确认识别结果 Sales->>Approver: 提交合同审批 alt 审批通过 Approver->>Sys: 审批通过 Sys->>Sys: 合同 → 审批通过，生成初始回款计划 Sys->>PMO: 同步初始回款计划 PMO->>Sys: 维护最终回款计划 else 审批驳回 Approver->>Sales: 驳回修改 end opt 开票申请 Sales->>Sys: 基于合同及其上游订单提交开票申请 Sys->>Kingdee: 提交动作发生时 直接同步开票申请数据 end
步骤角色动作
1销售在已有订单之后发起合同，并由合同选择关联一个或多个上游订单，建立合同 ↔ 订单关联关系
2销售上传合同文件
3AI → 销售AI 识别金额、回款计划、开票计划等关键字段并回填，人工确认
4销售 → 审批人提交合同审批；审批通过后生成初始回款计划，驳回则修改重提
5系统 / PMO初始回款计划在 CRM 中可见并同步给 PMO；PMO 维护的最终回款计划回写 CRM，作为销售参考
6销售 → 系统 → 金蝶销售基于合同及其上游订单提交开票申请；只有在提交开票申请时，系统才将该申请数据直接同步金蝶

业务规则

  1. 有订单才可发起合同，合同不允许仅关联商机
  2. 合同与订单为 N:M：一个合同可关联一个或多个订单，一个订单也可被后续一份或多份合同引用；关系在合同创建时由合同挂接已存在订单，订单可仍处于「审批中」
  3. 合同当前识别字段包括合同 ↔ 订单关系、合同金额、回款计划（含账期）和开票计划；正式必提取字段清单列入 C-10
  4. 回款计划：合同审批通过后可生成初始计划，但最终以 PMO 管理的计划为准；CRM 展示最终结果供销售参考
  5. 唯一已明确的金蝶同步：销售提交开票申请时，系统直接将开票申请数据同步金蝶
  6. 除开票申请提交外，本版不描述合同审批后的其他财务协同、回款确认或金蝶回流，待后续业务边界明确后再补充
  7. 合同与项目的归属关系不在 CRM 合同流程处理，由 PMO 手动管理，见 C-08/C-12
  8. 先开票后验收等管控规则归入 PMO 流程管理，不在合同环节处理

合同金额校验：合同提交审批前汇总关联订单金额并校验，提示遗漏、重复关联或金额差异；最终必填和阻断规则随 C-10 的合同表单与审批流一并确认。

合同审批流（详细）

【待办 · C-10】合同审批规则待补充确认，此处预留。待补充合同审批的节点、审批人/角色、审批内容、通过条件、驳回处理。

四、交付与采购链路（Order to Cash）

项目由 PMO 手动创建和管理，订单确认或合同审批通过均不自动生成正式项目或交付准备单。本节展示 PMO 后续需要补齐的管理范围，不把未确认的触发、审批、验收、结项和财务规则固化为系统约束；详细待办见 C-08、C-11 至 C-20、C-22。

时序图 · 交付与采购链路
sequenceDiagram participant PMO as PMO/项目经理 participant Finance as 财务 participant Procure as 采购 participant Customer as 客户 participant Kingdee as 金蝶 participant Sys as 系统 PMO->>Sys: 手动创建项目并选择关联订单/合同（规则待 C-08） Sys->>PMO: 校验重复关联并保存项目（规则待 C-08/C-12） PMO->>Sys: 手动维护交付节点与预算（待 C-13/C-19） PMO->>PMO: 执行交付 opt 需要外采 PMO->>Procure: 发起采购申请（关联订单产品行） Procure->>Sys: 创建采购单 Procure->>Procure: 采购执行 Procure->>Sys: 采购完成 Sys->>PMO: PurchaseCompleted（采购成本回流） Sys->>Kingdee: 同步采购付款/供应商发票 end PMO->>Customer: 交付完成，提请验收 alt 验收通过 Customer->>Sys: 确认验收 Sys->>Sys: AcceptanceCompleted → CRM else 验收不通过 Customer->>PMO: 退回修改 end PMO->>Finance: 提交收入确认 Finance->>Sys: 确认收入 Sys->>Sys: RevenueRecognized → 回流 CRM Note over Sys,Kingdee: CRM 仅在提交开票申请时同步金蝶，见阶段九 PMO->>Sys: 项目结项

流程说明

步骤触发条件执行角色动作
1PMO 手动发起PMO/项目经理PMO 手动创建项目并选择关联订单、合同；系统不因订单确认或合同审批通过自动立项。发起条件、重复校验、编号和取消规则见 C-08
2项目启动PMO/系统PMO 手动维护交付节点、实际开始日期和预算成本项；项目层级与 owner 见 C-12，立项数据和预算规则见 C-13、C-19
3（可选）需要外采PMO → 采购 → 金蝶PMO 发起采购申请 → 采购创建采购单 → 执行采购 → 完成后成本回流；同步采购付款、供应商发票至金蝶。供应商合同和验收职责见 C-17、C-20
4交付完成PMO → 客户当前 V2 基线为 PMO 提请客户验收、项目经理上传凭证、客户确认；里程碑内部验收及开票/供应商付款前置规则见 C-14
5验收通过PMO → 财务收入计划、收入确认和财务协同的责任及条件列入 C-20；不与 CRM 合同审批后的金蝶同步混为一条链路
6申请结项PMO/项目经理PMO 手动发起结项；结项硬条件、事实源和例外处理列入 C-15

业务规则

  1. 项目由 PMO 手动创建和管理，订单确认和合同审批通过均不自动创建项目
  2. PMO 手动立项的前置条件、订单/合同关联、编号、重复校验、取消及历史数据处理列入 C-08
  3. 合同前投入的审批、时限和强制停工机制尚未进入本流程，见 C-11
  4. 全员报工、项目/非项目工时及工时审批尚未进入本流程，见 C-16
  5. CRM 合同链路当前仅在提交开票申请时同步金蝶，不预设合同审批、回款等其他自动同步
  6. 数据拉取为按需模式——仅当用户填写某销售订单时才从 CRM 拉取对应数据
  7. 需考虑汽车以外的标准产品线，不能仅围绕汽车业务设计

五、AI 辅助链路

AI 在 L2C 全链路中的五类辅助能力：录音提取、报价识别、审批辅助、经营看板、赢单率建议。

时序图 · AI 录音提取（草稿 → 人工确认 → 正式事实）
sequenceDiagram participant Sales as 销售 participant Sys as 系统/AI Sales->>Sys: 上传会议录音 Sys->>Sys: 保存为 MeetingRecording Sys->>Sys: AI 提取结构化信息 （竞品/客户意向/下一步计划） Sys->>Sys: 生成 AI 草稿 AIDraft 状态: 候选 Candidate Sys->>Sys: 同时生成线索草稿 / 客户草稿 / 商机草稿 Sys->>Sales: 推送草稿，等待人工确认 alt 接受 / 修改 Sales->>Sys: 确认并提交 Sys->>Sys: 转为正式 CRM 事实 （可追溯到原始录音片段） else 拒绝 Sales->>Sys: 拒绝 Sys->>Sys: 丢弃草稿，记录拒绝原因 end
流程图 · AI 五类辅助场景全景
flowchart TB subgraph S1["1. 录音提取"] a1["上传会议录音"] --> a2["AI 提取结构化信息"] a2 --> a3["生成线索/客户/商机草稿"] a3 --> a4["人工确认 → 正式事实"] end subgraph S2["2. 报价识别"] b1["销售上传 Excel 报价表"] --> b2["AI 自动识别提取"] b2 --> b3["回填结构化表单台账"] b3 --> b4["减少重复填报"] end subgraph S3["3. 审批辅助"] c1["关键节点 AI 预审"] --> c2["合同预审驳回提示"] c2 --> c3["AI 不替代审批 仅做判断辅助"] end subgraph S4["4. 经营看板"] d1["目标缺口分析"] --> d2["AI 推出动作建议 （挑商机/推方案/话术）"] d2 --> d3["交互式问答 深入探索"] d3 --> d4["回写验证销售动作"] end subgraph S5["5. 赢单率建议"] e1["商机审批通过"] --> e2["AI 计算赢单率建议值"] e2 --> e3["写入独立 AI 赢单率字段"] e3 --> e4["销管未填时引用 AI 值"] e4 --> e5["销管填写后改用销管值
AI 字段仍保留"] end S1 --> S4 S2 --> S4 S3 --> S4 S5 --> S4

AI 辅助规则

#规则
1人工确认必过：任何未经人工确认的 AI 草稿不得进入正式列表、经营报表或下游同步
2可追溯：正式对象可追溯到原始录音片段，保留 AI 候选值、人工修改结果、确认人和确认时间
3多对象生成：一次录音可同时生成线索草稿、客户草稿、商机草稿，销售可选择全部或部分确认
4跟进有效性判断：AI 自动判断销售活动是否有效（是否获取客户反馈、明确需求等），虚假拜访触发扣分
5报价 AI 识别：销售线下填 Excel → 上传 → AI 自动识别提取到表单台账，减少重复填报。保留销售现有操作习惯
6审批 AI 辅助：AI 在关键节点做判断辅助（如合同预审驳回），但不能代替真实业务流审批
7经营看板 AI：以目标为导向（如"南区客户二部差1亿"），AI 从目标缺口倒推动作建议，而非被动展示数据
8赢单率建议：商机审批通过后 AI 计算结果写入独立的 AI 赢单率字段；销管赢单率为空时引用 AI 值，销管填写后改用销管值，但 AI 赢单率字段始终保留

业务规则

  1. AI 是辅助工具，不是决策者。所有 AI 产出物必须经过"候选 → 人工确认 → 正式事实"的转换链路
  2. AI 工作台不应仅作为信息展示平台，而应强化 AI 的主动指导能力
  3. 在呈现订单、客户、合同等对象的同时，叠加 AI 生成的动作建议
  4. 通过交互式问答支持用户深入探索

六、AI 工作台系统集成架构

AI 工作台作为统一入口，集成各业务系统数据，提供经营看板、审批中心和 AI 主动指导。不替代现有系统，通过接口读写。

架构图 · AI 工作台与各系统集成
flowchart TB subgraph AIWB["AI 工作台 (navy 平台)"] direction TB nav1["经营看板 目标缺口 → AI 动作建议"] nav2["审批中心 全流程审批聚合"] nav3["数据聚合展示 订单/合同/采购/项目"] nav4["AI 交互问答 深入探索"] nav1 --- nav2 --- nav3 --- nav4 end subgraph Systems["业务系统层"] direction TB s1["OA 报价系统"] s2["合同管理系统"] s3["CRM 系统 （线索/客户/商机/订单）"] s4["PMO 项目管理系统"] s5["采购系统"] s6["金蝶财务系统"] end subgraph DataFlow["数据流向"] direction LR d1["AI 工作台读取 各系统全量数据"] d2["审批结果反写 回各业务系统"] d3["领域事件 异步跨域通信"] end AIWB -->|"读取聚合"| Systems Systems -->|"审批结果/状态变更反写"| AIWB Systems -->|"领域事件"| Systems

系统集成说明

系统职责与集成方式
AI 工作台基于 navy 平台提供统一入口、Tab 分页、分层浏览和目标导向的经营看板
OA 报价系统承载报价 Excel 上传、AI 识别、业务线分类表单和按业务线配置的审批流
合同管理系统承载合同与上游订单的关联、关键字段和合同审批；当前仅在销售提交开票申请时将申请数据同步金蝶，其他合同后财务协同暂不界定。必要提取字段和审批流见 C-10
PMO 项目管理项目由 PMO 手动创建和管理，不接收订单或合同的自动立项指令；手动立项、验收、结项、工时和成本等规则见 C-08、C-11 至 C-22
金蝶系统在 CRM 提交开票申请时接收申请数据；采购付款、供应商发票等既有财务能力不在本版 CRM 合同流程中扩展描述
组织架构从企微同步并采用“新人新事”模式，组织变更后自动调整审批链

业务规则

  1. AI 工作台不替代现有系统，各业务系统继续运行
  2. 各业务系统通过标准接口接入 AI 工作台，并保持各自事实写入职责
  3. 领域间通过事件传递状态变化，审批结果和责任人操作统一回写 AI 工作台
  4. AI 不能代替真实业务流审批，仅在关键节点做判断辅助
  5. 全链路数据采用结构化模型，并通过异常处理机制保证跨域最终一致性

七、业务角色表

系统中各业务角色及其在各板块的职责。

覆盖范围：当前表以 CRM 角色为主，尚未完整定义 PMO、项目经理、交付负责人、财务 BP、采购、法务、客户等端到端角色的 RACI；角色补齐和“天猫侧”正式岗位映射见 C-20、C-23。

角色主要职责或参与的环节
高管可查看所有数据，查看公司经营报表与业务全景
CRM管理员可查看、修改和下载所有数据；负责后台设置管理，包括用户、角色、权限、业务流程等基础数据的维护
CRM观察者可查看、修改和下载所有数据，运营部门同事为该角色
销售leader可查看自己 + 自己部门旗下成员的线索、客户、联系人、商机、订单、开票、回款
销售人员可查看自己的线索、客户、联系人、商机、订单、开票、回款
售前leader审批销售订单业务线和金额，以及自己所属业绩线的商机和订单的查看权限
售前人员可查看所属业绩线的商机和订单；协助销售做产品演示、需求调研、方案设计与技术答疑；参与商机推进阶段、订单评审与投标应答，输出报价单/技术方案/POC 测试报告等文档
市场人员主要导入销售线索以及追踪线索进度、查看所有线索、线索生成的客户、联系人和商机；策划市场活动、运营内容投放与渠道推广，分析线索转化漏斗

八、分模块待办

本板块只记录仍需补充确认的事项。优先级定义：P0 = 阻塞主流程、状态或核心数据模型；P1 = 阻塞模块详细设计和跨域协同；P2 = 不阻塞主流程的优化项。待办确认前不得固化为代码、枚举、审批流或接口契约；已确认规则统一见附录 A。

编号模块优先级当前边界待办内容影响
C-05合同 / 金蝶P1当前只确认提交开票申请时将申请数据直接同步金蝶；不建立「合同审批 → 财务协同」链路，也不预设其他回款或财务回流后续如业务边界明确，再补充开票申请之外的系统交互；确认前不进入本版流程开票申请接口、系统边界
C-07CRM / 商机与报价P1商机可有多个报价轮次，但只有最新一版为有效报价（last）；商机金额、产品或指定字段变化时，最新报价失效并重新提报，与报价无关的字段变化不影响报价确认会导致报价失效的完整字段清单，并配置字段级影响规则商机变更、报价版本、失效判定
C-08PMOP0项目由 PMO 手动创建和管理；订单确认或合同审批通过均不自动生成正式项目或交付准备单补充 PMO 手动立项的发起条件、关联订单/合同规则、编号、取消、重复校验和历史数据处理PMO 流程、项目关系、项目状态机
C-10CRM / 合同P0合同审批当前只保留通用审批占位；开票申请是审批完成后的独立动作确认合同必要提取字段；补充合同审批节点、审批人/角色、审批内容、通过条件和驳回处理合同表单、AI 提取、审批流
C-11PMOP1交付资源提前投入归 PMO 管理补充适用场景、审批、投入期限、停工/恢复、例外和已发生资源处置PMO 资源与审批管理
C-12PMOP1项目层级、基数和主 owner 均由 PMO 管理确认总项目/子项目/项目群、父子关系、编号、跨事业部归属和主 owner 规则项目模型、权限和汇总
C-13PMOP0立项数据来源和预算校验归 PMO 管理确认手动立项的数据来源、成本口径、预算阻断、币种含税口径和变更版本项目字段、预算与成本
C-14PMOP0内部验收及其与开票、供应商付款的前置关系归 PMO 管理确认验收对象、阶段、审批人、通过条件、例外审批和解锁事件验收、开票和采购付款
C-15PMOP0项目结项条件归 PMO 管理确认结项硬条件、事实源、无供应商场景、坏账/终止/部分结项和强制结项例外项目状态机、结项校验
C-16PMOP1Timesheet 工时报工归 PMO 管理确认人员范围、项目/非项目归属、工时上限、补报、退回、锁定、审批和成本换算工时实体、审批和预算
C-17PMO / 采购P1采购归口和供应商合同作为 PMO 协同事项处理确认采购申请、采购单、供应商合同的对象关系及 PMO/采购/业务权限采购域、供应商合同、成本回流
C-18PMO / 财务P1回款资金占用和风险升级作为 PMO 协同事项处理确认资金占用算法、风险阈值、升级对象、执行动作、关闭和重开规则风险看板、回款模型、通知
C-19PMOP1项目成本分类和执行期管控归 PMO 管理确认成本分类、计提、差旅、预算占用/释放、超预算和历史豁免规则成本项、预算引擎、历史迁移
C-20PMOP0验收、收入计划和收入确认职责归 PMO 模块牵头梳理确认客户/内部/供应商验收以及收入计划、收入确认的正式角色和 RACI角色、权限、验收和收入流程
C-22PMOP1PMO 审批时效和升级机制暂未定义确认 SLA、工作日口径、提醒、超时升级、转交和自动处理规则审批引擎、通知和运营报表
C-23跨模块治理P0端到端角色表和 RACI 尚未覆盖 CRM、合同、PMO、采购、财务、法务和客户确认正式角色、所属组织、发起/审批/执行/知会责任、数据范围、代理和职责分离角色表、RBAC、审批路由和审计

附录 A：已确认规则

以下事项已经确认并写入正文，不再占用待办表。

编号模块已确认规则影响
C-01CRM / 报价高价格标品满足既定适用条件时，由销售发起后直接流转至产品总监审核，中间审批节点跳过；路由条件和节点采用配置报价审批路由、审计记录
C-02产品管理「业务场景」是产品主数据的普通属性字段，与名称、分类等字段一并维护；报价产品明细引用产品时可读取该字段产品字段、报价产品引用
C-03CRM / 商机输单与无效拆为两套独立审批路径和专属原因库；销管管理员可直接调整，但必须记录操作者、对应原因和时间商机权限、原因字典、状态审计
C-04CRM / 报价报价审批节点、顺序和必经性均可配置；财务 BP 和产品 VP 不写死为固定节点审批配置、路由引擎
C-06CRM三类拆分相互独立：商机按业务线做业务拆分；报价按产品做产品拆分；销售提报订单时只填写产品明细和业绩提成比例，金额调整和提成信息由销管在审批过程中完成三个明细实体、表单和审批口径
C-09CRM / 合同时序上先有订单、后有合同；合同创建时必须关联一个或多个既有订单，订单可仍处于审批中。合同与订单为 N:M，项目归属由 PMO 后续管理合同入口、关联表、基数与时序约束
C-21CRM / 跨实体一致性商机、报价、订单审批时按「商机 → 最新有效报价（last）→ 订单」追溯，核对关联、内容和版本；一致且为最新才继续，不一致则报错，修改后重新审批审批校验、版本一致性、错误提示
C-25CRM / 客户与权限客户首次分配对象即为唯一当前责任人，责任人不是领导层级；责任人可组建客户团队，并按成员配置业务角色、读写/只读权限及线索、商机、订单等关联业务对象可见范围；历史“上位负责人”仅表示前责任人记录客户归属、团队成员、对象级权限、审计
A1CRM / 线索所有来源线索当前归属有效期统一暂定 14 天并支持配置；部门线索池和销售拓展池独立管理、保有期可分别配置线索池、归属与回收规则
A2CRM / 商机输单和无效使用独立审批路径及专属原因库；“零单”不提前固化，待业务另行确认商机审批、原因字典
A3CRM / 联系人联系人查重命中后可关联已有联系人并补充缺失信息，或取消错误录入，不重复新建联系人查重与关联
A4CRM / 客户与商机客户连续无有效跟进先提醒再调出，商机连续未填写销售记录只提醒；时长均可配置、暂定 30 天，且只认负责人本人记录提醒、调出、责任人判定
A5CRM / 线索AI 无效标签仅作为提示，是否调出由销管人工判定，不因无效标签自动回收AI 标签、人工调出
A6CRM / 订单赢单审批通过后系统自动生成订单草稿并提醒销售确认提交；手动创建仅作补充赢单、订单创建
A7CRM / 订单审批时反向追溯商机、最新有效报价和订单，检查关联、内容及版本一致性；不一致时阻断并提示修改，修改后重新审批跨实体一致性、版本校验
A8CRM / 提成销售提报订单时只填产品明细和业绩提成比例；销管在审批过程中调整金额并补录提成信息，可能等待合同两至三个月，最终通过后全部事实固化订单长审批、提成核算、事实锁定
A9/A10CRM / 商机销售创建商机时填销售赢单率；审批后 AI 计算并保存独立的 AI 赢单率。销管未填时引用 AI 值，销管填写后以销管值为准，AI 字段仍保留三类赢单率字段、默认引用、预测
A11CRM / 合同与金蝶合同创建时挂接既有订单；当前只确认提交开票申请时将申请数据直接同步金蝶，其他财务协同暂不界定合同订单时序、开票申请接口

附录 B：跨域事件流汇总

当前边界：订单确认和合同审批通过均不自动创建项目。CRM 与金蝶当前只明确「提交开票申请时同步申请数据」这一项；其他合同后财务协同暂不进入本版。PMO 手动立项规则见 C-08。

事件发送方接收方触发的动作
PMOProjectCreated（待定义）PMOCRM / PMO仅在 PMO 手动创建项目后记录关联结果；正式事件名和载荷待 C-08
AcceptanceCompletedPMOCRM更新订单交付状态
RevenueRecognizedPMOCRM / 金蝶回流收入结果到经营分析；同步应收应付
PurchaseRequestedPMO采购发起采购流程
PurchaseCompleted采购PMO / 金蝶回流采购成本到 Project.CostItem；同步采购付款/发票
InvoiceApplicationSubmittedCRM金蝶销售提交开票申请时，直接同步开票申请数据
OrgStructureChanged企微全部系统组织架构变更后几小时内全系统同步审批链

改动记录

本表记录对本文档的每次业务确认修改，用于后续同步至《L2C业务实体与关系总览》《L2C核心实体状态机》《L2C领域建模建议》及其他文档。每次改动请追加一行，勿覆盖历史记录。

日期板块改动内容说明 / 同步要点
2026-08-18线索（阶段一/二）被回收线索的去向由「销管线索池」更正为「回收线索池」回收 / 超时 / 30 天无跟进的线索统一进入「回收线索池」，由销管运营重新分配或暂时搁置
2026-08-18线索（阶段一/二）首次跟进时限由「24 小时硬性要求」改为「可配置」，暂定 24H拿到线索后的首次跟进时限支持配置，当前暂定 24 小时
2026-08-18线索（阶段二）销售记录关联说明简化，删除「不强制关联到其他对象」线索可直接挂销售记录，去除易误解的补充说明
2026-08-18商机（阶段五）当时删除「AI 赢单率」独立字段并改为两类赢单率该理解已于 2026-08-19 纠正：恢复独立 AI 赢单率字段，三类字段并存
2026-08-18报价（阶段六）报价 Excel 由「按业务线分类填列」改为「按产品分类填列」报价明细按产品组织；业务线仅用于审批流与金额一致性校验
2026-08-18订单（阶段七/八）订单初始状态「待确认」统一改为「草稿」涉及赢单、订单两阶段及数据流汇总表
2026-08-18订单（阶段八）订单创建恢复「销售手动提订单」主路径，系统自动生成仅为补充保留销售主动提订单能力，自动创建作为补充
2026-08-18订单（阶段八）「业绩归属拆分比例」明确为「销售业绩归属拆分比例」；删除「不是后置独立流程」等冗余解释明确由销售填报的销售业绩拆分
2026-08-18订单（阶段八）当时将订单修改限制暂列 C-21/SM-06 待办该待办已于 2026-08-19 关闭，改为商机、最新报价、订单的关联与版本一致性校验规则
2026-08-18合同（阶段九）合同与订单 N:M 已确认；合同审批流继续按 C-10 预留待办合同仅关联订单；必要提取字段和审批规则待补充
2026-08-18状态机（C-21）按状态调研重写核心实体状态机，并将状态维度、线索 14/30 天回收、订单修改、合同归档和回款枚举差异显式列入 SM-01 至 SM-10HTML 继续作为现行权威基线；调研补充未冲突部分，冲突项独立确认后再同步实现
2026-08-18分模块待办与附录第八部分改为纯待办表；C-01、C-02、C-03、C-04、C-06、C-09 移至附录 A待办按模块和 P0/P1/P2 管理，已确认规则不再占用待办表
2026-08-18客户归属与团队权限（C-25）删除“上位负责人类似销售 Leader”的错误理解；客户首次分配对象即为责任人，责任人可组建团队并配置角色、操作权限和关联对象可见范围历史“上位负责人”仅作为前责任人记录；同步客户实体、权限模型和客户分配状态机
2026-08-19线索（A1/A5）线索归属有效期统一暂定 14 天并支持按池配置；补充部门线索池、销售拓展池；AI 无效标签不自动回收销管人工判定无效线索是否调出；保有期超时回收仍按独立规则执行
2026-08-19联系人（A3）查重命中后支持关联已有联系人并补充缺失信息错误录入可取消，不产生重复联系人
2026-08-19客户 / 商机（A4）新增客户无有效跟进的提醒与调出机制、商机无销售记录提醒机制时长可配置，暂定 30 天；两类判断均只认负责人本人填写的记录
2026-08-19商机赢单率（A9/A10）恢复独立的 AI 赢单率字段；销管未填写时默认引用 AI 值，销管填写后改用销管值销售赢单率、AI 赢单率、销管赢单率三类字段并存；AI 字段始终保留
2026-08-19商机结果（A2/C-03）输单和无效拆为独立审批路径和专属原因库“零单”暂不固化为独立状态，等待业务确认
2026-08-19商机 / 报价版本（C-07/C-21）明确同一商机只保留最新报价为有效版本（last）；商机指定字段变更使报价失效，审批时追溯商机、最新报价和订单的一致性具体影响报价的字段清单仍在 C-07 待确认；C-21 作为已确认一致性规则移入附录
2026-08-19赢单 / 订单（A6/A7）自动生成订单草稿并提醒提交；订单审批改为关联、内容和版本一致性校验，不一致时修改后重新审批不再描述自动强制回写上游对象
2026-08-19订单提成（A8）销售只提产品明细和业绩比例；销管在审批中调金额、补提成，等待合同期间保持审批中，最终通过后固化审批可能持续两至三个月，最终通过才形成固定事实
2026-08-19产品字段（C-02）明确「业务场景」只是产品主数据字段，报价明细通过产品引用取得产品进入实体关系，不把业务场景单独建模
2026-08-19合同 / 金蝶（A11/C-05）删除合同审批后的财务协同和回款确认链路，只保留提交开票申请时直接同步金蝶合同创建时挂接上游订单；其他财务协同以后再界定

— L2C 端到端业务流程权威基线 —