Skip to main content
Every deliverable comes with a built-in opportunity for refinement. The revision policy at One Guy Consulting is designed to give you the space to review work carefully and request meaningful changes — without the ambiguity of open-ended rounds that can cause scope creep or timeline drift. This page explains exactly what’s included, how to use your revision rounds effectively, and what happens when you need something beyond the original scope.

Included Revisions

Each deliverable includes two rounds of revisions as part of the standard engagement. A revision round works like this:
  1. The consultant submits the deliverable for your review.
  2. You consolidate your feedback and submit it in a single batch.
  3. The consultant addresses all feedback from that batch and resubmits.
  4. You review again — that completes one round.
Two full cycles of this process are included at no additional cost, provided the feedback falls within the original scope of the project (see the next section). Revision rounds do not roll over between deliverables; each deliverable has its own two-round allocation.

Revisions vs. New Requirements

Not every change request qualifies as a revision. Understanding the distinction prevents confusion and keeps the project timeline predictable. A revision is a change that refines, corrects, or improves the deliverable in a way that’s consistent with the original brief. Examples include:
  • Adjusting tone or wording in a written document
  • Resizing or repositioning elements in a design
  • Fixing a bug or addressing an edge case in code
  • Reorganizing the structure of a report based on your feedback
A new requirement is a change that adds functionality, scope, or direction that wasn’t part of the original brief. Examples include:
  • Adding a new section or feature that wasn’t in the original scope
  • Changing the core objective or target audience of the deliverable
  • Requesting work in a different format or platform than agreed
  • Introducing feedback based on new stakeholders or decision-makers brought in after the brief was finalized
If you’re unsure whether a specific change qualifies as a revision or a new requirement, ask before submitting feedback. It’s always better to clarify upfront than to discover a scope disagreement after work has been done.

Frequently Asked Questions

A revision is any change that brings the deliverable closer to what was described in the original brief — corrections, adjustments, refinements, and improvements based on the goals you and the consultant agreed on at the outset. If the change is rooted in the original scope and doesn’t add new work or new direction, it counts as a revision. Examples: rewriting a section for clarity, adjusting visual hierarchy in a design, fixing an error in a data model, or tightening the argument in a strategy document.
If you exhaust your two included revision rounds and still need changes within the original scope, additional rounds can be purchased. The consultant will provide a quote based on the estimated time required — typically a flat fee per additional round for straightforward deliverables. Additional revision rounds are scoped, agreed in writing, and invoiced before work resumes. There’s no penalty for needing extra rounds; it simply becomes a small add-on to the engagement.
Submit all feedback for a single round in one consolidated batch — either as a reply to the deliverable submission email or as a comment in the shared project tracker. For written documents, use inline comments or a numbered list. For designs, use comment tools in Figma or annotate an exported PDF. For code, use GitHub review comments or a written list of issues. Consolidating feedback into a single submission ensures the consultant can address everything in one pass and avoids confusion about which version of the feedback is current.

Out-of-Scope Change Requests

When you identify a change that goes beyond the original brief, it becomes a change request rather than a revision. Change requests are handled transparently and without friction — there’s no judgment attached to wanting more, and expanding scope is a normal part of evolving projects. Here’s how out-of-scope changes are handled:
  1. You describe the change. Submit a description of what you’d like to add or change via email or the project tracker.
  2. The consultant scopes it. You receive a written estimate covering the additional time, cost, and any impact on the current timeline.
  3. You approve or decline. If you approve, the change is added to the engagement with a formal scope amendment and updated schedule. If you decline, the original scope continues unchanged.
  4. Work proceeds. The change request is executed as a defined addition to the project, with its own milestone and review process.
No out-of-scope work begins until you’ve approved the estimate in writing. You’re always in control of what gets added and what it costs.
Make your revision rounds count by consolidating all feedback before submitting. Review the full deliverable from start to finish, gather input from everyone on your side who has approval authority, and submit one complete set of comments. Submitting feedback in pieces — or returning with additional notes after a round is already in progress — risks consuming multiple rounds on what could have been handled in one. The cleaner and more complete your feedback, the faster and smoother the revision process will be.