销售承诺与研发计划脱节，通常源于承诺发生在需求进入评估之前：销售在客户面前给出时间点，研发计划里却没有对应条目，后续只能靠会议和口头同步追赶。本文给出一条固定链路，把销售承诺转成可评估、可排期、可追溯的需求记录，并说明字段、职责、承诺表达与验证方式，适合正在建立业产研协同机制的团队参考。
要点总览（TL;DR）
- 把销售承诺转成需求记录，固定走销售提交、产品评估、研发排期、承诺回复四个环节，四个环节共用同一条记录和同一套状态。
- 需求记录必须写清客户与商机、期望时间、承诺强度、验收口径、不可让步条件、商业价值与替代方案，字段完整才进入评估队列。
- 价值判断归产品负责人，可行性与工作量判断归研发负责人，每类评估结论都有回复时限，争议按约定路径升级并回写记录。
- 对外承诺与记录状态严格对应，采用条件式表述；范围、时间、验收口径变化时触发重新评估，承诺与计划通过同一条记录双向同步。
- 机制上线前核对字段、责任、状态映射与升级路径，运行后按月跟踪承诺可追溯率、评估按时回复率、承诺与计划一致率三项指标。
先定一条从销售承诺到研发计划的固定链路
对齐的起点是让每一条对外承诺都能追溯到一条需求记录。链路固定为四个环节：销售提交、产品评估、研发排期、承诺回复。四个环节共用同一条记录和同一套状态，任何一方更新状态，其他角色看到的是同一份信息。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 销售提交 | 客户诉求、商机信息、期望时间 | 按统一字段填写需求记录并提交 | 一条待评估的需求记录 | 记录字段完整，进入待评估状态 |
| 产品评估 | 需求记录、产品路线图、历史反馈 | 评估价值、优先级与范围，给出结论 | 纳入、有条件纳入、不纳入或待补充的结论 | 结论写入记录并通知销售 |
| 研发排期 | 已纳入的需求、团队产能 | 判断可行性、工作量，放入迭代或版本计划 | 计划条目与预计交付时间 | 需求关联到具体计划条目 |
| 承诺回复 | 评估结论与计划条目 | 按结论向客户表达承诺强度 | 对外承诺口径与记录状态更新 | 记录状态与对客户口径一致 |
链路能跑通的关键是交接点明确。销售提交后，责任转移到产品负责人；产品给出“纳入”结论后，责任转移到研发负责人；研发排期完成，销售才能对外给出带条件的承诺。每个交接点都以记录状态变化为准，避免用即时消息代替状态更新。
承诺状态与计划状态需要一一对应：记录处于“待评估”时，销售只能表达“正在评估”；处于“已纳入未排期”时，可以表达“已列入规划方向”；关联到计划条目后，才能给出具体时间窗口；评估结论为“不纳入”时，销售需要按替代方案回复客户。状态对应关系写进协作约定，销售在对外沟通前先看记录状态。
在工具承载上，这类链路要求销售、产品、研发看到同一份需求及其状态。ONES 提供业务、产品经理与研发团队三大视角，聚焦需求来源、产品规划及落地交付，并通过统一的需求池、工单与任务看板实时同步状态与信息，适合把上述四环节放在同一工作项体系中流转。
需求记录要写清哪些字段
字段的作用是让不同销售提交的需求具备可比口径，产品评估时不必反复追问背景。下表可直接作为提交模板使用，必填字段缺失时记录不进入评估队列。
| 字段 | 填写要求 | 必填/选填 |
|---|---|---|
| 客户名称与商机阶段 | 写明客户、商机金额量级与当前阶段（意向、投标、签约谈判等） | 必填 |
| 需求描述 | 用客户业务语言描述要解决的问题，附客户原话或场景说明 | 必填 |
| 期望交付时间 | 写明客户期望的时间点及该时间的来源（合同条款、客户内部上线计划等） | 必填 |
| 承诺强度 | 标注当前对客户已表达的程度：未提及、口头方向性提及、已写入商务文件 | 必填 |
| 验收口径 | 客户判断“能用”的具体标准，如流程、数据量、对接系统 | 必填 |
| 不可让步条件 | 不满足则商机无法推进的硬性要求，逐条列出 | 必填 |
| 商业价值 | 合同金额、标杆意义、可复用的行业场景 | 必填 |
| 替代方案 | 现有产品能力、配置或人工流程能否部分满足 | 必填 |
| 关联客户历史需求 | 该客户此前提交过的相关需求编号 | 选填 |
| 竞争情况 | 客户是否在对比其他方案及对比要点 | 选填 |
“承诺强度”是最容易被忽略的字段。销售已经口头答应客户时间点、但尚未写入商务文件时，记录里必须如实标注，产品评估才能判断这条需求的紧迫程度。隐瞒已表达的程度，会让评估建立在错误前提上。
“验收口径”和“不可让步条件”决定研发工作量的估算边界。只写“需要报表功能”无法评估，写清“按区域维度出月度汇总，支持导出给财务系统”才能判断是配置还是开发。销售提交时多花十分钟写清这两项，可以省去评估阶段多轮澄清。
产品评估与研发排期怎么分工
分工的核心是让价值判断和技术判断分开，各自有明确责任人和时限。销售负责信息完整与客户沟通，产品负责人负责价值与优先级，研发负责人负责可行性与工作量，交付负责人负责已承诺需求的落地衔接。
| 角色 | 主要职责 | 时限约定（示例） |
|---|---|---|
| 销售 | 提交完整需求记录；向客户传达评估结论；承诺变更时第一时间更新记录 | 提交后补充信息在 1 个工作日内完成 |
| 产品负责人 | 评估需求价值、与路线图的匹配度，给出纳入结论与优先级 | 收到完整记录后 3 个工作日内给出结论 |
| 研发负责人 | 对已纳入需求判断技术可行性、估算工作量，放入迭代或版本计划 | 评估结论下达后 5 个工作日内完成排期判断 |
| 交付负责人 | 确认交付资源与实施条件，反馈交付侧风险 | 排期确定时同步确认 |
时限数字需结合团队节奏设定，上表仅为可调整的示例。关键是每个环节都有承诺的回复时间，销售能据此管理客户预期，而不是无限期等待。
评估结论统一为四类，写入记录并附理由：
- 纳入：进入研发排期，销售可给出带时间窗口的承诺。
- 有条件纳入：在满足特定前提（如客户确认范围、资源到位、依赖项就绪）后纳入，销售对外须同时说明条件。
- 不纳入：本期不做，记录中写明原因与替代方案，销售据此回复客户。
- 待补充：信息不足无法判断，列明需补充的字段，退回销售。
争议升级路径同样要事先约定。销售对“不纳入”结论有异议时，先与产品负责人基于记录中的商业价值和替代方案沟通；仍无法达成一致，提交至产品与销售共同的上级在约定时间内裁决，裁决结果回写记录。升级只针对结论，不绕过记录另开渠道。
在状态流转上，ONES 通过统一的业务需求池、产品需求池与工单系统实现业务反馈与产品开发联动，业务团队可随时跟踪需求处理进度，产品经理可基于反馈优化路线图，研发团队通过任务和工单完成开发、测试与修复，形成需求—任务—测试—缺陷的闭环。评估结论和排期结果作为记录状态的一部分，销售无需逐层询问即可看到进展。
承诺如何回复客户并与计划同步
对外承诺的表达应与记录状态严格对应，采用条件式表述，把已确认的部分和未确认的部分分开说。以下为话术框架，具体措辞需结合合同条款与客户关系调整。
| 记录状态 | 可表达的内容 | 应避免的表达 |
|---|---|---|
| 待评估 | “我们已记录该需求，正在评估，预计 X 个工作日内反馈结论” | 任何时间点承诺 |
| 已纳入未排期 | “该需求已列入产品规划方向，具体版本待排期确认” | 具体交付月份 |
| 已关联计划条目 | “计划在 X 版本交付，前提是验收口径按记录确认、无重大范围变更” | 无条件保证日期 |
| 有条件纳入 | “在满足 A、B 条件的前提下，计划于 X 时间交付” | 省略条件只谈时间 |
| 不纳入 | “本期规划未包含该能力，可通过替代方案 C 满足部分场景” | 模糊回应拖延 |
条件式承诺的要点是把前提写进对客户的沟通中，并同步回记录。客户确认验收口径、范围冻结、依赖系统就绪等条件，既是研发排期的输入，也是承诺生效的前提。条件变化时，承诺随之调整，而不是由研发单方面承担。
承诺与计划的双向同步依靠同一条记录：销售对外沟通后，把承诺口径和客户反馈更新到记录；研发计划调整时，计划条目的变更同步反映到记录状态，销售看到变化后主动联系客户。两个方向都以记录为唯一事实来源，避免销售手里一份表、研发计划里一份表。
变更触发重新评估的情形应事先列明，例如客户范围扩大、期望时间提前、验收口径变化、依赖项延期。触发后记录回到评估状态，由产品负责人重新给出结论，研发据此调整计划。这套触发规则按团队约定执行，写入协作规范，并在每次变更时检查是否满足触发条件。
一个完整示例：从商机到排期
以下为演示情景，用于说明链路如何跑通，不代表真实客户案例。
需求记录填写。某制造客户在签约谈判阶段提出按车间维度统计设备停机时长并导出报表。销售填写：客户为华东区某制造企业，商机处于签约谈判；需求描述为“按车间汇总停机时长，月度导出给生产管理部门”；期望交付时间为客户下一季度末，来源为客户内部生产管理系统上线计划；承诺强度为“口头方向性提及，未写入商务文件”；验收口径为“按车间、设备类型两个维度汇总，支持导出 Excel”；不可让步条件为“必须支持按车间维度，导出格式符合客户模板”；商业价值为合同金额量级与同行业标杆意义；替代方案为现有报表可按设备维度统计，车间维度需新增配置。
评估结论与承诺回复。产品负责人在 3 个工作日内评估：该能力与路线图中生产分析方向一致，结论为“有条件纳入”，条件为客户确认导出模板、范围限定为两个维度。研发负责人判断为配置加少量开发，工作量可放入下一版本。销售据此回复客户：“在贵方确认导出模板、范围限定为车间与设备类型两个维度的前提下，计划于下一版本交付。”客户确认后，条件写入记录。
计划更新与后续变更。需求关联到下一版本的计划条目，记录状态更新为“已排期”。两周后客户提出增加按班组维度统计，触发重新评估：产品负责人判断范围扩大影响版本容量，结论调整为“本期按原范围交付，班组维度列入后续版本”。销售按新结论与客户沟通，记录同步更新，研发计划保持原条目不变。整个过程没有出现销售承诺与计划不一致的情况，因为每次变化都经过同一条记录。
上线前检查与运行后的验证
机制上线前，逐项核对以下内容，全部满足再开始运行：
- 需求提交模板已发布，必填字段明确，销售知道在哪里提交。
- 四类评估结论的定义和回复时限已与销售、产品、研发三方确认。
- 承诺状态与计划状态的对应关系已写成书面约定，销售对外沟通前可查。
- 争议升级路径明确了裁决人和时限。
- 变更触发重新评估的情形已列明，并有指定的记录更新责任人。
- 试点范围已选定，建议先覆盖一到两个销售团队和一个产品线。
运行后按固定节奏验证三项指标：
| 指标 | 口径 | 观察目的 |
|---|---|---|
| 承诺可追溯率 | 对外给出时间承诺的商机中，能关联到需求记录的比例 | 判断是否还有绕过记录的承诺 |
| 评估按时回复率 | 在约定时限内给出结论的需求记录占比 | 判断产品侧评估是否成为瓶颈 |
| 承诺与计划一致率 | 抽查的承诺口径与记录中计划状态一致的比例 | 判断双向同步是否真实发生 |
建议按月复盘一次，复盘对象是异常记录而非整体汇报：哪些承诺没有记录、哪些评估超时、哪些承诺与计划出现偏差，逐条分析原因并调整约定。连续两个月指标稳定后，可扩大试点范围。机制的有效性最终体现在销售敢承诺、研发计划少被打断、客户预期可管理这三件事同时发生。
常见问题
销售已经口头答应了客户时间点，还能补进这套链路吗？
可以补，但要把已表达的程度如实写进需求记录的“承诺强度”字段，标注为口头方向性提及或已写入商务文件。产品评估据此判断紧迫程度，研发排期时也能识别哪些时间点已经对外释放。补录之后，销售对客户的后续沟通应切换到记录状态对应的口径，把之前的口头时间点转化为带条件的承诺，例如说明交付前提是验收口径确认、范围不扩大。
产品评估结论为“不纳入”时，销售怎么向客户交代？
记录中应同时写明不纳入的原因和替代方案，销售按替代方案回复客户，说明本期规划未包含该能力，可通过现有配置、人工流程或其他方式满足部分场景。如果客户坚持，销售可基于记录中的商业价值走争议升级路径，由约定裁决人在时限内给出结论并回写记录。升级针对的是结论本身，不另开沟通渠道绕过记录。
客户中途扩大需求范围，研发计划已经排好，怎么处理？
范围扩大属于事先列明的变更触发情形，记录回到评估状态，由产品负责人重新给出结论，研发据此调整计划。常见处理是本期按原范围交付、新增部分列入后续版本，销售按新结论与客户沟通并同步更新记录。关键是变更经过同一条记录，避免销售按新范围承诺、研发仍按原计划执行。
团队规模较小，这套链路能不能简化？
可以简化执行形式，保留关键控制点：需求有唯一提交入口、评估有明确责任人、对外承诺与记录状态对应、变更回流到同一条记录。小团队可以把评估时限压缩到一两天，由同一人兼任产品评估与研发排期判断，字段表也可只保留必填项。简化的是环节数量和时限，记录作为唯一事实来源这一点建议保留，否则承诺与计划仍会各说各话。
这套机制在工具里怎么承载，需要额外配置很多吗？
核心要求是销售、产品、研发看到同一份需求及其状态。ONES 提供业务、产品经理与研发团队三大视角，通过统一的需求池、工单与任务看板同步状态与信息，业务团队可跟踪需求处理进度，产品经理基于反馈优化路线图，研发通过任务和工单完成开发、测试与修复。字段模板、评估结论类型和状态映射的具体配置方式需结合团队实际在工具中设定，本文不展开配置步骤。
