How to Handle Out-of-Scope Client Requests Without Conflict

Compare it with deliverables, exclusions, assumptions, and revision terms in the actual agreement.

These are examples, not contract interpretations. The agreement controls.

Start with the goal and offer a choice. For example:

That additional page makes sense for the campaign. It isn't included in the current website scope, so I can price it as an add-on and show the impact on delivery. Would you like an estimate, or should we keep the original launch plan?

This avoids a defensive “that's not included” while preserving the decision boundary.

Assess four items: additional work, specialist involvement, dependency changes, and timing. A request that takes two hours may still delay a critical approval or change another deliverable. Estimate the whole impact rather than just the hands-on task time.

Do not treat a request as authorized until the agreed approval process is complete. If you decide to perform exploratory work before approval, clearly state its limits and who pays for it. Keep the original scope and proposed change separate.

Record the request, who made it, whether it was approved, revised price, affected milestones, and the resulting tasks. A simple change log makes future conversations about the baseline much easier.

Noddis Drift compares added tasks and subtasks with an established scope baseline. You can establish scope through a proposal import, or attach a client and turn on Scoped Project in Project Details. Review later additions as client-requested, internal, or still unclassified; Noddis does not infer the client's approval from the mere existence of a new task. The scope-creep guide explains how this record supports a change conversation.

Drift's percentage describes growth in recorded work items, not extra hours, a new price, or whether a deadline will slip. Review the plan comparison for current access details, and use the live demo to explore the wider workflow.

For each request, ask: Is it included? What changes? What are the options? Who approves? This keeps the conversation about the agreement and delivery tradeoffs rather than whether the client is being unreasonable.

For example, a client commissions a five-page website and later asks for two landing pages. The new pages may be valuable, but they change the agreed deliverables. Estimate design, copy, development, and review effort before offering a revised price or timeline. A typo fix, by contrast, may already be covered by the original scope. The contract and acceptance criteria determine the difference.

When it is clearly extra work: “Happy to add that. The two pages are outside our original five-page scope. I can send a short estimate for the additional work and timing before we begin.”

When the agreement is ambiguous: “I can see how that relates to the original deliverable. Let me compare it with our agreed scope and confirm whether it fits the current plan.”

When the budget cannot change: “We can keep the budget by replacing an existing deliverable, or keep the original plan and quote the extra work separately. Which option works better?”

Illustrative example. Record the request, proposed impact, decision, and approval date even when the client declines. A declined request can resurface later.

Do not begin significant extra work on the assumption that approval will follow. Do not treat every internal improvement as a client-requested change. Do not substitute a scope-growth percentage for a real effort estimate. Noddis Drift helps measure scope growth against a baseline and classify additions, but it does not replace an agreed change order.