Client Changes After Approval: A Software Response Guide
Handle client changes after approval with a software example, a client reply and an editable record linking the old decision to the proposed revision.
When a client requests changes after approval, keep the approved scope and its decision intact. Compare the new request with that scope, check what has already been delivered, and record a separate decision about the revision. A request to add a column to an accepted CSV export shows how this works.
This guide includes a client reply and an editable change-after-approval record. Use them to explain which work remains accepted, what needs investigation, and which version the client will review next.
Identify exactly what the earlier approval covered
Find the approved specification revision, the decision maker and the decision date. If the client accepted a delivered feature, also identify the build and review evidence. A scope approval authorises a defined piece of work; acceptance records a decision about the submitted delivery.
Keep both records available. Replacing the approved specification with an edited document leaves readers unable to tell what the earlier decision covered. Create a proposed revision and link it to the original.
The Association for Project Management's change-control guidance describes evaluating proposed baseline changes before a decision, then updating the plan when a change is approved. For software, carry the decision through to revised criteria and a reviewable build.
Check whether the request changes the agreement
Read the client's message against the agreed behaviour. A reported failure may require a correction even after acceptance. A newly requested behaviour needs an impact assessment. When the specification leaves the behaviour unclear, record the unanswered question and ask the responsible people to resolve it.
Our bug versus change request examples work through that classification. Approval history alone cannot settle whether a report is a defect or an addition.
Record whether the affected work is still being developed, awaiting review, accepted, or deployed. Confirm any decision to pause work with its owner. If users already depend on the deployed feature, assess the proposed change's operational impact before replacing it.
Work through a change to an accepted CSV export
The client owner accepted build B18 against scope S4 after a correction to the export's date filtering. S4 covers the selected organisation's orders, active date and status filters, four columns and a 5,000-row limit. The columns are order ID, order date, status and total. Customer contact details are excluded.
The operations lead now asks: “Can we add the customer's billing email to the export? Finance needs it for reconciliation.” This adds data explicitly excluded from S4. Log it as new request CR-015, linked to the B18 acceptance record.
Keep the accepted build and proposed revision distinguishable
| Record | Existing decision | New request |
|---|---|---|
| Scope | S4: four columns; contact details excluded | Proposed S5: add billing email under defined access rules |
| Authority | Client owner accepted B18 | Operations lead requested CR-015; client owner decides scope |
| Evidence | B18 review results support the S4 decision | Email export checks remain to be defined and run |
| Delivery | B18 remains the recorded accepted version | Replacement build and release timing remain unconfirmed |
The new message leaves the earlier acceptance record unchanged. It also gives the team no basis to claim that an email-enabled export has been reviewed.
Investigate the added field before estimating the work
Ask which billing contact to use when an account has several contacts. Confirm whether the export should reflect the contact at order time or at export time. Record what happens when the email is missing.
Check the agreed data-access rules with the responsible owner. A role that can export order totals may need a separate decision before exporting contact information. Define the intended access and denial cases before implementing the column.
The assessment should also identify downstream CSV consumers. Adding a column may affect an import that expects a fixed column count. Give that compatibility check an owner and record the outcome. Keep any delivery estimate provisional while these questions remain open.
Send a response that leaves the next decision clear
Acknowledge the client's purpose, name the existing agreement, and explain the assessment needed. Offer a response date only after the assessment owner confirms it.
Thanks for explaining the reconciliation need. B18 was accepted
against scope S4, which exports order ID, order date, status and total.
Billing email is excluded from that scope.
We've recorded the addition as CR-015. Before proposing the change,
we need to confirm the billing-contact rule, export permissions and
compatibility with Finance's CSV import.
The delivery lead will coordinate that assessment and confirm when
we can provide options. The client owner will then decide whether
to proceed with the proposed scope and delivery impact.
The B18 acceptance record remains available. A changed export will
have its own build reference, review evidence and acceptance decision.If the client believes billing email was already agreed, ask for the relevant requirement or decision reference and review it together. Correct the classification when the evidence supports that. Keep commercial treatment tied to the project's agreed terms.
Record the decision before changing the delivery commitment
Once the assessment is ready, present the feasible options and their consequences. The client owner might authorise the addition, defer it, decline it, or consider a scope trade-off. The software change request template covers those branches in detail.
For this example, suppose the owner authorises CR-015 revision 2 after the open questions are resolved. The agreed S5 specifies the current primary billing email, an empty field when none exists, and the role allowed to export it. The team records the assessed delivery impact alongside that decision.
Update the work record and criteria to match S5. Keep S4 and the B18 acceptance available as history. Tell affected developers, reviewers and the Finance import owner which revision now governs their next work.
Review the replacement build against the revised criteria
Suppose the team submits B19 for review. Prepare evidence for the added email field and the agreed missing-value behaviour. Check the export permission for an allowed role and a denied role. Recheck organisation isolation, filters, existing columns and the row limit where the change could affect them.
Record the CSV import compatibility result. If a check fails, link the correction and identify the replacement build before requesting another review.
The B18 results remain evidence for that earlier build. Assess which evidence still applies to B19 and supply fresh results for changed behaviour. Use the software client sign-off checklist to prepare the new decision.
Record acceptance against the exact submitted build and scope. Confirm any deployment instruction separately with its authorised owner. This example ends with B19 submitted for review; its acceptance and deployment remain pending.
Download the change-after-approval record
Download the editable change-after-approval record. It includes a blank record, the CR-015 example and the client reply. Copy it into your existing tracker or shared document.
Keep the original approval reference beside the proposed revision. Before handing work to the next person, check that the scope decision, review result and deployment instruction each name their owner and current state.
ProjectHubs is being developed around explicit client decisions and revision-specific approvals. Bring one change requested after approval to a ProjectHubs walkthrough to discuss the scope record, evidence and human decisions it needs.
