How to Review Agency Scope Changes Before Promising the Work

Catch the change before it becomes a promise

A client asks for one more variation. A designer agrees in the thread. Two days later, the delivery lead discovers that the variation needs a new data source and another review round. The problem is not that the client asked. It is that nobody translated the request into a shared decision.

A scope-change review is a short internal check between receiving the request and accepting it. Its purpose is to identify the actual difference, make the consequence understandable, and give the authorized owner enough context to respond. It should not turn every clarification into a commercial dispute.

Classify the request before estimating it

These categories are an operating aid, not a substitute for the account owner's judgment about the agreement. Keep the source of the accepted scope visible. A message saying 'like the earlier example' is not enough if several examples exist.

Build a six-field change packet

• Requested difference: what would be added, removed, or changed, in the client's words where appropriate.
• Current baseline: the specific agreed deliverable and version being changed.
• Reason: what the client is trying to achieve, separate from the proposed solution.
• Dependencies: people, source material, approvals, or production steps affected.
• Options: realistic choices with their known consequences and unresolved estimates.
• Decision: the authorized owner, the question they must answer, and when the answer is needed.

Link to the request and the baseline beside those fields. Do not paste a whole client history into the packet. If you discovered the ambiguity through an agency open-loop review, keep that loop open until someone records the scope decision. Detecting the request is not resolving it.

Show options instead of making a vague warning

Consider a hypothetical website project with an approved English landing page. The client now wants a second language at launch. The difference is not simply 'more copy'. It may require translated text, layout review, an approval owner, and a decision about the launch date.

A useful packet might offer three paths: retain the original launch scope and schedule the second language later; replace a lower-priority deliverable with the new work after confirming effort; or expand the scope with a separately agreed estimate and timeline. These are options to review, not promises the AI should make.

Unknown effort should remain unknown. Ask the delivery lead for the missing estimate rather than converting a rough Slack comment into a fixed date. Also distinguish a dependency that blocks all work from one that blocks only the requested addition.

Ask Mio for an internal comparison, not a client response

Mio's agency workflows include account context, briefs, deadlines and follow-up drafts. A bounded starting request is: 'Compare this client request with the current approved deliverable. Identify the exact change, unresolved assumptions, affected dependencies, and options for the account owner. Link the relevant versions. Do not estimate missing effort, accept the work, change the project plan, or contact the client.'

The reviewer should check whether Mio selected the current baseline, preserved the client's intended outcome, and distinguished a correction from additional work. If the source set is incomplete, gather the missing document or ask the owner. A polished answer cannot compensate for an absent baseline.

Close the loop with a versioned decision

Once the owner and client agree on a path through the agency's normal process, record the accepted option, affected deliverable version, owner, and next milestone. Put the resulting decision in the team's decision log. Update the work plan through the authorized owner, then make the consequence visible in the next client report.

Do not treat an emoji on an old mockup as approval of a newer version. If feedback arrives after acceptance, compare it with the accepted version again. The goal is not to win a debate about who said what. It is to keep both sides working from the same commitment.

Check whether the review is helping

For the first few requests, record how long the review took, how many needed clarification, and how often work started before the owner accepted the change. Track incorrect classifications as well. A process that catches genuine additions but turns harmless clarifications into friction needs adjustment.

Start with one client and one project. Keep the packet short enough to read in the account thread. Mio can help assemble the context; the agency still owns its estimates, commitments and relationship. Try Mio in Slack.