Agency Quality Assurance: The Checklist Beats the Careful Reader

Every agency believes it has quality assurance. What most have is care.

Care is real and it is not a process. Care means the designer looks over their work before sending it, the developer tests the thing they built, and the account lead skims the deliverable before forwarding it. All of that is genuine, and all of it degrades under exactly the conditions where it matters most - a tight deadline, a tired team, the fourth revision of something everyone is bored of.

The errors that reach clients are almost never sophisticated. They are the wrong version attached, a placeholder that survived to delivery, a link to a staging environment, a client request from week two that quietly never got done. Those are not failures of skill. They are failures of checking, and checking is systematisable.

This guide covers the three layers of QA, what belongs on the checklist, who should review, how to fit QA into a deadline, and how to handle the errors that get through anyway.

Why the boring errors dominate

Worth being precise, because it determines where to spend effort.

Sophisticated errors - a subtle design decision that does not work, an architectural choice that limits later flexibility - are relatively rare and genuinely hard to catch. Boring errors are common, trivially catchable, and disproportionately damaging to how the client perceives you.

A client who receives a deliverable with lorem ipsum still in it does not conclude that someone was rushed. They conclude that nobody checked, and that inference generalises to everything else you send. The cost is not the error; it is the doubt.

Which is the argument for a checklist over judgement. Judgement is required for the hard problems and is not what fails. The checklist covers the boring ones, and the boring ones are most of the damage.

What "quality" means in an agency context

Worth defining, because it is used to mean two different things and only one of them is checkable.

Craft quality is whether the work is good - the judgement, the taste, the execution. Subjective, developed over years, and not something a process improves directly.

Delivery quality is whether what you sent matches what was agreed, contains no errors, and includes everything promised. Objective, checkable, and entirely systematisable.

This guide is about the second. It is the one that fails under deadline pressure, the one clients notice most immediately, and the one a checklist actually fixes.

The three layers

Layer 1: the maker's pass

The person who produced the work checks it against the brief before it goes anywhere.

This sounds automatic and is not. The distinction is checking your work against the requirements rather than reading it again. A designer reviewing their own design looks at whether it is good; the maker's pass asks whether it does what was asked, all of what was asked, and nothing that was excluded.

Give it a structure so it survives a deadline: re-read the brief, list the requirements, confirm each one. Ten minutes.

Layer 2: peer review

Someone who did not make it looks at it.

The value here is entirely in the fresh eyes. Someone who has spent nine hours on a page cannot see it any more - not through carelessness, but because familiarity makes errors invisible. A colleague who has not seen it before will find things in four minutes that the maker could stare at for an hour.

Peer review does not require seniority. A junior person with a checklist catches more client-visible errors than a senior person reading carefully without one, because the errors in question are not subtle.

Layer 3: pre-delivery check

The final gate before it reaches the client. Run against the checklist, by someone with the brief open.

This layer specifically checks client-facing correctness rather than craft: is this the right version, does it include everything promised, does it exclude what was excluded, is it in the right format, is it addressed to the right people.

Mindful QA's recommendations for digital agencies makes a point worth carrying: agency QA has to work without the rigid sprint structure a product team has, which means it depends more on a repeatable checklist and less on ceremony.

The checklist

Written, specific, and versioned by deliverable type. A generic checklist gets ignored because most items do not apply.

Universal items, every deliverable:

• Is this the correct, latest version?
• Does it address every requirement in the brief? Go through them one at a time.
• Have all client requests from the current round been actioned, including the small ones raised in passing?
• Is anything included that was explicitly out of scope?
• Any placeholder content, dummy data, or internal comments remaining?
• Are all links working and pointing at the right environment?
• Correct client name, correct project name, correct date, correct branding throughout?
• Is it in the format the client asked for?

Design deliverables:

• Consistent with the brand guidelines actually supplied, not remembered?
• All states covered - empty, loading, error, long content?
• Responsive behaviour defined for the agreed breakpoints?
• Text legible at the sizes specified, contrast sufficient?
• Fonts and assets licensed for the client's use?

Development deliverables:

• Tested on the browsers and devices agreed in scope, not just yours?
• Forms submit, validate and confirm?
• Errors handled visibly rather than silently?
• Analytics and tracking in place and firing?
• No credentials, keys or debug output in the shipped code?
• Performance checked on a realistic connection?

Written deliverables:

• Proofread by someone who did not write it?
• Facts and figures verified against a source?
• Client and product names spelled correctly throughout - the single most common and most damaging error in this category?
• Tone consistent with what was agreed?

zipBoard's QA review playbook and Red Falcon's creative QA checklist are both useful for the fields worth tracking around a review - owner, approver, deadline, status, revision note - which is the administrative half of making QA repeatable rather than occasional.

The eight minutes

The whole practical case for QA fits in one number: a twelve-item checklist takes about eight minutes to run against a deliverable. That is the entire cost.

Who reviews

Not the person who made it, for layers 2 and 3. That is the whole point.

Not always the most senior person available. Senior review is expensive, becomes a bottleneck, and - because senior people are usually reviewing for craft - is not actually better at catching the boring errors.

A rotating peer, for most work. It spreads the load, exposes people to each other's work, and avoids one person becoming the quality bottleneck everyone waits on.

A named reviewer per project, agreed at kickoff, so it is never a question of who has time.

For larger agencies a dedicated QA function is worth it, particularly for development work. Below roughly fifteen people, a rotating peer model with a good checklist gets most of the benefit at a fraction of the cost.

Fitting QA into a deadline

The universal objection is that there is no time. Four responses, all practical.

Build it into the estimate. QA is not overhead, it is part of delivery. Add 10-15% for review to any estimate. If your estimates have no QA line, you are systematically under-estimating and then discovering it as a quality problem.

Make the checklist fast. A 60-item checklist will be skipped. A 12-item one takes eight minutes and gets done. Ruthlessly prune anything that has never caught anything.

Review in stages, not at the end. A single QA gate before delivery is where deadline pressure concentrates. Reviewing at each milestone spreads it and finds problems while they are cheap to fix.

Treat it as non-negotiable, especially when late. The temptation to skip QA is exactly proportional to the risk of needing it. A late delivery is recoverable; a late delivery with an obvious error in it costs the relationship.

When something gets through

It will. What matters is the response.

Tell them before they find it. If you spot an error after sending, say so immediately. An agency that flags its own mistake reads as rigorous; one that waits to see whether it is noticed reads as the opposite, and gets noticed anyway.

Fix it, then diagnose it. Correct the deliverable first. The question of how it happened is important and it is not urgent.

Ask what would have caught it. If the answer is "a checklist item we do not have," add it. If it is "the checklist item we skipped," that is a different problem - about process discipline rather than process design.

Do not add a checklist item for every single error. Checklists grow until they are unusable and then get abandoned entirely. Add items for errors that are likely to recur; note the genuine one-offs and move on.

Recurring errors belong in the retrospective, where the pattern across projects is visible in a way it never is from a single incident.

Building the checklist from your own errors

A generic checklist is a starting point. The one that catches things is built from what has actually gone wrong in your agency.

Keep an error log for three months. Every time something reaches a client that should not have - a wrong version, a missed request, a broken link, a typo in a client's name. One line each: what, which project, how it got through.

Review it quarterly and look for repeats. Three instances of the same category is a checklist item. One instance is a note.

Weight the list by damage, not frequency. A misspelled client name is rare and disproportionately damaging; a slightly-off margin is common and nobody notices. The checklist should reflect consequence rather than count.

Prune ruthlessly. Any item that has not caught something in a year comes off. Checklists die from length, and a twelve-item list that gets used beats a sixty-item one that gets skipped under deadline pressure.

This is also the most useful output of a retrospective: a specific, checkable item that prevents a specific recurrence, rather than a general resolution to be more careful.

QA and the client review

An underdiscussed interaction: your QA process and the client's review are different things, and conflating them wastes both.

Your QA asks whether the work meets the brief. Objective, checkable, and it happens before anything reaches the client.

The client's review asks whether they like it and whether it does what they wanted. Subjective, and legitimately so.

The failure mode is sending work that has not passed your own check and letting the client's review find the errors. That is outsourcing QA to the person paying you, and it produces two costs: their feedback is consumed by trivial corrections rather than the substantive judgement you actually need, and each round of obvious errors reduces their confidence in everything else.

A practical rule: the client should never be the first person to notice a mistake. If they are finding placeholder text and broken links, they are doing your job, and the revision round you paid for has been spent on things a checklist would have caught in eight minutes.

What QA is not

It is not approval. Reviewing that a deliverable meets the brief is different from deciding it is good enough to send. Keep them separate or QA becomes a second opinion on creative direction, which is slow and contentious.

It is not a substitute for a clear brief. You cannot check work against requirements that were never written down. Most "quality problems" that survive a real QA process turn out to be scoping problems, which is why the kickoff and the statement of work do more for quality than any checklist.

It is not blame. A QA process that finds errors is working. One that finds none is either reviewing trivial work or not being run.

The cost of not having one

Worth stating plainly, because QA loses to delivery time unless someone has quantified it.

Each revision round caused by an error you could have caught costs roughly a day - the client review, the correction, the re-review, the context switching. On a project with three such rounds that is three days of unbudgeted work.

The reputational cost is larger and invisible. A client who receives work with obvious errors does not conclude someone was rushed. They conclude nobody checked, and that inference attaches to everything else you send - including the things that were checked.

And it consumes the review you actually needed. A client's revision round spent on placeholder text and broken links is a round not spent on the substantive judgement you wanted from them, which means the real feedback arrives a cycle later.

Against that, eight minutes per deliverable against a twelve-item checklist is not a close decision.

Automating the boring half

A meaningful proportion of a QA checklist can be checked by a machine, and anything a machine checks is checked every time regardless of deadline pressure.

Development work has the most available: automated link checking, broken image detection, accessibility scanning, performance budgets, and tests that fail a build if debug output or credentials are present. None of it is exotic and all of it removes items from the human checklist permanently.

Content work benefits from spell and grammar checking configured with the client's product names added to the dictionary, which catches the single most damaging error category in written deliverables.

Design work automates least, though asset naming conventions and export scripts remove a category of version confusion.

The principle worth applying: every item you automate should be deleted from the human checklist. Checklists that grow indefinitely get abandoned. The goal is a short human list of things only a person can judge, with the mechanical checks running invisibly underneath.

QA on client-supplied material

An under-discussed failure. A meaningful share of errors that reach the end audience originate in material the client supplied - copy with a wrong figure, an out-of-date logo, a legal disclaimer that has since changed.

Your process should include a light check on incoming material, and your scope should be clear about the limits of it. Two lines in the statement of work prevent the argument later: you check supplied content for obvious errors and correct placement; you do not verify factual accuracy, legal compliance or claims.

That is a fair division, it is what the client expects when it is stated, and it is a genuinely contentious surprise when it is not.

Who owns quality when everyone is busy

The structural question underneath every QA process: quality competes with delivery time, and under pressure delivery wins unless someone is accountable for the other side.

Name a reviewer per project at kickoff. Not "whoever has time" - a name, agreed in advance, so it is never a question in the week it matters.

Give the reviewer the authority to hold something back. A review that can be overridden by whoever is anxious about the deadline is not a gate. This is uncomfortable the first time it is used and it is the entire point.

Make the reviewer someone other than the project's owner. The person accountable for the date should not be the person deciding whether it is ready, for the same reason account and project management are separated in agency structure - the tension should happen between two people rather than inside one.

Rotate it. A single quality gatekeeper becomes a bottleneck and, eventually, the person everyone resents. Rotation spreads both the load and the perspective.

What to do about a client who finds errors

Occasionally a pattern develops where a particular client keeps finding mistakes. Two possible causes and they need opposite responses.

Your QA is genuinely failing on that account. Usually because the work is unfamiliar, the checklist does not fit it, or the account is under time pressure that nobody has acknowledged. The fix is a project-specific checklist and an honest look at whether the engagement is resourced.

The client is reviewing at a level of detail nobody agreed to. Also real. Some clients review as though checking rather than approving, which surfaces things that are not errors - preferences, alternative choices, matters of taste presented as faults.

The distinction matters because treating the second as a quality problem leads to over-checking that costs hours and satisfies nobody. If the items being raised are preferences rather than defects, that is a scope and expectations conversation covered in difficult client conversations, not a QA one.

Starting from nothing

If you have no formal QA today, four steps in order:

1. Write a 12-item universal checklist from the list above. One page. This alone catches most client-visible errors.
2. Require a named second reviewer on anything that goes to a client. Not senior - just not the maker.
3. Add 10-15% to estimates for review, so it stops competing with delivery time.
4. Add one item per recurring error, and prune anything that has not caught something in a year.

That is a working QA process. It costs eight minutes per deliverable and it removes the category of error that does the most damage to how clients perceive you - which is not the hard problems, but the placeholder text that made it to the client and told them nobody was looking.