CHANGE DOCKET · SHENZHEN
修改先分三类
“再改一下”不是项目语言。先看它是 Correction、Preference Change 还是 Change Order，再核对 Scope of Work、Revision Round、成本和排期。
- TYPE 01Correction / 修正回到已确认标准
- TYPE 02Preference Change / 偏好变化同范围内重新选择
- TYPE 03Change Order / 新增变更先确认影响再开工
先说结论
先把交付物、验收标准、修改回合和付款触发条件写成同一张底稿。每条反馈收到后先分类，再确认负责人、截止时间、成本与排期；没有被确认的新增需求，不直接进入制作。
三类修改，用三种处理方式
分类不是为了推责，而是让客户和制作团队知道：这条意见回到哪项已确认标准，会不会改变资源，又由谁做最终决定。
- 01 / CORRECTION
没有达到已确认标准
错字、漏镜、技术错误，或画面没有满足已经签字的 Acceptance Criteria。记录问题与修正结果，不占用偏好讨论。
- 02 / PREFERENCE CHANGE
标准没变，选择变了
两个已完成方案都合格，但决策方改选音乐、节奏或画面。先确认是否仍在 Revision Round 内，再统一意见入口。
- 03 / CHANGE ORDER
范围、资源或时间变了
新增场景、演员、版本、语言或大幅重写脚本。先发 Change Order，写清 Cost Impact 与 Schedule Impact，确认后再排产。
付款节点，要跟可验收成果走
Payment Trigger 不写成模糊日期，而写成双方能回读的 Milestone 与 Acceptance Criteria。比例由项目合同决定，页面不替合同给固定答案。
- 立项与排期确认
Scope of Work、项目角色、主要日期和首笔付款触发条件已确认，制作团队开始锁定资源。
- 前期文件确认
脚本、Storyboard、拍摄清单、样品与场地边界可回读；超出范围的新增项转入 Change Order。
- 拍摄完成与素材核对
按通告单和镜头表核对已拍内容、缺失项与现场变化，不用“拍完了”代替交付事实。
- 粗剪、精剪与母版
每个 Revision Round 有唯一版本号、集中反馈与确认人；母版验收后再进入多语言和媒体适配。
变更底稿，留四格
这里是通用制作记录示例，不是任何客户的合同或报价，也不证明任何项目已经采用相同条款。真实项目仍以双方签署文件和适用约定为准。
- REQUEST
- 具体要改什么，来自哪位已确认决策人，关联哪个版本和时间码。
- TYPE
- Correction、Preference Change 或 Change Order，只选一个主类型。
- IMPACT
- 需要哪些人员、设备、素材与时间；是否影响已确认的里程碑。
- APPROVAL
- 成本与排期由谁确认，何时生效，旧版本是否停止继续制作。
合同与变更常见问题
合同里写“修改到满意”为何风险很高？
因为“满意”没有可核对标准。更稳妥的做法是写清交付物、Acceptance Criteria、Revision Round、意见入口和超出范围后的 Change Order 流程。
现场临时改脚本算不算新增变更？
先看是否改变已经确认的场景、演员、设备、时长或交付版本。只要影响资源、成本或排期，就应先记录影响并确认，不靠口头一句带过。
付款节点必须按固定比例吗？
没有通用固定比例。节点应对应真实可验收成果、资源投入和合同约定；具体比例与税务、法律问题需由项目双方和专业顾问确认。
把下一条修改先放进正确的格子。
ONCE 可以把 Scope of Work、Milestone、Payment Trigger、Acceptance Criteria、Revision Round 与 Change Order 整理成同一套项目底稿。
