Creative approval workflow: a step-by-step guide

Most agencies do not have an approval workflow. They have a habit. Someone exports a file, someone emails it to the client, and then everyone waits to find out who else needs to see it. The account manager learns on round three that legal has to sign off. A senior person on the client side appears on round five with a new opinion about the headline.

A creative approval workflow fixes that by deciding the route before the first file goes out: which stages exist, who signs off at each one, what a decision means, and when it is due. This guide walks through building one you can fit on a single page and actually use.

Step 1: Define your approval stages

Approval stages are the checkpoints a creative passes through between first draft and final sign-off, and most agencies need three to five of them. Fewer than three usually means internal quality checks are getting skipped. More than five usually means people are reviewing things they have no real stake in.

A common set looks like this:

1. Internal review. The creative lead checks the work against the brief and the brand before anyone outside the team sees it.
2. Client working review. The day-to-day client contact reviews the work and gathers feedback from their own team.
3. Specialist review. Legal, compliance, product or regional teams check the parts they own. Not every project needs this stage.
4. Final sign-off. One named person on the client side gives the decision that lets the work ship.
5. Pre-launch check. A last look at the exported files, sizes and specs before they go live.

Write each stage with a clear entry condition and exit condition. “Internal review ends when the creative lead approves” is a rule. “Internal review ends when it looks good” is not. If you want a structured way to run that first stage, our pre-send checklist covers what to check before a client ever opens the file.

Also decide which stages repeat. If the client asks for changes in stage 2, does the new version go back through internal review? In my agency the answer is yes for anything beyond a typo fix, because a quick change made under pressure is exactly where mistakes slip in.

Step 2: Decide who approves what

Every stage needs named approvers, and each approver should own a specific part of the work. “The client” is not an approver. “The brand manager, who approves visuals and tone of voice” is.

The question to ask is not “who wants to see this?” but “whose decision would actually stop this from shipping?” Plenty of people want to see work. Far fewer need to approve it. Separate them into two groups:

• Approvers make a decision that counts toward the status of the creative.
• Commenters add feedback and context, but their input does not block or release the work.

Keep the number of approvers per stage small, ideally one or two. Every extra approver adds another calendar, another set of opinions, and another person who might be on holiday. If a legal reviewer only cares about disclaimers, say so in the workflow, so nobody expects them to comment on the colour of a button.

Then name a tiebreaker. When two approvers disagree, someone needs the authority to decide. Agree on who that is at kickoff, not in the middle of a tense round.

Step 3: Use three decision types

Reviewers should pick one of three decisions: Approve, Approve with changes, or Changes required. Three options cover nearly every real situation, and they remove the ambiguity of replies like “looks fine, maybe tweak the headline?”

The middle option is the one that saves the most time. Without it, a reviewer who wants a comma fixed has to choose between approving something imperfect and forcing a full extra round. Write down what counts as “small” for your team, for example copy edits, alignment fixes and swapping in an image that was already agreed on.

Agree on one more rule: a single “Changes required” holds the creative. If one approver says changes are needed, the work does not move on just because others approved. This is how Yesquill handles it: any “Changes required” sets the status to Changes required, and the creative is marked Approved only when all assigned reviewers approve. Whatever tool you use, make the rule explicit so nobody ships work that one approver flagged.

Make sure reviewers know how to write the comments that go with a decision. A “Changes required” with no explanation is nearly as bad as silence. Our guide to clear design feedback is a useful thing to share with clients at kickoff.

Step 4: Set due dates for every stage

Each review round needs a due date that the reviewer agreed to in advance. Without one, review time expands to fill whatever space is left before launch, and the production team absorbs the squeeze.

Work backward from the launch date. Here is a worked example, not a benchmark: say a campaign launches on a Friday and you need two working days for final production. That puts final sign-off on the Tuesday. If you allow two working days for each client round and one for internal review, you can see straight away how many rounds you can afford, and you can tell the client that number on day one.

A few habits help due dates stick:

• Set the date when the file is sent, not after the reviewer has opened it.
• Give a time as well as a day. “Thursday” means different things to different people.
• Send one reminder before the due date, not five after it.
• Say what happens if the date is missed, for example the launch moves or the next stage starts later.

Due dates only work if the review is easy to open. If clients keep missing them, the problem is often the delivery, not the client. Our guide to review links clients actually open covers that side.

Step 5: Write it down in a simple RACI table

A RACI-style table puts the whole workflow on one page: for each stage, who is Responsible for doing the work, who is Accountable for the decision, who is Consulted, and who is only Informed. You do not need a formal framework. You need a table everyone can read in thirty seconds.

Here is a template you can copy and adapt:

The rule of thumb is one name in the Accountable column per stage. If you find yourself writing two, either split the stage or name a tiebreaker. The Turnaround column holds the time allowed, and the actual due date gets set each round.

Share the table at project kickoff and ask the client to confirm the names. It is much easier to agree on who approves when nobody has an opinion about the work yet.

Step 6: Run the workflow in one place

A workflow written on paper falls apart when the actual review happens across email threads, chat messages and a shared drive. Run every stage in one place, where the file, the comments, the decisions and the dates live together.

At minimum, that place needs:

• Comments pinned to the exact spot on the design or the exact frame of a video, so feedback is not open to interpretation.
• Clear decisions from each named approver, with a visible status.
• Version history, so a new round does not erase what was said on the last one.
• Due dates and notifications, so nobody has to chase by hand.
• An activity log, so you can see who approved what and when.

You can stitch this together with folders and spreadsheets, and plenty of teams do. A dedicated tool makes it easier to keep. In Yesquill, for example, you assign reviewers, set a due date, and send clients a review link that does not need an account. When you upload a new version, decisions reset and earlier comments stay attached to the version they were made on. The full list is on our features page.

After each project, spend ten minutes reviewing the workflow itself. Which stage took longest? Did anyone outside the table turn up with late feedback? Adjust the table for next time. A workflow is not finished when you write it down. It gets better each time you run it.