客户在例会上口头提出增加交付内容，如果只停留在会议记录或聊天消息里，后续很容易出现范围争议、工期被动和成本无人承担。稳妥的处理顺序是：当场复述并记录，形成书面变更申请并回传客户确认；由项目经理组织范围、工期、成本、质量和风险影响评估；按影响程度走分级审批；审批通过后更新计划与基线，再把书面结论回传客户。口头信息在书面确认前只作为待确认请求登记，不进入执行。
要点总览（TL;DR）
- 客户口头提出变更后，先当场复述确认，再整理成书面变更申请回传客户，记录变更内容、提出人及角色、提出时间、期望完成时间、涉及范围和期望结果。
- 客户书面确认前，该请求只作为待确认变更登记，不排入开发计划、不承诺交付时间、不调整基线。
- 影响评估由项目经理组织，技术、商务、测试角色参与，覆盖范围、工期、成本与资源、质量与验收、风险与依赖，并给出至少两个可选方案。
- 审批按影响程度分级：项目经理权限内、项目指导委员会或部门负责人、客户方授权代表与合同变更；结论记录为批准、有条件批准、退回补充或拒绝。
- 审批通过后更新计划与基线并保留版本对比，把书面结论回传客户；用闭环检查清单逐项核对后再视为处理完成。
口头变更先落成书面申请：记录哪些字段
客户口头提出变更时，项目经理或客户接口人应当场完成两件事：复述确认和字段记录。复述的作用是消除理解偏差，做法是把客户诉求用自己的话讲一遍，请客户当场确认“我理解的是不是这个意思”，重点确认变更对象、期望结果和期望时间。复述确认后，立即把内容填入变更记录，当天或次一工作日内整理为书面变更申请回传客户。
书面申请需要覆盖以下字段，缺项时应在回传时标注“待客户补充”，不能凭推测填写：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 变更内容 | 描述要改什么，指向具体交付物或工作项 | 在客户门户模块增加批量导出订单功能 |
| 提出人及角色 | 姓名、所属单位、是否具备变更授权 | 客户方信息部张经理，项目接口人 |
| 提出时间与场合 | 日期、会议或沟通渠道 | 3月12日项目周例会口头提出 |
| 期望完成时间 | 客户希望的上线或交付时间 | 希望4月30日前可用 |
| 涉及范围/交付物 | 受影响的模块、文档、验收项 | 订单管理模块、接口文档、验收测试用例 |
| 客户期望结果 | 客户要解决的业务问题或验收标准 | 运营人员可一次导出当月订单，字段与列表一致 |
| 记录人与记录时间 | 内部记录责任人 | 项目经理李工，3月12日当天整理 |
回传方式优先使用邮件或双方约定的正式渠道，附上变更申请并请客户在约定时限内回复确认，例如两个工作日内。客户确认的内容包括变更描述是否准确、期望结果是否完整、提出人是否具备授权。若客户逾期未回复，项目经理应再次提醒并记录提醒时间；在客户书面确认前，该请求保持“待确认”状态，不排入开发计划、不承诺交付时间，也不据此调整合同范围。
影响评估怎么做：范围、工期、成本、质量与风险
影响评估的输入包括三部分：经客户确认的书面变更申请、当前项目计划与基线、合同或双方约定的变更条款。项目经理负责组织评估，不能由提出需求的客户或单一技术角色单独判断。评估应围绕以下维度展开，每个维度给出结论和依据数据：
- 范围增减：新增或删减的工作项、交付物、文档和验收内容，是否触及合同约定的工作说明书。
- 工期影响：对关键路径、里程碑和交付节点的影响天数，是否需要调整后续阶段排期。
- 成本与资源：需要投入的人天、是否需要外部采购或加班，是否超出项目预算或需要商务追加。
- 质量与验收影响：新增内容的测试范围、验收标准变化，以及对已完成的测试和验收结论是否产生回溯影响。
- 风险与依赖：与外部系统、第三方接口、其他团队的依赖关系，以及技术可行性和交付风险。
参与角色按评估维度分工：项目经理统筹并汇总；技术负责人判断实现方案、工作量和依赖；商务或合同负责人核对合同条款、报价与付款节点；测试或质量角色评估测试范围和验收影响。评估输出是一份影响说明，并至少给出两个可选方案，例如“接受并调整计划”“调整后接受（分期交付或缩减范围）”“拒绝或延期至下一阶段”。每个方案要写明对应的工期、成本和风险差异，供审批者比较，而不是只给一个结论让审批者签字。
审批路径怎么定：分级授权与审批材料
审批层级的划分依据是变更对范围、工期、成本和合同的影响程度，而不是提出人的职位高低。项目团队应在项目启动时就把分级规则写入变更管理约定，避免每次临时找人拍板。常见做法如下：
| 影响程度 | 审批层级 | 典型情形 |
|---|---|---|
| 轻微 | 项目经理权限内 | 不影响里程碑和合同金额，工作量在预留缓冲内 |
| 中等 | 项目指导委员会或部门负责人 | 影响关键路径或需要内部资源调配，但不改变合同范围 |
| 重大 | 客户方授权代表与合同变更流程 | 改变合同范围、金额、验收标准或整体交付时间 |
具体金额阈值、天数阈值由组织根据项目规模设定，本文不给出统一数值。每级审批需要的材料包括：书面变更申请、影响说明、可选方案对比、客户书面意见。涉及合同变更时，还需附上合同条款依据和商务测算。审批结论应明确记录为四类之一：批准、有条件批准（写明附加条件）、退回补充（写明缺什么）、拒绝（写明理由）。结论记录要包含审批人、审批时间、审批意见，作为后续计划调整和客户沟通的依据。
角色与交付物分工：谁记录、谁评估、谁批准、谁回传
口头变更最容易出问题的环节是信息在角色之间传递时丢失。把每个角色的动作和交接物固定下来，可以减少“我以为他说过了”的情况。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 客户方接口人 | 书面确认变更诉求，说明授权范围 | 客户确认邮件或签字的变更申请 |
| 项目经理 | 当场记录、组织评估、提交审批、回传结论 | 变更申请、影响说明汇总、审批提交记录、客户回传函 |
| 技术负责人 | 提供实现方案、工作量与依赖判断 | 技术评估意见 |
| 商务/合同负责人 | 核对合同条款、测算商务影响 | 商务影响说明 |
| 测试或质量角色 | 评估测试范围与验收影响 | 质量影响意见 |
| 审批者 | 在授权范围内给出结论并留痕 | 审批记录 |
交付物按固定顺序流转：变更申请→影响说明与可选方案→审批记录→客户书面确认→计划与基线更新。每一步都有明确的接收方，项目经理负责跟踪流转状态。审批通过后，项目经理更新项目计划、里程碑和相关基线，保留变更前后的版本记录以便追溯；随后把审批结论、调整后的计划和新的交付时间以书面形式回传客户，请客户确认收到。未获批准的变更同样要书面告知客户原因和替代建议，并归档记录，避免同一诉求反复口头提出。
当变更申请、影响说明、审批记录和计划更新需要在同一处留痕时，可以借助项目管理工具承载这条流转链。ONES 支持用项目计划创建工作分解结构，为任务设置前后置依赖并用里程碑标记重要决策点；设置项目计划和里程碑基线后，可对比计划与执行的偏差；版本细节对比可用于追溯变更前后的差异。这些能力适合把审批通过后的计划调整和基线更新记录下来，具体可用范围以实际部署和套餐为准。
示例：一次口头变更从记录到审批通过
以下为演示情景，用于说明字段填写和流转方式，不代表真实项目数据。
情景：某企业软件项目处于开发阶段，客户信息部张经理在3月12日周例会上口头提出，希望在客户门户中增加批量导出订单功能，并希望4月30日前可用。
当场记录与回传：项目经理李工当场复述：“您需要运营人员在客户门户一次导出当月订单，字段与订单列表一致，希望4月30日前上线，对吗？”客户确认后，李工当天填写变更申请：变更内容为“客户门户增加批量导出订单功能”；提出人为张经理，客户方项目接口人；提出时间3月12日周例会；期望完成时间4月30日；涉及范围为订单管理模块、接口文档、验收测试用例；期望结果为运营人员可一次导出当月订单且字段与列表一致。当天邮件回传，请客户两个工作日内确认。
影响评估与方案：技术负责人评估后认为需要新增导出接口和权限控制，约增加8人天，影响关键路径3天；测试角色补充导出数据的字段校验和权限用例；商务负责人核对后确认未超出合同工作说明书范围。影响说明给出两个方案：方案A接受全部需求，交付时间顺延至5月6日；方案B先支持按当月导出，自定义时间范围放到下一阶段，交付时间维持4月30日。
审批与更新：因影响关键路径但未改变合同范围，按分级规则提交部门负责人审批。审批结论为“有条件批准”：采用方案B，并要求补充导出字段说明文档。项目经理据此更新项目计划和里程碑，将导出功能拆为两个工作项，保留变更前后的计划版本；随后邮件回传客户，附审批结论、调整后的计划和字段说明文档提交时间，客户回复确认收到。整个过程从口头提出到书面闭环用时四个工作日。
完成检查：口头变更处理是否闭环
处理完成后，项目经理可逐项核对以下检查项，全部满足才视为本次口头变更闭环：
- 书面变更申请已形成，且经客户书面确认，确认记录可查。
- 影响说明覆盖范围、工期、成本、质量与验收、风险与依赖五个维度，并给出至少两个可选方案。
- 审批在对应授权层级内完成，审批人、时间和意见均有记录。
- 审批通过后，项目计划、里程碑和相关基线已更新，变更前后版本可对比追溯。
- 客户已收到书面结论，包括批准内容、调整后的交付安排或拒绝理由。
- 未获批准的变更已明确告知客户，并记录在案，避免重复口头提出。
- 变更申请、影响说明、审批记录和客户回传已归档到同一项目记录中，便于后续审计和复盘。
检查中发现缺项时，按缺失环节补做，而不是在下次例会上口头补充。把这份清单固化为项目变更管理的例行检查，可以让每一次客户口头提出的变更都留下完整、可追溯的处理记录。
常见问题
客户口头提出变更后，客户迟迟不书面确认怎么办？
项目经理应按约定时限提醒，并记录提醒时间和渠道。在客户书面确认前，该请求保持“待确认”状态，不排入开发计划、不承诺交付时间，也不据此调整合同范围。若变更时间敏感，可以在提醒时说明：未确认将影响期望交付时间的可行性，请客户指定具备授权的人员回复。反复提醒仍无回复的，把沟通记录归档，并在项目例会上作为待决事项通报。
客户方接口人口头提出变更，但他没有合同变更授权，审批该怎么走？
先按记录流程形成书面申请，请客户方接口人确认诉求内容，同时请其说明授权范围或转交具备授权的代表。影响评估照常进行，因为评估结论是判断是否需要进入合同变更的依据。若评估结果显示变更改变合同范围、金额或验收标准，审批需走到客户方授权代表与合同变更流程；接口人的确认只作为需求确认，不能替代合同层面的授权。
多个口头变更同时提出，评估和审批如何排序？
建议先统一登记为待确认请求，再按影响程度和紧急程度排序。影响关键路径、涉及合同条款或与其他变更存在依赖的，优先评估；影响轻微且相互独立的，可以合并为一次评估和一次审批提交，减少往返。排序结果和合并理由要写入影响说明，让审批者看到处理顺序的依据。合并提交时，每个变更仍要单独记录字段和结论，避免审批结论无法对应到具体请求。
审批通过后客户又口头追加内容，需要重新走流程吗？
需要。追加内容属于新的变更请求，应重新记录并形成书面申请，不能附在前一次审批结论下直接执行。若追加内容与原变更紧密相关，可以在新申请中引用原变更编号和审批记录，评估时一并说明对原方案工期和成本的影响。原审批结论只覆盖已批准的范围，追加部分在书面确认和审批完成前不进入执行。
口头变更被拒绝后，如何避免客户反复提出？
把拒绝理由、评估依据和替代建议以书面形式回传客户，并归档到项目记录中。替代建议可以是延期到下一阶段、缩减范围或另行立项，让客户看到可行的路径。下次客户再提出同一诉求时，项目经理可以引用原记录说明结论和条件变化，而不是重新从头讨论。若客户坚持，按新的变更请求重新登记，并说明与此前结论的差异。
