A client asks for something that was not in the original plan.
The request may be reasonable. It may even be a good idea. But if it moves straight from a message into the task list, the project has skipped the most important step: deciding what the change actually means.
A change request workflow creates that decision point before extra work begins.
It does not need to be bureaucratic. For most service work, it only needs to make the request, impact, decision and next action visible in one place.
A request is not yet a task
Client requests often arrive through email, chat, calls, comments or meetings. Those channels are useful for conversation, but they are poor places to control a commercial change.
Before creating delivery work, capture the request as a decision that still needs to be assessed.
That keeps one small sentence — “Can we also add this?” — from silently changing the project.
Use a five-stage change request workflow
A useful sequence is:
Capture → Compare → Assess → Approve → Act
Each stage answers a different question. Keeping them separate makes it much harder for undefined work to start by accident.
1. Capture — what exactly changed?
Write down the request in language that will still make sense later.
Record who asked, when they asked, which project or deliverable it affects and what they want changed.
Do not reduce a meaningful request to a vague task such as “client edits”. The record should preserve the actual change being considered.
2. Compare — was it already included?
Compare the request with the agreed scope before estimating anything.
The answer may be included work, a normal revision, genuinely new scope or an unclear request that needs clarification.
This classification matters because not every client request deserves a change order, but every meaningful request deserves a scope check.
3. Assess — what does the change affect?
If the request changes the scope, assess its consequences before promising delivery.
- What additional work is required?
- How much time will it take?
- Does the fee change?
- Does the delivery date move?
- Does another task, milestone or dependency need to change?
A small request can have a large downstream effect. The assessment should capture the consequence, not just the size of the sentence that triggered it.
4. Approve — make the decision explicit
Once the impact is known, the client can make an informed decision.
- Approved — add the change under the agreed conditions.
- Declined — keep the original scope.
- Pending — wait for a decision.
- Swap — add the new work while removing or changing something else.
Whatever the outcome, preserve who made the decision and when.
“We talked about it” is not the same as knowing what was approved.
5. Act — only approved work enters delivery
After approval, convert the decision into the actions the project now requires.
Create the task, update the schedule, record the commercial impact and connect any invoice or follow-up that belongs to the change.
The important rule is the order: decision first, execution second.
Keep the workflow lightweight
The workflow only needs enough information to make the next decision: what changed, whether it belongs to the agreed scope, what it affects, what the client decided and what happens next.
What to send the client
The client does not need to see your entire internal system. They need a clear decision.
We can add this. It sits outside the current scope, so I have outlined the additional work, cost and timing impact below. Once you confirm, I will add it to the project.
That message does three useful things: it stays cooperative, makes the consequence visible and prevents work from starting before the decision.
Keep the approval connected to the change
A common failure is documenting the request in one place and the approval somewhere else.
Then the project still depends on finding the right email or remembering which message contained the final decision.
The cleaner model is one change record with the request, impact, decision and approval trail connected.
If the change affects money, keep its approved value and billing status connected too.
The rule worth keeping
Do not let a client request become a task merely because it arrived.
Capture it. Compare it with the agreement. Assess the impact. Get the decision. Then create the work.
A good change request workflow is not there to make change difficult. It is there to make change deliberate.
Use revision vs new scope when the boundary itself is unclear. Once the request becomes a formal change, keep its history in a client scope change log, and keep the approval evidence explicit rather than buried in messages.