Out-of-Scope Web Requests: What to Say Before Yes

Use these client-ready scripts to clarify extra web work, assess its cost and launch impact, and secure approval before changing the build.

November 13, 2026 7 min read

A web professional stands beside a whiteboard, pointing to a hand-drawn website layout in a bright studio meeting room.

A client asks for a new page, an integration or a “small” redesign during the build. Do not commit or reject it on the spot. First turn the request into a specific decision: what problem it solves, what changes, and what happens to the approved deliverables, budget and launch date. It is too early to say yes or no to an idea you do not yet understand. Boolu recommends the following repeatable six-step framework for handling unplanned requests.

The six-step response

Pause without implying acceptance.
Narrow the request to the underlying problem and desired outcome.
Compare the proposed change with the approved deliverables, timeline, budget and objectives.
Record its cost, schedule and delivery impact.
Offer a concrete choice: exchange existing scope, approve additional paid work, or defer it.
Record the selected option and obtain explicit approval before starting the changed work.

Treat that final approval as a recommended commercial control. Structured change control assesses a change’s impact and authorizes it before implementation; NASA’s guidance also calls for documented approval responsibilities and disposition options such as approval, deferral or rejection. The pause is not obstruction. Raw requests can conceal a much narrower need. Shape Up describes replacing a broad permissions request with a warning once the specific problem was understood, and narrowing “a calendar” to the need to see free spaces.

Script 1: pause and clarify the request

“Thanks for raising this. Before I confirm whether it fits the current project, could you tell me what is happening now, who encounters the problem, and what outcome you need? Once we have that, I’ll compare the request with the approved scope and come back with its delivery, cost and timing impact.”

Useful follow-up questions:

What specific task is failing or taking too long?
Who needs the change, and in what situation?
What would a successful outcome look like?
Is this necessary for launch, or could it follow later?
Which part of the current plan could become less important if this takes priority?

Avoid debating a vague label such as “redesign the resources area.” Broad redesigns without a single problem or use case are difficult to bound. A more workable request identifies what is failing, in what context, and what can remain unchanged.

Compare the baseline and the proposed change

Put the approved position and proposed position side by side. One scope-change template requests a comparison of original and revised timelines, budgets and objectives. Caltrans separately calls for the original, current and proposed overall project costs; the impact on the schedule; comparison of proposed and approved outputs or benefits; and a responsible party to contact.

Decision area	Approved baseline	Proposed change
Deliverables	What the team agreed to produce	What would be added, removed or altered
Timeline	Current milestones and launch date	Changed milestones or launch date
Budget	Current approved fee or budget	Additional cost or unchanged budget
Objective	Outcome the approved work supports	Outcome the request is intended to support
Scope trade	Current item retained	Current item reduced, replaced or deferred

Illustrative example: the approved build includes a five-page marketing site launching on 30 June. The client requests a searchable resources section. The comparison should not merely say “add search.” It should identify the resources, required filters, content responsibility, affected templates and whether an approved deliverable must move, the budget must change, or the launch must be reconsidered.

Compact change-request record

Keep one record containing:

Requested change
Approved baseline
Reason and desired objective
Affected deliverables
Cost impact
Schedule impact
Selected option: trade, paid change or later phase
Responsible client contact
Explicit approval: approver’s name and title, plus the approval date or recorded approval method

Waterloo’s project change form documents the request’s description, benefits, risks, funding, schedule, resources and deliverable impacts, followed by an approvals section with the approver’s name, title and date. NASA recommends recording the request’s rationale, cost, risk and schedule impact, disposition and approval status. These are adaptable controls for a web team, not universal legal requirements.

Use fixed time and variable scope

Fixed time, variable scope starts with a time boundary and shapes the solution to fit it. When the deadline stays fixed, the team has to distinguish core work from peripheral work and reduce scope rather than treating every addition as mandatory.

The source-backed trade-off is among time, quality and scope. To protect a fixed deadline and the quality of retained work, reduce or exchange scope. Shape Up illustrates this by choosing necessary corrections over adding another section before a deadline. If the client instead wants to change the budget, treat that as a separate commercial option under your agreement.

Script 2: trade existing scope

“We can keep the current launch date if we exchange scope rather than add to it. My proposed trade is to include [new request] and move [approved deliverable] out of this phase. The retained work will still receive the planned design, implementation and review time. If that trade works for you, I’ll document the revised deliverables for approval.”

Illustrative trade: add a campaign landing page now, while moving the approved case-study template to the next phase. Document clearly what enters and leaves the current scope so both parties can review the same proposed trade.

Script 3: request approval for paid work

“We have reviewed [request] against the approved scope. It adds [deliverables] and affects [parts of the build]. The additional cost is [amount], and the schedule impact is [change or no change]. If you want to proceed, please approve this change record in writing. We will begin the added work after approval.”

As operational guidance, evaluate the defined request before quoting it. Avoid relying on a standard surcharge, fee formula or unsupported effort estimate; document the proposed work and the basis used for its cost and schedule impact.

Script 4: defer it to a later phase

“This is a useful candidate for a later phase, but adding it now would affect [launch date, approved work or budget]. I suggest we keep the current phase unchanged and define [request] as a separate follow-up engagement after launch. We can then scope it using what we learn from this release.”

A phased project provides a deliberate home for work that is not essential to the current release. Smashing Magazine describes splitting digital work into separate engagements with clear deliverables and using the completed phase to inform the scope and estimate of the next one.

Script 5: give a soft decline

“I can see why that would be useful. We are not committing it to the current build because we do not yet have a sufficiently defined need or room within the approved scope. Let’s keep the current plan unchanged. If it becomes a priority, we can revisit it with a specific use case and decide whether to trade scope, approve separate work or plan a later phase.”

A soft decline keeps the option open without creating an expectation that the work will happen. Shape Up recommends avoiding an immediate commitment while an idea is still insufficiently understood.

Choose among trade, paid change and deferral

As a practical decision rule, choose a scope trade when the deadline must hold and the new request is more important than an identifiable approved item. Offer a paid change when the client wants both the approved work and the addition and accepts the documented cost and schedule impact. Defer the request when it is not required for the current objective or can be scoped more responsibly after the current phase.

Your governing agreement may set different rules for who can authorize a website-project change and what form approval must take. Check the signed agreement and confirm the authorized client contact and required approval method before beginning changed work.

Close with one decision, not an open thread

Send one concise decision note: the clarified request, approved baseline, impact, available options and approval requested. The aim is to give the client a visible choice while protecting the work, launch plan and commercial decision from an accidental commitment.

Frequently asked questions

Should I say that a client request is out of scope immediately?

Pause first. Clarify the underlying problem, compare the proposed work with the approved baseline, assess its impact and then present a decision.

How can I accept extra work without moving the launch date?

Offer a defined scope trade: add the higher-priority request and remove or defer a named approved deliverable. Document the revised scope and seek approval through the process set by your agreement.