How to manage client revisions
To manage client revisions, define how many rounds are included before the project starts, collect all feedback in one place anchored to the design (not in email threads), confirm a round is complete before making changes, and document what changed and why. Most revision chaos comes from feedback arriving scattered across iMessage, email, and Slack — consolidating it onto the artifact itself cuts the back-and-forth by half.
Define revision rounds in the contract
Before any design file is shared, agree on how many rounds of revisions are included and what counts as a round. A round is one consolidated batch of feedback — not one comment per day over a week. Write this in your contract: 'Two rounds of revisions are included. Each round begins when you send a consolidated list of changes and ends when the revised design is delivered.' This single clause prevents the drip of 'one more thing' messages that can stretch a two-week project to six. If the client asks what happens after two rounds, tell them: 'We scope it as additional work at [rate].' Most clients are reasonable once the boundary is visible.
Collect feedback on the design, not in email
The most common revision problem is feedback arriving in four places at once: an email with three bullet points, a Slack message with a screenshot, a voice note, and a PDF with sticky notes. By the time you reconcile them, you're already working on the wrong version. Instead, send the client a link to the design and ask them to leave comments directly on it. Comments anchored to the exact element — 'this heading' not 'the bit near the top' — are faster to action and less likely to be misread. Tools like Figma let collaborators comment in-canvas; for documents, PDFs, or anything outside Figma, a shared review link lets clients pin notes to the exact spot without needing an account or install.
Close each round before you start the next
Before picking up a single revision request, reply to the client and confirm the full list: 'I'm reading three changes from this round: [A], [B], [C] — is that everything?' This one message does two things. First, it catches the client who hasn't consulted their director yet and would have come back with six more changes after you'd already made the first three. Second, it creates a written record of what was agreed. Once they confirm, make the changes, deliver the next version, and mark the round closed. If new requests arrive mid-round, add them to a list for the next round — don't fold them in silently.
Deliver revisions on the same link, not as a new file
Sending 'logo-v2-FINAL-revised-johnREVIEW.pdf' by email starts a version-management problem immediately. The client opens the wrong file, approves an old version, or forgets which PDF is current. A better pattern: keep the deliverable on one permanent link and push new versions to that link. The client bookmarks it once and always sees the current version. The revision history lives on the same URL — they can compare v1 to v3 without asking you to dig through your Dropbox. When they finally approve, you have one URL to reference in the invoice or handoff note.
Get written sign-off before the project closes
A verbal 'looks good' in a call is not approval. Before closing a project, send a message that explicitly names the deliverable and asks for written confirmation: 'Attached is the final approved logo in three formats. Please reply confirming these are approved for production.' Save that reply. It matters if the client comes back six months later claiming the logo 'was never finalized.' For web projects, a screenshot of the live page with a date stamp works. The approval record is part of the project file, same as the invoice.
Feedback scattered across email and Slack is the root cause of most revision overruns. Drafty lets you share a design, doc, or live site as a link — your client clicks the exact spot they mean and pins a comment right there, with no account or install. Every note lands in one threaded place, anchored to the version they reviewed. When you push a revision, it goes on the same link — no more 'which PDF are we looking at?' Send the link instead of the file and one round of revisions takes an afternoon, not a week.
Open a live demoQuestions
- How many revisions should I include in my freelance contract?
- Two rounds is the most common standard for logo and brand identity work; three rounds for web design. What matters more than the number is defining what a 'round' means — one consolidated batch of feedback, not one comment per day. Build in a clause for additional rounds at an hourly or project rate so the boundary is clear upfront.
- What do I do when a client keeps requesting revisions past the agreed limit?
- Reference the contract clause you agreed to at the start — not as a confrontation, but as a reminder. 'We've completed two rounds of revisions as included in the scope. I'm happy to continue — here's what additional rounds cost.' Most clients who push past the limit don't realize they've hit it. A calm, documented response is more effective than avoidance.
- How do I get clients to give useful feedback instead of vague comments?
- Ask them to annotate the actual design rather than describe changes in an email. 'Make it pop' is impossible to action; a comment pinned to the headline that says 'this feels too small relative to the subtext — try 48pt' is not. You can also send a feedback prompt: 'Please tell me what to change, where it is, and what you'd like instead.' Giving clients a structure produces better feedback faster.
- How do I track which version the client reviewed and approved?
- Keep the deliverable on a single permanent link and push new versions to that link rather than emailing new files. The version history lives with the artifact, not in your inbox. When the client approves, note the version number and date in a reply they can reference. Emailing v2-FINAL-revised-v3 creates a version-management problem the client can't solve without your help.
- Should I charge for revisions beyond the contract scope?
- Yes — if the contract specifies a revision limit and the client exceeds it, additional rounds are billable. The key is establishing this in writing before the project starts, not after the client asks for a fourth round. Quote the additional round as a flat fee or hourly rate; most clients accept it without friction if the original limit was clearly documented.
- What's the difference between a revision and a new request?
- A revision refines or corrects something in the original brief. A new request adds scope that wasn't part of the original agreement — a new page, a different format, or a direction that contradicts the approved brief. When a client asks for something outside scope, name it plainly: 'That's a new deliverable rather than a revision of what we agreed — here's what it would cost to add it.' Staying silent and doing the extra work trains the client to keep asking.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.