Last updated: October 2026. Written by Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions.

Every client project changes. A client sees the draft and realises they want something different. A stakeholder joins late with new requirements. A regulation shifts. Change itself is normal and often healthy. The trouble begins when it happens informally, without anyone pausing to ask what it will cost in time, money and risk.

A change request process is the simple routine that turns “could you just add…” into an agreed, priced and documented decision. This guide explains how to set one up for a consulting, agency or professional services project, with a template, wording you can use and ways to handle the awkward conversations.

Why do you need a change request process?

• It protects your margin from unpaid extras.
• It protects the client from surprise invoices.
• It keeps the schedule honest, because every addition has a time impact.
• It creates a record of what was agreed and why.
• It makes conversations about scope factual instead of personal.

The six steps of a change request process

1. Capture. Log the request in writing, with who asked, when and why.
2. Clarify. Make sure you understand exactly what is wanted and what problem it solves.
3. Assess. Estimate the effect on scope, effort, cost, timeline and risk, including knock-on effects on other work.
4. Present options. Offer choices: do it now at an extra cost, do it later, swap it for something already in scope or decline.
5. Decide. The client approves or rejects in writing, by someone with authority.
6. Update. Record the change, adjust the plan and fee, and tell the team.

When should a change go through the formal process?

Set a threshold in your contract, for example any change above a small number of hours goes through the process, so you are not negotiating the rule each time.

Change request form template

Wording you can use

• “That is a great idea. Because it is outside the agreed scope, I will put together a short change request with the cost and timing so you can decide.”
• “We can fit that in if we swap it for [item]. Would you like that, or shall I price it as an addition?”
• “I want to protect the launch date, so let me show you what adding this does to the schedule.”
• “Let us log that for phase two so it is not lost.”

How do you handle difficult conversations?

• Stay calm and factual. Show the original scope and the request side by side.
• Separate the idea from the process. You can like the idea and still price it.
• Offer options, not just a no.
• Explain that the process protects the client as well as you.
• Agree the process at kickoff, so it is not a surprise later.

What mistakes should you avoid?

• Agreeing in a hallway or a chat message and never recording it.
• Absorbing so many small changes that they add up to a large unpaid one.
• Pricing changes without checking the schedule effect.
• Letting the wrong person approve changes.
• Having no process written into the contract.
• Treating all change as the enemy. Some changes improve the outcome.

How does a change process fit software and app projects?

The same approach protects app builds, where changes are quick and tempting. A written scope, a PRD, makes it clear what counts as a change. Our Discovery Sprint produces that baseline: $345, delivered in 24 hours and credited toward a build starting at $3,500. See MVP scope creep and what to cut before you build.

Frequently asked questions

What is a change request in project management?

A formal request to alter the agreed scope, schedule or cost of a project, which is assessed, priced and approved before work begins.

Should I charge for every change?

Not necessarily. Small tweaks can be absorbed as goodwill, but set a threshold and record what you absorb.

How do I introduce a change process to a client mid-project?

Explain that it protects both sides, apply it to the next significant change and confirm the arrangement in writing.

What should a change request include?

A description, the reason, priority, impact on scope, cost and timeline, options and a recorded decision.

What if the client disagrees about what was in scope?

Return to the written scope. If it was unclear, resolve the ambiguity, document it and improve your scope wording next time.