第 2 章 · 预计阅读 19 分钟
需求沟通与方案
客户要的功能，销售都应该答应吗？
方案要解决客户的关键问题，也必须尊重产品边界和交付成本。
先放回整门生意
先知道这一章为什么存在
先把“需求沟通与方案”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“找到潜在客户”应先形成：B2B SaaS 要先确认组织问题、决策链和适配度，才能判断一条线索是否值得继续投入。
本章把“方案要解决客户的关键问题，也必须尊重产品边界和交付成本。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“签约与开通”：合同确认商业承诺，账号、席位和权限则把承诺转成可使用的软件服务。
- 收入怎么受影响
- 栈桥协同通过账号订阅费、超额存储与算力费、实施迁移费和高级支持服务费收费。本章形成的“方案边界被写清楚”要和“本步核对线索：需求发现在处理前后的状态变化”、“本步核对线索：非标准需求在处理前后的状态变化”、“本步核对线索：方案范围在处理前后的状态变化”和“本步核对线索：需求发现在处理前后的状态变化”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：订阅通常按年预收；实施费在启动和上线验收时分段收取，用量费次月按账单结算。
- 风险在哪里出现
- 全程要警惕“宕机、数据泄露、成本随用量失控和客户流失”。本章至少要用“本步核对线索：需求发现在处理前后的状态变化”、“本步核对线索：非标准需求在处理前后的状态变化”、“本步核对线索：方案范围在处理前后的状态变化”和“本步核对线索：需求发现在处理前后的状态变化”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“客户要的功能，销售都应该答应吗？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原4个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
客户要的功能，销售都应该答应吗？
访谈确认客户需要统一项目空间、角色权限、文件版本和审计记录。采购负责人额外要求一个产品尚不支持的专属审批流程，并希望销售写进合同。
把它放进栈桥协同的经营现场：本章只聚焦“需求沟通与方案”这一环，追踪它怎样承接已有输入，并把“方案要解决客户的关键问题，也必须尊重产品边界和交付成本”变成可以执行和复核的工作。
本章从“访谈关键场景”开始，依次经过“访谈关键场景”、“拆分需求边界”、“设计标准替代”和“确认方案范围”，最后得到“方案边界被写清楚”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“方案边界被写清楚”；关键记录“本步核对线索：需求发现在处理前后的状态变化”、“本步核对线索：非标准需求在处理前后的状态变化”、“本步核对线索：方案范围在处理前后的状态变化”和“本步核对线索：需求发现在处理前后的状态变化”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着栈桥协同，把“需求沟通与方案”完整跑一遍
现在把镜头放到栈桥协同的“需求沟通与方案”：客户要的功能，销售都应该答应吗？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
栈桥协同
一家给中小设计机构提供项目协同 SaaS 的软件公司，客户购买账号后持续上传图纸、审批版本和工时；团队正在判断客户增长是否真的能覆盖云成本和客户成功投入。
- 付费客户
- 74 家企业、1,120 个付费账号企业合同数决定续费关系，账号数决定当期订阅金额，两者不能混成一个增长指标。
- 标准价格
- ¥69 / 账号 / 月客户按年预付可获得折扣，但合同期内仍要持续提供可用服务。
- 产品使用
- 月活账号 836 个，月活率 74.6%已经付费不等于真正使用；低活跃客户会在续费时集中暴露价值问题。
- 服务状态
- 本月可用性 99.97%，未关闭工单 23 个可用性说明系统整体状态，工单则暴露具体客户仍未解决的使用障碍。
客户为什么付钱
账号订阅费、超额存储与算力费、实施迁移费、高级支持服务费
钱在什么时候进来
订阅通常按年预收；实施费在启动和上线验收时分段收取，用量费次月按账单结算。
利润最容易被什么吃掉
云计算与存储、研发和测试人员、客户成功与技术支持、获客佣金和渠道分成
这笔业务怎样一步一步形成可交付结果
- 01访谈关键场景可供“拆分需求边界”使用的双方确认的沟通结论
- 02拆分需求边界可供“设计标准替代”使用的检查结论与待处理项
- 03设计标准替代可供“确认方案范围”使用的可评审的解决方案
- 04确认方案范围方案边界被写清楚
访谈关键场景
在栈桥协同，团队先面对一条共同事实：“付费客户”为74 家企业、1,120 个付费账号。企业合同数决定续费关系，账号数决定当期订阅金额，两者不能混成一个增长指标。
确认项目、权限、版本和审计的真实问题
这一步真正要判断：业务访谈与方案设计；澄清产品能力边界与替代路径
如果本步没有形成“可供“拆分需求边界”使用的双方确认的沟通结论”，下一步“拆分需求边界”就没有可靠输入。
- 谁在参与
- 解决方案顾问、产品经理
- 关键记录
- 本步核对线索：需求发现在处理前后的状态变化
- 形成产出
- 可供“拆分需求边界”使用的双方确认的沟通结论
- 交给下一步
- 把“可供“拆分需求边界”使用的双方确认的沟通结论”交给产品经理，继续处理“拆分需求边界”。
如果没做好：风险观察：服务范围可由现有产品交付——客户购买的是持续软件服务，不是一个尚未估算的定制研发项目。
拆分需求边界
上一步已经形成“可供“拆分需求边界”使用的双方确认的沟通结论”。与此同时，案例里的“标准价格”为¥69 / 账号 / 月，客户按年预付可获得折扣，但合同期内仍要持续提供可用服务。
区分标准能力、真实目的与非标准要求
这一步真正要判断：澄清产品能力边界与替代路径
如果本步没有形成“可供“设计标准替代”使用的检查结论与待处理项”，下一步“设计标准替代”就没有可靠输入。
- 谁在参与
- 产品经理
- 关键记录
- 本步核对线索：非标准需求在处理前后的状态变化
- 形成产出
- 可供“设计标准替代”使用的检查结论与待处理项
- 交给下一步
- 把“可供“设计标准替代”使用的检查结论与待处理项”交给解决方案顾问，继续处理“设计标准替代”。
如果没做好：风险观察：方案 SOL-101 明确包含与排除项——标准能力写入交付范围，非标准需求明确不构成本次合同承诺。
设计标准替代
上一步已经形成“可供“设计标准替代”使用的检查结论与待处理项”。与此同时，案例里的“产品使用”为月活账号 836 个，月活率 74.6%，已经付费不等于真正使用；低活跃客户会在续费时集中暴露价值问题。
用现有权限、状态流转和审计实现关键目标
这一步真正要判断：业务访谈与方案设计
如果本步没有形成“可供“确认方案范围”使用的可评审的解决方案”，下一步“确认方案范围”就没有可靠输入。
- 谁在参与
- 解决方案顾问
- 关键记录
- 本步核对线索：方案范围在处理前后的状态变化
- 形成产出
- 可供“确认方案范围”使用的可评审的解决方案
- 交给下一步
- 把“可供“确认方案范围”使用的可评审的解决方案”交给解决方案顾问和客户经理，继续处理“确认方案范围”。
如果没做好：风险观察：报价基于可交付范围——避免把未知研发成本藏在 60 个标准席位的订阅价格里。
确认方案范围
上一步已经形成“可供“确认方案范围”使用的可评审的解决方案”。与此同时，案例里的“服务状态”为本月可用性 99.97%，未关闭工单 23 个，可用性说明系统整体状态，工单则暴露具体客户仍未解决的使用障碍。
SOL-101 写清包含项、排除项和未承诺反馈
这一步真正要判断：业务访谈与方案设计；线索判断与需求发现
这是本章最后一项可核验产出，用来判断团队是否真的完成了“需求沟通与方案”。
- 谁在参与
- 解决方案顾问、客户经理
- 关键记录
- 本步核对线索：需求发现在处理前后的状态变化
- 形成产出
- 方案边界被写清楚
- 交给下一步
- 把结果带入“方案边界被写清楚”，并回答：合同已经签了，账号为什么仍可能不能正常使用？
如果没做好：风险观察：销售、方案与产品共同守住边界——销售理解商业目标，方案顾问设计替代路径，产品记录真实缺口。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“方案边界被写清楚”已经形成、证据可以追溯，并且解决方案顾问和客户经理能够解释结果怎样产生、风险怎样被控制。双方确认以标准权限、状态流转和审计日志解决当前核心问题；专属审批不列入本次承诺，而作为未承诺的产品反馈记录。方案 SOL-101 可进入商务评审。
章末经营结果
方案边界被写清楚
双方确认以标准权限、状态流转和审计日志解决当前核心问题；专属审批不列入本次承诺，而作为未承诺的产品反馈记录。方案 SOL-101 可进入商务评审。
- 标准能力
- 权限 + 版本 + 审计
- 非标准需求
- 未承诺
- 方案状态
- 范围已确认
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“客户要的功能，销售都应该答应吗？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
访谈关键场景 → 可供“拆分需求边界”使用的双方确认的沟通结论
- 02
拆分需求边界 → 可供“设计标准替代”使用的检查结论与待处理项
- 03
设计标准替代 → 可供“确认方案范围”使用的可评审的解决方案
- 04
确认方案范围 → 方案边界被写清楚
出现这个信号要警惕：风险观察：服务范围可由现有产品交付——客户购买的是持续软件服务，不是一个尚未估算的定制研发项目。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能销售与商机管理 | 提供本章所需的约束、输入或审批 | 识别值得投入的企业机会，推进从需求发现到合同与续费的商业关系；重点关注：目标客户与商机资格判断 | 下一章节或业务结果的接收方 |
| 业务职能解决方案咨询 | 提供本章所需的约束、输入或审批 | 把客户业务问题映射到标准产品能力，并守住方案范围、替代路径和验收边界；重点关注：业务问题分析与方案设计 | 下一章节或业务结果的接收方 |
| 业务职能产品管理 | 提供本章所需的约束、输入或审批 | 维护产品边界和路线判断，吸收共性需求但不把每个询盘都变成承诺；重点关注：产品能力与路线管理 | 下一章节或业务结果的接收方 |
| 外部参与者客户采购与决策人 | 提供本章所需的约束、输入或审批 | 评估商务条件、合同风险和预算，并安排企业内部的审批和付款；重点关注：报价、条款与预算评审 | 下一章节或业务结果的接收方 |
| 代表岗位解决方案顾问 | 访谈关键场景、设计标准替代、确认方案范围 | 把客户业务问题映射到标准产品能力，设计可演示、可交付的方案；重点关注：业务访谈与方案设计 | 产品经理、客户经理 |
| 代表岗位产品经理 | 访谈关键场景、拆分需求边界 | 整理跨客户需求证据，维护产品边界，并把共性问题转成可排序的产品工作；重点关注：澄清产品能力边界与替代路径 | 解决方案顾问 |
| 代表岗位客户经理 | 确认方案范围 | 识别合适客户、推进商业沟通，并对自己写进承诺的内容负责；重点关注：线索判断与需求发现 | 下一章节或业务结果的接收方 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 本步核对线索：需求发现在处理前后的状态变化 | 访谈关键场景 | 解决方案顾问和产品经理 | 可供“拆分需求边界”使用的双方确认的沟通结论 | 拆分需求边界 |
| 本步核对线索：非标准需求在处理前后的状态变化 | 拆分需求边界 | 产品经理 | 可供“设计标准替代”使用的检查结论与待处理项 | 设计标准替代 |
| 本步核对线索：方案范围在处理前后的状态变化 | 设计标准替代 | 解决方案顾问 | 可供“确认方案范围”使用的可评审的解决方案 | 确认方案范围 |
| 本步核对线索：需求发现在处理前后的状态变化 | 确认方案范围 | 解决方案顾问和客户经理 | 方案边界被写清楚 | 方案边界被写清楚 |
本章术语：先用白话理解，再回到正式定义
- Discovery需求发现
- 白话：通过访谈和验证理解客户问题、影响、现有流程、决策人和成功条件。
- 正式定义：通过访谈和验证理解客户问题、影响、现有流程、决策人和成功条件。
- 放进业务里：销售不只问想要什么功能，还追问版本混乱怎样影响项目交付。
- Non-standard Requirement非标准需求
- 白话：超出当前标准产品或服务边界，需要额外评估成本、风险和复用价值的客户诉求。
- 正式定义：超出当前标准产品或服务边界，需要额外评估成本、风险和复用价值的客户诉求。
- 放进业务里：专属审批流程尚无产品能力和排期，不能被销售口头承诺为本次交付。
- Solution Scope方案范围
- 白话：明确本次解决方案包含什么、不包含什么以及用什么条件验收的边界。
- 正式定义：明确本次解决方案包含什么、不包含什么以及用什么条件验收的边界。
- 放进业务里：标准权限和审计日志在范围内，专属审批流程不构成本次承诺。
新手最容易误解的地方
先承诺上线日期，签约后再找研发
为什么不对：未经评估的承诺会让销售、产品和交付在合同之后才暴露冲突。
应该继续追问：如果改成“澄清真实目的，给出标准替代方案”，需要谁确认、留下什么证据？
因为一个需求不支持，直接放弃整个客户
为什么不对：非标准要求不等于整个机会不适合，关键是区分目的和手段。
应该继续追问：如果改成“澄清真实目的，给出标准替代方案”，需要谁确认、留下什么证据？
“访谈关键场景”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：服务范围可由现有产品交付——客户购买的是持续软件服务，不是一个尚未估算的定制研发项目。
应该继续追问：是否已经形成“可供“拆分需求边界”使用的双方确认的沟通结论”，并留下“本步核对线索：需求发现在处理前后的状态变化”供下一步核对？
“拆分需求边界”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：方案 SOL-101 明确包含与排除项——标准能力写入交付范围，非标准需求明确不构成本次合同承诺。
应该继续追问：是否已经形成“可供“设计标准替代”使用的检查结论与待处理项”，并留下“本步核对线索：非标准需求在处理前后的状态变化”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“访谈关键场景”，如果跳过会影响哪一步？
- 在“拆分需求边界”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响账号订阅费、超额存储与算力费、实施迁移费和高级支持服务费？结合“订阅通常按年预收；实施费在启动和上线验收时分段收取，用量费次月按账单结算。”判断它何时才会形成收入或现金。
- 如果只看到“方案边界被写清楚”的口头结论，你还会要求核对哪些业务记录？
销售怎样回应这项非标准审批需求？
客户的核心协作问题可由现有产品解决；专属审批流程尚无排期，也没有评估研发和维护成本。