Change Request
A decision-oriented request to modify agreed scope.
What a Change Request is
A Change Request is a decision-oriented request to modify scope that both sides already agreed to. It anchors itself to the original agreement, states exactly what should change, and explains why that change is warranted now.
It is not a casual email asking for more. It carries a structured impact analysis: what shifts in scope and deliverables, and what shifts in cost and timeline, so an approver can weigh the change against the baseline.
Because it ends in a recorded sign-off, the Change Request becomes the audit trail for the decision. When scope moves later, the document shows who approved the change, the justification behind it, and the risks that were accepted.
Anatomy of a Change Request
Reference to the original agreement
Name the agreement, version, or contract being amended so everyone shares the same baseline. This is the anchor the rest of the request measures against.
Description of the change
State precisely what is being added, removed, or modified, in plain terms. Ambiguity here is what later turns into disputes.
Justification
Explain why the change is needed and why now, tying it to a trigger such as a new requirement, constraint, or correction. A justified change is far easier to approve.
Impact on scope and deliverables
Spell out which deliverables grow, shrink, shift, or disappear as a result. This separates the work itself from the money.
Impact on cost and timeline
Quantify the change in budget and schedule against the original commitment. Approvers decide on these numbers, so they belong in their own section.
Risk and options
Lay out the risks of proceeding, the alternatives considered, and the cost of doing nothing. Giving options frames a decision rather than an ultimatum.
Approval and sign-off
Capture who authorizes the change, in what role, and on what date. This block is the recorded authority the change runs on.
Getting a Change Request right
Do
- Cite the exact agreement and version the change amends so the baseline is unambiguous.
- Separate the impact on scope and deliverables from the impact on cost and timeline.
- Tie the justification to a concrete trigger rather than a general preference.
- Present at least one alternative and the cost of doing nothing in the risk and options section.
- Route the document to a named approver and capture the sign-off with a date.
Avoid
- Do not bury a scope change inside a status email with no impact analysis.
- Do not describe the change so loosely that two readers picture different work.
- Do not state new cost without showing how it moves against the original agreement.
- Do not skip the risk and options section and present the change as the only path.
- Do not treat verbal agreement as approval; the sign-off block must be filled in.
The old way vs. waxTable
How Waxe builds your Change Request
- 1
Name the agreement being changed
You tell Waxe which original agreement or contract the request amends and point to its version. Waxe sets that reference as the anchor at the top of the document, so the entire request is measured against a single, agreed baseline.
- 2
Describe the change and why
You explain what is being added, removed, or modified and the trigger behind it. Waxe turns that into a precise description of the change and a justification that ties the request to a concrete reason, leaving no room for two readings.
- 3
Draft the impact analysis
Waxe writes the impact on scope and deliverables and, separately, the impact on cost and timeline. Each is framed against the original commitment, so an approver can see exactly what shifts in the work and exactly what it costs in budget and schedule.
- 4
Frame risk and options
Waxe lays out the risks of proceeding, the alternatives worth weighing, and the cost of doing nothing. This turns the request into a decision rather than a demand, giving approvers a clear basis to choose with confidence.
- 5
Add sign-off and hand it back
Waxe builds the approval and sign-off block with named roles and a date field, then formats the whole document to match. The complete draft arrives in about five minutes for a few cents, ready for you to review, adjust, and route for approval.
Frequently asked
What is a Change Request and when do you raise one?
A Change Request is a decision-oriented document that asks to modify scope you already agreed to. You raise one the moment a change touches deliverables, cost, or timeline rather than absorbing it silently. It points back to the original agreement, describes exactly what changes, and explains why. It then sets out the impact on scope, cost, and schedule, lists the risks and options, and ends in a sign-off. Without it, scope drifts and nobody can say who agreed to what.
What goes inside a Change Request?
It opens with a reference to the original agreement so everyone knows the baseline being amended. Next comes a clear description of the change and the justification behind it. Then two impact sections: one for scope and deliverables, one for cost and timeline. After that you lay out the risk and the options, including the cost of doing nothing. The document closes with an approval and sign-off block that records who authorized the change and when.
How is a Change Request different from a change order or an amendment?
A Change Request proposes and justifies a change; it is the decision document that comes before money moves. A change order is the executed instruction that follows approval, and a contract amendment formally rewrites the agreement itself. The Change Request carries the justification, impact analysis, risk, and options so approvers can decide. Once it is signed off, the approval block becomes the authority a change order or amendment is built on. Keeping them separate preserves a clean audit trail.
How does waxTable generate a Change Request?
You tell Waxe, your AI operations manager, what is changing and which agreement it touches. Waxe drafts every part in order: reference to the original agreement, description, justification, impact on scope and deliverables, impact on cost and timeline, risk and options, and the sign-off block. The wording, structure, and look match the document you describe rather than a stock layout. What might take two days of scoping and formatting arrives in about five minutes for a few cents. You review, adjust, and send.
Why does the impact analysis matter so much?
The impact analysis is what turns a vague ask into a decision an approver can actually make. By separating impact on scope and deliverables from impact on cost and timeline, it shows precisely what shifts and what it costs. The risk and options section then frames the trade-offs, including the consequence of declining. Approvers sign because the numbers and reasoning are in front of them, not because they were pressured. That clarity is what keeps the relationship intact when scope changes.
Skip the writing — generate the whole change request
Waxe drafts it on your brand in about five minutes, then you refine it. From two days of work to a few cents.
Your next change request, in five minutes
Tell Waxe about the client and get a complete, on-brand change request to review — the work of two days for a few cents. There is no blank page to start from and nothing to format by hand; you answer a short brief, Waxe does the drafting, and you keep full control of the final document in the editor.