Automate client change requests with four linked records: the client's original request, your impact assessment, the authorized decision, and the updated delivery plan. Rules can capture, route, and reconcile those records. People should interpret scope, price the change, confirm capacity, and approve the exact revision. Do not let a message become work automatically.
What counts as a client change request?
A client message becomes a candidate for change control when it may alter an approved deliverable, acceptance criterion, responsibility, sequence, date, price, capacity allocation, dependency, risk, or approval path. Capture the request first, then decide whether it needs a formal change process.
Not every request is a scope change. A client may be correcting a typo, answering an open question, reporting a defect, clarifying an existing requirement, proposing a new outcome, or asking for work that belongs in a later phase. The workflow should preserve that ambiguity until the responsible person compares the request with the current baseline.
Use a short routing decision before anyone estimates or assigns work.
| Client signal | Route | Next action |
|---|---|---|
| The request clearly fits an approved deliverable and acceptance criteria | Standard task | Confirm the owner, source, version, and due date |
| The request is unclear but may fit current scope | Clarification | Ask a focused question and keep work paused |
| The request may change scope, time, price, capacity, dependencies, or acceptance | Change request | Complete an impact assessment before commitment |
| The request creates a separate outcome or engagement | New proposal | Move it to the commercial process with a linked reference |
| The idea is useful but not for the active plan | Backlog or later phase | Record the decision, owner, and review condition |
| The client reports work that does not meet agreed acceptance criteria | Defect or correction review | Compare the result with the baseline before calling it a change |
This distinction protects both sides. The business does not absorb every request as free work, and the client does not receive a surprise change order for something already included.
Which records should the workflow keep?
Keep the original request, impact assessment, decision, and plan update as separate linked records. Each record has a different author, purpose, and completion condition, so combining them in one editable ticket makes it hard to tell what the client asked, what the team inferred, and what was actually approved.
| Record | What it preserves | Authority | Complete when |
|---|---|---|---|
| Source request | Original wording or file, sender, channel, time, client, project, and attachments | The captured source | The source is stored or linked without rewriting its meaning |
| Impact assessment | Affected baseline, options, effort, timing, cost or capacity, dependencies, risks, and acceptance criteria | Named delivery and commercial owners | The relevant owners have reviewed one assessment revision |
| Decision | Approve, reject, defer, split, replace, or request clarification | Verified approver under the business's rules | The approver, decision, conditions, time, and assessment revision are recorded |
| Plan update | Changes to tasks, dates, owners, budget, billing, documents, and client communication | Owners of the affected systems | All required updates have been written and reconciled with the decision |
Give the four records one stable request ID. Version the impact assessment and decision rather than overwriting them. If the client changes the ask after seeing the impact, keep the earlier request and decision history, then create a new assessment revision.
The source request should stay close to the client's own words. A summary may help the team work, but it should link back to the email, form, transcript, file, or meeting conclusion that produced it. GitLab's communication handbook recommends writing down conclusions and using a durable source of truth instead of relying on email or chat. For client change control, that means moving the decision into a controlled record while preserving the source that gave it context.
Where should an automated change request workflow start and end?
Start when a request enters an approved channel or when a team member logs a request received elsewhere. End when the approved change is reflected in every affected operational record, or when a rejection, deferral, or clarification request has been communicated and recorded.
An intake form can create a clean trigger, but clients will still ask for changes during meetings, in comments, by email, or in messages. Do not force the client to repeat the whole request before you acknowledge it. Let a team member create the record, attach the original source, and send the client a concise confirmation of what will be assessed.
The workflow should then run through six visible stages.
From client request to reconciled delivery plan
- Capturepreserve the original request, sender, channel, time, project, and attachments.
- Identifymatch the client, project, baseline revision, affected deliverable, and possible approvers.
- Assessreview scope, effort, timing, price or capacity, dependencies, risk, and acceptance criteria.
- Decideapprove, reject, defer, split, replace, or request clarification for one assessment revision.
- Updatechange the plan, commercial record, billing step, tasks, owners, dates, and client communication that the decision affects.
- Reconcileread the systems back and confirm that they reference the same request ID, decision, and revision.
Do not define “approved” as the finish line. An approved change that never reaches the project plan creates a different failure: the client expects one outcome while delivery follows an older version. Closure requires proof that the operational records match the decision.
The Asana change control guide separates initiation, assessment, analysis, implementation, and closure. A small service business can use a lighter process, but it still needs a visible difference between asking, evaluating, deciding, changing the plan, and closing the record.
What information belongs in the impact assessment?
The impact assessment should explain what changes if the request is approved and what happens if it is not. It should be specific enough for an authorized person to choose among options without reopening the entire project.
Start with the current baseline. Link the statement of work, proposal, order, plan, approved brief, service package, or other record your business treats as authoritative. Record its revision or date. If the team cannot identify the baseline, it cannot reliably decide whether the request is included or additional.
Then assess the dimensions that actually change:
- the requested outcome and the client's reason for it;
- the affected deliverable, acceptance criterion, responsibility, or assumption;
- work that must be added, removed, replaced, repeated, or resequenced;
- the people, tools, data, access, and client decisions required;
- the effect on milestones, delivery dates, review windows, and other commitments;
- the effect on price, budget, retainer capacity, or billing triggers;
- new quality, privacy, security, operational, or dependency risks;
- options such as add, swap, reduce, defer, split, or decline;
- the recommended option and the decision deadline, if one exists.
Separate the client's desired outcome from your proposed implementation. “Add a dashboard” may be the client's wording, but the real need may be a weekly view of three measures. Preserving both allows the team to offer a smaller or safer option without pretending the client asked for it.
An estimate is not approval. Store assumptions, range conditions, and expiry conditions when they matter. If a vendor quote, staff availability, exchange rate, or external deadline can change, name the condition instead of presenting the estimate as permanent.
What should rules, AI, and people each do?
Use rules for capture, identity, required fields, routing, reminders, templates, status transitions, and reconciliation. AI can draft a summary from bounded sources, while people interpret the agreement, assess feasibility, make commercial choices, and approve the change.
| Work | Best starting mechanism | Required control |
|---|---|---|
| Create a request ID and preserve the source | Deterministic rule | Prevent duplicates and keep the original source accessible |
| Match the client, project, and baseline | Stable IDs and version checks | Stop when the match is uncertain or the baseline is stale |
| Request missing information | Template and routing rule | Ask only for fields needed to assess this request |
| Draft a request summary | Template or optional AI draft | Link the source and label inference or uncertainty |
| Decide whether work is included | Authorized human owner | Compare with the current baseline and record the reasoning |
| Estimate effort, timing, and capacity | Responsible delivery owners | Record assumptions, dependencies, and assessment revision |
| Set price or commercial terms | Authorized commercial owner | Use approved pricing rules and current business records |
| Approve or reject | Verified approver | Bind the decision to one frozen assessment revision |
| Update the project and billing records | Rules after approval | Limit each integration to the fields it owns |
| Confirm completion | Automated checks plus accountable owner | Read back every affected record and surface mismatches |
Workflow tools can enforce named approval steps. Atlassian documents approvals attached to workflow states and assigned approvers. That capability is useful only after the business has defined who may approve which kind of change. A software role does not create commercial authority by itself.
AI is optional. It may extract candidate fields from a request, compare text passages, draft a client-facing summary, or flag missing information. It should not decide that a request is in scope, interpret a contract, choose an approver, set a price, promise a delivery date, or send a consequential response without the controls appropriate to that action.
The NIST Generative AI Profile describes automation bias and information integrity, including the need to distinguish fact from inference and retain provenance. Preserve the client's request and baseline beside any generated summary. If the sources conflict, route the conflict instead of asking the model to select the most plausible version.
How should approval and revisions work?
Approval should bind a verified person to one frozen impact assessment revision. If a material assumption, price, delivery date, option, dependency, or acceptance criterion changes afterward, invalidate the earlier approval and request a new decision.
Give the approver clear choices. Depending on the business, those choices may include approve, reject, defer, replace existing work, split into phases, or return for clarification. Avoid a generic “looks good” state that does not identify the chosen option or the authority of the person responding.
The decision record should include:
- request ID and assessment revision;
- decision and selected option;
- approver identity and verified authority;
- conditions, exclusions, or dependencies;
- effective date or decision time;
- required updates and their owners;
- the next client-facing message or action.
Do not assume the requester can approve the impact. A project participant may ask for a useful change while another person owns the budget, schedule, or final acceptance. Confirm the approval path in the service agreement or the business's documented operating rules. This article cannot determine the legal validity of an approval for a specific company or jurisdiction.
Keep approval close to the action it controls. A delivery lead may confirm feasibility, a commercial owner may approve price, and a client sponsor may accept the tradeoff. One approval checkbox should not hide several decisions with different owners.
How should the workflow change by engagement model?
Use the same four-record structure for fixed-price, time-and-materials, and retainer work, but make the relevant tradeoff explicit. A billing model changes the decision, not the need to preserve the request and update the plan.
| Engagement model | Primary question | Typical decision options | Record that must change |
|---|---|---|---|
| Fixed price | Does the request change agreed scope, assumptions, or acceptance? | Add fee and time, swap scope, reduce the option, defer, or decline | Change order or approved commercial amendment plus plan |
| Time and materials | Is the request the best use of the available budget and sequence? | Reprioritize, add budget, adjust milestone, defer, or stop another task | Budget forecast, backlog, schedule, and client confirmation |
| Retainer | Does the request fit current capacity and service boundaries? | Use available capacity, replace another item, carry forward if allowed, add work, or defer | Capacity plan, priority list, and any commercial exception |
| Recurring standardized service | Does the request fit the service package or require a different path? | Standard option, approved exception, add-on, new package, or decline | Service configuration, price, operating checklist, and schedule |
Do not encode one model's assumptions into every workflow. A fixed-price change may need a signed commercial update before work. A retainer request may require a priority swap rather than a new fee. Time-and-materials work may still need client approval because budget and dates can move even when each hour is billable.
How do you keep the systems in sync after approval?
Update each affected system from the approved decision, then read the records back and compare them. A successful automation response proves that an API accepted an operation, not that the project, budget, billing, and client communication now agree.
Assign ownership by field. The project tool may own tasks and milestones, the accounting system may own invoice state, the CRM may own the commercial status, and the controlled change record may own the decision revision. Let each integration update only the fields it is allowed to own.
Make creation steps idempotent. Processing the same approved revision twice should not create a second project phase, invoice, task group, approval message, or client email. Use the stable request ID and approved revision as part of the external key when the tools allow it.
After the updates run, verify at least these conditions:
- the project and client IDs match the source request;
- the baseline and approved assessment revisions are still current;
- the selected option appears in the project plan;
- new or removed work has the correct owners and dates;
- the budget, capacity, price, and billing trigger reflect the decision;
- acceptance criteria and dependencies are visible to delivery;
- the client received the intended message once;
- rejected or deferred work did not enter production;
- every failed update has an owner and a safe retry or manual path.
If one update fails, do not hide the partial state. Mark the change as approved, update incomplete, pause affected work, and route the missing action to an owner. Retrying should continue from known state without repeating completed actions.
How should you test the first automation?
Replay completed change requests with safe data before the workflow can modify a live plan or send a client message. Build the expected four records by hand, then compare the automated result with the original sources and final project state.
- Choose one recurring service, one engagement model, and one change type with a stable baseline.
- Select completed examples that include an included request, a paid change, a scope swap, a deferral, a rejection, and a clarification.
- Record the expected source, classification, assessment, decision, plan updates, and client communication for each example.
- Test requests from email, meeting notes, comments, forms, duplicate messages, and forwarded messages.
- Test a missing baseline, conflicting revisions, an unmatched client, an unauthorized requester, an unknown approver, and an expired estimate.
- Test an AI summary that omits a condition, invents a plausible deliverable, or treats a question as approval.
- Test the same event twice, two requests for the same change, approval of a stale revision, and a changed request after approval.
- Test rejection, deferral, a scope swap, and approval with conditions so only the selected path updates delivery.
- Simulate failure after the project update but before the billing or client communication update, then verify safe recovery.
- Read every system back and confirm that the request ID, decision, revision, owners, dates, and next action match.
- Keep meaningful failures as regression tests when templates, services, fields, integrations, pricing rules, or models change.
Useful operating measures include requests awaiting clarification, assessments returned for missing impact, stale approvals prevented, duplicate actions blocked, partial updates recovered, and approved changes not yet reconciled. Measure your own baseline and outcomes. Do not turn an estimate of avoided work into claimed margin or revenue.
When to avoid it
Do not automate client change requests when the current scope or plan cannot be identified, approval authority is unclear, pricing and scheduling ownership are undefined, or the team cannot pause changed work while a decision is pending. Start with one shared register and a manual review. Keep disputed, regulated, safety-critical, or heavily negotiated changes in a deliberate human process until the rules and evidence are clear.
What to remember
- Capture the client's request before deciding what it is.
- Keep the source request, impact assessment, decision, and plan update separate but linked.
- Bind approval to a verified person and one frozen assessment revision.
- Let rules manage records and routing; keep interpretation, commercial choices, and approval with accountable people.
- Adapt the tradeoff to fixed-price, time-and-materials, retainer, or standardized service work.
- Start changed work only after the approved decision is reflected in the operational plan.
- Make updates idempotent and reconcile every affected system after the workflow runs.
If you want to build this workflow, bring one recent client request, the baseline it referred to, the impact assessment, and the plan that followed to a free 30-minute call. I can help you define the four records, approval gate, and smallest reliable path before you connect every client and delivery channel.
Frequently asked questions
No. Capture every request that may affect active work, then classify it against the current baseline. A correction, clarification, defect, standard task, or backlog idea may follow another route. Use formal change control when the request may alter scope, acceptance, responsibility, timing, price, capacity, dependencies, risk, or approval.
It can record a decision only when your business has already established that the sender is authorized, the selected option and revision are clear, and that channel is acceptable for the specific use. Do not assume one approval method is legally sufficient for every agreement, industry, or jurisdiction. Get legal advice for that determination when needed.
AI can compare passages and draft a candidate classification, but an authorized person should decide. The decision may depend on contract meaning, project history, assumptions, commercial policy, and client context. Keep the original request and baseline visible, and route conflicts instead of letting the model resolve them silently.
Work can begin after the correct people approve the exact impact revision and the affected plan, budget, billing, owners, dates, dependencies, and client communication have been updated or explicitly controlled. Approval without operational reconciliation leaves delivery working from an older version.
Written by Antoine mazu. Antoine helps small service businesses understand and improve their workflows with solutions tailored to their needs, with or without AI. He combines product thinking with hands-on technical execution from Bayonne, France.
Sources accessed October 8, 2026: Asana, Change Control Process, Atlassian Support, Set up approvals in Jira, GitLab Communication Handbook, NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, VocalJet, Client Change Request Workflow for Agencies, Attract Group, Change Request Process, Rework, Scope Creep Management, and Joby, Change Order Workflow for Home Service Teams.
