A change request is recorded, but it stays pending for days. The register says what was requested; it does not explain who will obtain the decision or what the client still needs to confirm.
This guide adds a decision review queue to an existing scope-change register. It keeps requested work distinct from agreed implementation.
1. Identify what pending means
Use a field called Decision Status with options such as Pending, Approved and Declined. If your existing decision field already serves that purpose, keep it.
Track execution separately if needed. Approved means a decision has been recorded; it does not mean the work is complete or paid.
Start with the scope change report example if your request records lack the original scope and impact assessment.
2. Add the next decision action
| Property | Type | Meaning |
|---|---|---|
| Decision Needed | Text | Exact unresolved question |
| Review Owner | Person | Who will obtain or check the response |
| Next Check | Date | When the review owner acts again |
| Decision Status | Select | Pending, Approved or Declined |
The review owner can be your project lead. That person is not automatically the client’s authorized decision-maker. Preserve the actual decision source in the change record.
3. Build the pending queue
Create a Table view called Pending decisions. Filter Decision Status is Pending. Show Change, Project, Decision Needed, Review Owner and Next Check.
Sort Next Check ascending, but review the full queue, including undated requests. Add separate diagnostic views for Pending AND Next Check is empty, and for Decision Status is empty.
A blank status should not silently disappear from the review process.
4. Test three requests
| Change | Decision Status | Decision needed | In pending queue? |
|---|---|---|---|
| Add case studies section | Pending | Confirm proposed fee and revised date | Yes |
| Replace services illustration | Approved | Decision source recorded | No |
| Add another language | Pending | Clarify required pages before estimating | Yes, even without a check date |
The two pending requests need different actions. One awaits a decision on assessed terms; the other needs information before a proposal can be prepared.
5. Process the response against the actual question
- Check the normal client communication channel.
- Locate the response and the request it refers to.
- Confirm whether it resolves the recorded decision question.
- If incomplete, update Decision Needed and Next Check.
- If sufficient, record the outcome, decision-maker, date and source.
- Update Decision Status and the next implementation action.
“Yes, but with a lower fee” leaves terms unresolved. Record the revised proposal instead of treating the original terms as accepted.
The approval register guide helps preserve the exact decision reference.
6. Keep reminder dates separate
Next Check is when you will seek or review the decision. It is not the requested delivery date or an automatic extension of an existing commitment.
If timing is affected, record the impact and resolve it through the agreed project process. Continue work that does not depend on the unresolved request.
7. Review age without treating it as authorization
At each project review, inspect requests that remain pending and explain what is missing. Choose a concrete next action rather than moving every reminder forward.
Elapsed time does not itself establish approval in this workflow. Use the actual agreed decision process.
For the wider register, use the Notion scope-change tracker.
Common mistakes
- Using one status to mean pending, implemented and billed.
- Moving reminder dates without checking responses.
- Omitting undated requests from every review.
- Starting dependent work while the decision remains unresolved.
Frequently asked questions
Should Pending include implemented work?
Pending describes the unresolved decision. Track implementation separately so each field has one clear meaning.
What happens if Next Check is empty?
Keep the request in the full pending queue and a missing-check-date review.
Does any client response resolve the request?
No. Compare the response with the exact decision needed and record what remains unresolved.
Who is the Review Owner?
The person responsible for obtaining or checking the response. They are not automatically the person authorized to approve it.
Is Next Check the revised delivery date?
No. It schedules the next review action. Resolve delivery changes separately.
Explore the wider workflow
You can build this with your existing records. For a broader client and project workspace, explore Freelancer CRM and compare its structure with your workflow.