这张表不含任何报价：CRM Agent 目前没有谈过价格，所以「投入」「回收期」两列整列不做。 剩下的问题只有一个 —— 这套东西一年给立邦 TUB 带来多少钱的价值，钱从哪一类里来，以及不做的话会怎样。
表从左往右按判断顺序排：年化价值（按增收／提效／提质／风控／合规五类拆，锚在 TUB 的签约额与人力口径上） → 不做的损失 → 覆盖谁 → 现在能不能真跑。 把鼠标划过、或点一下那个金额，算式就在原地展开，不进弹窗；点任一行，展开这条能力在系统里的真实形态。 金额全部由下方参数实时算出，预填 的参数请以贵司实际数替换。
第 1 行的价值不计入合计。它的方案已经写完（docs/tub/17-字段优化方案-销售减负），
但「必填从 12 项收到 7 项」这一步还没落到代码里 —— 表里标成待落地，金额灰掉。
一张全是绿灯的价值表说服不了人，所以每一行都要先答「现在能不能真跑」。
| 能力 | 年化价值划过 / 点击看算式 | 不做的损失 | 覆盖谁每年多少次 | 现在能不能真跑后端 · 界面 · 回归 · 线上 | |
|---|---|---|---|---|---|
| 合计 · 12 条能力— | — | 合计年化价值 ≈ 年签约额的 —。 CRM 类系统的行业价值基准通常按「销售事务工时降 10%–20% ／ 赢率 +1–5pt ／ 撞单与无效商机损失降 30%–50%」计， 本表逐项落在这些区间的保守端，并对所有与赢率相关的口径统一乘了一个可调的归因系数。 | |||
与采购侧的评估表不同，CRM 的钱主要不在「降本」上，而在「同样的人能签更多、少签错、少撞单」。所以第一类是增收，不是降本。
改任何一格，上面整张表实时重算。标 预填 的是我方按 TUB 业务形态估的数， 没有一个来自贵司的真实读数 —— 请直接改。人天成本只用于把节省的工时折成金额，与本系统的任何费用无关。
这些不是独立的价值项，是上面每一条能力都踩在上面的地基。单独给它们记一笔会和上面的行重复计算，所以只列不算。
年化价值 = 五类之和，每一类的算式都写在对应行的展开区里，逐项可查。凡是与赢率、成交额相关的口径， 一律再乘一个归因系数（预填 30%）—— 因为签下一个项目从来不是系统一个人的功劳， 不乘这一刀的价值表看着好看，但站不住。工时折算统一按销售侧人天成本，与本系统费用无关。
主要价值我方拿不到读数、没折成金额的，标「未算全」。 它不等于不划算，只等于没算全：比如跟进记录来源可溯（妙记 vs 手写）对预测可信度的作用、 拜访门头照与离场测距对拜访真实性的作用、审批等待时长从天级压到小时级对项目周期的作用 —— 这三件事都真实存在， 但把它们折成钱需要贵司的历史数据，现在没有。
「现在能不能真跑」四项各 1 分：后端有路由（接口真的在跑，不是画的）、前端有界面（人能点，不是只有接口）、
有回归测试（npm test 里有这一条，改坏了会红）、线上已验证（生产环境上跑过真实数据，不是只在本机）。
仓库里现有 66 条回归脚本全部进了 npm test。
三处仍在路上，表里已逐条标出，不藏在「功能很全」里面： ① 报备必填收口（12→7）方案已出、代码未落，价值不计入合计； ② 妙记转跟进的线上飞书权限仍在审核（群聊与手写两条链路线上已通）； ③ 双包本部三件事本机走查通过，线上尚无真实业务样本。
能力清单与形态取自代码本身（server/src/modules/ 66 个模块、web/src/pages/ 62 个页面）；
业务规则与「不做的损失」取自 飞书CRM准备资料V1.xlsx（含《TUB事业群销售业绩销量计量规则》v4.1）
与 2026-08-17《立邦TUB业务调研》逐字稿、《CRM 商机管理与操作管理制度》。
业务量参数全部为我方预填，无一来自贵司实际读数。