Change Request Process for SaaS Implementations (2026)
A change request process for a SaaS implementation is a short written routine: log every out of scope ask with its source, size the effort and go-live impact, and get a named customer approver to say yes before work starts. Use thresholds so small items are absorbed and logged while larger ones get a change order. Offer options rather than refusals, and price in days if you do not charge in dollars.
What is a change request process in a SaaS implementation?
A change request process is a short, written routine for deciding what happens when a customer asks for something the signed scope does not cover. Every request gets logged, sized in days and dollars, and approved or declined by a named person before any work starts. Without it, the work gets absorbed silently and the go-live date moves with no one having chosen that.
It is the follow-on to scope definition. Our guide to preventing scope creep in SaaS implementations covers how to write the exclusions and spot drift early. This post covers what you do once a specific request lands and you have to say yes, no, or "yes, at a price."
Why do implementations need a formal change process?
Because uncontrolled change is the norm, not the exception. PMI's Pulse of the Profession found that 52% of projects completed in the prior 12 months experienced scope creep or uncontrolled scope changes, up from 43% five years earlier. In the same research, high-performing organizations reported scope creep on 33% of projects, against 69% for underperformers. The gap is largely process.
The financial side is just as sobering. McKinsey and the University of Oxford studied more than 5,400 IT projects and found that large ones ran 45% over budget and 7% over schedule while delivering 56% less value than predicted. Those are big programs, not a typical onboarding. But the mechanism, new requirements arriving without a decision about cost or time, is identical at small scale.
For professional services teams specifically, SPI Research reports an average project overrun of 10.7% in 2025, and it flags 10% as the point where overruns start to meaningfully damage client relationships. Billable utilization sat at 66.4%, against a 75% target. When utilization is already that low, hours given away unrecorded are hours your team cannot recover.
What should a change request contain?
A change request needs five things: the request in the customer's own words, the person who asked, the effort and cost to deliver it, the effect on the go-live date, and a named approver. Anything more is paperwork. One practitioner guide notes that the form does not need to be a legal document, but it should be consistent each time.
Use this template as a starting point:
| Field | What to write | Why it matters |
|---|---|---|
| Request | The customer's words, plus a link to where they said it (call timestamp, email, or Slack message) | Settles later disputes about what was actually asked |
| Requester | Name and role at the customer | Shows whether the ask came from the sponsor or a single team member |
| Type | Clarification, new requirement, change to an agreed requirement, or new integration or data source | Clarifications should never need the full process |
| Effort | Hours or days by role, and any third party cost | The basis for price and capacity |
| Schedule impact | Days added to go-live, or "none if added after launch" | Makes the trade visible before the customer says yes |
| Options | Add now, defer to phase two, swap for something already in scope, or decline | Gives the customer a choice instead of a refusal |
| Decision | Approver name, date, and the outcome | Your audit trail |
The "options" row does the heaviest lifting. Most customers do not actually want to pay for extra work or delay launch. Given four options, many will defer the request or swap it for something lower priority.
Which requests need a change request, and which do not?
Only requests that change effort, cost, or the go-live date need the formal process. Clarifications, fixes to your own errors, and tiny adjustments should be handled in the normal flow. If every request triggers paperwork, your team will stop using the process within a month.
Set thresholds in advance so nobody decides case by case. The numbers below are examples; tune them to your average project size.
| Size of the request | Example threshold | Who decides | What happens |
|---|---|---|---|
| Clarification of agreed scope | No new effort | Implementer | Answer it and record the decision |
| Small | Under 4 hours, no date impact | Implementer | Absorb it, log it, and tell the customer it was a courtesy |
| Medium | 4 to 24 hours or up to 3 days of schedule impact | Implementation lead and customer project owner | Written change request, quick approval |
| Large | Over 24 hours, new integration, or more than 3 days of slip | Both sides' steering committee or sponsors | Full change order with revised timeline and price |
Logging the small absorbed items matters more than it seems. Five "free" hours a week across eight concurrent projects is a full extra implementer you are not billing for. Tracking them is also how you spot a customer who is drifting before the drift becomes a dispute.
How do you respond when a customer asks for something out of scope?
Say yes to the goal and attach the process to the request. A flat "no" damages the relationship, and a silent "sure" damages your margin. The response that works is: confirm you understand the need, state that it is outside the current scope, and say a short change request with cost and timeline is coming today.
The practitioner script from the Agiled guide is a good model: "Happy to do that. It's outside our current scope, so I'll send a quick change order with the added hours and the new timeline." For a long-term, friendly customer, soften it: "Good idea. That one's a bit bigger than what we scoped, so let me put together a short change order so we keep the original work on track."
Two habits make this easier. First, respond in the channel where the request was made, so the customer sees continuity. Second, send the written change request the same day. Delay turns a routine procedural step into an awkward negotiation.
If the request is a product gap rather than an implementation request, treat it differently. Sales may have promised something the product cannot do. That situation needs a reset conversation, covered in our guide on what to do when sales overpromised.
How should you price and approve change requests?
Price changes with the same model as the original contract and say so in your initial statement of work. Professional services billing typically falls into three models, as Ordway describes: fixed fee, invoiced upfront or by milestone; time and materials, often with a not-to-exceed cap; and hybrid, which combines fixed project phases with flexible hourly support for change orders.
The hybrid model is the cleanest fit for most onboarding teams. The base scope is fixed, and anything beyond it is billed at a stated rate or a quoted fixed amount. That keeps the base conversation simple and gives change requests a natural price.
If you do not charge for onboarding at all, you still need the process, because the cost shows up as lost capacity and slipped dates rather than invoices. In that case, price the change in days instead of dollars: "this adds nine working days to go-live." Customers who will not pay money will often pay attention to dates. Our post on the cost of a delayed go-live helps you quantify what those days mean for both sides.
On approval, the McKinsey research includes a useful public sector example: scope was defined in an initial six month phase, and all later change requests required board approval. You do not need a board, but you do need a named approver on the customer side who has authority over budget and timeline. Rocketlane's customer onboarding research similarly points to requiring steering committee approval for requests outside the agreed scope.
Who should approve a change request?
Someone on the customer side who owns the budget and the go-live date, plus your implementation lead. The person making the request is usually not the person who should approve it, because they rarely feel the cost of the trade.
Map this at kickoff, not when the first dispute arrives. Your stakeholder map should say who the economic buyer is, who owns the technical decisions, and who can block. PMI's 2026 research found that sponsor alignment at initiation was used by 39% of high performers versus 30% of low performers, a modest but telling difference.
How do you keep an audit trail without extra admin?
Record the decision where the conversation happened and link it from one central log. The failure mode is not a missing form; it is a request that was agreed in a Slack thread or on a call and never made it into any record. McKinsey's diagnostic work traced unstable scope to infrequent communication between project managers and stakeholders about new requirements and change requests.
A workable setup has three parts:
- One log per engagement with the seven fields above. A shared sheet works; so does the change section of a RAID log.
- A source link on every entry pointing to the call, email, or message where the request or decision happened.
- A weekly review of open and recently closed requests, folded into your status update.
Doing this by hand is the part teams skip, which is where tooling helps. Stipulate reads customer Slack channels and builds a record of decisions, requirements, and risks linked to their source messages. That makes a new request easier to spot, and gives you the evidence when someone asks whether a feature was ever agreed. You still make the call about what counts as a change; the record just does not depend on someone remembering to write it down.
What goes wrong with change requests?
Four failure patterns show up repeatedly. Knowing them makes the process easier to enforce.
- Retroactive change orders. Work is done first, paperwork follows. Customers push back because they never got to choose. Always get a yes before starting.
- Everything is a change. Teams that raise a form for every small request wear out goodwill. Use thresholds.
- Nothing is a change. The opposite problem, driven by a desire to be helpful. The cost lands later in delayed projects, as the SPI overrun figures show.
- Approvals from the wrong person. An end user says yes, the sponsor never hears about it, and the invoice is disputed at go-live.
Also watch the schedule. Wellingtone's 2026 State of Project Management report found only 36% of organizations always or mostly complete projects on time. If a change pushes a date, say so plainly, and use your escalation process when the customer will not accept the trade. When a date is already at risk, the go-live recovery playbook covers next steps.
Next steps
You can put a basic process in place this week.
- Add a change clause to your statement of work template: extra work needs a written change request approved by named people before it begins.
- Copy the seven field template into your project tool or shared sheet.
- Set your thresholds for absorb, request, and change order, and publish them to your team.
- Name the customer approver for each active engagement and add them to your stakeholder map.
- Backfill two weeks of requests from your most at-risk project, and see how many would have counted as changes.
- Review open requests weekly as part of your status routine.