如何给修改和范围变更定价，又不把客户关系搞砸

区分错误修正、修改和范围变更

错误修正用于修复不符合已约定要求的工作，或你自己造成的错误，通常由你承担。已包含的修改是在规定轮次内调整已约定交付物。范围变更是在协议之后增加新的交付物、行为、受众、格式、集成或决策。

判断时看定义，不看请求表面大小。改按钮颜色可能只是已包含的修改。给系统增加用户角色可能一句话就能提出，却仍然是重大范围变更。“就一个小改动”不是计量单位。

• 错误修正：交付结果不符合已约定要求
• 已包含修改：在约定结果和额度内调整
• 范围变更：新增结果、行为、依赖或验收标准
• 客户延迟：按照约定时间条款处理的排期问题

在项目开始前定义修改额度

不要只写“包含两次修改”并假设所有人理解一致。应定义一轮修改：由有权决策的人统一提交的一组反馈，并在明确截止日前送达。还要说明未使用轮次是否失效，以及反馈分散在多条消息和会议中时如何处理。

同时定义允许修改的深度。设计修改可以包含字体、间距、视觉方向，但可以排除新的页面层级或新的商业模式。所谓无限修改只有在高度标准化且边界严格的服务中才有效，否则“无限”往往最先吃掉利润。

用三个问题判断是否超出范围

第一，问这个请求是否是满足书面验收标准所必需的。如果是，可能属于错误修正。第二，问它是在替换一个已包含选项，还是新增一个选项。第三，问它是否改变依赖、测试、时间表或责任。出现新的后果通常意味着新的范围。

如果答案不清楚，暂停相关工作并写下双方的解释。实施前花两分钟澄清，比到开票时才发现客户以为“已经包含”便宜得多。

先定价，再做变更

一个简单的内部公式是：变更价格 = 额外工时 × 适用单价 + 直接成本 + 针对剩余不确定性的固定价风险缓冲。除非事先约定了加急费、专家费或最低变更费，否则使用合同单价。

发送一个简短的书面变更请求。它应写明：改了什么、为何不在原范围、将交付什么、增加多少价格、对时间表有什么影响、新假设是什么、客户如何批准。不要因为一个没有预算审批权的人发了👍就开始额外工作。

• 引用原始范围或验收标准
• 描述请求的变更及其新交付物
• 增加的价格、税务处理和付款时间
• 调整后的里程碑或交付日期
• 新的依赖、排除项和审批方式

实际案例：落地页上的一个“小改动”

已批准范围包括一个标准线索表单和两轮集中设计修改。批准后，客户要求改成连接CRM并触发分析事件的多步骤表单。这是新的行为、新的依赖和额外测试，不是视觉修改。

估算实现7小时、测试2小时、沟通和发布1小时，共10小时。单价80时人工800。再加50的第三方直接成本，以及因CRM连接仍不确定而对人工增加10%的风险缓冲80。变更税前价格为930，交付推迟两个工作日。

相比之下，在已包含设计轮次中改按钮颜色仍然属于包含范围。判断依据是已约定结果和后果，不是谁更有激情地强调“这真的很小”。

用保护关系的方式表达

保持客观：“这个请求超出已约定范围，因为它增加了CRM集成和新的表单行为。我可以以930增加它，并把交付延后两个工作日；或者保持当前范围和原日期。请确认你希望哪个方案。”

这不是拒绝，也不是惩罚。它让客户对预算、范围和时间保有控制。冷静的变更管理通常反而增强信任，因为替代方案往往是突然的账单、积累的不满，或者以客户服务为名的免费工作。

批准后把变更闭环

更新估算、任务列表、验收标准、时间表和付款计划。把批准记录保存在项目档案中，并确保所有执行人员知道新的边界。

项目结束后，回顾哪些额外请求经常出现。如果客户总是要求同一种额外内容，就把它加入未来提案的可选项。范围控制不只是防守；它也是穿着没那么华丽外套的产品研究。