# How to Handle Change Requests on Shopify Projects

> How to handle change requests on Shopify projects: a change request process that prices the impact, gives clients real decisions, and protects margin.

_Published: 2026-10-26 · CommerceCopilot_

## Change requests are not the problem; silent absorption is

Every Shopify project generates change requests. The client sees the staging link and realizes the mega menu needs a third level. A stakeholder who skipped discovery joins week four with opinions about the product page. Marketing decides the launch needs a bundle builder that was never in the quote. None of this is a failure, it is how clients work: they keep learning what they want after the contract is signed. The question of how to handle change requests is really the question of what happens in the thirty seconds after the ask lands, because most agencies do not handle them at all. They absorb them.

Absorption looks polite and costs the margin. The developer says "sure, quick change" in a Slack thread, the quick change takes a day and a half, and three weeks later the project is over budget without any single moment anyone can point to. This post lays out a change request process light enough for agency work, on web projects generally and Shopify builds specifically. It picks up where [project scoping](/blog/shopify-project-scoping) leaves off: scoping draws the line around the work, and change control is what keeps the line meaningful once the project is moving.

## What actually counts as a change request

Formally, a [change request](https://en.wikipedia.org/wiki/Change_request) is a documented proposal to alter something that has been baselined: scope, schedule, or budget. The enterprise version comes with change control boards and approval workflows that no six-person agency will ever run, and should not. But the definition carries one idea worth keeping: a change is measured against a baseline. If your scope document is vague, you cannot tell a change from a clarification, and every disagreement about new work collapses into a disagreement about what the quote meant.

In practice, incoming asks on a Shopify project sort into three buckets, and the sorting is most of the skill:

- **A clarification** fills in detail the scope always implied. "The announcement bar should close when dismissed" on a ticket that says "add an announcement bar" is not a change, it is the spec getting finished. Build it.
- **A defect** is the agreed scope not working as agreed. That is rework you owe, not a change, which is why tickets with [clear acceptance criteria](/blog/writing-acceptance-criteria-shopify-tickets) settle these arguments before they start.
- **A change** is new or different scope: a feature that was not in the baseline, a revision to something already approved, or a dependency nobody agreed to. This is the bucket that needs a process.

The buckets only work if the baseline is specific enough to sort against. "Improve the collection page" can absorb infinite asks; "rebuild the collection page filter with these five facets" cannot.

## How to handle change requests without blowing the budget

The process below is five steps, and the whole point is that it is cheap enough to run on a two-line Slack message, because that is where most change requests arrive.

### Capture every ask, in writing, the day it lands

Change requests arrive in calls, Slack threads, email replies, and comments on staging links. The ones that kill budgets are the verbal ones: agreed in a call, built from memory, disputed at invoice time. The rule is mechanical: every ask gets written down as a one-line candidate change the same day, even if the answer is obviously yes. You are not building bureaucracy, you are building the record that makes the end-of-project conversation about facts instead of recollections.

### Classify before you react

Run the three-bucket sort before anyone says yes, no, or "quick change." Clarifications and defects proceed without ceremony. Only genuine changes move to the next step, which in a normal project is a few items a week, not a flood. If everything is landing in the change bucket, the problem is upstream in the scope, not in the client.

### Price the impact before you answer

A change request has no meaning without its cost attached, and the cost is three numbers, not one: effort, schedule, and budget. A two-hour change that lands on the critical path a week before launch is a schedule problem wearing an effort disguise. Estimate it the way you would [estimate any other ticket](/blog/how-to-estimate-shopify-development-work), as a range where uncertainty is real, and on Shopify work check the two classic cost multipliers before quoting: installed apps that already own the DOM element in question, and anything drifting toward checkout, which can change the project's category depending on the store's plan. The same handful of variables that drive [what a build costs](/blog/how-much-does-a-shopify-build-cost) drive what a change costs, in miniature.

### Give the client a real decision

Present the change with its price and let the client choose between honest options: accept it (budget and timeline move accordingly), defer it to a post-launch phase, or swap it for something of similar size that has not been started yet. The swap option matters more than it looks: it reframes the conversation from "pay more" to "choose what matters," which is a conversation clients handle well. What you never offer is the fourth option the absorbing agency defaults to: yes, free, silently, with the cost paid out of your margin and your team's weekend.

### Record the decision and move the baseline

Approved changes become tickets with scope and acceptance criteria like everything else. The budget and timeline numbers move visibly, in the tracker and in the next status update. Deferred changes go on a named backlog so they resurface at the phase-two conversation instead of evaporating. The baseline is now the new baseline, and the next ask gets sorted against it.

## Pre-wire the process before the first change arrives

A change request process introduced mid-project, right when the client asks for something, reads as defensiveness. Introduced at kickoff, it reads as professionalism. Three habits do most of the pre-wiring.

Put the mechanism in the contract and the kickoff deck: changes are welcome, here is the form they take, here is who can approve them on the client side. Naming the approver matters, because a Shopify project collects stakeholders, and "the CEO saw staging and wants the hero changed" is only a change request if the CEO is the person who signs off on spend.

Sell a change budget on projects where change is predictable, which is most of them. A named allowance, say ten hours, that changes draw against turns every mid-project ask from a renegotiation into a routine draw-down, and whatever is left at launch funds the post-launch tweaks every store needs anyway.

Batch the small stuff. Processing every two-line tweak individually generates friction out of proportion to the work. A weekly change review, fifteen minutes alongside the status update, handles the week's candidates in one pass and keeps the daily channel for build questions.

The pricing model changes the texture but not the need. On [fixed-price work](/blog/fixed-price-vs-time-and-materials-shopify), change control protects the agency's margin; on time and materials, it protects the client's budget and your relationship. Either way, the project with no change process is the one that ends in a dispute.

## Where CommerceCopilot fits

The step that fails in real agencies is the first one: capture. Changes arrive as a sentence in a client call or a Slack thread, everyone nods, and nothing is written down until the work is already half-built. CommerceCopilot's Business Analyst agent works against exactly that gap, because its discovery is continuous rather than a one-time document pass. The [meeting notetaker](/docs/meeting-notetaker) carries call transcripts straight into the project's discovery, where the Business Analyst extracts decisions, surfaces open questions, and updates the backlog picture, and connected channels feed it the asks that arrive in writing. A "small addition" mentioned in minute forty of a status call shows up as a drafted backlog item your team reviews, instead of a memory someone has to reconstruct at invoice time.

The same review-before-create flow from the [brief-to-tickets walkthrough](/docs/your-first-brief-to-ticket-project) applies: nothing lands in your tracker until a human confirms it, so the agent is doing the capture and drafting, and your team is still making the accept, defer, or swap call with the client.

## FAQ

### Should small changes go through the process too?

Capture and classification, yes, always, because "small" is a guess until someone looks, and the record is the point. Full pricing and a formal client decision, no: that is what the change budget and the weekly batch review are for. The process should scale down to a thirty-second sort for a two-line ask.

### How do you handle a client who disputes that something is a change?

Against the baseline, not from memory. If the scope document is specific, the conversation is short either way: it is in the baseline and you owe it, or it is not and it is a change. If the scope document is too vague to settle it, concede gracefully this time and fix the scoping, because the dispute is evidence about your process, not about the client.

### What if the client refuses any change process at all?

Clients rarely object to the process; they object to friction. A one-line written confirmation with a price attached is less friction than a surprise invoice. If a client genuinely insists on unlimited verbal changes at a fixed price, that is pricing information about the engagement, and time and materials, or a walk-away, is the honest answer.

### Does a change freeze before launch make sense?

A soft one, yes. In the final stretch, new changes default to the post-launch backlog unless they are blocking launch, because late changes carry regression risk out of proportion to their size, especially around anything the theme or installed apps share. The freeze is easiest to enforce if the deferred list is visibly scheduled rather than refused.

---
Canonical page: https://www.commercecopilot.ai/blog/how-to-handle-change-requests-shopify-projects