A client approval workflow that holds up
Why feedback scatters, why final-final keeps happening, and the approval workflow that ends disputes: named approvers and timestamped decisions.
· 4 min read · Client delivery
The file is called Homepage-v4-FINAL-final-2.pdf. Nobody in the agency can say with certainty whether it is approved. The client's marketing manager left comments in the shared doc. Their managing director said something different on Thursday's call. Someone forwarded an email that ends "looks good, just tweak the blue", and it is not clear which blue, or which version, or whether "looks good" was an approval or a mood.
The work is finished. The decision about the work is nowhere.
Feedback scatters because every channel feels reasonable
No client sets out to make feedback untraceable. They reply to the email you sent, because that is where the PDF was. They mention a thought on a call, because you were both on the call. They comment in the doc, because the doc has a comment button. Each channel is individually sensible. Collectively they produce a decision smeared across four surfaces, in fragments that do not agree with each other.
Then someone in your studio has to reconcile it. The MD wants the logo bigger; the marketing manager, in writing, wants it smaller. The email approves "the latest version", which was two versions ago by the time it was sent. Reconciling scattered feedback is real work, it is billed to nobody, and it must be redone from scratch every round, because the fragments never converge on their own.
Why final-final keeps happening
Version chaos is not a naming problem, so naming conventions do not fix it. It happens because the versions have no spine. Each round of feedback spawns a new file, the files accumulate in email attachments and shared folders, and the approval, when it finally comes, attaches to no version in particular. "Approved" is a word in a thread. Which artefact it refers to is a matter of inference.
So version four gets a suffix, and version five gets two, and the version the client remembers approving is not quite the version in the folder. When the printed brochure arrives with the old strapline, both sides are certain, and both sides are looking at different files.
What a workable flow actually needs
The fix is structural, and it is smaller than it sounds. Four properties, all of them boring, all of them non-negotiable.
One place per deliverable. Not one place per project or per client: per deliverable. The homepage design has a home, every version of it lives there in order, and anything said anywhere else is a remark, not a decision. This only works if the client can reach that place without friction, which is a portal problem as much as an approvals problem; the wider requirements are covered in what a client portal for agencies actually needs.
Feedback pinned to the artwork. "The image on page three feels off" is a riddle. A comment pinned to the exact spot on the exact version is an instruction. Pinned feedback also quietly ends the reconciliation job, because there is nothing to reconcile: every comment already knows which version it belongs to and which pixel it is about. That is the heart of how deliverable reviews should work.
Named approvers. A deliverable is approved by a person, not by a company. Agree up front whose click counts. When the MD and the marketing manager disagree, the flow does not need diplomacy, it needs a rule that was agreed in week one, and a named approver is that rule. Anyone else can comment; one person can approve.
A recorded decision with a timestamp. The approval is an event, not a vibe: this person approved this version at this time, and the record says so. If they requested changes instead, that is recorded the same way, against the same version.
One more thing keeps rounds from sprawling: give the review itself a date. Feedback that can arrive whenever it likes will arrive after the deadline. A review round with a visible landing date turns "waiting on client" from an excuse into a status the client can see, with their own name on it. There is a broader case for dates the client can see in landing dates, not deadlines.
What this changes about disputes
Here is the conversation this flow makes possible, delivered calmly, with the record open: you approved this on the 12th. Version three, 2:41pm, approved by Sarah. The changes you are describing arrived on the 19th, a week after sign-off, so we can absolutely make them, and here is what that round will cost.
Notice what that sentence is not. It is not an accusation, and it does not depend on anyone's memory. The dispute stops being an argument between two recollections and becomes a lookup. Most disputes, faced with a lookup, simply dissolve, and the ones that remain become commercial conversations about new work rather than moral conversations about who dropped what.
The record protects the client just as much, which is exactly why they accept it. If your studio ships something that was never approved, the record says that too. A one-sided audit trail would feel like a trap. A neutral one feels like professionalism, because that is what it is. Clients do not resent a clear approval flow. They resent doing feedback twice.
Where HoopoeHQ fits
Reviews in HoopoeHQ work the way this argues they should: each deliverable has one home in the client's own workspace, feedback is pinned to the artwork, approvers are named, and every decision is recorded with a timestamp. It exists because vague approvals kept costing a real agency real money. If final-final-2 is a filename you recognise, start a 14-day trial and put your next deliverable through a review that holds up.