Merlino AI

How Client Work Actually Moves Through Our Agency

2026-08-184 min readclient-deliveryreview-cadenceagency-operationsproof-of-work

Skipping the first step is the most common way to fail

I have watched more engagements go sideways from a skipped first step than from any bad execution later on. My agency runs client work through four stages, in order: Discovery, Build, Review, Handoff. Discovery is the one people are most tempted to rush past, and it is explicitly the stage I treat as non-negotiable, because skipping it is the single most common cause of engagement failure I see. Nobody fails at Handoff because Handoff is hard. They fail because nobody agreed on the actual problem at Discovery.

Four stages, one client-facing checkpoint at each

The pipeline is not four internal steps that happen to end with a delivery. Each stage has its own client-facing checkpoint built in.

  • Discovery ends with agreement on what problem is actually being solved, confirmed with the client, not assumed by the team.
  • Build is where the work actually happens against that agreed scope.
  • Review is the checkpoint before anything ships. This is where proof of work gets checked against what Discovery promised, before the client ever sees a final deliverable.
  • Handoff is the close: the client receives the work with a clear record of what was done and why.

That Review stage is the whole point of this piece. Nothing moves from Build to Handoff without passing through a checkpoint that exists specifically to catch drift between what was promised and what got built.

Proof of work is not a one-time event, it is a tracked cadence

The Review checkpoint only means something if there is a real system feeding it, not a single meeting before delivery. My agency runs a standing cadence for this on live client workstreams, tracked through what the team calls the CTR campaigns tracker and a document called the review checker. This is not a one-off mention in a single meeting. It shows up repeatedly in real call transcripts, with named team members updating it on a recurring basis, the same way a status report gets updated every week because the work is actually ongoing, not because someone remembered to check a box.

That distinction matters. A tracker that gets mentioned once and never referenced again is decoration. A tracker that named people update on a cadence, and that shows up unprompted in multiple separate recorded calls, is infrastructure the team actually relies on.

The folder structure backs up the process, it is not just a claim

None of this lives only as a verbal process. The agency's real operating folder contains dedicated, structured categories for exactly this kind of ongoing verification: an audit-tracker, a client-operations-dashboard, and a client-workspace-inventory sit alongside the admin, templates, and client-roster folders any agency would expect. Those are not folders I created for this article. They are the live structure the team works out of, which means the proof-of-work discipline is baked into where the files live, not just into how people talk about the process.

Why proof before shipping beats proof after complaints

The alternative to this structure is familiar to anyone who has run an agency without it: work ships, the client finds a problem, and now the team is doing damage control instead of delivery. A Review stage that happens before Handoff, backed by a tracker that gets updated on a real cadence and a folder structure that makes the tracking visible, moves that failure point earlier, to where it is cheap to fix instead of expensive to explain.

The rule I actually operate by is simple to state and harder to keep: nothing ships until someone can point to what was checked and against what standard. Discovery sets that standard. Review checks the work against it. Only then does Handoff happen. Skip any one of those and you are not running a delivery pipeline, you are hoping.

The Build Log

One email.The whole build.

One email when something ships: the dashboard, the agent, the GMB play, and the prompts and configs that made it go. If it fell over on the first try, I say that too.