
When an agency revises the same deliverable repeatedly, the visible problem is extra work. The less visible costs include delayed approvals, disrupted schedules, reduced capacity for paying clients, and declining project margin. The answer is not to prohibit revisions. It is to separate useful creative iteration from preventable rework and to put decisions, inputs, and handoffs under control.
This seven-step guide shows agency owners, account managers, and project leads how to diagnose recurring revisions, improve creative briefs, manage changes, secure approvals, verify handoffs, measure costs, and learn from completed work.
First, define the terms: planned iteration is a review round included in the agreed process; preventable rework is extra effort caused by defective or missing inputs, avoidable process failures, or previously resolved decisions being reopened; a scope change is a new or materially different request that requires assessment and potentially a separate agreement. Track these separately rather than treating every revision as a failure.
1. Diagnose why work is being redone
Do not start by buying new software. Begin with evidence from recent projects. Review work logs, approval records, change requests, and deliverable histories. For each significant rework event, record the trigger, when it was discovered, hours spent, and the control that might have prevented it.
Five recurring sources of preventable rework
- Unclear requirements: audience, objectives, constraints, or acceptance criteria were not confirmed.
- Late or conflicting stakeholder input: a decision-maker joins after a concept has already progressed.
- Uncontrolled scope changes: work starts before the price, schedule, and responsibilities are evaluated.
- Weak handoffs: outdated assets, unresolved questions, or incomplete acceptance records cross a team boundary.
- Unrealistic capacity assumptions: resource shortages or compressed schedules lead to avoidable errors.
These five sources are a diagnostic framework, not a claim about their prevalence across all agencies.
Use a consistent cause log
Assign each event one primary category—input, process, decision, or capacity—and optionally note contributing factors. This keeps reporting consistent without pretending a complex problem always has one cause.
| Event | Primary cause | Corrective control | Owner / verification |
|---|---|---|---|
| Landing page rebuilt using superseded copy | Input | Version-controlled asset register | Project lead; check next handoff |
| Approved concept reopened by new stakeholder | Decision | Named approver and approval record | Account lead; review next project |
Examples are illustrative. In a 45-minute blameless retrospective, review a small sample of recent projects, agree on the most frequent controllable cause, assign an improvement owner, and establish a date to test whether the change actually worked.
2. Make the creative brief a start-readiness control
A brief is not complete just because a document exists. Work should begin only when the people doing it can explain the objective, boundaries, inputs, and approval route.
Creative brief readiness checklist
- Business objective and reason for the work
- Target audience and desired audience action
- Deliverables, formats, channels, and explicit exclusions
- Brand references, approved assets, and source-of-truth locations
- Measures of success and acceptance criteria
- Key milestones, dependencies, and review windows
- Named client decision-maker and consolidated feedback owner
- Number of included review rounds and how additional rounds are handled
- Known risks and unresolved questions
For example, “create a landing page” is not an acceptance criterion. “Provide a mobile-responsive landing page with approved copy, a functioning inquiry form, and analytics events verified against the agreed test plan” gives reviewers an observable basis for acceptance.
Record a dated approved baseline. Changes after that point should be assessed, not automatically rejected or automatically billed. Correcting an agency mistake is generally different from a client requesting a new deliverable.
Agencies that need a more controlled kickoff process can explore The Client Start System book and implementation bundle.
3. Put change control into the contract and daily workflow
The agreement should explain deliverables, exclusions, client responsibilities, revision allowances, acceptance points, and how proposed changes are evaluated. Contract language should be reviewed for suitability by qualified counsel rather than copied unquestioningly from a blog.
Every new request follows the same decision path:
- Log it: capture the request, requester, and affected deliverable.
- Classify it: within scope, correction of a defect, or proposed scope change.
- Assess the effect: estimate hours, cost, dependencies, and impact on milestones.
- Decide: obtain authorization from the designated parties before out-of-scope work starts.
- Update the baseline: revise the work plan, budget, and acceptance conditions if approved.
| Request | Likely classification | Next action |
|---|---|---|
| Fix a broken agreed form | Defect correction | Correct and verify |
| Adjust copy within an included review round | Planned iteration | Log and complete |
| Add a new landing page | Proposed scope change | Assess and authorize |
| Replace the approved brand direction | Major scope change | Replan and agree on terms |
Classification depends on the actual agreement; these examples are not universal contract rules.

4. Make client approvals explicit and traceable
A good approval system answers four questions: what is being approved, who may approve it, when a decision is needed, and what happens if the decision is delayed.
Approval-request example
Approval requested: Campaign landing page v2.3
Decision-maker: Designated client sponsor
Review deadline: Thursday, 3 p.m. local time
Decision options: Approve; approve with listed conditions; return for revision
Changes since v2.2: Hero copy and form layout
Supporting materials: Preview link and acceptance checklist
If delayed: Project lead will assess milestone impact and communicate a revised schedule.
Use one system of record for the final decision, even if discussion happens in several channels. Document the approval date, person, version, conditions, and outstanding exceptions. Do not treat silence as acceptance unless the contract expressly establishes an appropriate mechanism and it is legally suitable.
For conflicting stakeholder feedback, ask the designated client owner for one consolidated decision before proceeding.
5. Verify handoffs at each stage gate
Creative work often moves between strategy, copy, design, development, quality assurance, and the client. A meeting does not prove the next team can proceed. A verified handoff does.
Stage-gate handoff checklist
- Current approved brief and acceptance criteria are accessible
- Latest files are clearly named and older versions are distinguished
- Open issues and approved change requests are visible
- Dependencies, owners, and due dates are confirmed
- Quality checks appropriate to the deliverable are completed
- The receiving owner confirms readiness or records blockers
Example: before a landing page moves from design to development, verify that responsive layouts, asset licensing information, approved copy, interaction behavior, and the client approval record are available. If a required item is missing, mark the gate “blocked” and assign an owner to resolve it.
For a fuller approach to delivery-stage control, see The Client Delivery System.
6. Measure rework without confusing it with normal revisions
Agencies need a consistent baseline before setting targets. Tag time as first-pass work, planned iteration, preventable rework, or approved scope change. This prevents contractual revisions from being counted as operational failure.
Five useful agency rework KPIs
- Preventable rework rate: preventable rework hours divided by all tracked project hours, multiplied by 100.
- Revision rounds: actual review cycles per deliverable compared with the number planned.
- Approval lag: elapsed business days between a complete approval request and the decision.
- Rework cost: preventable rework hours multiplied by a documented internal hourly cost rate.
- First-pass acceptance rate: deliverables accepted at their first scheduled formal review divided by all deliverables submitted for first review.
Illustrative calculation
If a completed project logs 200 total hours, including 16 hours of preventable rework, its preventable rework rate is 8%. At an internal labor cost of $60 per hour, those 16 hours represent $960 in direct labor cost, before overhead or opportunity cost. These figures are hypothetical, not industry benchmarks.
Sample your last five sufficiently documented projects and calculate the measures using the same rules. If records are incomplete, start prospective tracking instead of presenting estimates as historical facts. Break out results by project type and complexity to avoid misleading comparisons.
Choose improvement targets only after examining the baseline. For example, reducing an 8% preventable rework rate to 7% over a quarter is a one-percentage-point absolute reduction, equivalent to a 12.5% relative reduction. Review whether the change persists across comparable projects.

7. Build a learning loop that verifies corrective actions
Hold a short closeout review after each project or major delivery milestone. Ask what required preventable rework, why the control failed, and what needs to change in the operating system.
For every significant corrective action, document the owner, due date, expected evidence, and verification date. For example, if outdated copy caused a rebuild, introduce a controlled asset register and check the next three handoffs for version errors. Close the action only when the control is in use and there is evidence it addresses the original cause.
Lessons learned are valuable when they change the next project. See the Project Management Institute's discussion of lessons learned for additional perspective.
Putting the seven steps together
Start small: diagnose one repeatable issue, strengthen the relevant brief or approval control, measure the result, and check whether the improvement survives the next project. Reducing rework is an ongoing management discipline, not a one-time software installation.
Workflow Lift's Client Start System bundle addresses controlled initiation and early readiness. The Client Delivery System bundle supports ongoing delivery controls, change management, and handoff discipline. Choose the point in your process where defects first occur rather than adopting every control at once.
Related Workflow Lift implementation resources
Choose the system that addresses the earliest source of rework in your client workflow.
Frequently asked questions
Does every client revision count as rework?
No. Planned creative iteration belongs to the agreed review process. Preventable rework involves avoidable duplication or correction. New client requests may be scope changes. Separating the three yields more credible metrics.
How can a small agency start tracking rework?
Use a spreadsheet with project, deliverable, date, hours, cause category, and action owner. Apply the same definitions to every project. A simple consistent log is more useful than a sophisticated dashboard built on inconsistent data.
What belongs in a client approval record?
The deliverable version, identified decision-maker, decision date, approval status, conditions, and location of supporting evidence.
What if a client repeatedly changes direction?
Confirm the underlying objective, obtain a consolidated decision from the designated approver, and explain the schedule and fee implications of proposed changes under the agreement. Keep the conversation collaborative while protecting the agreed baseline.
How quickly should rework decline?
There is no universal timeline. Agencies should evaluate progress against their own baseline over comparable projects and verify that changes do not sacrifice quality or client outcomes.


