Function: Delivery operations

AI Workflow for Change Request Handling

Deployment Brief

Use this workflow when changes arrive casually through email, Slack, calls, or meetings and need to become explicit before the team absorbs them.

Difficulty

Medium

Revenue impact

High

Operational impact

High

Risk level

High

When it runs

A client, stakeholder, or internal owner asks for work that may change scope, schedule, budget, quality, or deliverables.

Evidence in

original scope or SOWchange request textrequest reasonaffected deliverablescost and schedule assumptionsdependenciesapproval rulesclient communication history

What AI prepares

change request brief
scope impact note
cost and schedule estimate task
approval or rejection draft
updated project log
measurement event for scope control

Decision rules

Compare every request against the approved baseline.
Capture the request before work begins.
Flag cost, schedule, deliverable, quality, or approval impact.
Separate clarification from new scope.
Require owner approval before client-facing commitment.

Human approval point

The project or delivery owner reviews scope impact, cost, timing, approval authority, and client-facing response before any work begins.

What stays human

Do not automate change approval, pricing, legal amendments, delivery commitments, or client-facing scope decisions without owner review.

Quality and stop gates

Source evidence is attached
Human owner is assigned
Sensitive language is reviewed
Stop rules are visible
Measurement event is logged

How it is measured

Track requests captured, approved changes, rejected changes, approval time, margin impact, schedule impact, and unapproved work prevented.

Systems involved

CRM or project systemSource notes and recordsReview checklistReporting or task platform

Workflow Dataset Record

Deployment evidence and duplicate boundary

This section is generated from the enriched workflow dataset. It is designed for pilot planning, not as validated outcome evidence.

Buyer Problem

Client or internal change requests are accepted, delayed, or rejected without consistent scope, risk, approval, and commercial impact review.

Economic Logic

Change handling protects margin and delivery trust by making request type, impact, risk, approval, and implementation path explicit.

Baseline Metric

change_request_review_completeness

Share of change requests with scope, impact, risk, approval path, owner, and decision documented before implementation.

Source system: Service desk, project management tool, CRM, contract/SOW, approval workflow

Minimum Viable Pilot

Duration: 45 days
Sample: One change request type or one delivery team
Owner: Delivery operations or change manager
Threshold: Every change request receives type, risk, approval, and customer communication status before work begins.

Unique Workflow Test

Compare change intake to classification, scope/contract impact, risk review, approval path, and implementation status.

Duplicate Guard

Do not merge with task intake triage. Change handling governs scope/risk/approval of modifications; triage handles ordinary work intake.

Not Ready If

Change categories are undefined.
Approval rules are informal.
Contract/SOW impact cannot be checked.

Claim level: Pilot-shaped. Sources support workflow mechanics and pilot design unless field evidence is attached.

Atlassian Success Central: Process a Change Record

Change requests can be categorized as standard, normal, or emergency and routed through authorization based on risk and guardrails.

Atlassian Support: Jira Service Management Priority Levels

Request and incident priority can be calculated with impact and urgency matrices.

Docusign CLM

Contract and SOW workflows can use templates, approved clauses, conditional review, version control, comments, and approval routing.

Keep moving

Where this workflow connects next

A useful AI build rarely lives on one page. Check the surrounding workflow, the decision rule, and the deployment path before you commit budget.

Workflow group

Client Onboarding

Compare the nearby workflows that usually break before or after this one.

Open

Decision tool

Automate vs. keep manual

Check which parts should stay human before this workflow touches customers or records.

Open

Industry fit

Browse industries

See how this workflow changes by revenue model, buyer urgency, delivery risk, and customer handoff.

Open

Service path

Business Process Automation

Turn repeated internal work into a reviewed process people can actually run.

Open

Revenue review

Request a workflow review

Bring this workflow and the business number it should move.

Open

Adjacent workflows

Deliverable Scope Clarification Proposal Offer Alignment Statement Of Work Creation Client Request Prioritization

TL;DR

A change request is not a problem. An undocumented change request is the problem.

What is change request handling?

Change request handling is the process of capturing a proposed change, comparing it to the approved baseline, estimating impact, and routing it for approval before work changes.

Who is this workflow for?

Agencies, consultants, construction-adjacent firms, software teams, and service businesses doing scoped projects.
Teams where clients ask for small changes that quietly affect timeline or margin.
Owners who want a firm process without making every change feel bureaucratic.

What breaks in the manual process?

The manual process fails when a request sounds small, the team starts helping, and nobody records the tradeoff. By the time the work is visible, the budget and schedule conversation is harder.

How does the AI-enabled process work?

The workflow reads the request, scope baseline, notes, deliverables, and timing context. It prepares an impact brief and response draft for owner review.

What does this look like in practice?

Example scenario: A client asks to add one more dashboard view during implementation. The workflow compares the request to the SOW, flags that the data source is not included, estimates the delivery impact, and prepares a short approval note for the project owner.

What decision rules should govern this workflow?

Compare every request against the approved baseline.
Capture the request before work begins.
Flag cost, schedule, deliverable, quality, or approval impact.
Separate clarification from new scope.
Require owner approval before client-facing commitment.

What are the implementation steps?

Trigger: A change request arrives through email, call notes, project comments, or chat.
Inputs collected: The workflow collects baseline scope, request text, reason, affected deliverables, dependencies, cost and schedule assumptions, and approval rules.
AI/system action: AI prepares a change brief, impact flags, missing questions, and response draft.
Human review point: The project or delivery owner reviews scope, cost, timing, and client language.
Output delivered: The approved decision is logged and communicated to the client or stakeholder.
Measurement logged: Change volume, approval time, margin impact, schedule impact, and repeat request patterns are logged.

Required inputs

original scope or SOW
change request text
request reason
affected deliverables
cost and schedule assumptions
dependencies
approval rules
client communication history

Expected outputs

change request brief
scope impact note
cost and schedule estimate task
approval or rejection draft
updated project log
measurement event for scope control

Human review point

The project or delivery owner reviews scope impact, cost, timing, approval authority, and client-facing response before any work begins.

Risks and stop rules

work begins before approval
small requests become unpaid scope creep
impact is estimated without delivery review
client-facing response sounds defensive

Stop the workflow when evidence is missing, source records conflict, sensitive employee/customer details are involved, pricing or scope would change, or executive/customer-facing claims need owner approval.

Best first version

Create a one-page change request brief before any out-of-scope work begins.

Advanced version

Add change-order templates, pricing thresholds, approval routing, scope-risk scoring, and recurring request analysis.

Related workflows

Measurement plan

Track requests captured, approved changes, rejected changes, approval time, margin impact, schedule impact, and unapproved work prevented.

What not to automate

Do not automate change approval, pricing, legal amendments, delivery commitments, or client-facing scope decisions without owner review.

FAQ

What is change request handling?

It is the process of capturing, assessing, approving, rejecting, and communicating changes to project scope, cost, schedule, or deliverables.

What can AI prepare?

AI can prepare the change brief, scope comparison, missing questions, impact flags, and response draft.

What should stay under human review?

Cost, schedule, scope, legal terms, approval decision, and client-facing response should stay under project owner review.

What is the simplest first version?

Create a short change request brief before out-of-scope work begins.

How should this workflow be measured?

Measure requests captured, approval time, unapproved work prevented, margin impact, and schedule impact.

Related Workflow Group

AI Workflows for Client Onboarding

Compare this workflow against nearby operating problems before choosing the first build. The group shows what usually breaks together, what evidence is needed, and where review still matters.

View Workflow Group

Related Workflows

Client Onboarding Onboarding Forms Client Kickoff Preparation

AI reporting workflow operating briefs

A field report on turning scattered updates into reviewable operating briefs with source evidence and decisions.

Read Report