A twelve-person AI agency in Chicago delivered a natural language processing platform for a healthcare client. The original SOW was $185,000 for a twelve-week engagement. By the time the project wrapped, the agency had absorbed $67,000 in unbilled work because the client's team kept requesting "small adjustments" that were never formally documented or priced. The sentiment analysis module was supposed to handle three document types. It ended up handling nine. The API was supposed to integrate with one EHR system. It integrated with three.
Every individual request felt reasonable. "Can you also handle discharge summaries?" "What about adding the Epic integration since we are already doing Cerner?" The project manager said yes each time because the relationship felt strong and the requests felt minor. But nine weeks of accumulated "minor" requests added up to a margin that dropped from thirty-eight percent to eleven percent.
This is the most common margin killer in AI agency work. Not bad estimates. Not technical failures. Unmanaged scope changes that erode profitability one "quick addition" at a time.
A formal change order process fixes this. Not by being adversarial with clients, but by making scope changes visible, deliberate, and properly resourced.
Why AI Projects Are Especially Vulnerable to Scope Creep
AI agency work has characteristics that make scope creep more likely and more damaging than in traditional software projects.
Model performance is subjective. When you deliver a REST API, it either works or it does not. When you deliver a model with eighty-seven percent accuracy, the client might say "that is not good enough" and expect you to keep iterating. Without clear acceptance criteria in the SOW, "improve the model" becomes an open-ended obligation.
Data is unpredictable. The client promised clean, labeled data. What arrived was messy, incomplete, and inconsistently formatted. Cleaning that data is real work that someone has to do, but it often gets absorbed as "part of the project" instead of documented as a scope change.
Stakeholder understanding evolves. Clients often do not fully understand what they want from an AI system until they see early results. That is natural and healthy. But each evolution of understanding tends to produce new requirements that were not in the original scope.
Experimentation feels different from development. When an engineer builds a feature, everyone understands that is billable work. When a data scientist runs another experiment to try a different model architecture, it can feel like "exploration" rather than delivery, making it psychologically harder to document as additional scope.
All of these dynamics mean that AI agencies need a more rigorous change order process than traditional development shops, not less.
What a Change Order Actually Is
A change order is a formal document that modifies the original statement of work. It describes what is changing, why, what it will cost, and how it will affect the timeline. Both parties sign it before work begins.
A change order is not:
- A casual Slack message saying "sure, we can add that"
- A verbal agreement during a call
- An email thread where the client asks and the PM says "let me look into it"
- A line item added to a sprint board without client acknowledgment
A change order is:
- A written document that references the original SOW
- A description of the new or modified scope
- An estimate of additional hours, cost, and timeline impact
- A signature or formal approval from the client's authorized decision-maker
- An update to the project plan reflecting the change
The formality is the point. It creates a shared record that prevents the "I thought that was included" conversation that destroys relationships and margins.
Building Your Change Order Process
Step One: Define the Scope Boundary in the Original SOW
The change order process starts before the project begins. If your SOW is vague about what is included and what is not, you will have no basis for identifying changes later.
Be specific about:
- The number of model iterations or experiments included
- The data sources and formats you will support
- The integration endpoints and their complexity
- The performance targets and how they will be measured
- The number of revision cycles for each deliverable
- What is explicitly excluded from scope
Use an "Assumptions and Exclusions" section. List everything you are assuming about the client's environment, data, team availability, and technical infrastructure. When an assumption proves wrong, that is a natural trigger for a change order.
Example assumption: "This estimate assumes the client will provide labeled training data in CSV format with fewer than five percent label errors. If data cleaning or labeling is required, it will be scoped as additional work."
That single sentence saves you from absorbing tens of thousands of dollars in data preparation work.
Step Two: Train Your Team to Recognize Scope Changes
The biggest failure point in most change order processes is that the people closest to the work, the engineers and data scientists, do not recognize when a client request constitutes a scope change.
Common requests that should trigger a change order:
- "Can you also handle this additional data source?"
- "We need the model to work in a different language too."
- "Can you add an integration with this other system?"
- "The accuracy is not good enough, can you keep working on it?" (when the agreed accuracy target has been met)
- "We changed the data format, can you update the pipeline?"
- "Can you train the team on how to use this?" (when training was not in scope)
- "We need the documentation to be more detailed."
- "Can you deploy to our on-premise environment instead of cloud?" (when cloud was specified)
Train your team with a simple rule: If a client request was not explicitly described in the SOW, it is a potential change order. When in doubt, escalate to the project manager before doing any work.
Make it safe for engineers to flag scope changes. If engineers feel that raising a scope concern will damage the client relationship or make them look difficult, they will stay quiet and absorb the extra work. Create a culture where flagging scope is valued, not penalized.
Step Three: Create a Change Order Template
A template ensures consistency and reduces the friction of creating change orders. When the process is easy, people use it. When it requires writing a document from scratch each time, they skip it.
Your change order template should include:
- Change Order Number: Sequential identifier (CO-001, CO-002, etc.)
- Project Reference: Link to the original SOW
- Date Requested: When the client first raised the change
- Requested By: Name and role of the person who requested the change
- Description of Change: Clear explanation of what is being added, modified, or removed
- Reason for Change: Why the change is needed (client requirement, data issue, technical discovery, etc.)
- Impact on Scope: What new work is required
- Impact on Timeline: How many days or weeks the change adds (or removes)
- Impact on Budget: Additional cost with a breakdown of hours by role
- Dependencies: Any prerequisites or blockers for the change
- Approval: Signature lines for both the agency and the client
Step Four: Establish the Change Order Workflow
When a potential scope change is identified, it should follow a predictable workflow:
Identify. Any team member can identify a potential scope change. They flag it to the project manager with a brief description.
Assess. The project manager works with the technical team to estimate the impact on scope, timeline, and budget. This assessment should happen within one to two business days.
Document. The project manager creates the change order using the template.
Present. The project manager or account manager presents the change order to the client. This is a conversation, not a document drop. Explain the change, the rationale for the cost, and the timeline impact.
Approve or Decline. The client reviews and either approves, negotiates, or declines the change order. If approved, both parties sign. If declined, the change is not implemented and the original scope stands.
Execute. Once approved, the change is added to the project plan, the budget is updated, and the team begins work.
The critical rule: No work begins on a change until the change order is approved. This is where most agencies break down. The PM sends the change order but the engineer starts working on it "in the meantime." Then the client declines or negotiates the price down, and the agency has already consumed hours it cannot bill.
Step Five: Handle the Awkward Conversation
Many agency leaders avoid change orders because they fear damaging the client relationship. "The client will think we are nickel-and-diming them." "They will go to a competitor who is more flexible."
This fear is almost always unfounded. Here is why:
Sophisticated clients expect change orders. Enterprise clients, in particular, have procurement processes that require formal documentation for any budget change. They actually prefer change orders because it helps them manage their own internal approvals.
Transparency builds trust. When you present a change order with a clear explanation of what is changing and why, the client sees a partner who is organized and honest. When you absorb scope changes silently and then struggle with delivery quality because your team is overextended, the client sees an agency that cannot manage projects.
The alternative is worse. If you do not manage scope changes formally, you will eventually either deliver late, deliver below quality, or have a difficult conversation about money after the work is done. All of those options are worse for the relationship than a straightforward change order conversation.
How to frame the conversation:
"We have been reviewing the additional requirements your team raised this week, and we want to make sure we handle them properly. These fall outside the original scope, so we have put together a change order that covers the additional work, the timeline impact, and the cost. We want to be transparent about this so there are no surprises. Here is what we are proposing."
That framing is professional, not adversarial. It positions the change order as a tool for transparency, not a barrier to collaboration.
Handling Common Client Pushback
"This should have been included in the original scope."
Sometimes the client is right. If your SOW was genuinely ambiguous and a reasonable person would expect the requested work to be included, absorb it gracefully and tighten your SOW template for future projects. If the SOW was clear and the request is genuinely new, walk through the SOW language with the client and explain the boundary.
"We do not have budget for a change order."
Offer options. Can the change be deferred to a phase two? Can something else be removed from the current scope to make room? Can the change be implemented in a reduced form that fits within the existing budget? Flexibility in how you solve the problem, combined with firmness that additional scope requires additional resources, is the right balance.
"Our previous agency never charged for this kind of thing."
Their previous agency either went out of business or fired them as a client. Politely explain that your approach is to be upfront about scope and pricing so that the relationship stays healthy and the work stays high quality.
"Can you just do this one as a favor?"
Once, maybe. If you choose to absorb a small change as a goodwill gesture, do it explicitly. "We are happy to handle this one at no charge. We just want to note that it is outside the original scope so we are both aware." This creates the precedent that scope changes are recognized even when they are not charged.
Tracking Change Orders Across Your Portfolio
At the agency level, change order data is a goldmine for operational improvement.
Track these metrics:
- Change order frequency by project type. If NLP projects consistently generate more change orders than computer vision projects, your NLP scoping process needs improvement.
- Change order acceptance rate. If clients reject most change orders, your pricing or presentation might be off. If they accept all of them, you might be under-pricing or only submitting obvious ones.
- Revenue from change orders as a percentage of total revenue. A healthy range is ten to twenty percent. Below ten percent might mean you are absorbing too much scope. Above thirty percent might mean your original scoping is consistently inadequate.
- Time from identification to approval. If change orders take weeks to get approved, the process is creating delivery bottlenecks. Streamline the workflow or get pre-approved budgets for small changes.
- Root causes of change orders. Are they driven by client requirement changes, data issues, technical discoveries, or estimation errors? Each root cause suggests a different improvement.
Preventing the Most Common Change Order Triggers
The best change order is the one you do not need because you scoped the project correctly from the start.
Invest in better discovery. Most change orders trace back to things that should have been uncovered during discovery. Spend more time on data assessment, stakeholder interviews, and technical architecture review before committing to a scope and price.
Build buffers into your estimates. Not padding. Legitimate contingency for the unknowns that always appear in AI work. A ten to fifteen percent contingency is reasonable for well-understood work. Twenty to twenty-five percent for novel work.
Use phased engagements. Instead of scoping a twelve-week project upfront, scope a three-week discovery phase followed by a proposal for the build phase based on what discovery reveals. This dramatically reduces scope surprises.
Define acceptance criteria precisely. "The model will achieve at least eighty-five percent F1 score on the held-out test set, measured using the evaluation script delivered in Week 6" is far better than "the model will perform well."
Your Next Step
If you do not have a change order process today, implement one this week. Create the template, brief your project managers and engineers on how to identify scope changes, and commit to the rule that no out-of-scope work begins without an approved change order.
Then review your last three completed projects. Identify the scope changes that were absorbed without documentation. Calculate the revenue you left on the table. That number will be all the motivation you need to enforce the process going forward.
Change orders are not about squeezing clients. They are about running a sustainable business that can deliver excellent work because it is properly resourced for the work it takes on. Your clients benefit from that just as much as you do.