client-revisions

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Client Revisions

客户修订处理

Control revision rounds and scope creep on motion projects: define what a revision is, cap rounds in the SOW, collect feedback the right way, translate vague notes into actionable changes, and decline out-of-scope work politely as a change order.

控制动态项目中的修订轮次与范围蔓延：明确修订的定义，在SOW中设定修订轮次上限，以正确方式收集反馈，将模糊意见转化为可执行的变更，并礼貌地将超范围工作转为变更订单处理。

When to use

适用场景

Use when feedback is mounting, when a client keeps adding "small tweaks," when the SOW needs revision language, when a vague note ("make it pop") needs decoding before touching the file, or when a request has clearly crossed into new work and needs a change-order reply.

当反馈不断累积、客户持续要求“小调整”、SOW需要添加修订条款、遇到“让它更亮眼”这类模糊意见（需先解读再修改文件），或请求明显属于新增工作需回复变更订单时使用。

Decision tree — classify every note before touching the file

决策树——处理每个意见前先分类

The whole skill is one judgment applied per note: is this a revision, a new request, or just vague? Run each note through this before opening the project.

A note arrives.
├─ Is it vague ("make it pop", "feels off")?
│   └─ YES → translate to a decidable choice + ask for a timestamp.
│            Do NOT act yet. Re-classify once it's concrete.
└─ Is it concrete?
    ├─ Does it change something ALREADY approved in brief/board?
    │   (timing, palette colour, approved-copy edit, a fix)
    │   └─ YES → REVISION. Counts against the round cap. Do it.
    └─ Is it anything NOT in the approved brief/board?
        (new scene, +runtime, new concept, new ratio, new asset,
         reversing an approved decision, "let's also try…")
        └─ YES → NEW REQUEST. Send the change-order email. Quote it.
                 Do NOT silently absorb it.

Is feedback scattered across people/messages?
└─ YES → STOP. Send the consolidated-feedback request first; one
         document, all stakeholders, conflicts resolved by the client.

Decision rule: when unsure whether a note is a revision or new request, ask "was this decided and approved already?" If yes → revision. If it adds, replaces, or reverses → new request.

整个技能的核心是对每条意见做出判断：这是修订请求、新增需求还是模糊意见？ 在打开项目文件前，先对每条意见进行如下判断：

A note arrives.
├─ Is it vague ("make it pop", "feels off")?
│   └─ YES → translate to a decidable choice + ask for a timestamp.
│            Do NOT act yet. Re-classify once it's concrete.
└─ Is it concrete?
    ├─ Does it change something ALREADY approved in brief/board?
    │   (timing, palette colour, approved-copy edit, a fix)
    │   └─ YES → REVISION. Counts against the round cap. Do it.
    └─ Is it anything NOT in the approved brief/board?
        (new scene, +runtime, new concept, new ratio, new asset,
         reversing an approved decision, "let's also try…")
        └─ YES → NEW REQUEST. Send the change-order email. Quote it.
                 Do NOT silently absorb it.

Is feedback scattered across people/messages?
└─ YES → STOP. Send the consolidated-feedback request first; one
         document, all stakeholders, conflicts resolved by the client.

决策规则：若不确定某条意见是修订还是新增需求，询问“该内容是否已获批确定？”若是则为修订；若属于新增、替换或推翻已获批内容，则为新增需求。

The core distinction: revision vs new request

核心区分：修订 vs 新增需求

This single line prevents most disputes — put it in the SOW and the feedback request:

A revision = a change to something that was already in the approved brief/board (adjusting timing, colour from the palette, swapping an approved word, fixing a glitch).
A new request = anything not in the approved brief/board (a new scene, added second of runtime, a different concept, a new aspect ratio, a logo not previously supplied, "let's also try…").

Revisions are included up to the cap. New requests are change orders, quoted and scheduled separately. State this before round 1, not after the dispute.

这一界定可避免大部分纠纷——将其写入SOW和反馈请求中：

修订 = 对已在获批brief/board中确认内容的修改（调整时长、调色板颜色、替换已获批文字、修复问题）。
新增需求 = 获批brief/board中未包含的任何内容（新场景、延长时长、新创意方向、新格式或宽高比、未提前提供的新素材、“我们也可以试试…”）。

修订包含在轮次上限内。新增需求需走变更订单流程，单独报价并安排工期。需在第一轮修订前明确说明，而非出现纠纷后再解释。

SOW revision-cap language

SOW修订上限条款

Drop this into the contract/quote:

REVISIONS
This project includes [2] rounds of revisions. A "round" is one
consolidated set of feedback, collected from all stakeholders and
delivered in a single document, then addressed in full.

Included (a revision): changes to elements already approved in the
brief and storyboard — timing, pacing, colours from the agreed
palette, approved copy edits, and fixes.

Not included (a new request / change order): new scenes, added
runtime, new concepts or directions, additional formats or aspect
ratios, new assets not previously supplied, or feedback that
reverses a previously approved decision.

New requests are quoted as a change order before work proceeds and
may affect the timeline. Additional revision rounds beyond those
included are billed at [day rate]. Feedback split across multiple
messages may be treated as separate rounds.

将以下内容加入合同/报价中：

REVISIONS
This project includes [2] rounds of revisions. A "round" is one
consolidated set of feedback, collected from all stakeholders and
delivered in a single document, then addressed in full.

Included (a revision): changes to elements already approved in the
brief and storyboard — timing, pacing, colours from the agreed
palette, approved copy edits, and fixes.

Not included (a new request / change order): new scenes, added
runtime, new concepts or directions, additional formats or aspect
ratios, new assets not previously supplied, or feedback that
reverses a previously approved decision.

New requests are quoted as a change order before work proceeds and
may affect the timeline. Additional revision rounds beyond those
included are billed at [day rate]. Feedback split across multiple
messages may be treated as separate rounds.

Workflow when feedback arrives

反馈处理工作流程

Stop. Do not open the project file yet.
Consolidate. If feedback is scattered or per-person, send the consolidated-feedback request (below). One document, all stakeholders, deduped and de-conflicted.
Classify each note as revision or new request using the distinction above.
Translate vague notes into targeted questions before executing (see translator).
For new requests, send the change-order email — do not silently absorb them.
Log the round. Record which round this is so the cap is visible to both sides.

暂停。先不要打开项目文件。
整合。若反馈分散在不同人员或消息中，先发送下方的整合反馈请求。要求所有相关方将反馈汇总至一份文档，去重并解决冲突。
分类每条意见：根据上述界定，将其归类为修订或新增需求。
翻译模糊意见：先将模糊意见转化为针对性问题再执行（见翻译工具）。
针对新增需求：发送变更订单邮件——切勿默默承担。
记录轮次：记录当前是第几轮修订，确保双方都能看到轮次上限。

Consolidated-feedback request template

整合反馈请求模板

Subject: Feedback on [project] — Round [N]

Hi [name],

Ready for your notes on V[n]. To turn these around fast and cleanly,
could you send everything in one go:

• Gather feedback from everyone who needs to weigh in and merge it
  into a single list (if two notes conflict, tell me which wins).
• Use timestamps where you can — "at 0:08 the logo feels slow."
• Tell me the problem, not the fix — "the intro drags" is more useful
  than "make it faster," because it lets me solve it properly.
• Flag any must-have vs nice-to-have.

Send it all together and I'll address the full set in this round.
Notes that arrive after, or in separate messages, may roll into the
next round. Thanks!

Subject: Feedback on [project] — Round [N]

Hi [name],

Ready for your notes on V[n]. To turn these around fast and cleanly,
could you send everything in one go:

• Gather feedback from everyone who needs to weigh in and merge it
  into a single list (if two notes conflict, tell me which wins).
• Use timestamps where you can — "at 0:08 the logo feels slow."
• Tell me the problem, not the fix — "the intro drags" is more useful
  than "make it faster," because it lets me solve it properly.
• Flag any must-have vs nice-to-have.

Send it all together and I'll address the full set in this round.
Notes that arrive after, or in separate messages, may roll into the
next round. Thanks!

Vague-feedback translator

模糊意见翻译器

Never act on a vague note. Convert it to targeted questions first:

Client says	Ask back
"Make it pop"	"More saturated colour, faster pacing, bigger scale moves, or stronger sound? Point to a second that already pops."
"It feels off"	"Off in pacing, colour, type, or message? Which 2 seconds feel most wrong?"
"Make it more premium"	"Slower easing, more space, restrained palette, or refined type — which one?"
"Can it be more dynamic?"	"More camera movement, faster cuts, or more elements in motion?"
"I don't love it"	"What specifically — and what would 'loving it' look like? A reference helps."
"Make it bigger / stronger"	"Larger scale, bolder type, higher contrast, or more screen time?"
"Something's missing"	"A scene, a message, a brand element, or energy? Where in the timeline?"
"Can we punch it up?"	"Pacing, colour, or sound? Show me a moment that already has the energy you want."

Rule: turn every feeling into a choice between concrete, decidable options, and ask for a timestamp.

切勿直接执行模糊意见。先将其转化为针对性问题：

客户表述	回复询问
"Make it pop"	"是要更饱和的色彩、更快的节奏、更大的缩放动效还是更有冲击力的音效？请指出一个你觉得已经达到‘亮眼’效果的时间点。"
"It feels off"	"是节奏、色彩、字体还是传达的信息有问题？哪2秒的内容感觉最不对？"
"Make it more premium"	"是要更平缓的过渡、更宽松的布局、克制的调色板还是精致的字体——选哪一个？"
"Can it be more dynamic?"	"是要更多镜头运动、更快的剪辑还是更多动态元素？"
"I don't love it"	"具体是哪里不满意？‘满意’的效果是什么样的？提供参考案例会有帮助。"
"Make it bigger / stronger"	"是要更大的尺寸、更粗的字体、更高的对比度还是更长的展示时间？"
"Something's missing"	"是缺少场景、信息、品牌元素还是氛围感？在时间轴的哪个位置？"
"Can we punch it up?"	"是节奏、色彩还是音效？给我看一个已经符合你想要的氛围感的片段。"

规则：将所有主观感受转化为具体、可决策的选项，并请求提供时间戳。

Out-of-scope / change-order email template

超范围/变更订单邮件模板

Subject: [project] — quick note on the new request

Hi [name],

Happy to help with [the new request] — flagging that it sits outside
the approved brief/storyboard, so it's a change rather than a revision
under our current scope.

Here's what it takes:
  • Work: [what's involved]
  • Cost: [amount / day estimate]
  • Timeline impact: [+X days / new delivery date]

If you'd like to go ahead, reply "approved" and I'll add it and update
the schedule. If you'd rather keep to the original scope and budget,
no problem — we'll proceed as planned and can revisit this later.

Either way works for me; just let me know which you prefer.

Tone notes: collaborative, never accusatory. Offer the choice (proceed or park), give a number, and state the timeline impact. The goal is to make the trade-off visible, not to say "no."

Subject: [project] — quick note on the new request

Hi [name],

Happy to help with [the new request] — flagging that it sits outside
the approved brief/storyboard, so it's a change rather than a revision
under our current scope.

Here's what it takes:
  • Work: [what's involved]
  • Cost: [amount / day estimate]
  • Timeline impact: [+X days / new delivery date]

If you'd like to go ahead, reply "approved" and I'll add it and update
the schedule. If you'd rather keep to the original scope and budget,
no problem — we'll proceed as planned and can revisit this later.

Either way works for me; just let me know which you prefer.

语气提示：保持协作性，切勿带有指责意味。提供选择（执行或暂缓），给出具体数字，并说明对工期的影响。目标是让客户清晰看到取舍，而非直接拒绝。

Worked examples

实操案例

GOOD — vague note decoded, then executed cleanly:

Client: "The intro feels off." → You: "Off in pacing, colour, or message — and which 2 seconds feel worst?" → Client: "The first 3 seconds drag before the logo." → You re-time the entrance (a revision, within scope), log it as Round 1. One question turned a feeling into a precise, in-scope fix.

ANTI-PATTERN — silently absorbing scope:

Client: "Love it! Can we also do a square version and add a quick outro scene?" → You quietly build both, eat 2 extra days, and the project runs late and unprofitable.

Why it fails: a new aspect ratio and a new scene are both new requests, not revisions — but absorbing them without a change order trains the client that scope is free, sets a precedent, and erases your margin. The fix: reply with the change-order email, give a number and a timeline impact, and let the client choose. Saying "happy to — here's what it takes" is not saying no.

正面案例——模糊意见解读后高效执行：

客户：“开头感觉不对。” → 你：“是节奏、色彩还是信息有问题——哪2秒感觉最不好？” → 客户：“前3秒logo出现前的部分太拖沓。” → 你调整了logo入场时间（属于修订，在范围内），记录为第1轮修订。一个问题就将主观感受转化为精准的范围内修改。

反面案例——默默接受范围蔓延：

客户：“很喜欢！我们能不能再做一个方形版本，再加一个简短的片尾场景？” → 你悄悄完成了两项工作，多花了2天时间，导致项目延期且无利润。

失败原因：新的宽高比和新场景都属于新增需求，而非修订——但默默承担而不走变更订单流程，会让客户觉得范围变更免费，开了先例，还会侵蚀你的利润空间。解决方法：回复变更订单邮件，给出报价和工期影响，让客户选择。“很乐意帮忙——以下是所需成本和时间”并非拒绝。

Common mistakes

常见误区

Symptom	Why it happens	Fix
Endless rounds, never "final"	No cap defined, or cap not cited	State the cap in the SOW before round 1; cite it at round N+1
Conflicting notes, redo loops	Acted on per-person feedback	Require one consolidated doc; client resolves conflicts
Margin gone on "tiny tweaks"	New requests absorbed as revisions	Classify every note; new work → change order with a price
Acted on "make it pop," still wrong	Executed a vague note literally	Translate to a decidable choice + timestamp before touching the file
Reworking an approved scene	Approval gate not locked	Lock each stage in writing; reopening a locked stage = new request
Feedback dribbles in for days	No single submission deadline	One round = one document; later notes roll to the next round
Client feels nickel-and-dimed	Change orders framed as "no"	Frame as a visible trade-off (proceed or park), never as refusal

症状	原因	解决方法
无休止的修订，永远无法“定稿”	未设定修订上限，或未明确引用上限	在第1轮修订前就在SOW中明确上限；在第N+1轮修订时引用该条款
意见冲突，反复返工	直接处理个人反馈	要求提供一份整合后的文档；由客户解决意见冲突
“小调整”导致利润流失	将新增需求当作修订处理	对每条意见进行分类；新增工作→走变更订单流程并报价
执行“Make it pop”后仍不符合要求	直接按模糊字面意思执行	在修改文件前，先将模糊意见转化为可决策选项 + 请求时间戳
重新修改已获批场景	未锁定审批节点	以书面形式锁定每个阶段；重新开启已锁定阶段=新增需求
反馈持续多天零散提交	未设定统一提交截止时间	一轮修订对应一份文档；晚提交的意见归入下一轮
客户觉得被“敲竹杠”	将变更订单表述为“拒绝”	将其表述为清晰的取舍（执行或暂缓），而非拒绝

Deliverable spec — what good revision handling produces

交付标准——优质修订管理的成果

The outputs are emails and contract language, not files. Good handling means:

The SOW defines a "round," caps rounds, and distinguishes revision vs new request before work starts.
Each feedback round is one consolidated document, logged by round number.
Vague notes are converted to decidable questions with timestamps before execution.
New requests get a change-order email with work, cost, and timeline impact — never silent absorption.
Tone stays collaborative: every email offers a choice and states the trade-off.

产出物为邮件和合同条款，而非项目文件。优质管理意味着：

SOW在工作开始前就定义了“一轮修订”、设定了轮次上限，并明确区分修订与新增需求。
每轮反馈对应一份整合后的文档，并记录轮次编号。
模糊意见先转化为可决策的问题并获取时间戳，再执行修改。
新增需求需发送包含工作内容、成本和工期影响的变更订单邮件——绝不默默承担。
语气保持协作：每封邮件都提供选择并说明取舍。

Before you finish — checklist

收尾检查清单

Quick reference

速查指南

Situation	Move
Feedback dribbling in per-person	Send consolidated-feedback request; restart the round
"Make it pop"	Translate to concrete options + ask for a timestamp
Client requests a 4th round	Cite SOW cap; quote extra round at day rate
"Just one tiny new scene"	Change-order email; it's new work
Reversing an approved decision	New request, not a revision
New aspect ratio added late	Change order — separate format = separate deliverable
Two stakeholders conflict	Require client to pick the winning note before work

场景	应对动作
反馈零散来自不同人员	发送整合反馈请求；重启本轮修订
“Make it pop”	转化为具体选项 + 请求时间戳
客户要求第4轮修订	引用SOW上限条款；按日费率报价额外轮次
“只是一个很小的新场景”	发送变更订单邮件；这属于新增工作
推翻已获批决策	属于新增需求，而非修订
后期新增宽高比	走变更订单流程——新格式=独立交付物
两位相关方意见冲突	要求客户确定最终意见后再开展工作

Reference files

参考文件

```
references/sow-clauses.md
```
— full SOW revision section, approval-gate language, and "round" definition variants.
```
references/email-templates.md
```
— consolidated-feedback, change-order, extra-round, and stalled-approval email templates.
```
references/feedback-translator.md
```
— expanded vague-to-targeted feedback lookup and the "problem not fix" coaching note for clients.

```
references/sow-clauses.md
```
— 完整的SOW修订章节、审批节点条款，以及“一轮修订”的多种定义变体。
```
references/email-templates.md
```
— 整合反馈、变更订单、额外轮次、审批停滞等场景的邮件模板。
```
references/feedback-translator.md
```
— 扩展版模糊意见转针对性问题对照表，以及给客户的“说明问题而非解决方案”指导说明。