Scope drift happens when the job moves beyond the original baseline without a clean record of what changed. In practice that means the team does extra work, the client remembers a different promise, and the final total becomes harder to defend at closeout.
Why scope drift matters
For small contractors and job-based service teams, scope drift usually shows up as margin loss and friction, not as a dramatic project failure. A few undocumented add-ons, field changes, or client requests can turn a profitable job into a payment dispute.
It also creates an internal clarity problem. When there is no single source of truth, your estimate, agreement, change orders, and final invoice stop lining up. That makes the closeout package weaker and leaves the team reconstructing what happened from texts, emails, and PDFs.
Scope drift vs. a change order
A change order is a recorded decision. Scope drift is what happens when the change is real but the record is weak, missing, or delayed. The work changed either way, but only one of those paths gives you a defensible trail.
That difference matters because a structured change order updates the job record, protects the baseline, and keeps the current total financially clear. Scope drift leaves the team arguing over memory instead of pointing to an approved record.
Common causes of scope drift
Most scope drift starts with good intentions: a quick field fix, a customer request that feels too small to document, or a team member assuming the extra work can be handled later. It can also come from version confusion when the latest agreement or estimate is not the one everyone is using.
If you regularly hear phrases like 'we already talked about that' or 'just add it for now,' the job is at risk of drifting away from the baseline even if nobody intends to create conflict.
How to control it
The practical control is simple: lock the baseline at commitment, record every approved change in one place, and keep the current total visible on the job. That is what prevents a job from becoming an archaeology project at the end.
SMB Workbench is designed around that workflow. The job becomes the system of record, the baseline stays intact, change orders are attached to the job, and the closeout package can show what was agreed, what changed, and what the job became.