What you can use
Define the purpose, feedback owner and boundaries of each revision round, with a planning block and examples of corrections, included revisions and new requests.
SOLOHATCH FIELD GUIDE · OFFERS AND CLIENTS
Define a revision round by its purpose, the deliverable and version being reviewed, who sends consolidated feedback, and which decisions that feedback can change. Keep corrections against agreed checks separate from new outputs or changed approved inputs.
Choose the number and timing of review stages for the actual work. A useful boundary tells both people how to review a deliverable and how a new request will be assessed. A number alone leaves those questions open.
Describe what each review stage is meant to settle
Start with the output and the sequence of work. A content-structure review asks whether the right approved information is included and organised sensibly. A layout review asks whether the presentation works for that information. Name the decision each stage is intended to resolve.
For each stage, record:
- The deliverable and version to be reviewed.
- The input or earlier decision needed before review starts.
- The type of feedback included at this stage.
- The person who consolidates comments and the person who decides, if different.
- The review point actually agreed, and what happens when an input remains open.
Ask the client whether that arrangement is workable before treating it as the production plan. They may need to gather comments from colleagues or arrange a specialist check. A single feedback contact should make the next decision clearer while preserving relevant stakeholder input.
Check the request against the agreed work
A scope defines the work and its boundaries. Microsoft’s scope-management guidance also distinguishes defining the scope from managing later changes. The categories below are a practical aid for reviewing feedback against that baseline.
| Type | Question to ask | Useful next step |
|---|---|---|
| Correction | Does the work fail an agreed input or completion check? | Identify the mismatch and what needs checking or correcting. |
| Included revision | Does this feedback fit the agreed output and current review stage? | Consolidate it and update the relevant version. |
| Proposed additional work | Does it add an output, replace approved input or go beyond the agreed boundary? | Assess the effect and ask for a decision before starting that change. |
| Unclear request | Can you identify what should change and why? | Ask for a concrete example or intended result before classifying it. |
Use the scope actually agreed. Calling something a “quick revision” does not reveal its effect. Equally, a limited number of review stages is not a reason to hide a mismatch against the agreed completion checks.
Copy this revision-boundary planning block
Add a short review section to your project scope. These fields help plan a conversation; adapt them to the work and arrangements you actually agree.
PROJECT / SCOPE VERSION: Deliverable, quantity and format: REVIEW STAGE: Purpose and decision to settle: Version or input being reviewed: Required inputs before this stage: Feedback included at this stage: Person consolidating feedback: Decision owner, if different: Review point agreed with the client: COMPLETION AND CHANGES: Checks used to identify corrections: Number and sequence of review stages chosen for this project: How contradictory comments will be resolved: How added outputs or changed approved inputs will be assessed: Timing or fee decisions still to be confirmed: RECORD: Where the consolidated response is kept: How the updated version is identified: Next action and owner:
Replace vague phrases such as “reasonable changes” with a description tied to the output. For example, state whether the layout round concerns presentation of approved text and how a request to replace that text will be assessed.
Do not promise every possible change in order to keep the section short. If you cannot explain an exclusion or its route forward, clarify the work before selecting a review count.
Filled example: reviewing a small logo package
Illustrative example: a designer is developing one logo direction for an independent fitness instructor, with a primary version and a compact version for a profile image. This fictional project shows how two review stages can settle different decisions.
DELIVERABLE: One selected logo direction, adapted into the two agreed versions. STAGE 1 — DIRECTION: Review the proposed symbol, lettering and overall character. The instructor gathers comments and sends one consolidated response. Settle the chosen direction before refining the final artwork. STAGE 2 — REFINEMENT: Review spacing, colour and readability at the agreed sizes. Check comments against the direction selected in Stage 1. COMPLETION CHECKS: Both agreed versions are present. The supplied business name is correct. Files open in the agreed formats and the compact version is readable in the named profile-image context. CHANGE ROUTE: Assess a second logo direction, a new business name or an added application for its effect on work, inputs, timing and any fee. OPEN: Confirm the review dates and the exact file formats before production.
A misspelling of the supplied business name is a correction. Adjusting spacing in Stage 2 may be an included revision. Asking for a different symbol after selecting the direction needs a discussion about the work involved.
The review count belongs to this example. For your project, choose stages that settle useful decisions and explain how a request outside them will be handled.
Make consolidated feedback usable
Ask the review contact to identify the version, the location of each issue and the desired change. If comments conflict, name the decision needed. “Make the opening shorter” and “add every detail to the opening” require a priority choice before editing can sensibly proceed.
If new comments arrive after an earlier response, check whether they correct the work, clarify the existing direction or introduce another decision. Discuss their effect through the agreed process rather than assuming that their arrival automatically starts a free round or creates a new fee.
Where the review owner or required inputs are unclear, use the client intake questions to resolve the missing information. Keep the accepted direction and current file version together.
Test the boundary before production starts
Ask the client to describe one included review and one request that would need assessment. Compare their answer with yours. Continue when the purpose, reviewer, inputs and change route are clear enough for the next stage; revise the plan when a realistic example exposes a gap.
Reflect the same arrangement in the service proposal. If a change is already being requested, use the scope change response process to record its effect and the next decision. Browse Offers and Clients for related resources.
This guide was developed with AI assistance for SoloHatch, operated by My Target Limited. Examples are illustrative, and planning templates should be adapted to your project. About SoloHatch.