How to turn invisible QA work into a client-facing deliverable

There is a category of agency work the client never sees, and launch QA sits at the top of it. The site looks the same after the review as before — that was the point — so from the client's side of the table, nothing happened. Work that is invisible is hard to value, and work that is hard to value is hard to bill.

Most agencies respond by making the work visible in the worst possible way: exporting the scanner and forwarding it. Forty rows, tool jargon, severity colours, no verdict. The client cannot read it, so they either ignore it — QA stays invisible — or they read three rows, find one that sounds scary, and now the launch call is about a viewport meta tag.

The raw dump fails because it answers the wrong question. The client is not asking what did the tool find? They are asking can we launch, and what should I worry about?

Three reading layers, three readers

A QA deliverable that earns its line item is structured for how people actually read: almost nobody reads everything, and different readers need different depths. Build it as three layers.

The layers are not three documents — they are one document that stops making sense to each reader at the right moment. The owner reads a page and stops. The project lead reads four and stops. The developer reads what they need, finding by finding.

The 60-second layer

One page. The decision, stated in a sentence a non-technical person can repeat in their own meeting. The score, if you use one — with what it means, not just the number. And no more than three findings, chosen by client consequence rather than by tool severity.

Ready to launch, with one item to resolve this week.

The site passed 47 of 50 checks. One finding materially affects visitors: the contact form's error state shows a raw server message. Two further items are recorded for the next sprint; neither blocks launch. Full detail and evidence follow.

The hardest edit is leaving things out. A finding that is real but immaterial belongs in the operating layer — putting it on page one tells the client you cannot tell the difference between important and true.

The 5-minute layer

Every material finding, one row each: what it is, what it means for this client's visitors, its status, and who owns it. Status does the heavy lifting — the difference between a confirmed defect and an item awaiting the client's own confirmation is the difference between "fix it" and "tell us".

This is also where honesty about uncertainty lives. An automated check that could not see behind a login says so here, plainly, instead of pretending coverage it did not have.

The implementation layer

The layer the client's developer opens the morning after the meeting. Each finding carries its evidence — what was requested, what came back — the exact location, and an acceptance criterion someone can verify without re-arguing the finding.

Inspection ticket№ AP-2026-0395

Medium priorityConversion

Contact form error state exposes a raw server message

FILED ON · /contact

Submitting with an unreachable endpoint renders the raw 502 body. Evidence: submission attempted 24 July, response captured. Acceptance: a designed error state that keeps the visitor's typed message on screen.

A finding written that way transfers without a meeting. A finding written as "form broken (high)" generates one.

What belongs to the client report, and what does not

The developer handoff and the client report are different documents wearing the same findings. The split:

• Client report: decisions, material risks, what was verified, who owns what, and the evidence for anything consequential. Written in the client's vocabulary.
• Developer handoff: everything, including the immaterial and the speculative, with locations and acceptance criteria. Written in yours.

The failure mode is leakage in either direction — tool jargon drifting up into the client layer, or material risk staying buried in a ticket the client never sees.

Frame limitations as scope, not apology

Every automated review has limits, and the deliverable should state them the way a surveyor states theirs: as the boundary of what was inspected, not as a confession.

From deliverable to service

Once the report exists as a real artifact, three commercial doors open. It can be branded — a report carrying your name reads as agency work rather than as a tool's output, which is the difference between billing for QA and absorbing it. (In AgencyProof, full white-labelling is an Agency-plan entitlement; the other tiers produce a client-facing summary you forward under your own cover.) It can be repeated — the same structure before every launch turns a one-off favour into a line item. And it can be compared — this launch against the last one, which is the beginning of a retainer conversation.

None of that requires more findings. It requires the findings you already have, structured so each reader can do their job in the time they were ever going to give you.

This article is the method. If you want to see the shape as a client would receive it, the sample report is the same three layers rendered as a real deliverable.