S21-A11 · 对外承诺的管理：答应了之后怎么办

销售在客户现场答应了"下月上线"，工程这边一周后才知道——从那天起，团队不是在交付，是在还一笔没人核算过的债。

承诺管理的核心不是"别说大话"，是让每一个说出去的日期都有出处、有缓冲、有人负责改。 这篇谈判据：承诺有哪几种形态、谁有权说、缓冲放在哪、变更怎么走、失约之后怎么办。

1. 三种成本，第三种会复利

成本	什么时候付	可控性	量级
履约成本	承诺期内，加班或缩范围兑现	中	当期产能 10–30%
变更成本	改日期或改范围	高	一次谈判 + 信任折损
失约成本	到期未兑现	低	复利：此后承诺被打折

失约的复利来自定价机制：客户不会记住"这次没做到的原因"，只会把这家供应商的承诺打一个折。此后每次说"下月上线"，对方内部都要加一个缓冲，于是真实交付期被要求提前，压力反过来又推高失约率。

这条链条很难靠一次成功交付打断，连续三个承诺准时兑现，折扣才回一点。

// 承诺成本三记法，缺一种就低估
承诺 = 履约产能 + 缓冲 + 变更概率 × 谈判成本
失约 → 客户缓冲 ↑ → 要求提前 ↑ → 失约率 ↑   (正反馈)

2. 四种承诺形态

形态	承诺的是什么	谁最容易许	违约判定
日期	某天/某月能用	销售、售前	到期是否可用
范围	一定包含哪些能力	产品、方案	功能清单是否齐全
质量	达到什么水平（性能、稳定）	技术负责人	指标是否达标
能力	能做某件事（不限时间）	全员	需求是否可实现

四种形态经常被同时许出去，而日期与范围同时锁死，必然有一头失守：技术不确定性不会因为承诺而消失，它只会转移到"缩范围"或"延期"两个出口上。可行的组合只有三种——锁日期放范围、锁范围放日期、锁范围与质量但放具体日期。

判断是否超载问一句："难度翻倍时哪个维度可以让？"答不出来，说明四个维度全锁死了。

3. 承诺权归属

承诺内容	有权承诺的人	越权的组织成因	后果
具体日期	交付负责人（有排期权者）	销售背着 KPI，日期是最强签单工具	工程被动接单
范围裁剪	产品 + 交付共同	谁都能对客户说"这个简单"	缩范围时无人认账
质量指标	技术负责人	售前拿旧数据当基线	达标口径不一致

越权承诺总能发生，原因不在品质：说"行"收益即时（签单），说"不行"成本即时（冲突），代价却延后（延期、加班）。 这种时间错配靠意识解决不了，只能靠制度：未登记的承诺不进产能核算，也不被承认。

4. 表述方式与适用场景

表述	例子	适用	代价
确定日期	12 月 15 日上线	需求稳定、技术路径已验证	缓冲不足时必然失约
区间	12 月中下旬，最迟 12 月 20 日	有 1–2 个未验证环节	客户可能只记住晚端
条件式	若 11 月底完成接口联调，则 12 月 15 日上线	依赖外部方	需要有人持续跟依赖
里程碑式	12 月可用查询，1 月可批量	能力可分阶段交付	需要客户理解分阶段含义

条件式承诺被低估：它把不可控部分写出来，客户因此可能提前知道延期。代价是得有人真去跟那个依赖，否则退化成"到时候再说"。

// promise.yaml ── 一条对外承诺的最小登记
id: C-2026-041
form: date+scope          // 日期与范围都锁 → 必须写缓冲与出口
text: 12/15 上线，含退款与对账
depends_on: [接口联调 11/30]
owner: 交付负责人          // 唯一有权改日期的人
buffer_internal: 12/8      // 内部目标，不对外
exit: 缩范围（去批量）  // 难度翻倍时让哪一项

5. 缓冲放在哪

缓冲只有一种正确放法：内部承诺早于对外承诺，且缓冲量不公开。

放法	表现	结果
不放缓冲	内部目标 = 对外日期	任何波动都直接变成失约
公开缓冲	"我们 12 月 15 日上线，其实 12 月 8 日就能好"	客户记住 12 月 8 日，缓冲失效
内部缓冲	内部 12 月 8 日，对外 12 月 15 日	有一周吸收波动

常见失控是最后一行：缓冲一宽裕就被拿去填别的事，到期自然消失。硬规则一条：缓冲不能被用来接新承诺。

6. 变更流程

项	必须明确的内容	不明确的后果
提前多久	提前通知的最小时长（与交付周期成比例）	到期才说，等于失约
谁来说	唯一对外口径的负责人	多个人给不同说法
说什么	新的日期或范围 + 一句原因 + 影响	客户自行脑补原因

变更本身不致命，方式致命：提前三周并给替代方案，通常被接受；到期当天才说，延三天也记成失约。客户要的不是准确日期，是能向老板交代的时间。

// 变更通知检查：三条都满足才允许发出
// 1) 距原承诺日 >= 提前通知时长
// 2) 含新日期或新范围，不能只有"要延期"
// 3) 由台账 owner 发出，不是转述

7. "尽力而为"等于没有承诺

"我们尽量""应该问题不大""下周看看"——这类表述在组织里被当成安全的缓冲，实际效果相反：它让客户按最好的理解去转述，而工程按最坏的情况去准备。

表述	客户的理解	工程的理解	结果
尽量下周给	下周一	有空就做	下周三被追问
问题不大	一定能做	大概能做	发现做不了时已无退路
到时候看	有安排	不在计划里	排期会上才发现

// 把模糊表述改写成可核对的句子
尽量下周给 → 11/20 联调完，我给你确定日期
问题不大 → 能做，但依赖 A 接口，A 不通就做不了
到时候看 → 这不在计划里，要做得走变更

唯一正确的模糊：明说"还不能给日期"，并给出能给出日期的时间点。模糊的是日期，不是责任。

8. 总量不能超过可靠产能

承诺管理的算术只有一条：在途承诺的所需产能 ≤ 可靠产能 × 折扣系数。可靠产能要扣掉值班、故障、审批、会议，通常不是名义人力的全部。

口径	典型偏差	用法
名义人力	高于实际 20–40%	只用于预算，不用于承诺
可用人力（扣值班与会议）	接近实际	排承诺的基数
可靠产能（再扣故障与波动）	略低于实际	承诺只能用这个数

校准比口径重要：用过去四个季度达成率反推系数。70% 说明承诺总量约为可靠产能 1.4 倍，该削的是数量。

// 承诺台账，每季度核一次
reliable_capacity = 可用人力 × 历史达成率
in_flight_commitments = Σ 每条承诺所需产能
if in_flight > reliable_capacity → 停止新承诺，先做变更

9. 对外承诺与内部路线图错位

两张表对不上是常态：对外按客户重要性排，内部按技术依赖排。错位的代价通常由工程承担。

错位形态	表现	处理
承诺未进路线图	承诺只活在合同与聊天里	承诺必须占路线图的一个条目
两个承诺争同一资源	两条都承诺同一批人	冲突要在承诺前发现，不是交付前
承诺依赖未立项工作	承诺背后有一块没人负责的地基	承诺时同步立项，或改承诺

检查很土但有效：承诺清单与路线图并排，逐条问"这条在第几行"。答不上来的就是事故种子。

10. 失约之后

处理方式	适用	代价	禁忌
补偿交付	范围可减、日期不能动	客户拿到的少了	悄悄减，不告知
降级交付	核心可用、周边缺失	需要客户接受半成品	把半成品说成完整品
延期 + 透明说明	质量不能降	信任折损	到期当天才说

第一条最常被误用：缩范围本身不是问题，不告知才是问题。客户发现"说好的三样只给了两样"，伤害大于延期本身——因为延期是可预期的风险，隐瞒不是。

必做动作：把原因写进台账，调整下一条的缓冲；不调整就会连续失约。

11. 度量

指标	口径	读到什么	反噬
达成率	按承诺日期或范围兑现的比例	承诺是否超产能	靠缩范围刷高
变更次数	每条承诺的平均变更次数	前期评估是否充分	压制变更 → 到期失约
提前通知时长	变更距原日期的天数	变更方式是否体面	只发通知不改计划
失约影响面	受影响客户数 × 合同金额级	该优先修哪个环节	只统计大客户

读法：达成率稳定 + 变更不为零 + 通知时长在增长才算健康。100% 通常许得太保守。

12. 排错

现象	可能原因	验证
工程总在"救火式接单"	承诺不经交付方	查承诺登记是否有 owner
到期前一周才发现做不完	无内部缓冲或缓冲被挪走	对比内部目标与对外日期
客户觉得"总在变"	变更无统一口径	查变更是否由同一人发出

13. 边界

场景	为什么正式管理不划算	替代
内部口头协作	无对外约束，成本高于收益	明确"这次不算承诺"
可随时调整的探索项目	目标本身在变，日期无意义	约定评审节奏而非日期
对方只在乎能力	日期不是决策依据	用能力清单沟通
紧急故障支援	当时只能承诺"在处理"	承诺状态更新频率，不承诺结果

另一条边界：承诺对象是内部团队时，正式流程常变负担，跨团队接口靠清单与联调节点表达更有效。

14. 自测

失约成本为什么会复利？靠什么打断这条链条？
日期与范围同时锁死时，为什么必然有一头失守？
越权承诺的成因是收益与代价的时间错配，制度上怎么对冲？
条件式承诺的代价是什么？它需要什么配套动作才成立？
缓冲被"用来接新承诺"之后，会发生什么？
达成率 100% 为什么不一定健康？