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
Evidence in
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
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
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
Change request handling is weak when scope, schedule, and cost changes enter through emails or meetings before impact, approval authority, and client response are controlled. The business problem is not the absence of an AI draft; it is the lack of source-backed fields that show what can move forward, what must be reviewed, and what would create commercial, customer, or operating risk if automated.
Economic Logic
The value comes from reducing rework, missed review points, and unsupported decisions in change request handling. The pilot should measure whether required evidence is captured earlier and whether owners can act with fewer unresolved exceptions, not whether AI independently improves the business outcome.
Baseline Metric
change_request_approved_path_rate
Share of change requests with scope impact, cost or schedule estimate, approver, client communication status, and final decision before work starts.
Source system: project management tool, ticketing system, contract or SOW, client email, change log, approval workflow
Minimum Viable Pilot
- Duration
- 30 to 60 days
- Sample
- First 40 client change requests or all requests in one delivery pod over 45 days
- Owner
- Delivery operations lead
- Threshold
- 95% of requests receive an approved path before work starts and 0 paid-scope exceptions are handled without owner review.
Unique Workflow Test
Trace each request to original scope, impact estimate, approver, decision, client response, and work-start timestamp. The test passes only when records include timestamp, owner, source link, review status, exception outcome, and a measurable pilot result.
Duplicate Guard
Keep separate from client request prioritization. Change request handling applies when scope, schedule, budget, or deliverable commitment may change and work must not begin until the commercial path is approved.
Not Ready If
- Scope baseline, approval authority, or change log is missing.
- No accountable owner can approve exceptions, customer-visible output, or business-impacting decisions.
- Source records cannot be sampled with enough timestamp, owner, status, and outcome fields to measure the pilot.
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.
OpenDecision tool
Automate vs. keep manual
Check which parts should stay human before this workflow touches customers or records.
OpenIndustry fit
Browse industries
See how this workflow changes by revenue model, buyer urgency, delivery risk, and customer handoff.
OpenService path
Business Process Automation
Turn repeated internal work into a reviewed process people can actually run.
OpenRevenue review
Request a workflow review
Bring this workflow and the business number it should move.
OpenTL;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
- AI Workflow for Deliverable Scope Clarification
- AI Workflow for Proposal Offer Alignment
- AI Workflow for Statement Of Work Creation
- AI Workflow for Client Request Prioritization
- AI Workflow for Project Status Updates
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 GroupRelated Workflows
Further Reading
AI reporting workflow operating briefs
A field report on turning scattered updates into reviewable operating briefs with source evidence and decisions.