A delivery lead told me recently that she had absorbed fourteen small changes on one project before she flagged it. The biggest took a day. The smallest took an hour. None felt like a change. By week ten the deal was twelve percent over its margin target and the customer still thought everything was on track.
That is how fixed-price margin dies. Not in one big scope fight, but in fourteen unpriced favours that no one wrote down.
Change request pricing is the discipline that stops this. It is not a contract clause, a template, or a process document. It is the agreement, across sales and delivery, that every scope change gets the same treatment as the original deal: raised, sized, priced, approved. Anything less is a gift to the customer at your team's expense.
The fourteen small changes that ate the margin
The pattern repeats across project-based firms: agencies, systems integrators, specialist engineering practices, MSPs shipping a one-off platform on top of a retainer. It looks like this.
A seller closes a fixed-price SOW. Kickoff is friendly. The PM is proud of the relationship. A stakeholder asks for a field on the onboarding form. The PM says yes, because it takes a developer an hour. Three weeks later, the same stakeholder asks for a second login flow, because the CEO pushed back on the first design. The PM says yes again, because the team is "ahead anyway."
By week eight, the deal has fifteen unpriced changes. Two of them are genuinely small. One of them is a week of work. The other twelve are somewhere in between. Nobody priced any of them, because nobody wanted the awkward email. The PM keeps a note in Slack. Finance has no idea. Sales finds out in the margin report, three weeks after the deal closes delivery.
The fix is not to refuse changes. Customers have real reasons to change their minds, and a rigid "no changes" stance kills trust faster than any scope creep. The fix is to price every change, and to make pricing the change take minutes, not days.
Why "we'll price it later" never gets priced
Every team says the same thing at kickoff: we'll track changes, we'll price them properly, we'll send a change request when it matters. Then reality hits.
Delivery cannot stop mid-sprint to rebuild an estimate. Presales has moved on to the next deal and does not want to reopen the last one. The seller is worried that an invoice for a "small" change will sour the relationship. The customer is on Slack, not in a change-control meeting. So the change gets absorbed, flagged in a backlog column that never gets cleared, and surfaces months later as a delivery over-run.
The root cause is usually one of three things, sometimes all three.
- The priced estimate lives in a spreadsheet that nobody wants to reopen. Re-pricing a change means rebuilding the model from the line item up.
- The SOW has no change mechanism, or has a vague "mutually agreed in writing" clause that nobody treats as enforceable.
- The team has no shared definition of what counts as a change, so every change becomes a judgement call the PM wants to avoid.
Solve those three, and change requests stop being the thing that kills margin.
A change request is a mini-deal. Price it like one.
The most useful reframe: every change is a small deal inside the bigger deal. It has scope. It has effort. It has a commercial decision. If you would not ship the original deal without an estimate, a price, and an approval, do not ship the change without the same three.
Priced like a mini-deal, a change request has five ingredients.
- A scope statement, one or two sentences, in the customer's language.
- An effort estimate, built from the same roles and rates as the original.
- A price, with the same margin discipline as the original.
- An impact on schedule, if any, named explicitly.
- A named approver on each side, with a deadline.
The seller on a services deal is already doing this for new work. Change request pricing is the same skill, applied inside a live engagement. The only thing that changes is speed. A change request that takes two days to price is a change request that got absorbed.
The test that says whether something is actually a change
Most absorbed changes could have been priced if anyone had stopped to ask a single question: is this inside the SOW, or outside?
A useful three-part test, used at the point someone raises the change:
- Is this work the team would have included if it had been named at estimate time?
- Does it consume effort from a role that is already scoped for that effort?
- Does it change the acceptance criteria, the integration surface, or the dependencies the SOW was priced against?
If the answer to any of these is yes in the direction of new work, it is a change. Raise it.
The test is deliberately imperfect. Borderline cases still need judgement. But it pushes the default from "absorb unless someone complains" to "price unless we decide otherwise," and the default is what leaks margin.
Raise, size, price, approve
The workflow every change follows, every time. No exceptions. If the PM can absorb it under the test above, it was not a change in the first place.
Raise. Anyone on the customer or delivery side can raise. It lands in one place, not in Slack DMs or the PM's inbox. A one-paragraph description, the stakeholder who asked, the date raised.
Size. Delivery estimates effort against the same roles and rates that priced the original deal. A small change gets a small estimate, often inside an hour. A bigger change needs presales involvement, but still days, not weeks.
Price. Apply the SOW's rate card and margin floor. Do not discount change requests to "keep the relationship." Discounted changes are the margin leak in a different costume.
Approve. A named sponsor on the customer side signs. The SOW's change clause (see below) names the threshold that triggers written approval.
Most change requests under one or two percent of contract value can run on an email approval. Anything bigger needs a signed variation. A quarterly cadence of signed change requests, stitched onto the original SOW as appendices, keeps the contract state clean.
The change ledger every delivery team should keep
If the workflow is the spine, the ledger is the memory. One row per change, one source of truth, updated as each change moves through the workflow. Not a project tracker, not a backlog column. A small table that names every change, its status, and its commercial impact.
A useful ledger has ten or so columns, and they all earn their place.
- Change ID, raised date, raised by.
- One-line scope, and which part of the original SOW it affects.
- Status: raised, sized, priced, approved, rejected, completed.
- Effort estimate in hours or days, by role.
- Price and margin.
- Schedule impact, in weeks or days.
- Approver and approval date.
- Link to the signed variation or email thread.
The ledger is what delivery leads take to the steering committee. It is what finance cross-references against invoices. It is what presales reads when the customer comes back for a related deal and asks for "the same as last time." Firms that keep this ledger tell the same story: the first time they presented a clean ledger to a customer, the change-request conversation stopped being a negotiation and became an operational update. The authority comes from the paper trail.
The contract clause that makes this enforceable
Most SOWs have a change clause. Most change clauses are useless. They say something like "any changes to scope will be mutually agreed in writing." That is a sentiment, not a mechanism.
A change clause that actually works has five parts.
- A definition of what constitutes a change, tied to the scope, acceptance criteria, and assumptions in the SOW.
- A threshold below which email approval is enough, and above which a signed variation is required. Five percent of contract value is a common line.
- A named approver on each side, by role not by individual.
- A time-to-approve window. Forty-eight hours is tight but sensible on an active project. Five business days is the upper bound.
- The rate card and pricing method for changes, usually the same as the original SOW.
Anchor all of this to Schedule A, not to prose. If the customer's procurement team redlines the clause, push back. A vague change clause is not a concession, it is an invitation to absorb.
For the full reference on what belongs in a SOW (and why), see statement of work, what belongs in one. For the discounting discipline that sits alongside change requests, see never discount without a trade.
Where Estii fits
Most change request pain traces back to a single problem: the priced estimate is stuck in a format that nobody wants to reopen. Re-pricing a change means rebuilding the model. The fix is an estimate you can re-price in minutes, and a proposal that regenerates from the new state without anyone retyping anything.
Click-to-rescope, every change priced in minutes
Scope in Estii is an interactive pivot over the deal's estimates. Click any priority, item, or workstream to descope it, or add new items to the priced model to represent a change. Effort, value, price, and margin recalculate across every breakdown in the same interaction. A change that would have taken an hour in a spreadsheet takes thirty seconds. The speed is what moves the team from "absorb unless someone complains" to "price by default."
Descoped items shown in grey with price and margin recalculated instantly
Rescope cascades to schedule and milestones
A change that looks small on price often moves the schedule. Estii's schedule auto-recalculates a best-fit duration and resource plan from the new scope, and payment milestones adjust dynamically to the revised price and duration. Recurring roles rescale with the new duration, which matters on build-and-run deals where the change adds a week of run but no net new build. The schedule impact on the change request comes from the model, not the PM's best guess.
Resource schedule updated automatically when scope changes
A new version per approved change
Estii creates deal versions automatically on redraft and approval, and you can create manual versions at any point (for example, when a change is approved). Approved deals go read-only, so the signed state is locked. Every version has a unique URL, so the customer gets a stable link to "Draft 3, approved 14 Feb" rather than a PDF attached to an email. The change ledger becomes a list of version URLs, not a Word document that drifts.
Deal with multiple saved versions and a locked signed state
The change lands everywhere it needs to, in one go
Re-pricing the deal is half the job. The other half is making sure the new scope shows up in every system that runs the engagement, not just the proposal. Estii renders the change into all of them from the same model.
- Generated proposals regenerate with a structured SOW appendix at the new scope, price, and schedule, so the customer-facing change request is a branded one-pager backed by the full itemised breakdown.
- Spreadsheet exports ships the hierarchical WBS with references back to estimates, costs, prices, and margins, which is what finance and delivery leads want to see.
- Push the approved scope items directly into Jira or ClickUp so the new work lands in the delivery tool your team already uses, rather than a ticket someone has to rebuild.
- The Salesforce integration pushes the revised deal value back to the opportunity, so pipeline and forecast stay in sync without anyone re-keying the CRM.
SOW appendix with itemised scope, estimates, units, and prices
What this looks like in practice
A stakeholder asks for a second login flow on a Wednesday. The PM opens the deal in Estii, adds the two new items to the priced scope, and the model re-prices in seconds. Schedule moves by three days. Milestones shift the back two payment dates by a week. The PM saves a version called "CR-04, second login flow, raised 15 Apr," regenerates the proposal, and sends the customer the one-page change request rendered from the same deal. The customer signs by Thursday. The ledger updates, the margin floor holds, and nobody rebuilt the estimate from scratch.
You can try Estii for free.
Wrapping up
Fixed-price SOWs live or die on change requests. The firms that protect margin are not the ones with the strictest "no changes" policy. They are the ones where pricing a change takes minutes, the ledger is boring, and the contract clause means something. Every change is a small deal. Price it like one, and margin stays where you put it at signing.
