ZAMBO.

Direct answer

Every task is small. The pile is not.

Nobody adds a whole second project at once. They add a page, a tweak, a quick call, a tiny export, each one small enough that refusing feels petty. By the end you have done half again the work for the original price, and the client honestly believes it was all included, because nobody ever said otherwise out loud. The fix is not saying no harder. It is making every addition visible, priced, and decided as it arrives, so included stops being a memory contest.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 25, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on publication day.

Step 1. Start the extras list today, with dates, and keep it where the client can see it

Write down every extra task already absorbed: what it was, when it was asked for, and roughly what it took. Then keep the list running from today, one line per request, shared in the same place the client sees the project state. The list does the persuading that tone never can. Five small lines are a pattern anyone can see, including the client, who in most cases genuinely did not notice the pile growing. Do not present the list as an ambush or a bill for the past. Present it as the project's change log, starting now, so both sides are looking at the same project.

Step 2. Sort each new request against the agreed scope, in one sentence

For each new ask, answer with the sort before anything else: that is inside the agreed scope, or that is an addition. One sentence, no lecture: happy to do it, it sits outside the pages we agreed, so it goes on the extras list with a price. The sort only works if the agreed scope itself is written down somewhere both sides can point at. If it is not, write the baseline now from the proposal and the work so far, and get it accepted before the next addition arrives. Most included arguments are really missing baseline arguments: there is no shared list of what the price bought, so every task looks arguably included.

Step 3. Price the extras as a batch, on a rhythm, not one coin at a time

Quoting every fifteen minute task on its own feels petty and trains the client to argue line by line. Instead, let the extras list collect, and price it as one batch at a natural point: at the next stage boundary, or when the pile reaches a size you name in advance. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the two states a batch can sit in:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, is a batch the client has seen, checked, and agreed to pay for. A pending record, 5 of 5 steps checked and release_hint hold, is a batch sitting in the open waiting for a decision, visible to both sides, with no work started on it yet. That pending state is the whole method: additions accumulate in the open, priced, and nothing in the batch starts until the state flips to accepted. The client keeps control of the spend. You keep control of your hours.

Step 4. Offer the swap when the budget truly cannot grow

Sometimes included means the budget is fixed and the client knows it. Then the honest answer to an addition is a trade: we can add this if we drop or defer that, and here is what moves. Put the swap in the same extras list, with the dropped item named. A swap respects a real budget without quietly expanding your workload, and it forces the priority conversation clients avoid: everything is important is not a priority order. If nothing can be dropped and nothing can be paid, the addition is a request for free work, and it is better for both sides when that is said plainly and early, while the relationship can still survive the sentence.

Step 5. Use the sentence that ends the pattern without ending the relationship

When the next small task arrives, the whole reply is: of course, adding it to the extras list, the batch is at this amount and I will send it for your decision on Friday, or sooner if you want this one started now. Warm, short, identical every time. The consistency is the boundary. A client who learns that every addition lands on a visible list with a price attached starts sorting their own requests before sending them, which is the actual goal. You are not trying to bill more. You are trying to make the project's real size a shared fact, so the price and the work can match again.

Step 6. Write the additions rule into the next agreement

One clause does most of this work next time: the price covers the listed deliverables, additions are logged as they arrive, priced in batches at stage boundaries, and start only when accepted in writing. Add the two numbers clients actually ask about: how revision rounds are counted, since half of all small tasks are revisions in disguise, and what counts as a new task versus a fix of work already accepted. Fixes of your own errors are yours, always, and saying so in the clause is what makes the rest of it credible. Clients respect a boundary that visibly runs in both directions.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not decide whether a given task was inside your agreed scope, does not set the price of an addition, and cannot make a client accept a batch. The written baseline, the dated extras list, and the acceptance states are what the conversation stands on. This page is general information, not legal advice.

Frequently asked questions

My client keeps adding small extra tasks and says they should be included in the price. How do I stop it?

Stop it by making additions visible and decided, one by one, instead of absorbed. Keep a shared extras list with a dated line for every request outside the agreed scope. Sort each new ask in one sentence, inside the scope or an addition, and let additions collect on the list, priced as one batch at the next stage boundary. Nothing in the batch starts until the client accepts it. When the budget is fixed, offer a swap: the new task comes in, a named agreed task goes out or moves later. Said warmly and identically every time, this ends the pattern without a confrontation, because the client starts seeing the pile at the same time you do, and the word included has to survive contact with a written baseline.

Were the small tasks I already did for free just lost money?

Mostly treat them as tuition, with one exception. Going back and billing a pile of extras the client never agreed to pay for, after you silently did them, rarely collects and usually costs the relationship. The list still matters: write the absorbed tasks down with dates and show the list once, as the reason the new system starts today, not as an invoice for the past. The exception is a task you flagged as extra at the time and the client told you to proceed anyway; that one was decided, and it belongs in the next batch with the date of that decision beside it. From today, nothing is absorbed silently, and that is where the money stops leaking.

How do I tell what counts as included and what counts as extra?

Measure against the written baseline: the deliverables the price bought, named as outputs, not as effort. A new output, a new audience, a new format, or work on something already accepted and closed is an addition. A fix to your own work that does not do what was agreed is yours to repair free, and saying so out loud is what makes your extras credible. When a request is genuinely arguable, name it arguable, price it small, and let the client decide; the decision itself becomes the precedent for the next gray case. The arguments happen when there is no baseline to measure against, so if yours is missing, writing it and getting it accepted is step zero.

What if the client gets annoyed and says other people just do these things?

Let them check the arithmetic instead of debating the custom. The extras list shows every request, its date, and its price as a batch, and the swap option shows you are not holding the project hostage: fixed budget, named trade, their choice. Some clients do leave over a boundary like this, and it is worth being honest about the trade: a client who only stays while the extras are free is buying your hours at a discount you never agreed to, and the hours come out of clients who pay for theirs. Most reasonable clients, shown the pile they had not noticed, adjust quickly, because the list is obviously fair and they can see their own requests on it.

How do I keep additions and acceptances on one record?

Run the project in stages and batches that live on a record the client opens: the agreed baseline, each addition with its date, and an accept decision with a name and a date before batch work starts. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and a batch waiting on the client shows as pending instead of dissolving into chat. New users get 20 free calls per day, then they upgrade when the job needs more. For $0.99, run the next project that way and let the extras list carry itself: get the Day Pass. A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related