客户拉通大表 · 产品介绍
内部使用 · 两层设计（第一层项目推移表 / 第二层活动录入与待办）
DEMO 原型 · 示例数据，未上线 · 本页仅说明设计与口径，非线上产品
01
一句话定位
Positioning
把「销售活动 → 资源协作 → 部门闭环 → 商机成交」拉通成一条可追溯链路的客户项目运营平台 —— 一行一商机看得见项目走到哪、一条活动拉得动跨部门资源，并把机会性商机断尾与客诉替换周期变成可预警的规则。
它以《客户拉通大表》原型（工具/客户拉通大表_demo.html）为载体，后端落在 CloudBase 七表 + 宽表/列定义表（结构清单 §1 / §8）。
02
它解决什么问题
The gap
- 信息分散：活动在飞书、订单在 ERP、待办散在多个地方；查一个客户项目的来龙去脉要拼好几张表，且各表 ID 互不打通。
- 跨部门协作靠人催、无留痕：销售、技术支持、研发之间的请求与回复靠口头/群里喊，谁在何时做了什么，缺一条统一的过程记录。
- 机会性商机断尾无预警：上年度的机会性商机（如一次性大单）本年度未延续时，往往事后才发现，没有提前提醒机制。
- 客诉 → 替换 → 采购恢复无周期度量：替换做了多久、采购何时恢复，没有统一口径与基线，无法度量服务效率。
依据：结构清单 §13（机会性商机断尾、客诉替换周期两个真实案例）；数据源盘点 §4（三类 ID 缺口：活动→客户 / 活动·订单→商机 / 商机→客户）。
03
两大层
Two layers
第一层
项目推移表（一行一商机）
里程碑轨道：默认形态为「形态1 里程碑轨道」（一行一商机、8 节点圆点串、按 4 个部门分组、行可点）。项目按「部门：大客户部 / 销售拓展部 / 生物制药销售部 / 国际业务部」分组。
商机性质标记：每行带 chip —— 机会性持续性待判；工具条提供「全部 / 机会性 / 持续性 / 待判」筛选（点选即过滤第一层行，可复位）。
项目关键节点可向右延展：陌生开发 → 方案匹配 → 中试 → 临床试验 → 已确认被用于注册 → 已转产 → 客户已获证 → 新证迭代（＋ 新增节点列）。
资源协助列每选一类 ＋1 列：列名 = 选项名 ＋ 序号 N（技术支持测试项目单N / 研发项目单N / 售后N / 其他N）。
点行展开第二层：点任意一行 → 下方展开该商机的资源泳道矩阵（形态B）。
第二层
活动录入与待办（一行一活动）
活动类型 ＋ 模板化活动描述（段级校验）：活动类型 3 类（测试结果跟进 / 采购跟进 / 客户档案完善）；描述按类型套模板，测试结果跟进须含 6 个必填段（段级校验，缺段拦截）。
四类资源协作手动多选：技术支持测试项目单 / 研发项目单 / 售后 / 其他（「其他」必填说明）—— 由销售手动多选触发，选中即生成承接待办。
待办事项：事项 / 负责人 / 时间节点（×N，可加多条）。
周会决议（三岗各填一栏）：销售 / 技术支持 / 研发 三岗各填一栏，提交后落盘待办库 support_todos。
三轨落盘：本地记录（活动编号）／ CloudBase 集合 ／ 飞书描述一键复制。
图 1 · 两层联动：第二层活动录入 →（按「客户名称 + 商机名称」抓取）→ 第一层项目推移表 →（回写：节点推进 · 资源协助加列）
04
六大机制
Six mechanisms
机制 ①
两层联动
第二层提交一条活动 → 第一层对应商机行自动更新（节点推进、资源协助 ＋1 列）。
为什么要它：活动不再只躺在飞书里，一处录入，项目视图即时同步。
机制 ②
按角色分字段权限
销售 / 技术支持 / 研发各写各栏，管理员不受限（可全字段读写）。
为什么要它：跨部门协作时谁改哪一格有边界，避免互相覆盖、责任说不清。
机制 ③
资源协作手动触发 ＋ 自动加列
第二层「资源协作（多选）」勾选 技术支持测试项目单 / 研发项目单 / 售后 / 其他，每选一类第一层「资源协助」组自动加一列（列名带序号 N）。
为什么要它：资源请求由人明确发起、系统留痕，不靠口头催办。
机制 ④
段级校验（缺段拦截）
活动类型 = 测试结果跟进时，描述须含 6 个必填段（客户需求 / 宝锐方案 / 测试结果 / 问题现象 / 客户反馈 / 待办事项），缺段 → 提交被拦截并提示缺哪段。
为什么要它：把「填写质量」前移到入口，避免事后补不齐、口径不一致。
机制 ⑤
三轨落盘（可追溯）
一条活动同时写三处：本地记录（活动编号）／ CloudBase 集合 ／ 飞书描述（一键复制）。
为什么要它：任一轨都能回溯同一动作，换系统、换人都不丢记录。
机制 ⑥
两块预警
④ 机会性商机流失预警（机会性商机 连续 N 个月无活动 / 无订单 → 提醒；过预计成交窗口 60 天仍未成交 → 复盘）＋ ② 客诉 → 替换 → 采购恢复周期（6 阶段进度条，替换周期基线 ≈60 天）。
为什么要它：把「下季度能自动预警」做成规则，机会性断尾与客诉长尾提前暴露。
| 商机性质判定（机会性判别三条 · §13.1） | 可执行口径（输入 = 客户近 12 个月订单 + 商机框架字段 + 金额占比） |
|---|
| 机会性（任一命中） | ① 该客户近 12 个月该品类订单 ≤1 单（无历史复购）；② 无框架 / 年度协议字段；③ 预计金额占客户年采购 >40% 且集中在单一项目。 |
| 持续性 | 三条均不满足机会性条件（有稳定复购、 有框架协议、 金额分散且占年采购 ≤40%）。 |
| 待判 | 复购 / 框架 / 金额占比三项数据任一缺失到无法判定 → 转人工复核。 |
05
数据从哪来
Data sources
图 2 · 数据对接：ERP 订单（对接键 = 单据编号）· 飞书（活动/客户/商机/客诉）· CloudBase 集合 → 客户拉通大表 → 成交 / 闭环
来源 ①
ERP 订单
订单记录，对接键 = 单据编号（飞书 销售订单.name ≡ ERP 单据编号，两侧完全一致）。
对接键是既有的、现成的，不需要新造编码就能把订单挂到客户项目上。
来源 ②
飞书
活动 / 客户 / 商机 / 客诉四类工作项；空间与表 ID 见右侧清单（盘点 §2）。
销售日常在飞书写活动，拉通大表直接复用，不要求二次录入。
来源 ③
CloudBase 集合
落库集合见对接图（activities 沿用现有集合，其余新建）。
统一落到一套集合，才谈得上跨表关联与「只追加不覆盖」的留痕。
| 飞书实体 | 可调用 ID / 字段（逐字） | 关联到 |
|---|
| 销售管理空间 | 6593cd71471290e3cc6be6e6 | 全部飞书表 |
| 售后管理空间 | 658288abfb8bd616b17025f1 | 客诉 |
| 客户 · 工作项类型 | 65ae1e403c87b152f3365ca6 | cust_master（表A） |
| 销售订单 · 工作项类型 | 662612aea6bb7089fea044ef | orders（表F） |
| 活动 · 工作项类型 | 65ae1e5d44338dbe7c39a29a | activities（表C） |
| 客诉(客户反馈单) · 工作项类型 | 6669433056a98249604376de | dept_feedback（表E）/ 售后 |
| 商机 · 工作项类型 | story | opportunities（表B） |
| 订单 · 单据编号（对接键） | name（例 ZHBR260907070） | orders ↔ ERP |
集团归集口径（硬性）：集团维度只能用 ERP 表的 集团客户# 列做归集键 —— 不能用客户名关键词匹配。实测：某集团客户名不含集团关键字的抬头会被整个漏掉，实测漏 68.6% 金额。
出处：脚本/统计_天隆_按抬头_货号统计.py 交叉核对输出「2026 集团归集总额 1228060.00 ｜ 客户名含『天隆』385310.00 ｜ 差 842750.00」→ 842750 / 1228060 ≈ 68.6%。
06
当前状态与上线路径
Status & rollout
当前状态：DEMO 原型，示例数据，未上线。所有页面（基线 工具/客户拉通大表_demo.html、仪表盘 工具/客户拉通大表_仪表盘.html）为零外链、数据内嵌的静态页，不联网；后端七表结构已设计但尚未建库。
1建 CloudBase 集合（七表 + 宽表 / 列定义表）
2权限与鉴权（按角色分字段 · 服务端二次校验）
3小范围试点（大客户部）
4推广
待确认项（沿用数据源盘点 §5 / 结构清单 §7）：
- 飞书可写性：`create_workitem` 可用的 `work_item_type` / `template_id`（现 `销售工作台服务.py:3392-3397` 用 `template_id:'700373'`，是否通用）待确认。
- 客户 ID 是否随活动返回：`field_5f20fc` 读回只有 label（客户名），MQL 能否取客户 `work_item_id` 待确认。
- 商机「关联客户」字段名是否存在于 `story` 表 —— 影响 `opportunities.customer_id` 回填。
- 课题组口径：以 `ketizu_list.json`（1744，飞书商机）还是 ERP 商机(飞书)#（88.68% 覆盖）为准。
- 订单 `field_8d9153` 是否 = 出货批号#（值形如 `20260417`）待确认。
07
可度量的价值
Measurable value
每项指标都给出上线后从哪张表 / 哪个字段取数（DEMO 为示例值，不在此页给出执行数字）：
| 度量指标 | 口径 / 公式 | 上线后取数位置 |
|---|
| 资源闭环率 | 已闭环待办 / 全部资源协助待办 | 分子分母均来自集合 `support_todos`（`status` 归一后统计；§1 表 D）；事件留痕在 `thread_view`（`event_type = todo_close`）。 |
| 替换周期 | 替换完成日 − 客诉发生日（基线 ≈60 天） | 集合 `replacement_cases`：`replace_done_date − complaint_date` 即 `cycle_days`（§13.2 A/C）。 |
| 机会性商机断尾预警数 | 机会性商机连续 N 个月（默认 3）无活动 / 无订单 的条数 | `opportunities.nature = opportunistic`（§13.1 A）叠加 `thread_view` / `activities` 的最新事件时间计算沉默月数。 |
| 活动填写合格率（段级校验拦截数） | 提交被拦截次数 / 提交尝试次数 | 前端 `#formErr` 拦截计数 + 采集字段 `activities.desc_content`（段级校验口径见结构清单 §12.3）。 |
| 周会决议落盘条数 | 提交后落盘 `support_todos` 的决议条数 | 集合 `support_todos` 中 `source = 周会决议`、`todo_id` 前缀 `WR-` 的文档计数（§11.2）。 |
口径来源：结构清单 §1（表 D/E/G）、§9.8、§11.2、§12.3、§13.1 / §13.2。替换周期基线 ≈60 天（天隆 M5244-ZJ4 → MD2104-003006，客诉 2026-07-01 → 替换完成 2026-08-30，出处：结构清单 §13.2）。
