Review scope changes after a quotation

Start from the original agreed scope

Compare the request with the original offered or accepted scope. Separate quantity, specification, deliverables, destination and timing, and note which parts remain unchanged. Replace ambiguous phrases such as “a little larger” with a dimension or count that can be reviewed. Receiving a change request does not mean approving it. Keep the request in review until someone has checked whether the team can deliver it and what other commitments it affects.

Give each change request its own record

Use case ID, change ID, source quotation version, request time, before and after values, reason, reviewer, impact and customer decision. In SC-102, increasing twenty units to thirty and bringing delivery forward are separate changes. They can share a request reference, but the record should still support accepting one and declining the other. Preserve the original values rather than replacing them, so the cost and scheduling review has a stable starting point.

Review effects beyond the price

Check materials, production time, subcontracting, shipping and work already completed. A change with no price increase may still alter delivery or ongoing support. State the difference between leaving the scope unchanged and accepting the request, then identify the required reviewers. Separate internal calculation notes from customer-facing terms. Someone should confirm the values and assumptions actually being offered rather than exposing a draft calculation as though it were an approved commitment.

Confirm acceptance of the revised terms

Reference the change ID and quotation version in the revised offer. Acceptance of the amount alone may not settle a changed delivery date or reduced deliverable. Confirm scope, price, schedule and treatment of existing work together, and preserve the customer’s response. Keep pending changes visible to production or fulfilment so work does not switch to an unaccepted draft. A status labelled “customer asked” should never be interpreted as “approved for execution.”

Handle work that started before approval

If work starts before approval, record what changed and pause the affected step. Determine whether the original scope can be restored, whether costs have already been incurred and what needs reconfirming with the customer. Do not rewrite the history to make the change appear pre-approved. If a notification or integration triggered the work, check its approval condition before resuming. Recovery should address both the immediate work and the rule that allowed it to start.

Test partial acceptance and withdrawal

Use examples for quantity accepted with timing pending, a withdrawn request and an expired original quotation. Check that withdrawn changes do not remain in the order and partial acceptance does not become blanket approval. The effective scope should be one coherent set of conditions, not quantities from one version and dates from another. Ask the delivery team to read it back. If they need to guess which values apply, the review is not complete.

SC-102: quantity accepted while timing remains unresolved

In SC-102, the proposed change combines twenty to thirty units with earlier delivery. A reply saying “please make thirty” does not by itself confirm the timing. Record quantity accepted and timing pending, and do not pass an unconfirmed deadline to production. If materials must be ordered before all details settle, record the limited internal decision and its scope. Should the customer withdraw the quantity change, the team can then explain work already authorised without pretending the entire revised offer was accepted.

Choose a tool and budget around the actual workload

A quotation register and review document may be sufficient for occasional changes. A shared case system becomes useful when several teams need the same effective scope. Budget for re-estimation, rework and customer communication as well as the software subscription. Automating calculations can reduce typing, but it does not decide whether a new promise is feasible. Establish approval ownership first and add integration only after the manual review produces consistent results.

• Build a quotation request form in Tally
• Build a quotation calculator with AI
• Choose an internal approval workflow with explicit authority