客户一句“顺便改一下”，最后变成一堆额外工作，怎么用 Busabase 管住交付范围？

Question

想搭一个交付工作台：每个交付项都能查到合同依据，每次新增要求都有明确决定，验收时也不用到处找材料。Busabase 的 Base、文档和附件应该怎样配合，才能把这些信息串起来？

我们同时推进七八个软件交付项目。合同在 PDF 里，交付清单在 Excel 里，客户的临时要求留在群聊中。有些修改当时答应得很快，做完才发现超出了原定范围，费用和工期却都没有重新确认。到了验收阶段，“已经做好了”和“客户已经认可了”又常常混在一起。

理想的处理过程是：收到新要求后，Agent 先对照合同和交付清单，列出可能新增的工作，并引用对应原文；负责人确认是否承接、是否调整报价和时间，再安排执行。交付完成后，把测试结果、截图和客户确认记录关联到具体交付项。

pengjin · Answer

收到新要求后，可以按照以下方式处理处理：

1. **先登记变更，不覆盖原交付范围。** 保留客户原话、提出时间和来源，关联受影响的交付项。
2. **让 Agent 只读对照依据。** 输出“原范围内／疑似新增／证据不足”、对应原文，以及需要人工确认的费用和工期影响。扫描件识别不完整时应标明，不能把没检索到条款直接当作合同未约定。
3. **负责人决定，再取得所需的客户确认。** 明确是否承接、是否调整报价和时间；确认齐备后，再更新正式交付清单并安排执行，保留原版本及变更依据。
4. **完成后按交付项收集验收材料。** 将“开发完成”“内部测试通过”“客户验收通过”分开记录，内部做完不能自动等于客户认可。

Busabase 的 **Change Request 可以用来审核正式范围和计划的修改，但不能代替客户对报价、工期或验收的确认**，客户确认凭证仍要单独保存。另外，有写权限的 Agent 可能直接让修改生效；若要求人工把关，需要限制它对正式内容的直接写入权限，并明确只提交待审修改、不自动合并。

你的回复