How do you price an out-of-scope request?

Start from the delta rather than the request. Read the new ask against the inclusions and exclusions in the signed scope, decide whether it adjusts an agreed deliverable or introduces a new one, then cost the hours it will actually consume including the re-briefing and rescheduling it forces. Price that total, add a coordination fee as its own line, and put it in writing before any work starts.

Should a change order include a project management fee?

As a separate line item, yes. A mid-project change costs more than the hours in the task: it costs the re-brief, the timeline rework, and the disruption to whatever it displaces. Burying that in an inflated hourly figure makes the number look arbitrary. Naming it makes it reviewable, which is what gets it approved.

Should I ever absorb out-of-scope work as a goodwill gesture?

Once sets the precedent for the rest of the engagement, because the client learns the price of an addition is zero. If you want to give something away, discount a priced change order rather than skipping it — the document still exists, the record still shows what the work was worth, and the concession reads as a decision instead of a default.

How does Stria help price a change?

You forward the client's email and Stria checks the request against the scope you locked, quotes back the clause it falls outside, and drafts a change order priced against your rate card. You approve what goes out. Stria does not connect to your inbox — you choose what to forward.

How to Price a Scope Creep Request Without Losing the Margin You Quoted

Most advice about scope creep stops at recognising it. That is the easy half. The hard half arrives about ninety seconds later, when you have decided a request is out of scope and now have to attach a number to it that you can say out loud without flinching.

The number is where this usually goes wrong, in both directions. Price it from a gut estimate and you will undercharge, because the gut estimates the task and forgets everything around it. Price it defensively and you will produce a figure you cannot explain, which is the fastest way to have a change order argued with instead of approved.

What follows is the sequence: find the delta, cost it properly, present it, then fix the plan.

Step 1: Find the delta between the scope and the request

The comparison is against the document, not against your memory of the document.

Open the signed statement of work and read the inclusions and exclusions against the request, word for word. If those sections are vague, you have a second and separate problem — but do not let vagueness pressure you into absorbing the work. An ambiguous scope is an argument for a change order, not against one.
Decide whether this adjusts something or introduces something. An adjustment refines a deliverable that was already agreed. An introduction adds a deliverable, an audience, or a workflow that was not. One is inside the engagement; the other is new work. The category decides everything downstream, so be precise about it before you think about price.
Write down the hours and resources the request will consume, before you talk to the client. Estimating during the conversation is how the number ends up lower than the work.
Count the cost of the interruption, not just the task. "It only takes five minutes" is the most expensive sentence in service work. Redirecting a live project means re-briefing whoever is on it, re-sequencing what it displaces, and re-entering work you had already put down. That cost is real and it belongs in the estimate.

One rule with no exceptions: do not absorb out-of-scope work as a goodwill gesture. Doing it once teaches the client that additions are free, and every subsequent request arrives with that expectation attached.

For the judgement call in step 2, how to tell a client something is out of scope covers the conversation, and the free scope check will run the comparison on a pasted excerpt of your scope with no account.

Step 2: Build a number you can defend

A defensible change order price is assembled from named parts rather than produced whole. Four of them:

Base labour at your real rate. Multiply the hours from step 1 — the realistic figure, not the optimistic one — by your rate. If you are not confident in that rate, effective hourly rate is the more useful number to start from than your nominal one.
A buffer for the revision cycle this will trigger. Change requests attract revisions at least as often as original work does, and usually more, because the client is specifying something they have not seen before. Contract Logix suggests a 5% to 15% buffer for contract changes generally; the right number for you is whatever your last three change orders actually took.
A coordination fee, as its own line item. This is the timeline rework, the re-brief, and the rescheduling — the overhead of changing direction mid-project rather than the work itself. Naming it separately is what makes the total reviewable instead of arbitrary.
A sanity check against outcome value. If the addition materially improves the client's result, the hourly arithmetic is a floor rather than an answer. A revenue-generating page is not priced the same way as a layout tweak that takes the same time.

The total will usually land higher than the client is expecting. That is not a reason to discount it — it is the reason the next step is a document rather than a sentence in an email.

Step 3: Present it as a change order, not as bad news

The goal is not to say no. It is to say yes on terms that hold.

Open with "yes, and". Answer the request positively before the cost appears. "Yes, we can absolutely add that, and here is what it needs" keeps the client on the same side of the table as you. Chris Do of The Futur makes the related point that a solid SOW is what stops scope creep turning into a loss — the change order is the instrument that enforces it without spending the relationship.
Put it in a document. A verbal agreement is not an agreement. Itemise the new deliverable, the hours, the fee, and the effect on what was already scheduled. The change order template covers the wording.
Require the signature and the deposit before work begins. Not after the first draft, not on delivery. This single discipline is most of the difference between projects that make money and projects that quietly do not, and how much deposit to ask for covers where to set it.
Reduce the friction of producing the document. The reason change orders do not get written is rarely that the template is slow — it is that deciding to write one, under deadline, costs attention you do not have. This is the step worth automating, and it is the one Stria takes: you forward the client's email, it checks the request against the scope you locked, and it drafts the change order with the relevant clause quoted back. You approve what goes out.

Step 4: Re-baseline the plan

Pricing the change without rescheduling the project just moves the loss from the invoice to the calendar. Approved additions do not come out of nowhere; they come out of the time already committed to something else.

Move the delivery date as soon as the change order is signed. Map the new hours against real capacity, not theoretical capacity. Eight hours of work can move a delivery date by three to five business days once dependencies and handoffs are counted.
Tell the client which milestones shift, in writing. Clients rarely anticipate the downstream effects of their own request. A two-line summary at approval time prevents the conversation you would otherwise have at delivery.
Treat the approved change as the new scope boundary. Without an explicit re-baseline, secondary creep attaches to the expanded scope and the whole cycle restarts from a worse position.
Reassign the work explicitly. Do not let new tasks be informally absorbed into someone's existing load. That is the path to a quality problem you will pay for later.

What this adds up to

Every hour added to a project without a corresponding change to the schedule is an hour borrowed from another deliverable, and eventually from your margin. Research on scope creep and agency profitability points at unmanaged scope as a leading driver of margin erosion, which matches what the arithmetic above predicts.

The sequence is the same every time a request arrives:

Go back to the signed scope before agreeing to anything. The comparison is against the document.
Build the price from named parts — labour, revision buffer, coordination — so the total can be reviewed rather than only accepted or refused.
Issue it in writing, with a deposit, before any work starts. No signature, no start.
Move the dates, and say which ones moved.

Priced this way, an out-of-scope request stops being a threat to the project and becomes the most profitable work in it — because it is the only work you are quoting with full information about the client, the material, and how long things actually take.

If you want the comparison in step 1 done for you, forward the email to Stria and it will name the clause the request falls outside before you reply. The free scope check runs it on a pasted excerpt with no account, and you can start a 14-day Stria trial when you want it on live projects.