What should a price-locked change order contain?

A reference to the governing contract and its date, so the addendum is tethered to something. A plain-language description of the new scope. The fee as its own line item. A deposit requirement. A short acceptance window, typically 48 to 72 hours, so the document cannot stall indefinitely. And an explicit line saying the quoted fee covers only the scope described — that one sentence does more than a page of legal language to stop one approved change being treated as a blank cheque.

Who should sign a change order first?

The client, then you. Setting an explicit signing order rather than sending to both parties at once means acceptance is unambiguous: the client's signature is the act of approval, and your countersignature closes it. Simultaneous sending produces documents where it is unclear who committed first.

Should files be released before the deposit clears?

No, and this is the gap most workflows leave open. A signature is a promise to pay; a cleared deposit is payment. Holding new deliverables until the money arrives removes the ambiguity about when work becomes accessible, and it means the approval and the payment are the same event rather than two you have to chase separately.

Does Stria connect to my email to catch these requests?

No. You forward the messages you choose, and Stria checks the forwarded request against the scope you locked. It has no access to your mailbox and does not read anything you have not sent it. Forwarding is a manual step by design — the point is that you decide what Stria sees.

The E-Signature Change Order Workflow, From Inbox to Cleared Deposit

A change order that never gets signed is a worse outcome than one that was never written, because you have now spent the effort and still have no record. Most of the time the reason is not the document. It is that the workflow around it has a gap — no acceptance window, no signing order, or no connection between the signature and the money — and the request quietly reverts to being a favour.

This is the loop, end to end: catch it, price-lock it, sequence the signatures, and tie the file release to the cleared deposit.

Step 1: Catch the request before you reply

Every billable hour you lose starts the same way. An email arrives with a "quick addition" that sits outside the signed scope, and the reply goes out before anybody compares the two.

Scope creep: any client request that expands, modifies, or redirects deliverables beyond what the signed contract defines — regardless of how it is phrased.

That definition is the short version; what scope creep actually is covers the shapes it arrives in and why the contract alone does not catch them. This post assumes you have already decided a request is outside the scope, and picks up at the paperwork.

Run every inbound client message through the same filter:

Compare it against the signed scope. Anything that introduces a new deliverable, pulls in a date, or changes an agreed specification is a billable change rather than a favour.
Categorise it immediately. Two buckets: included, or billable. Deferring that decision is where the revenue goes, because an un-categorised request gets answered as though it were included.
Get a second opinion on the borderline ones. You can forward the client's email to Stria and it will check the request against the scope you locked, then quote back the clause it falls outside — see watching client email for scope creep for how that works. Forwarding is deliberate: Stria has no access to your mailbox, so you decide what it sees.
Hold the work. As the Contractor Coaching Partnership puts it, change orders should be written, approved, and paid before the additional work is performed. Starting first turns the change order into an invoice for work already delivered, which is a much weaker position.

Step 2: Produce a price-locked document

Before anything goes to a signature platform, the change order has to be a document that cannot be reinterpreted later.

Original contract reference — the exact contract date and identifier, so the addendum is legally tethered to the agreement it modifies.
New scope definition — the additional deliverables in specific, plain language. Vagueness here is what lets secondary creep attach to the new boundary.
Additional fee — as a line item, broken down by hours or deliverable. How to price the request covers how to arrive at the figure.
Deposit requirement — a financial commitment up front, so the signature carries consequence rather than intent.
Acceptance window — typically 48 to 72 hours. Without one, the document sits.

Then add the line that does the most work for its length: state that the quoted fee is valid only for the scope described, and that further changes need a separate addendum. In practice this stops one approved change being treated as permission for the next three far more reliably than a paragraph of legal wording does.

Use the same template every time. Consistency reads as competence, and it makes the process much harder to push back on than a document that looks improvised. The change order template is a starting point.

Step 3: Sequence the signatures

Getting the document into a signature platform is the easy part. Configuring the flow is where a defensible record is either created or lost.

Upload the finalised document and check the field placements — signature blocks, dates, initials — before sending. A misplaced field is a re-send, and a re-send resets the acceptance window.
Set the client to sign first. Adobe's guidance on signing order explains the mechanics: an explicit sequence means each party receives the document at the right point and the executed copy is distributed automatically. Client acceptance, then your countersignature — not both at once.
Turn on automated reminders. Most platforms will nudge unsigned documents on a schedule. Enable it at send time, because the cost of a stalled change order is billable time you are not spending on anything else.
Confirm a certificate of completion is generated. This is the artefact that matters six months later: a timestamped record of who opened the document, when, and from where. Without it you have a signed PDF and no evidence of the signing.

If you want to understand what makes that record hold up rather than just exist, Stria's e-signature alignment page maps ESIGN, UETA and eIDAS element by element — and states explicitly what Stria does not claim.

Step 4: Connect the signature to the money

The signature is not the finish line. The gap between "signed" and "paid" is where a well-run change order still loses.

Trigger the deposit invoice off the completed signature. Most platforms support event-based automation; make the signed change order the event that generates and sends the invoice, so there is no manual handoff to forget.
Hold the new deliverables until the deposit clears. Release revised assets or next-phase files on cleared payment, not on signature. Holding files until the deposit clears covers how Stria does this; the principle is that the approval and the payment should be one event rather than two chases.
File the signed addendum with the original contract. One location, consistent naming. The value is not tidiness — it is being able to answer "what did we agree to" in one action instead of five.
Tell whoever is doing the work, formally. A written internal note that the new scope is approved and funded. No verbal green lights, because a verbal green light is how work starts before the deposit clears.

Keeping the loop tight

Once those four steps are in place the loop is closed: approval triggers billing, billing releases work, and every agreement is on file. Three habits keep it that way.

Never start before the signature lands. Written, approved, and paid before you begin, regardless of how urgent the request is or how good the relationship feels. Urgency is the argument that gets this rule broken, and it is the argument most likely to be wrong.
Keep each change order narrow. One request, one price, one signature. A change order that tries to cover four pending questions becomes a re-negotiation of the project.
Look at how often you are writing them. Reviewing change order frequency monthly tells you something your invoices do not: if a particular kind of project generates three of them every time, the estimate is wrong rather than the client. Fixed price versus hourly is the more useful question at that point than how to write the next addendum.

Build the workflow once and it stops being a decision. That is the entire benefit — not that the paperwork gets faster, but that it stops being optional at the exact moment you are least inclined to do it.

Stria runs this loop end to end: forward the email, get the clause it falls outside, send a priced change order, and hold the files until the deposit clears. Try the comparison with no account at the free scope check, or start a 14-day Stria trial to run it on your own projects.