A client message says, “Could we also add a short booking flow?” It sounds small, and you want to respond helpfully. But the approved brief describes an inquiry form, not a booking system. Before anyone can discuss timing or cost, the team needs a shared understanding of what has changed.
A revision request template creates a place for that conversation. It records the request in the client’s words, connects it to the current agreed baseline, and separates your impact assessment from the decision about what happens next.
This guide uses a fictional website project to demonstrate the method. It is about documenting and reviewing project changes, not determining contractual rights. Use your organization’s existing approval and commercial processes for the agreements that govern the work.
Keep the request separate from your interpretation
Start by capturing the request as it arrived. Preserve the relevant message, annotated image, document, or meeting note. Record its date and source so that another person can understand the context.
Then write a separate summary in plain language. A client’s phrase such as “a short booking flow” may refer to several possible experiences. Your summary should identify what you currently understand without presenting an unconfirmed interpretation as the client’s final requirement.
Keep questions visible. Does the client want to choose a preferred appointment time, reserve an available slot, or receive an automatically confirmed booking? Those outcomes may involve different work. A useful revision record makes that uncertainty easier to resolve.
Avoid moving straight from the message to a confident estimate. If the request is ambiguous, the next useful action may be a clarification rather than a price. The template should support that step too.
Identify the baseline being compared
A change needs a reference point. Name the brief, design, specification, or other approved version that defines the current work. Include its version and the relevant section or page where possible.
In the fictional project, the baseline is “Website brief, version 3,” which describes an appointment inquiry form. That reference is more useful than “the original scope,” especially if several drafts circulated during discovery.
Quote or summarize only the part needed for the comparison and keep a link to the fuller source. A small excerpt can make the question understandable without requiring everyone to reread a large document.
If the baseline itself is unclear, record that problem honestly. A missing or ambiguous requirement is not automatically evidence that the client has requested an addition. Sometimes the next step is to resolve a gap in the existing brief rather than classify a change.
Use a revision record with distinct sections
The template below gives each part of the review a clear job. You can use it in a document, table, or dedicated change-review workspace. Keep the source material accessible rather than scattering it across unrelated notes.
| Section | What to record |
|---|---|
| Request reference | Unique identifier, date, requester, source |
| Requested result | The intended change, with unresolved questions |
| Current baseline | Document version and relevant requirement |
| Comparison | What appears unchanged, changed, or uncertain |
| Impact assessment | Affected work, assumptions, dependencies, timing or cost questions |
| Options | Feasible responses and their tradeoffs |
| Decision | Chosen option, authority, date, conditions |
| Next action | Owner, expected result, checkpoint |
Do not make “decision” a required field before the discussion has happened. The record can move through clarification and assessment before it reaches a decision. Its status should communicate the actual stage.
Classify the question carefully
Useful working categories might include clarification, correction, requested addition, requested substitution, and unresolved interpretation. The exact labels depend on your process. Their purpose is to organize review, not to settle a commercial disagreement automatically.
A correction might address an implementation that does not match an agreed requirement. A substitution might replace one planned output with another. An addition might introduce a new outcome. A clarification may explain an existing requirement without changing the requested result.
Some requests contain several categories. “Please fix the form and add automatic confirmation” may combine a defect report with a new feature. Split those parts so they can be assessed and discussed accurately.
Keep the classification provisional until the relevant sources and people have been consulted. A label chosen too early can make the conversation more defensive while hiding the actual uncertainty.
Assess the affected work before discussing dates
List the parts of the project that would need to change. For a booking flow, that might include interaction design, availability rules, a connected service, confirmation wording, testing, and staff instructions. These are possibilities in the example, not assumptions about every booking project.
Distinguish new work from rework. An addition may require something that has not yet been built, while a late substitution may also require revising completed material. Recording both makes the assessment easier to explain.
Identify dependencies you do not control. The client may need to select a service, provide access, confirm operating hours, or approve wording. A schedule estimate that ignores those decisions can look precise while resting on unconfirmed assumptions.
Record the confidence and basis of the assessment. “Initial estimate pending service choice” communicates a different state from “Implementation plan reviewed after requirements confirmation.” Use wording that matches the evidence available.
A worked revision request
Consider request REV-014 in the fictional website project. The client asks for customers to select a preferred appointment time. The approved brief currently provides a contact form that collects repair details and lets staff arrange an appointment afterward.
The reviewer first asks whether the selected time is only a preference or a guaranteed reservation. The client confirms that staff will still approve appointments manually. This removes an assumption that could have inflated the assessment.
| Record element | Fictional entry |
|---|---|
| Request | Add a preferred appointment-time field |
| Baseline | Website brief v3, inquiry form section |
| Clarification | Selection is a preference; staff confirms later |
| Affected work | Form design, wording, validation, notification review |
| Dependency | Client confirms the available preference choices |
| Decision status | Awaiting review of the proposed option |
The record has become more specific, but it is not yet an instruction to begin work. The assessment and proposed option still need the decision required by the team’s existing process.
Offer options that describe meaningful choices
A useful response may offer more than acceptance or rejection. You might retain the current version, add the clarified feature in the current phase, substitute it for another planned item, or place it in a later phase. Offer only options you can explain and realistically assess.
Describe each option’s result and relevant consequences. “Later phase” should identify what remains true in the current release. “Substitution” should name the work being removed or changed. Avoid presenting an option as cost-free simply because it uses fewer words in the reply.
If you cannot yet assess an option, state what you need to learn. A short discovery step may be appropriate where a dependency or technical question is unresolved. Treat that as a defined next action rather than hiding the uncertainty inside a broad estimate.
Keep the options comparable. Readers can make a clearer decision when each option addresses the same intended outcome and explains the differences in timing, work, or assumptions.
Write a reply that connects evidence to the next step
A diplomatic reply acknowledges the intended result, explains the baseline, states the assessment, and asks for the required decision. It should be readable without sounding like an argument assembled from disconnected quotations.
For the example, a reply could say: “We understand that you would like customers to indicate a preferred time while staff continues to confirm appointments. The current brief covers an inquiry form without that selection. We have outlined the additional form and review work below. Please confirm which option you would like us to plan.”
That wording describes the current understanding and the next action. Adapt it to the actual agreement and relationship. Do not imply that a draft response is approved merely because a tool produced it.
Before sending, check that the referenced baseline, request, and options are the correct versions. A calm tone cannot compensate for citing the wrong document or attributing a request to the wrong person.
Record a decision without erasing the discussion
When a decision is made, record who made it, when, which option was selected, and any conditions. Link the decision to the relevant approval evidence through your normal process.
Do not reduce a conditional response to a simple “approved.” If the decision depends on a revised date, a supplied asset, or a confirmed service, keep that condition visible. Otherwise someone may begin work under a different understanding.
If the requester changes the proposal, preserve the earlier version and show the new question. The history should explain how the final requirement developed without making the reader reconstruct every message.
After the decision, update the appropriate project records. The revision log does not replace the production brief, work plan, or other authoritative documents. It explains why those documents changed and points to their current versions.
Hand the accepted change to the delivery team
An accepted revision still needs a usable delivery handoff. Identify the current requirement, the decision reference, the work it replaces or adds, and the person responsible for implementing it. Attach the relevant acceptance checks so the next reviewer knows what the chosen option means in practice.
For REV-014, the handoff could specify a preference field, the approved choices, confirmation wording, and notification checks. It should also retain the decision that a selected preference does not reserve an appointment. Without that context, someone implementing the feature could reasonably build a different interaction.
Check for dependent records that need updating: a design specification, task list, content review, test plan, or handover guide. Assign those updates rather than assuming that changing the main brief will notify everyone affected. If the revision changes an earlier instruction, make the superseded instruction easy to recognize.
Finally, define how completion will be reported back. Connect the implemented result to the revision record and its review outcome. A request can be approved but not yet implemented, or implemented but still awaiting review. Keeping those states separate prevents a decision log from overstating delivery progress.
Review revision patterns without inventing conclusions
A periodic review can reveal recurring sources of uncertainty. Perhaps requests frequently concern content ownership, device support, or review authority. Those observations can help you improve future discovery questions and brief templates.
Be specific about what the record shows. Several questions about form behavior may indicate an unclear brief, a changing business process, or a new stakeholder’s involvement. Do not assume that the client is creating avoidable work simply because requests share a label.
Track useful process measures only when you can define them consistently. The number of open clarification questions or requests awaiting decisions may be more actionable than a vague score for project friction.
Use the review to improve the next conversation. A good log helps the team discuss changes earlier and more accurately, rather than becoming a collection of material saved only for a disagreement.
Choose a workspace that preserves context
A simple table can work when there are few requests and the supporting files are easy to retrieve. As the volume grows, check whether the request, baseline, assessment, reply, and decision remain connected across versions.
RevisionFence provides a focused workspace for comparing approved scope with later material, reviewing potential changes beside evidence, shaping a response, and retaining a dated decision trail. Its official listing states that the user controls copying, exporting, and sharing; it does not send client messages automatically.
You can view RevisionFence: Scope Changes on the App Store. Evaluate it using a real, already-resolved request so you can see whether the recorded sources and final decision remain understandable.
For your next revision, begin with the original request and the exact baseline. Clarify the intended outcome, assess the affected work, and make the next decision explicit. Those steps give the conversation a reliable structure before anyone commits to an implementation.
Product reference: RevisionFence’s official App Store listing. The website project, request identifier, and sample response are fictional editorial examples.