A BPO contract puts the process scope in writing as it exists on the day of signing: the steps, the known exceptions, the expected volume. That scope never stays still. The client launches a new product, changes a policy, a regulation moves, a channel appears that did not exist before. None of that is an incident: it is the business running normally. The problem is not that scope changes, it is that almost no operation has a defined place for that change to be recorded.
Without that place, the change happens anyway. It arrives by email, by a Slack or Teams message, by a verbal instruction on a status call. The team executes it because it is the operationally correct thing to do, and it stays there: no effective date, no named approver, no effect reflected in the SLA or the rate. Six months later nobody remembers precisely what was agreed, and the conversation turns on perception instead of on facts.
A scope change is not an exception
Two things get confused often and are worth separating. An exception is an individual case that does not fit the normal flow and that the team resolves within rules already agreed — who authorises it and how fast is the subject of support tiers and escalation. A scope change is different: it changes the rule itself. Adding a product to the catalogue the team must know, adding a support channel, changing the criterion used to approve a refund: none of that gets solved case by case, it gets decided once and applied going forward.
The line between the two is not always obvious on day one. The practical test is repetition: if the same question gets resolved the same way three times, it is no longer an exception, it is a new instruction that is missing documentation and approval as a change.
The three questions every change needs to answer
A change control process does not need to be heavy to work. It needs to answer three questions before the change goes live:
- What exactly changes, described in a sentence a new agent could read and apply without having to ask. "Refunds up to a set amount can now be approved without escalation" is an instruction; "let's be more flexible about refunds" is not.
- What effect it has on handling time, expected volume, training needs or process risk. An exact figure is not required — sometimes it does not exist yet — but an honest estimate of whether the change is minor or moves something the contract already measures is.
- Who approves it and from when it applies. Without an effective date, the change gets applied differently depending on who heard about it first, and the team ends up running two versions of the same rule at once.
Who has the authority to answer the third question depends on the contract's decision structure, the subject of BPO contract governance. Change control with no clear authority just moves the ambiguity from the instruction to the approval.
A simple format beats a complete one
The most common mistake when setting this up is over-engineering it: a long form, with fields nobody fills in properly because it takes longer than the change is worth. When that happens, the process gets skipped and the instruction goes back to arriving by chat. A short record — what changes, who requested it, estimated impact, who approves, effective date — is enough for the vast majority of changes that come up in an operation. What matters is not the format, it is that there is a single place where that record lives, and that nobody treats an instruction as current if it is not there.
A change approved over chat is not an approved change. It is an instruction someone will have to reconstruct from memory the day something goes wrong.
When the change should touch the SLA or the rate
Not every change is free for the provider or the client, and pretending otherwise is where resentment starts on both sides. A change that increases handling time, adds a channel or adds volume without notice affects directly what the SLA can promise — what makes a commitment sustainable is covered in how to write an SLA you can meet — and it may require adjusting the rate or headcount, depending on the pricing model agreed in BPO pricing models. Accepting the change without touching either one is common early in the relationship, when both sides want to show flexibility. It is also the quietest way an operation ends up billing for a smaller scope than the one it actually carries.
What happens when the process does not exist
Scope creep does not show up overnight. It accumulates through dozens of small changes, each reasonable on its own, until the team is carrying a considerably larger process than the one that was quoted, at the same rate and the same headcount. Nobody decided it that way; nobody ever recorded it at any point. When a quality or SLA problem finally surfaces, the conversation gets harder because neither side is clear on what the scope actually was — the same blind spot that makes it difficult to act once there is already an SLA breach to resolve.
Making it routine
Change control works when it has a fixed slot in the contract's steering meeting, not when it depends on someone remembering to bring it up. A short item on every committee agenda — which changes were logged since the last meeting, which are still pending approval — is enough to keep the habit alive. The rule worth setting from the start is simple: no verbal or chat instruction counts as in effect until it is in the log, no exceptions for urgency.
How smartBPO handles it
We keep a single change log per account, visible to the client, where every entry has a request date, description, estimated impact and approver. Before executing any instruction that changes a rule already agreed, we ask for it to be logged there, even when it first arrives through an informal channel. We review that log at every steering meeting, and when the accumulation of changes starts moving handling time or volume in a sustained way, we say so explicitly instead of letting it show up first in the metric.