How seasoned project teams identify, assess, and channel the first indications of change well before they materialize as formal, priced change orders
Before a change order is actually signed, a number of smaller things usually happen first. One of the first things that happens is that someone realizes that the work in front of them doesn’t match the contract documents anymore. For example, a superintendent sees a conflict between some structural steel and some ductwork. An owner asks about upgrading a finish. A design bulletin lands in the inbox. Each of these moments is a change request in its earliest form, even if nobody has written the words “change request” yet.
A change request is the initial, often informal, notice that a potential change exists and needs evaluation. It is distinct from a change order, which is the final contractual document, and from a Change Order Request (COR), which is the priced proposal submitted for approval. The change request workflow is the process that takes a raw signal a field discovery, an RFI response, an owner ask and turns it into a properly evaluated, priced proposal ready for the formal change order process.
This article details the specifics of how that process plays out on a calculated commercial project: the sources of change requests, how they get sorted and assessed, what paperwork backs each step, and how AI-powered tools help teams spot and assess design-based change requests way faster than manual review could.
Key Definitions
| Term | Definition |
|---|---|
| Change Request | The initial notice that a potential scope, cost, or schedule change exists, prior to formal pricing or approval. |
| Change Order Request (COR) | A priced, formally submitted proposal describing the cost and time impact of a confirmed change. |
| Triage | The initial evaluation determining whether a change request is valid, in scope, and worth pursuing through formal pricing. |
| Field Discovery | A change request originating from a condition or conflict identified during actual construction. |
| Owner-Initiated Request | A change request originating from the owner’s desire to modify scope, finishes, or systems. |
| Design-Driven Change | A change request triggered by a bulletin, sketch, or RFI response that modifies the contract documents. |
| ★ KEY TAKEAWAY The change request workflow exists to answer one question quickly and reliably: is this actually a change, and does it deserve the time and cost of full evaluation? |
|---|
Objectives of the Change Request Workflow
- Capture potential changes as early as possible, before they become urgent or contested.
- Filter out items that are not genuine contract changes before they consume estimating resources.
- Route legitimate change requests to the right evaluation path based on their origin and complexity.
- Maintain a clear, chronological record of when a change was first identified, which matters significantly for schedule and notice-related disputes.
- Create a smooth handoff into the formal change order process once a request is confirmed and evaluated.
Why the Change Request Workflow Matters
The gap between “someone noticed something” and “the team formally evaluated it” is where a surprising amount of project risk hides. A field condition noticed on a Tuesday but not formally logged until three weeks later, when it finally becomes urgent, has already lost weeks of schedule float that a faster triage process could have preserved.
There is also a notice-related legal dimension. Most contracts state that contractors must notify owners about changes within particular timeframes of usually five to ten days, or else they won’t be able to claim compensation. An efficient change request process that consistently captures and times the exact moment an issue is first noticed is often what distinguishes a legitimate claim from a lost claim.
| ⚑ FIELD REALITY Superintendents notice more potential changes in a single week than most formal systems ever capture. The weak link is rarely awareness in the field, it is getting that awareness into a system before it gets lost in the pace of daily activity. |
|---|
Stakeholders in the Change Request Workflow
| Role | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Superintendent | Yes (field identification) | |||
| Project Engineer | Yes (logging and initial triage) | |||
| Project Manager | Yes | Yes | ||
| Estimator | Yes (evaluation) | |||
| Design Team | Yes | Yes | ||
| Owner / Owner’s Rep | Yes | Yes | ||
| Subcontractors | Yes (sub-tier identification and pricing input) |
The project engineer often functions as the workflow’s traffic controller, logging every incoming request and performing the initial triage that determines whether it moves forward. This role requires enough technical understanding to distinguish a genuine change from a misunderstanding of existing scope, without needing full estimator-level pricing skill at this early stage.
Measuring Change Request Workflow Health
Most project teams can point to their overall change order volume but rarely track how efficiently requests move through the earlier stages of the workflow. A few indicators reveal whether the intake and triage process is working or quietly creating delay.
| Indicator | Healthy Signal | Warning Signal |
|---|---|---|
| Time from discovery to logging | Same day or next business day | Requests logged days or weeks after discovery |
| Time from logging to triage decision | Within 1–2 business days | Requests sitting unreviewed for extended periods |
| Percentage of notice deadlines met | Consistently at or near 100% | Recurring missed or late notice communications |
| Percentage of requests rejected at triage | Reasonable proportion reflecting genuine filtering | Very low, suggesting triage is a formality rather than genuine review |
These indicators matter most in combination. A project with a fast logging habit but a slow triage process still loses much of the benefit, since the notice clock is often running from the moment of discovery regardless of how quickly the internal review happens.
Where Change Requests Originate
| Origin | Typical Trigger | Initial Evaluator |
|---|---|---|
| Field Discovery | Unforeseen condition, trade conflict, or constructability issue | Superintendent |
| Design Bulletin / Sketch | Design team issues a revision to contract documents | Project Engineer / VDC Manager |
| RFI Response | An RFI answer modifies scope beyond simple clarification | Project Engineer |
| Owner Request | Owner requests a scope, finish, or system change | Project Manager |
| Regulatory / Code Requirement | Inspector or code official requires a modification | Superintendent / PM |
| Value Engineering Proposal | Contractor proposes an alternate approach for cost or schedule benefit | Project Manager / Estimator |
The Change Request Workflow, Step by Step
| Step | Activity | Output |
|---|---|---|
| 1 | Identify and log the potential change immediately upon discovery | Logged change request with date and description |
| 2 | Perform initial triage to confirm it represents a genuine scope change | Triage decision: proceed, reject, or seek clarification |
| 3 | Notify the owner and design team per contractual notice requirements | Documented notice, preserving contractual rights |
| 4 | Assign the request for detailed evaluation | Assigned owner and target evaluation date |
| 5 | Gather subcontractor input and cost/schedule estimates | Draft pricing and schedule impact |
| 6 | Compile the evaluated request into a formal COR | Change Order Request ready for submission |
| 7 | Hand off into the formal change order approval process | Submitted COR (see companion change order article) |
Logging Requests the Moment They Are Identified
The single highest-leverage habit in this workflow is logging a potential change the same day it is identified, even before anyone knows whether it will ultimately be approved. A brief entry what was found, where, and by whom preserves the timeline that later matters enormously for notice compliance and schedule impact analysis.
Triage: Separating Real Changes from Scope Clarifications
Not every question is a change. Triage exists to filter out items that turn out to be a misunderstanding of existing scope, already covered by the contract documents, before they consume estimating time. A disciplined triage step, ideally done within a day or two of logging, keeps the pipeline of real change requests streamlined and honest.
A helpful triage habit is to ask a simple, consistent question for every request: does the current contract docs straight up address this scenario, or does it really leave a gap or conflict here? Requests that turn out to already be covered by the contract, even if the answer required some research to confirm, should be closed out with a brief explanation rather than left ambiguous, since an unresolved “maybe” tends to resurface repeatedly as a source of friction.
Preserving Notice Rights
Most construction contracts include a notice provision requiring the contractor to inform the owner of a potential change within a defined window. Missing this window, even for a legitimate change, can jeopardize the contractor’s right to compensation. A change request workflow that automatically triggers a notice communication at the logging stage, rather than waiting for full pricing to be complete, protects this right consistently.
Required Documentation
| Document | Purpose | Timing |
|---|---|---|
| Change Request Log Entry | Establishes the date and description of the initial discovery | Same day as identification |
| Notice Letter or Communication | Preserves contractual notice rights | Within the contractual notice window |
| Triage Decision Record | Documents why a request was accepted, rejected, or needs clarification | Within a few days of logging |
| Subcontractor Pricing Input | Supports the accuracy of the evaluated cost and schedule impact | During the evaluation stage |
| Completed COR | The evaluated, priced proposal ready for the formal approval process | At handoff to the change order process |
Technology Integration
| Platform Type | Best Use | Limitation |
|---|---|---|
| Field Reporting App | Immediate logging of field-discovered potential changes | Requires consistent field adoption to catch everything |
| Project Management Platform | Tracking requests through triage and evaluation stages | Needs disciplined workflow configuration to be reliable |
| Email / Correspondence Log | Capturing owner-initiated and design-driven requests | Prone to items getting buried without a structured intake process |
| AI-Assisted Revision Intelligence | Automatically detecting design-driven changes needing evaluation | Most effective as an intake source feeding into the broader workflow |
AI-Assisted Opportunities
Design-driven change requests pose a unique challenge because one bulletin can affect many sheets, and determining accurately what changed, before you can even start the triage step, has mostly involved a time-consuming, manual review of each sheet. That review delay pushes back every subsequent step in the workflow, including the notice communication that protects the contractor’s contractual rights.
AI-assisted revision intelligence directly addresses this bottleneck. A platform like iFieldSmart AI’s Change Management AI automatically overlays a newly received drawing set against the previous baseline, detects and clouds the areas that changed, and produces a structured list of changes with narrative descriptions. For the change request workflow, this means the intake and triage steps for design-driven requests can begin almost immediately after a bulletin is received, rather than waiting for someone to first manually work through the entire revised set.
This speed matters most for notice compliance. If a contract requires notice of a potential change within five business days, a manual review process that takes three or four days just to identify what changed leaves almost no margin for the rest of the notice process. Compressing that identification step to hours rather than days meaningfully protects the contractor’s contractual position.
| Workflow Challenge | Traditional Approach | AI-Assisted Approach |
|---|---|---|
| Identifying design-driven changes from a new bulletin | Manual sheet-by-sheet comparison | Automatic overlay with clouded, numbered changes |
| Triaging which changes need full evaluation | Reviewing the entire revised set uniformly | Immediate visibility into exactly what and where something changed |
| Meeting contractual notice deadlines | Racing to complete manual review before the window closes | Faster identification preserves the full notice window for other steps |
| Documenting the basis for the request | Manually written summary of the change | AI-generated narrative descriptions supporting the log entry |
| ✓ EXPERT TIP Route every incoming bulletin through AI-assisted revision detection before assigning it for manual triage. This turns hours of comparison work into a starting point the project engineer can review and act on immediately. |
|---|
Implementation Roadmap
| Phase | Timeline | Key Activities |
|---|---|---|
| Phase 1: Define Intake Process | Preconstruction | Establish how and where change requests get logged from every origin |
| Phase 2: Set Triage Standards | Preconstruction | Define criteria and turnaround time for the triage step |
| Phase 3: Configure Tools | Mobilization | Set up field reporting, tracking platform, and revision detection tools |
| Phase 4: Operate | Throughout construction | Log, triage, and evaluate requests consistently as they arise |
| Phase 5: Review | Monthly | Audit cycle time from identification to COR submission |
Best Practices
| Practice | Why It Works |
|---|---|
| Log every potential change the same day it is identified | Preserves the timeline needed for notice compliance and schedule analysis |
| Complete triage within a defined, short turnaround | Prevents genuine changes from stalling and false positives from consuming resources |
| Send notice communications immediately upon logging, not after full pricing | Protects contractual rights that depend on timely notice |
| Involve affected subcontractors early in the evaluation stage | Produces more accurate pricing and avoids missed downstream impacts |
| Use AI-assisted revision detection for every design bulletin | Compresses identification time, preserving the notice window |
Common Mistakes
| Mistake | Consequence | Correction |
|---|---|---|
| Waiting until pricing is complete to send notice | Contractual notice window is missed, jeopardizing compensation rights | Send notice immediately upon logging, separate from the pricing timeline |
| No consistent intake process for field-discovered changes | Superintendents’ observations get lost or delayed | Provide a simple, fast logging method accessible directly from the field |
| Skipping triage and sending everything straight to full pricing | Estimating resources get consumed evaluating non-changes | Apply a disciplined, fast triage step before full evaluation |
| Evaluating design-driven changes without confirming full extent first | Missed downstream impacts surface later as disputes | Use revision detection to confirm the complete scope of a bulletin before pricing |
| No visibility into how long requests sit at each stage | Bottlenecks go unnoticed until they cause a schedule problem | Track cycle time by stage and review it regularly |
| ✖ COMMON MISTAKE The costliest workflow failure is not a bad triage decision, it is a good change request that sits unnoticed for weeks because no one had a fast, reliable way to log it the moment it was discovered. |
|---|
Industry Examples
| Project Type | Common Request Origin | Workflow Adaptation |
|---|---|---|
| Commercial Office | Field-discovered trade conflicts during MEP rough-in | Same-day field logging tied directly into the coordination meeting agenda |
| Healthcare Facility | Code official requirements during inspection | Expedited triage for life-safety-related requests |
| Data Center | Design bulletins affecting multiple technical disciplines | AI-assisted revision detection applied before any manual review begins |
| Manufacturing Facility | Owner equipment integration adjustments | Early coordination with owner’s equipment vendors during evaluation |
| Residential Multifamily | Owner-requested unit finish upgrades | Standardized intake form for common upgrade requests |
| Infrastructure / Civil | Differing site conditions discovered during excavation | Formal differing conditions notice process integrated into intake |
| Institutional (K-12/Higher Ed) | Phasing adjustments driven by academic calendar constraints | Fast-tracked evaluation given fixed occupancy deadlines |
| Industrial / Process Plant | Process equipment coordination conflicts | Mandatory engineering consultation before triage decision is finalized |
On a healthcare renovation project, a code official flagged a fire-rating deficiency during a routine inspection that required an immediate design response. Because the project’s change request workflow included an expedited path specifically for life-safety findings, the request moved from field discovery to a submitted, priced COR within three business days, compared to the standard two-week cycle time for routine changes. That speed avoided a stop-work order that would have cost far more than the change itself.
A commercial office project offers a contrasting lesson in the cost of slow triage. Early in the project, potential changes identified by the superintendent were logged in a shared spreadsheet but had no defined owner for the triage step, so requests routinely sat for a week or more before anyone confirmed whether they were genuine changes. After assigning a specific project engineer to review new entries every morning, average triage time dropped from roughly eight days to under two, which in turn meant notice communications went out reliably within the contract’s required window instead of frequently missing it.
FAQs
What is the difference between a change request and a change order request (COR)?
A change request is an informal notification given on the understanding that a request will be evaluated and priced. A Change Order Request is the formal, evaluated and priced, request submitted to the owner.
Who is responsible for logging a change request?
All project personnel are permitted to log change requests. However, field-related change requests are typically the responsibility of the superintendent; change requests that are design-related are the responsibility of the project engineer, and the project manager logs owner-related change requests.
How quickly should a change request be logged after discovery?
Ideally, at the time of the discovery. Delayed logging may mean missing contractual notice requirements and may also complicate an already contentious timeline reconstruction if a change request is contested at a later date.
What happens if a change request is rejected during triage?
A rejected change request should be documented. This would include the reason for the rejection. Documented rejections also become an effective hindrance to logging the same item, since it will have to be reevaluated.
Why does contractual notice matter so much in the change request process?
Many contracts require notice of a potential change within a specific window, and missing that window can forfeit the contractor’s right to compensation, regardless of how legitimate the underlying change is. A workflow that sends notice immediately upon logging, rather than waiting for pricing to be complete, protects this right consistently.
Can AI tools help identify change requests before a human notices them?
AI-assisted revision detection can surface design changes across a large drawing set far faster than manual review, effectively accelerating identification for design-driven requests. It does not replace field observation for conditions discovered through direct construction activity, which still depends on experienced staff noticing conflicts in real time.
How does the change request workflow differ for owner-initiated requests versus field-discovered issues?
Owner-initiated requests typically skip the triage question of “is this a genuine change” since the owner’s intent is usually clear, moving more directly to scope definition and pricing. Issues found in the field take more work to triage to make sure they actually represent a real difference from the contract documents instead of just a misunderstanding of the current scope.
Should subcontractors be allowed to submit change requests directly, or only through the general contractor?
Most projects route subcontractor-identified potential changes through the general contractor’s formal intake process rather than allowing direct owner submission, since the GC needs visibility into every change affecting the overall contract and coordination between trades. Subcontractors should still be encouraged to flag issues immediately to the GC’s field team rather than waiting.
What happens to a change request that turns out to involve multiple origins, such as a field discovery that also requires a design bulletin?
These should be logged as a single, linked request rather than duplicated, with the workflow tracking both the initial field discovery date and the subsequent design response. Keeping a single, connected record prevents confusion later about which trigger actually started the notice clock.
Expert Recommendations
- Allow field staff to easily capture possible changes as soon as they happen from a mobile device.
- Keep the notice communication step separate from the pricing timeline so contractual rights are safeguarded even during the evaluation process.
- Use a uniform, time-bound triage standard to filter out changes that aren’t real since true changes must be prioritized.
- Adopt AI-assisted revision detection for every incoming design bulletin to compress the identification step for design-driven requests.
- Monitor cycle time for each step of the workflow and examine it monthly to identify developing bottlenecks before they impact the schedule.
Conclusion
The change request workflow is the quiet, early-stage discipline that determines how well a project handles change before it ever becomes a formal, priced change order. Projects that capture potential changes quickly, triage them honestly, and protect their notice rights consistently avoid a significant share of the disputes that plague less disciplined teams.
AI-assisted revision intelligence is compressing the most time-consuming manual step in this workflow figuring out exactly what changed in a design revision from hours or days down to minutes. That speed does not replace the judgment required to triage and evaluate a change properly, but it gives project teams considerably more room to apply that judgment well, rather than racing simply to keep pace with the paperwork.
