The deliverable is finished. The files are in the shared folder. The Slack message went out three days ago. And now you are waiting on one email that has not arrived. Meanwhile, the project sits, the deadline slides, and your team moves on to other work while this one quietly bleeds time. This is the most common failure point in agency delivery, and it has nothing to do with the quality of the work. It has everything to do with the absence of a real pipeline between done and delivered.
This article gives you a concrete delivery pipeline you can build and use, including client approval gates that create accountability without creating friction.
What a delivery pipeline actually is
A delivery pipeline is not your project management board. It is not the production workflow your team uses to build things. The delivery pipeline starts the moment work is done and ends the moment it is live. Everything in between, who reviews it, who approves it, what triggers the next step, belongs to the pipeline.
Most agencies have a production process and a publish button, with nothing structured in between. That gap is where time disappears. A delivery pipeline closes the gap by giving every stage a clear entry condition, a clear exit condition, and one person responsible for moving it forward.
From done to delivered
Internal QA
team review
Staging
client preview
Client approval
sign-off gate
Revisions
if needed
Final approval
locked
Publish
live
The three approval gate models
Before you build anything, choose your approval gate model. The model determines how many times the client formally reviews work before it goes live. Each model fits a different type of project and client relationship. Picking the wrong one creates either unnecessary friction or unnecessary risk.
Single-gate
How it works
One approval point before publish
Best for
Simple deliverables, fast turnarounds
Risk
High on complex projects
Speed
Fastest
Revision exposure
High if scope is unclear
Multi-gate
How it works
Approval at each stage: copy, design, final
Best for
Complex projects, high-stakes deliverables
Risk
Low, problems caught early
Speed
Slower upfront, faster overall
Revision exposure
Low, issues caught per stage
Async approval
How it works
Client reviews via shared link on their schedule
Best for
High-volume work, retainer clients
Risk
Medium, depends on deadline clarity
Speed
Variable
Revision exposure
Medium without firm deadlines
The multi-gate trade-off
Most agencies default to single-gate because it feels simpler. Multi-gate takes more setup but cuts revision rounds by roughly half on complex projects. The extra approval steps pay for themselves in time saved during revisions.
Building your pipeline step by step
Map your current handoff points
Look at your last five projects and find every place work stopped and waited. These are your current handoff points. Write them down before you design anything new.
Define each stage with entry and exit conditions
Every stage needs a clear start trigger and a clear end trigger. 'In review' is not a stage definition. 'Client has received the Figma link and has 48 hours to respond' is a stage definition.
Assign one owner per stage
Name one person, not a team, who is responsible for moving each stage forward. When a stage has multiple owners, it effectively has no owner.
Choose your approval gate model
Use the comparison above to pick single-gate, multi-gate, or async. Document the choice in your project brief so everyone on the team knows what to expect.
Set up a staging environment or preview method
Give the client something concrete to review. A staging URL, a Figma link, a Google Doc with comment access. The format depends on the deliverable type.
Write your approval request template
Create a reusable message template that tells the client exactly what to look at, what to do, and by when. You will use this template every time you send work for review.
Define what happens when a deadline passes with no response
Decide in advance: does silence count as approval? Does the project pause? Does an automatic follow-up go out? Write this into your contract and your template.
Stage definition
A stage definition tells everyone when a stage starts and when it ends. Vague definitions create ambiguity about who needs to do what.
Stage owner
One named person owns each stage. That person is responsible for the stage moving forward, not the team in general.
Approval deadline
Every approval request needs a deadline and a stated consequence for missing it. Open-ended requests produce open-ended delays.
Writing an approval request that actually gets a response
Clients do not delay because they are difficult. They delay because the approval request does not tell them exactly what to do. A vague message that says 'let us know what you think' requires the client to figure out what they are supposed to think about, how to respond, and when. Most of them do not figure it out. They set it aside and forget it.
A good approval request has five components: a subject line that names the deliverable and the action, one link to the preview, one specific question, a deadline, and a fallback action if no response arrives. That structure removes every reason to delay.
Generate an approval request message
Claude / GPT-4Write a client approval request email for [project name]. The deliverable is [describe it]. The client needs to review [specific element, e.g., homepage copy, final logo file]. The deadline for feedback is [date/time]. If they approve, the next step is [action]. If they have changes, they should [how to submit feedback]. Keep the tone professional but direct. No filler. Under 150 words.
Setting up your staging environment
Staging is not only for developers. Every deliverable type needs a preview state before the client approves the final version. The preview method you choose determines how easy it is for the client to review the work and how specific their feedback can be. The right method depends on what you are delivering.
Staging by deliverable type
Deliverable types
choose the right preview method
Never send a raw file as the first review artifact
A Figma link with no context, a ZIP file, or a raw .psd tells the client nothing about what they are approving. Always pair the preview with a short brief of what to look at. Without that context, clients either ignore the file or give feedback on the wrong things.
Handling revision rounds without losing control
A revision is a change within the agreed scope. A new request is a change that expands scope. Most agencies do not draw this line clearly, and most clients do not know it exists. When the line is missing, every revision round becomes a negotiation about what the project actually includes.
Before any revision round starts, confirm in writing what counts as a revision for this stage and what counts as a new request. That one step prevents most scope creep.
How to handle out-of-scope requests without damaging the relationship
When a client adds scope mid-revision, the instinct is to either absorb the request or push back hard. Neither works well. Absorbing it trains the client to keep adding. Pushing back without an alternative creates friction.
Use this script instead: "That change falls outside the current scope. We can add it as a separate task or include it in the next phase. Which works better for you?"
This response does three things. It names the boundary clearly. It gives the client two paths forward. And it keeps the decision in their hands, which removes the adversarial dynamic. Most clients pick one of the two options without argument.
Document the exchange in writing, even if it is just a reply to an email thread. If the client later disputes the scope, you have a record of the conversation and the decision they made.
Automating approval gates with tools
Automation removes the manual work of following up, tracking status, and routing feedback. It does not replace the judgment call of reading client feedback and deciding what to do with it. Keep humans in the loop for decisions. Automate everything else.
The goal is a stack where the client receives the right message at the right time without your team manually sending it, and where your team gets notified the moment something changes in the approval status.
Approval automation stack
Client-facing
Workflow automation
Tracking & records
The automation most agencies skip
The most common automation agencies miss is the fallback trigger. Set a Zap or Make scenario that fires a follow-up message to the client automatically if no approval arrives within 48 hours. This alone cuts average response time by a third, without anyone on your team having to remember to follow up.
Common pipeline failures and how to fix them
If your pipeline keeps breaking at the same points, the problem is usually one of four structural failures, not individual mistakes.
No single owner at handoff
When anyone on the team can send the review link, no one feels responsible for making sure it goes out correctly or on time. Ownership diffuses and handoffs stall.
Approval request sent without a deadline
A review request with no deadline is a request with no urgency. Clients file it away and return to it when they have time, which is often never.
Revisions accepted outside the defined channel
When clients can send feedback by email, Slack, phone call, or comment thread simultaneously, you end up with four partial sets of feedback that contradict each other.
No record of what was approved
Without a timestamped approval record, clients can dispute whether they approved something. This creates rework, delays, and relationship damage that a simple log would have prevented.
A pipeline is only as strong as its weakest handoff
Most agencies fix one or two of these failure points and leave the others in place. The result is a pipeline that works most of the time and fails unpredictably. Audit all four failure points before you call the pipeline done.
