How agencies can fix client approvals and control scope changes

A client approval process works when everyone can answer four questions: which version is being reviewed, who can decide, what decision is needed, and what happens after that decision. A beautiful presentation cannot compensate for missing answers. When comments arrive through several conversations, the agency can finish the wrong work perfectly.

This guide builds a practical approval system for a small creative or marketing agency. It covers the handoff between production, client review, changes, and release. You can run the system with your existing documents and a shared register. The useful part is the agreement about decisions, rather than a particular application.

Start with the approval object

An approval should refer to a specific object. “The campaign” is usually too broad. A landing page, advertising concept, email sequence, and publication schedule can need different reviewers. Define the smallest package that supports a meaningful decision without forcing the client to review disconnected fragments.

Give each object an identifier, a version, a review purpose, and an owner. A package might be LAUNCH-EMAIL-04, version three, submitted for copy approval. Its subject lines and body copy belong inside the package. Sending configuration and audience selection can remain separate decisions because they involve different evidence and responsibilities.

Record the boundaries explicitly. Copy approval does not automatically authorize publication, approve a mailing audience, or confirm that product claims have been checked. Where a specialist review is necessary, identify that reviewer before the package reaches the client. A client contact cannot silently stand in for someone with a different responsibility.

Separate contributors from the decision owner

Several people may contribute useful feedback, but someone must reconcile it. Ask the client to name one decision owner for each package and a backup for absence. The owner can consult colleagues, then return one consolidated response. This is an operating arrangement to agree with the client, rather than authority the agency can impose after a disagreement.

Capture who can approve content, authorize extra spending, and permit publication. Those may be three different people. A coordinator can collect comments without having authority to accept an added fee. Likewise, a senior stakeholder’s enthusiastic message may be feedback rather than the specified release instruction.

Agree how a replacement decision owner will be confirmed. Do not accept an unfamiliar forwarded message as automatic evidence of changed authority. Keep a short approval register that the team can understand without reading every past email. The client onboarding checklist provides a useful place to establish these roles before production begins.

Build a complete review package

A useful package helps the client make the requested decision in one sitting. Include the current artifact, a concise description of what changed, the review criteria, the deadline and time zone, and the exact response options. Explain what remains outside this review so that unresolved work does not look accidentally missing.

Use a stable review link where possible. If a document must change after submission, create a new version and clearly withdraw the earlier request. Silent edits under an unchanged approval request make it difficult to prove what the client actually saw. An approval history needs to remain understandable after the project team has moved on.

Asana’s discussion of creative requests emphasizes a brief with scope, goals, specifications, and reviewers. Use that principle to check whether the review package carries enough context; it does not require adopting that vendor’s software.

Before sending, a colleague should check the package as a recipient would. Can the person open the link? Is the intended version visible? Are annotations legible on a phone? Can they understand the decision without agency shorthand? A smaller accessible package is often more useful than a large folder containing unexplained alternatives.

Define a small set of decision states

Avoid a single status called “with client” that hides several situations. Use states that lead to different next actions. The following is an operating example, not a universal standard.

Allow a decision to include conditions, but make those conditions specific. “Approved if everything is fine” cannot guide release. “Approved after correcting the telephone number on page two, with no other changes” is clearer, although your process should still identify who verifies that correction.

Distinguish revisions from changes to scope

The distinction comes from the agreed deliverable and assumptions. Correcting an agency error, revising within an included review round, and adding a new audience are different events. Staff need a way to classify them without turning every comment into an argument about fees.

Use a simple triage question: does this request change what was agreed, or help the agreed output meet its existing criteria? Then check the contract, brief, included rounds, and any relevant history. Where the answer is ambiguous, have the project owner discuss it before more production work accumulates.

Asana’s change control explanation describes recording proposed changes, assessing their impact, and retaining the decision. For a small agency, a short change record can perform that job. The record should show the requested difference, affected deliverables, cost implication, schedule implication, and the person authorized to decide.

Do not use a new charge as a surprise at invoicing time. Make a proposed adjustment visible while the client still has choices. Our quote-to-cash handoff map explains how an accepted scope change should reach billing without relying on someone remembering a conversation. The scope-change workflow guide provides another planning reference; adapt its decisions to your operation rather than assume a ready-made live integration.

A hypothetical approval that becomes a scope change

Imagine a small design agency preparing a five-page brochure for a training provider. The agreed package includes one consolidated client revision round. The client owner receives version two, with a clear request to approve the text and layout for those five pages.

The response contains a correction to a trainer’s name, a request for a different photograph, and a new section describing another course. The agency logs all three against the same review package, then separates their treatment. Correcting the name is an accuracy correction. Changing the photograph may fit the existing revision allowance. Adding a course could change the page count and therefore the agreed scope.

The project owner prepares a choice: retain the original five-page structure and defer the new course, or approve a revised package with an explicit additional fee and later delivery date. The client owner can recommend a choice, but a separate budget approver must accept the fee if that is how the client has defined authority.

Only after that decision does the agency revise the production plan. The original version remains in history as superseded, rather than being renamed “approved final.” This illustrative case demonstrates the records needed; it does not claim a measured reduction in rework or disputes.

Give feedback a usable structure

Ask reviewers to connect each comment to a page, section, frame, or item identifier. Encourage them to state the problem and intended outcome before suggesting wording. “This sounds too strong because the offer applies only to existing customers” is easier to act on than “make it better.”

Require the decision owner to reconcile contradictory comments. The agency can present alternatives and consequences, but should not guess which client stakeholder wins. If one reviewer asks for a shorter page and another adds substantial copy, return that conflict as a decision with a clear owner.

Keep a response log with the comment, agency interpretation, proposed treatment, and disposition. Some comments will be incorporated; others will require clarification or an explicit decision not to change. Record the reason concisely. Avoid treating every rejected suggestion as a failure: a well explained decision can preserve the brief and save unnecessary work.

Protect client access while sharing this record. An external reviewer needs their review package, not a link to every other client’s folder. Internal notes about commercial negotiations also need an appropriate audience. Clear permissions support a smooth review experience without turning the approval register into an uncontrolled archive.

Agree timing without inventing approval

Set a requested decision date, the response channel, and the consequence of delay. For example, a delayed decision may mean the agency must propose a new production slot. This is more useful than an unexplained red deadline that nobody has agreed to maintain.

Treat silence according to the actual agreement and applicable requirements. As an operating default, do not convert an unanswered request into positive approval. If the project uses a particular contractual mechanism, have the responsible person confirm how it applies. The tracking system should reflect that decision instead of creating commercial terms through a timer.

Send reminders that name the package and decision needed. Before each reminder, check whether a response has already arrived elsewhere, the request was superseded, or the project was paused. Repeated reminders about an obsolete version undermine trust and create avoidable replies.

The guide to setting client expectations covers how to explain dependencies early. Approval timing is one of those dependencies, especially when publication dates depend on several organizations.

Keep publication as a separate checkpoint

An artifact can be approved while release is still blocked. The client may need to confirm a launch date, final price, image rights, legal wording, or the correct audience. Build a short release checklist tied to the approved version rather than assuming all these matters were included in creative feedback.

Have the release owner compare the final output with the approved package. Exporting, resizing, or transferring content can introduce changes after review. Verify the relevant links, destinations, dates, and assets in the actual release environment. Decide which corrections can be checked internally and which require renewed client approval.

Record the release authorization, responsible person, time, and exact output. Where there is a scheduled publication step, check for a cancellation or newer instruction immediately beforehand. A prepared schedule is not permanent authorization to publish after circumstances change.

For first-party downloadable resources, the same principle applies to automatic delivery. Release the correct, reviewed resource version and retain a route to replace a broken file. Automatic distribution should execute a settled decision rather than become a substitute for deciding what is ready.

Measure the source of waiting and rework

Track time awaiting a valid decision separately from agency production time. Also track incomplete review packages, conflicting comments, scope changes, and post-approval corrections. These categories help identify whether the problem belongs in briefing, production quality, client coordination, or release checks.

Use a small review sample alongside the numbers. A long approval interval may reflect a planned holiday rather than poor coordination. A fast approval followed by major corrections may be less healthy than a careful review that catches a real issue. Explain excluded or paused time consistently so that comparisons remain meaningful.

Do not judge people by raw comment counts. Ten precise corrections could resolve a package faster than one vague instruction. Prefer measures that connect to decisions: how often a package is complete at submission, how often a client must ask what to review, and how often an approved version is changed accidentally.

Write a decision request the client can act on

A concise decision request can carry the essential context without reproducing the whole project history. For the hypothetical brochure, the opening might read: “Please review brochure package BR-17, version three, for text and layout approval. This version includes the corrected trainer name and replacement photograph. The additional course remains outside this package while its scope proposal is pending.”

Follow that with the specific choices: approve the stated package, request consolidated revisions with locations, or explain a blocker. Name the decision owner and requested response date with a time zone where needed. Link to the exact artifact and the response route. Explain that publication is a later step if that is how the project is structured.

The agency’s internal record should preserve what was sent and the response received. If the client replies “approved except page four,” clarify the remaining decision instead of allowing production staff to interpret the exception independently. A useful follow-up identifies page four’s unresolved issue and confirms whether other pages can proceed under the agreed process.

Avoid burying a new fee, changed deadline, or extra deliverable in an approval message that appears to concern only artwork. Present commercial adjustments as clear decisions for the authorized person. This makes the request easier to understand and gives the agency a record that reflects what the client was actually asked to decide.

Test the process before making it the default

Choose one upcoming project with a cooperative client contact. Explain the proposed review structure and agree any commercial terms through your normal process. Prepare a sample register using synthetic content before putting client work into it.

Walk through an absent approver, a replaced version, contradictory feedback, a scope increase, and a cancellation after scheduling. A process that handles only an immediate “yes” is not ready to manage ordinary agency work. Verify that staff can locate the latest decision without assistance from the project’s original coordinator.

After the pilot, remove fields that never informed a decision and clarify the fields that staff interpreted differently. Keep the result short enough to use on a busy day. The objective is a dependable trail from request to approved output, with room for thoughtful creative work between those checkpoints.

Sources and editorial method

Research checked October 15, 2026. Sources are Asana on change control and Asana on creative request management. Their general operating concepts informed brief contextual references. The review register, decision states, agency checklist, and hypothetical brochure example are original editorial frameworks, not vendor instructions, a tested software integration, or legal advice about a particular agreement.