A change request is rarely just a small adjustment. It is a commercial decision arriving mid-delivery, usually after people have already made assumptions about timing, ownership, and what the original price was meant to cover. Knowing how to price change requests is not about sounding rigid with clients. It is about stopping unpaid work from becoming normal operating behavior.
For a small B2B business, the damage is often hidden. A team accepts a “quick change,” work is reshuffled, someone revises a deliverable, a manager checks it twice, and the owner gets pulled in when the client asks why the date moved. None of that may appear as a separate line on the P&L. The margin still disappears.
The useful question is not, “Can we do this?” It is, “What does doing this displace, consume, and expose?”
A Change Request Is a New Piece of Work
A change request begins when the requested outcome, effort, timing, or risk is materially different from what was agreed. The wording matters less than the operating reality.
A client may call it a clarification, revision, exception, enhancement, or small favor. Your team may call it a one-off. If it requires new work, changes the sequence of work, creates new review cycles, or adds risk to a committed delivery date, it needs a commercial decision.
That does not mean every request requires a formal proposal and three approval layers. Overprocessing a minor correction wastes time too. The point is to establish a threshold: below it, the team can handle a contained adjustment within the original agreement; above it, the request is priced, approved, and scheduled as additional work.
Without that threshold, the loudest client and the most accommodating employee set the real scope. That is expensive babysitting dressed up as service.
Start With the Original Commercial Baseline
You cannot price a change cleanly if nobody can identify what the original price bought. Before estimating anything, pull the agreed scope, assumptions, deliverables, timeline, acceptance criteria, and exclusions.
This is where many businesses discover the problem is not merely weak pricing. The original scope may describe an outcome in broad language while leaving the effort undefined. Or sales may have promised responsiveness without defining how many rounds of revision that includes. In that case, the team is trying to enforce a boundary that was never operationally visible.
For each request, document three things in plain language: what the client asked for, what the existing agreement covers, and the specific difference between them. Keep it factual. Avoid arguments about intent.
For example, “Update the report with corrected source data” may be included if the client supplied inaccurate data during an agreed validation window. Rebuilding the report after the client changes the reporting model two weeks after approval is different work. The distinction is not whether the request seems reasonable. It is whether the work was priced and scheduled.
How to Price Change Requests Using Cost, Margin, and Risk
The cleanest pricing method starts with the cost of delivery, not a guess at what the client might tolerate. Estimate the actual work required across every role that will touch the change. Include preparation, execution, review, quality checks, client communication, project coordination, and any work needed to re-sequence the delivery plan.
Then convert that effort into a price that preserves the margin the business needs.
A practical calculation is:
Change-request price = labor cost divided by (1 – target gross margin), plus external costs and risk allowance.
If the fully loaded labor cost of a change is $1,200 and the target gross margin is 40%, the labor portion must be priced at $2,000. Add any subcontractor, materials, licensing, shipping, or third-party costs. Then account for risk if the request has uncertain inputs, compressed timing, or dependencies outside your control.
The common error is adding a markup to an hourly cost and assuming the result protects margin. A 40% markup is not a 40% margin. That gap is where businesses quietly underprice work while believing they are being disciplined.
The target margin will vary. A low-risk addition that fits into available capacity may justify a different margin than a request that interrupts committed work or creates a fragile deadline. The principle stays the same: price the operational consequence, not just the visible task.
Include the Work Around the Work
Most underpriced changes are estimated as if a person can begin immediately, complete the task without interruption, and hand it over with no downstream effect. Real delivery does not work that way.
A request that takes four hours to execute may consume eight hours across the business once you include scoping, meetings, rework, approvals, documentation, and quality control. If the request forces another deliverable to move, there may also be a client-management cost and a higher risk of errors.
Those are not overhead abstractions. They are real capacity losses. If your team repeatedly debates whether to include them, the business is probably absorbing them for free.
Price Time Compression Separately
Urgency is not a reason to discount. It is often the reason to price higher.
When a client asks for an accelerated change, the cost is not only extra hours. It may require shifting staff from planned work, delaying another customer commitment, increasing review pressure, or asking the owner to make fast decisions that should not be theirs to make. A rush fee is not punishment. It is recognition that the request consumes scarce delivery capacity differently.
Do not use a standard rush percentage blindly. Price the actual disruption. Sometimes the work can be completed quickly with little effect. Sometimes a modest request creates a chain reaction across the week. Those are different commercial situations.
Use Three Commercial Paths, Not One Default Response
Not every request should receive the same answer. A useful operating model gives the team three paths: include it, price it, or defer it.
Include a request when it clearly falls within the agreed scope and acceptance criteria. Price it when it adds material work, risk, or schedule impact. Defer it when the client wants the work but the current delivery window cannot absorb it without damaging existing commitments.
Deferral is often the missing option. Teams tend to choose between saying yes for free and demanding more money immediately. But some changes are valid and still unsuitable for the current phase. A later date may be the most honest answer.
This protects both margin and delivery quality. It also exposes whether the business has a pricing issue or a capacity issue. If nearly every change must be deferred because the team has no slack, the problem is larger than change-order discipline.
Make Approval Visible Before Work Starts
A change is not approved because someone mentioned it in a meeting or replied, “Sounds good,” in a message thread. The approval should state the added work, price, delivery effect, assumptions, and who authorized it.
This can be a short written record. It does not need legal theater. What matters is that the delivery team can see a clear go or no-go before spending time.
If a client declines the price, the original scope remains the plan. If they approve it, the work enters the schedule with a named owner and a defined delivery consequence. That simple sequence prevents the familiar pattern where the team starts “just to keep things moving” and commercial approval arrives after the cost has already been incurred.
The owner should not be the default exception handler. If every change request reaches their inbox, the business has not delegated a pricing decision. It has delegated the work and retained the bottleneck.
Watch What Change Requests Reveal
A healthy change-request process does more than recover revenue. It produces evidence about where operations are drifting.
Repeated changes tied to the same type of client may point to weak qualification or ambiguous sales commitments. Changes appearing after internal handoffs may indicate that requirements are degrading between teams. Heavy revision volume may signal unclear acceptance criteria. Requests that consistently need owner approval may reveal decision rights that were never defined.
Do not treat every change as a client problem. Track the source, value, time required, approval status, and delivery impact. After a few months, patterns become hard to ignore. You can see whether scope drift is isolated, concentrated in one stage of delivery, or built into how work enters the business.
That is the distinction that matters. One unpaid request is annoying. A recurring pattern is margin leakage with a process behind it.
Price the next change request with the full cost of delivering it, not the smallest number that keeps the conversation comfortable. The result may be a cleaner yes, a justified no, or a later delivery date. Any of those is better than discovering at month-end that the team was busy, the client was happy, and the margin is gone.
