Discuss a Customer Scope Change Before Making a New Promise

Overview

When a customer asks for work beyond the current scope, clarify the desired result before promising a solution. Compare the request with the agreed outcome, assess its effect on cost and timing, and present the available choices. The conversation should end with a clear next step and an authorized record of any change.

A scope discussion is not automatically a dispute. Customers often discover new needs once work begins. The service provider may also discover that its original description was unclear or incomplete. A useful process distinguishes those situations from a genuinely new request.

Atlassian's scope and change-control guidance supports making requirements and consequences explicit. The practical conversation below applies that discipline to the customer relationship.

Understand the task behind the request

Ask what the customer is trying to accomplish and what changed. “Can you add another dashboard?” might mean the current report is hard to use, a new stakeholder needs a different view, or the original work omitted an agreed requirement.

Avoid starting with a price or a refusal before understanding that distinction. Ask for an example of the decision the customer needs to make or the output they need to share.

Restate the desired result in ordinary language. This gives both sides an opportunity to correct an assumption before the delivery team estimates the wrong work.

If the request reveals a service failure, use the customer complaint process as appropriate. A provider should not automatically label correction of its own failure as an optional upgrade.

Compare with the agreed scope

Review the proposal, statement of work, acceptance criteria, and relevant correspondence. Identify what is included, excluded, assumed, or ambiguous.

Use the sales proposal workflow to locate the approved version. A draft or an old sales slide may describe a different promise from the agreement the team actually accepted.

Explain the difference neutrally. “The current plan includes one monthly report for the operations team; this request adds a weekly view for regional managers” is more useful than “that is out of scope.”

Where the documents conflict or the interpretation is consequential, involve the responsible contract or account authority. The delivery team should not invent legal conclusions during a customer call.

Separate clarification, correction, and change

A clarification explains an existing requirement without altering the agreed outcome. A correction brings work into line with the obligation already accepted. A change alters what will be delivered or the conditions of delivery.

These categories can overlap, so use them to investigate rather than as labels that end the conversation. A customer may request a new report because the original one fails an agreed need.

Record the evidence for the classification and who can resolve disagreements. If the scope was ambiguous, the account owner may choose a commercial accommodation while improving future documentation.

Do not make staff absorb every unclear request informally. Invisible extra work can reduce capacity for other commitments and create inconsistent treatment between customers.

Assess the complete delivery consequence

Ask the delivery team what the request affects: design, implementation, testing, training, documentation, support, dependencies, and ongoing maintenance. A visible feature may be only part of the work.

Check timing against the actual schedule. The requested change may be small in effort but depend on a specialist or supplier whose next availability is limited.

Identify what can remain unchanged and what must move. Avoid saying “no impact” until the relevant owners have reviewed it.

The assessment should include assumptions. If the estimate depends on the customer supplying clean data by a particular date, that condition belongs in the proposed change rather than remaining in an internal note.

Offer choices with clear tradeoffs

Where practical, provide two or three meaningful options. They might include adding the requested scope with a revised price and date, replacing a lower-priority deliverable, or scheduling the request after the current phase.

Do not present an artificial choice designed to pressure the customer. Each option should be feasible and described honestly.

For example, a team preparing a launch might offer a standard report at launch, a custom report in a later phase, or a revised launch date that includes the custom report. The customer can then choose based on the consequence that matters most.

If no acceptable option is currently available, explain what evidence or decision is needed next. A pending answer is better than a promise made without delivery support.

Use language that preserves the relationship

A useful response might be: “I understand why the regional view would help. I will check the data and review work it adds, then send options showing the effect on the launch date and price by Thursday.”

That response acknowledges the need without implying approval. It also creates a commitment the account team can own.

Avoid phrases that sound final when they are only exploratory, such as “we can definitely include that.” Customers may reasonably rely on them even if the delivery team later calls the conversation preliminary.

Keep the discussion about the work and its consequences. Blame over who should have anticipated the request rarely helps establish the next sound decision.

Confirm who can authorize the change

Identify the customer's decision-maker and the provider's approval authority. A user requesting a feature may not control budget, and an account representative may not be authorized to commit delivery capacity.

Use the agreement's required approval method. Preserve the exact scope, price, timing, assumptions, and acceptance criteria being approved.

Do not begin consequential added work merely because silence followed an estimate, unless the applicable agreement and authorized process clearly support that action. Ambiguous approval creates avoidable disagreement later.

If urgent work must proceed before all details are settled, the responsible authority should define the limited authorization and unresolved terms explicitly. Treat the exception as an exception, not the normal route.

Update the operating records

Once approved, update the delivery plan, project record, relevant commercial documents, and customer-facing expectations. Inform the people whose work or deadlines changed.

Connect the change to the customer onboarding process when it alters setup, training, access, or the definition of first value. A new promise can require a different handoff even if the original onboarding is already complete.

Keep the original scope history. Replacing it silently with a new document can erase the explanation for changed timing or cost.

Assign an owner to verify implementation. A signed change is a decision, not proof that the requested outcome has been delivered.

Review patterns across requests

Look for repeated scope questions. They may reveal unclear sales material, missing discovery questions, an unsuitable package, or a product opportunity.

Separate one customer's unusual need from a recurring gap. The business should not redesign every offer around the loudest request, but it should learn when many customers misunderstand the same boundary.

Track accommodations as well as charged changes. A service that appears profitable may rely on unrecorded extra work, and the team cannot evaluate that pattern if every accommodation disappears into ordinary delivery.

Use the findings to improve proposals and discovery. The next customer should benefit from a clearer description of the work.

Close with an accurate commitment

Summarize the decision, what will happen next, who owns it, and when the customer will receive an update. If no change was approved, state how the existing work continues.

After delivery, check the revised acceptance criteria and record completion. If new information changes the plan again, return to the same disciplined conversation rather than layering informal promises.

A good scope discussion helps the customer choose knowingly and lets the team deliver what it actually agreed. That is the basis for both a sustainable service and a trustworthy relationship.