How to Write a Change Order for an AI Project

A change order is a short written document that records a change to agreed scope, what it costs, what it does to the deadline, and the client's approval, before the work starts. On AI projects it needs one field that standard templates omit: the change in running cost. A new feature on a traditional build raises the price once. A new feature that calls a model raises the price once and then adds to the monthly bill forever, and a fixed-price quote that absorbed that delta silently is a project that loses money quietly for a year.

Why a change order and not a conversation

Scope creep on AI projects is unusually easy, because the work looks cheap from outside. Adding a field to a form clearly costs something. Asking the model to "also handle invoices" sounds like a prompt edit. Sometimes it is. Usually it is a new document type, new failure modes, new test cases and a measurable increase in tokens per request.

A change order does three things a conversation cannot. It makes the cost visible at the moment of asking, when the client can still decide the feature is not worth it. It creates a record, so the final invoice contains no surprises. And it ends the argument about whether something was in scope, because either there is a signed change order or there is not.

This is not a novel idea; it is standard contracting practice borrowed down to small-project scale. The US federal procurement rules give the canonical shape in the Changes clause for fixed-price contracts: changes are made "by written order", and if a change increases or decreases cost or time, the contracting officer "shall make an equitable adjustment in the contract price, the delivery schedule, or both". The clause also puts a clock on it, requiring the contractor to "assert its right to an adjustment under this clause within 30 days" of receiving the order (FAR 52.243-1).

Three ideas worth stealing: the change is written, the adjustment covers price and schedule and not just price, and claims expire. The last one cuts both ways, which is why clients accept it.

The five fields

Keep it to one page. A change order that takes an hour to write will not get written.

1. What is changing, in the client's words and yours.

Quote the request as it was made, then restate it as the work you will do. The gap between the two is where the misunderstanding lives, and writing both forces it into the open now rather than at delivery.

2. Build cost.

Hours and rate, or a fixed figure. If it touches something already delivered, say so and price the rework separately, because clients reasonably resist paying twice for the same screen and need to see why this is not that.

3. Running cost delta.

The AI-specific field. State the change in monthly cost at the agreed volume, and who absorbs it.

If you cannot calculate the delta, give a range and a date by which you will replace it with a measured figure. A range beats silence. Silence means you have agreed to pay it yourself. Forecasting methods are in how to forecast your AI bill and the pass-through question in how to bill clients for AI API usage.

4. Schedule impact.

In dates, not durations. "Adds one week" invites the client to assume it runs in parallel with everything else. "Moves delivery from 14 November to 21 November" does not.

5. Approval and expiry.

Name, date, and a line stating the quote holds for a stated number of days. Expiry stops a change order approved in February being invoked in June at February's prices, after the model you quoted has been deprecated or repriced.

The sentence that stops the drift

You need something to say when a small request arrives mid-build, and it needs to be routine rather than confrontational. This works:

Happy to do that. It is outside what we scoped, so I will send a change order with the cost and the new date, and start once you approve it.

Three things it gets right. It says yes, so you are not refusing work. It states the consequence as process rather than complaint. And it puts the decision back with the client, which is where it belongs: they may well decide the feature is worth it, and that is a good outcome.

The failure mode is agreeing in the moment and raising the cost later. By then the work is half done, the client has budgeted nothing for it, and you are negotiating from a weak position about something you already built. More on the pattern in how to handle scope creep on an AI project.

Changes that specifically need one on AI work

• A new input type. New document format, new language, new file source. Rarely just a prompt change.

• A model switch for quality. Changes cost per call and latency, and invalidates your evaluation results.

• An accuracy target. "Make it more accurate" without a number is unbounded work. Price a measurement, agree a threshold, then price the work to reach it.

• Volume above the quoted ceiling. If the quote assumed 5,000 documents a month and the client arrives with 50,000, that is a change order even though nothing about the software changed.

• A new integration. Each one adds credentials, error handling and an ongoing maintenance surface.

• A human review step. Usually the right call, and it adds build work plus an operational cost the client needs to see.

A filled-in example

A fixed-price build for a logistics firm: a tool that reads delivery notes and extracts five fields. Agreed at £11,000, delivery 14 November. Three weeks in, the client asks whether it can also handle the handwritten exception slips the drivers fill in.

CHANGE ORDER 002 | Delivery note extraction | 2026-10-20

REQUESTED (client wording, 17 Oct call)
"Can it also do the handwritten slips the drivers leave with the notes?"

SCOPE OF CHANGE
Add handwritten exception slips as a second input type: image
pre-processing, a separate extraction prompt, and a confidence
threshold below which a slip is routed to manual review.
Not included: correcting the existing printed-note extraction,
or any change to the five output fields.

BUILD COST
Pre-processing and prompt work         18 h
Evaluation set of 60 slips, scored      6 h
Manual review queue                    10 h
                                    -------
                              34 h @ £85 = £2,890

RUNNING COST DELTA
Handwriting extraction uses the larger vision model.
+£0.011 per slip. At the agreed 4,000 slips/month: +£44/month.
Assumes slips stay under 2 pages. Above that, re-quote.
Who pays: client, added to the monthly platform charge.

SCHEDULE
Delivery moves from 14 November to 28 November 2026.
Milestone 3 payment date moves with it.

APPROVAL
Quote valid until 3 November 2026.
Client: ______________________  Date: __________

The parts doing the work: the explicit "not included" lines, which prevent the change order being read as a general warranty on extraction quality; the volume assumption attached to the running cost, so an arriving flood of 12-page slips is a new conversation rather than a loss; and the milestone moving with the delivery date, which clients otherwise assume stayed put.

When to skip it

Not every change needs paperwork. Set a threshold, state it in the original agreement, and hold to it: changes under two hours with no running cost impact get absorbed. It buys goodwill cheaply and keeps you from sending a change order for a label change.

Keep a note of what you absorbed. If the small-change total reaches a day across a project, that is a conversation to have at the next milestone, with the list in hand. Where the whole arrangement has shifted rather than one feature, a change order is the wrong instrument and you want to revisit the structure, as in how to structure a retainer for ongoing AI app maintenance, or the original scope document described in how to write an AI project proposal. Milestones and change orders interact, so set both up together using payment milestones for an AI project.

FAQ

What is the difference between a change order and a new contract?

A change order amends the existing agreement and inherits its terms, rates and liability provisions. A new contract starts fresh. Use a change order while the original project is live and the change is an addition rather than a different engagement.

Do I need a lawyer to write one?

Not for ordinary scope additions, provided your original agreement says that changes are made in writing and signed by both parties. That clause is what gives the change order its force, so make sure it is in the main contract.

How do I price a change when the running cost is uncertain?

Give a range with the assumption stated, usually a volume figure, and commit to replacing it with a measured number by a named date. Then measure it. Charging a point estimate you cannot support is how fixed-price AI work goes wrong.

Can a client refuse a change order and still demand the work?

Only if the work was in the original scope, which is the question the change order forces you both to answer. If the scope document is vague, that is the real problem, and it is worth tightening before the next project rather than arguing this one.

Should I charge for writing the change order?

No. It is sales and administration, it takes fifteen minutes, and charging for it undermines the point, which is to make raising changes easy and costing them routine.