Change requests

Scope creep rarely announces itself; it arrives as "while you're in there…". Change requests give the moment a shape: describe the change, what it does to time and cost, and get the client's approval before the work starts — in writing, attached to the project.

Raising a change request

Create one from Work → Documents (the Change requests tab), or from the project itself. Describe what's changing and the impact — additional fee, extended timeline, altered scope. It starts as a Draft you can refine.

Getting it approved

Submit the request and share it with the client — they get a secure link where they can review and approve without needing a portal login (though portal users have it in context too). Statuses track the journey: Draft → Submitted → Approved (or declined), so the Change Requests page is a live answer to "what's still awaiting sign-off?"

Why it beats an email

• The approval is attached to the project, findable in one click when the invoice conversation happens months later.
• Impact is stated up front — the client approves a cost, not a vibe.
• The status list keeps you honest too: work on an unapproved change request is a choice you can see yourself making.

Change requests vs approvals

They're neighbours, not twins: approvals sign off deliverables (is this design right?); change requests sign off scope (should this work happen, and at what cost?). A healthy engagement usually uses both.

Versions

Every change request supports version history — save a frozen copy from its Versions button before submitting or renegotiating, so "what did we originally ask for?" always has an answer. See Proposals, contracts and SoWs for how versioning works across the commercial documents.

Tip: raise small ones. A two-line change request for a day's extra work takes ninety seconds and sets the precedent that scope has a price — the fifth freebie is much harder to charge for than the first.

Requests raised by the client

A client can ask for a change from their portal: on the Agreements tab, Request a change on the SoW or MSA opens a short form for what they want changed and why. That creates a change request in the Requested by client state, linked to the agreement, and emails the owner.

Until you've drafted the impact and sent it back for approval, the request is private: only the person who raised it and the organisation owner (or admins) can see it. Who can see this on the request lets the owner add other project members as viewers, with View or Edit — Edit lets a stakeholder amend the request note, never the impact fields. Once it's sent, everyone who can see the agreement sees it, on the same card in the portal, with the usual approval link.

Your own change requests can be linked to the agreement they amend too, so the whole chain — MSA, SoW, changes — reads in one place in Documents.