How to handle change requests after a client signs

Write down what is in scope, name one approver, and answer every out-of-scope request with a price and a date. Here is how to apply that to an AI buildout without losing margin or the client.

Lumina8 min read
Two overlapping amber line rectangles on a dark charcoal background, one extending past the other, lit by a warm glow from the right edge

Write down what is in scope before the build starts, name one person on the client side who can approve changes, and answer every out-of-scope request the same way: yes, that is a change, here is what it adds in cost and time. That is the whole system. The rest of this post is how to make it work for an AI buildout, where the requests are small, frequent, and sound harmless.

Most agency owners lose margin here, not on the sale. The client signs, the receptionist goes live, and a week later the texts start. Can it also answer questions about financing? Can it say the Saturday hours are different next month? Can we add a second location? Each one takes five minutes to say yes to. Ten of them take a month of your attention, and you are the only one who gets paid nothing for it.

What counts as a change request on an AI buildout?

A change is anything that alters what you and the client agreed the system would do. A correction is anything that makes the system match facts the client already gave you. The line between them is the whole game, so draw it on purpose.

Corrections are the client's own information drifting: a price went up, a staff member left, the holiday schedule changed. We covered who owns that in who maintains the AI system after it goes live. Keep corrections free and fast. If the agent quotes an old price, that is a bug in the facts and you fix it the same day.

Changes are new scope. A new service line, a second location, a new call-routing rule, a new language, a different booking calendar, a new person who gets the leads, a request for the agent to take a new kind of action. These are the ones that need a price.

A quick test: would the original quote have been different if the client had asked for this on day one? If yes, it is a change.

Why does scope creep hit AI projects so hard?

The work is invisible and the system talks. A client can hear the agent say something wrong on a test call, and in their head that is a defect, even if what they wanted was never in the brief. And because everything is a prompt edit, clients assume every edit is trivial.

Agiled's guide to agency scope creep makes the structural point well: "Prevention is structural, not a matter of being firmer with clients" (Agiled). Their advice is to define deliverables with quantities, list exclusions, cap revision rounds, name one client-side approver, and state your assumptions. None of that is AI-specific, and all of it works.

For a voice or chat build, translate it like this:

  • Deliverables with quantities. One phone line. One location. One booking calendar. The services listed at intake, each with a price band.
  • Exclusions. No payment taking. No outbound calling. No integrations beyond the calendar and lead routing you agreed. If it is not in the intake, it is not in the build.
  • Revision rounds. Say how many rounds of script tuning are included after launch. Two is a reasonable number to start with, but pick your own and write it down.
  • One approver. Whoever signed. Not the office manager, not the owner's spouse, not the technician who "has ideas."

How do you say no without losing the client?

You do not say no. You say yes with a price attached. Agiled suggests one script for every out-of-scope request: agree in principle, note it is outside scope, and offer a change order. Their wording is "It's outside our current scope, so I'll send a quick change order with the added hours and the new timeline" (Agiled).

For an AI buildout it sounds like this: "Yes, we can add financing questions. That adds a service to the build, so I will send you a short note with the cost and when it would go live. Tell me yes and I will schedule it."

The note is short. It states the new request, the added cost, the new timeline, and who approves it. That is all. A change order exists to make the cost visible at the moment the request is made, not to be a legal weapon.

Two habits keep this friendly. First, never say "that is not included." Say what it would take. Second, send the note the same day. A quote that arrives in a week feels like punishment. One that arrives in an hour feels like service.

Where does wholesale pricing fit?

Here is the part specific to how we work. When you order a client build, the wholesale setup fee and monthly are agreed on a 30-minute pricing call before anything is built. That call is included for every client build you order. The detail of how to run it is in the 30-minute pricing call for client AI builds.

For a change that adds a service or a line, I would treat it the same way: decide the scope, get the wholesale number, then set your own retail on top. Do not quote your client a number before you know your own cost. A small change that adds a service line can add a monthly cost on your side, and if you absorb it silently you have just cut your own margin for the life of the account.

If you are not sure whether something is a free tweak or a new line, ask before you promise. Promising first and pricing later is how a $2,000 deal turns into an unpaid part-time job.

When should you just do it for free?

Sometimes. The Agiled guide says absorbing a very small extra can be a deliberate choice, such as goodwill with a client you expect to convert to a retainer. The key is making that decision on purpose rather than letting small favors pile up.

Here is my rule. Free once, said out loud. "I will do this one as a favor. Next time it is a change order." That one sentence resets the relationship and costs you nothing. If the client then asks for a second favor, you have already told them the policy.

Also give away anything that fixes a real mistake on your side. If you misheard intake, or the agent handles something the brief clearly covered, you own that. Charging for your own errors is how you lose the account and the referral.

What do you put in the contract?

Sprintlaw's guide to change request clauses lists what a good one covers: what counts as a change, who can approve it, how approval is recorded, how pricing and payment work, how timelines move, what the client must supply, and what happens with disputed extras (Sprintlaw). Their core line is that your contract should require "authorised written approval before the agency starts out-of-scope work."

For a small AI agency you can fit that in a short paragraph. Name the approver. Say that anything outside the agreed intake needs written approval, and that an email reply counts. Say that delays in supplying materials move the launch date. Say what happens if a request is disputed: you keep running the agreed system while the extra waits.

I am not a lawyer, and I would get a real one to look at your template once. But the structure above is what the clause needs to do.

Who is this approach not for?

It is not for the client who changes their mind weekly about the basics. If the owner rewrites the services list three times during onboarding, no clause fixes that. Pause, hold a kickoff-style call (here is an agenda for one), and get the facts nailed down before you spend more time.

It is also no excuse to nickel-and-dime a good account. If you charge for every sentence, clients will stop telling you when their hours change, and then the agent starts giving wrong answers. A JustCall troubleshooting guide lists stale knowledge, where policies or hours changed but the knowledge base still has the old answer, as the first cause of wrong AI receptionist answers (JustCall). You want clients to tell you about corrections fast. So keep those free.

Frequently asked questions

Should I charge for small tweaks to the script? Not for corrections. If the client's facts changed, update them. Charge when the request adds a service, a location, a routing rule, or a new action. A good test is whether the original quote would have been different.

How many revision rounds should I include? There is no standard number. Agiled gives no fixed cap either. Pick a small number, such as two rounds of script tuning after launch, and write it into the scope so the limit is visible before anyone hits it.

What if the client says the AI "is wrong" but it matches the intake? Pull the transcript, show the intake answer next to what the agent said, and ask whether the fact changed. Usually it did. Treat that as a correction and fix it. If they want new behavior, it is a change.

Does the 30-minute pricing call cover change requests? The call is included with every client build you order. For a later change, I would still price it the same way: get the wholesale number first, then set your retail.

Can I run all this inside the client portal? The client portal is where the client sees status and next steps under your name, which is a natural place to point them. Use it for status, and keep approvals in writing by email so you have a record.

Next step

Open your last client's intake and write one page: five things the build does, three things it does not, one named approver, and the sentence you will say when they ask for something new. Attach it to your next kickoff. If you do not have a client yet, start your workspace and build the demo first.