ZAMBO.

Direct answer

Finished is finished. A new change is a new job.

Months after a job closes, a friendly message lands: could you just tweak this, update that, move one thing. Some of it may be yours to fix. Most of it is new work wearing an old job as a disguise. The line between the two is not your generosity and not their memory. It is the record of what was delivered and accepted, plus the support window you stated when the job closed.

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

Updated October 24, 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 from the closed record, not from memory

Open the job as it closed: what was delivered, on what date, and the client acceptance with its date. That record is the whole basis of your answer, because months later both sides remember the job differently and both memories are honestly unreliable. An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, says this exact result was checked and accepted. Anything outside that result starts the conversation as a change, and the burden is not on you to prove it is new. It is on the request to show it was inside what was accepted.

Step 2. Sort the request: defect, change, or something that changed since

Put every item in the request into one of three piles. A defect is the delivered work not doing what was accepted, and it is yours to fix. A change is a different result from the one accepted, new content, new features, a new direction, and it is priced. The third pile is the quiet one: work that was fine at delivery and broke later because a platform updated, a login changed, or someone else edited it. That is repair work, and repair work is priced too, because the cause was not your delivery. Sorting out loud, in the reply itself, is what makes the answer feel fair instead of stubborn.

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record like the first one, closed with its date, is what a months later request gets measured against. A pending record like the second means the job never fully closed, and closing it, with the acceptance and the support line in writing, comes before arguing about any change.

Step 3. Apply the support window you stated at close

If you stated a window at close, hold it exactly, in both directions. A defect reported inside the window gets fixed promptly and without debate; that is what the window was for. A request outside it gets quoted, kindly and without apology. If you never stated a window, do not invent one now and do not accept an unlimited one either. Judge a genuine defect in the delivered work generously this once, quote everything else, and then set the window in writing as part of this job close, so the next request already has its line. The absence of a window is a gap to close today, not a debt that runs forever.

Step 4. Quote the change as a small new stage

Old changes go fastest when they are packaged like any new work: a fixed price or a clear hourly cap, what the change includes, a start date, and a delivery the client accepts on the record when it lands. Bundling three small tweaks into one stage with one acceptance beats three open ended favors, each with its own follow up thread. Keep the stage small and complete: this change, this price, done by this date. If more wants appear mid stage, they join the next stage, not this one. That shape protects the client too, because they approve a known price for a known result instead of discovering the cost of a casual ask.

Step 5. Send the reply in writing, with the record attached

One message carries the whole answer: the job name and acceptance date, the sort of their request into defect and change, what you will fix at no charge and by when, and the price and date for the rest, quoted as a new stage. Link the accepted delivery record so they can see the closed job for themselves. A client reading their own acceptance rarely argues that everything after it was included. Keep the tone warm and the arithmetic plain. You are not refusing the work. You are refusing to let finished work quietly reopen, which is a different thing, and the record is what shows the difference.

Step 6. Close every job with the line already drawn

The permanent fix costs one paragraph at close. Every final delivery from now on ends with the acceptance on the record and a closing line: defects in this delivered work are covered for a stated number of days from acceptance, and changes after that are quoted as new stages. Clients sign off on that line without blinking when the work is fresh and they are happy, which is exactly when to set it. The next months later message then answers itself: you point at the closing line both sides already hold, sort the request, and quote the change. No debate about what free means, because free was defined on the day the job closed.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the delivered work was right, does not decide whether a request is a defect or a change, and cannot set a support window you never stated. The acceptance record, the closing line, and the dated request are what you would show anyone asked to judge where free ends. This page is general information, not legal advice.

Frequently asked questions

A client I finished work for months ago just asked for changes. Are old changes free?

No, not by default. Work you finished and the client accepted months ago is a closed job, and a change asked for now is new work, priced and scheduled as new work. The line is the closed acceptance record plus any support window you stated when the job closed. Inside that window, fixing a defect in what you delivered is yours to fix at no charge. Outside the window, or any change to what was agreed, a different result, new content, new features, or fixes caused by something that changed since delivery, it is a new small job with its own price and its own acceptance. Reply from the record, not from memory: name the date the work was accepted, restate what was delivered, sort the request into defect or change, and quote the change as its own stage with a start date. Old work stays finished. New wants get a new price.

What is the difference between a defect and a change in finished work?

A defect is the delivered work failing to do what was agreed and accepted: a broken link in the delivered site, a file that does not open, a result that does not match the accepted version. That is yours to fix. A change is the client wanting something different from what was agreed: new wording, a new page, a different layout, updated prices, or the same work redone because their business moved on. The test is one question: would fixing this restore the accepted result, or create a different one? Restore is a defect. Different is a change, and changes are priced, however small they look.

How long should a support window be, and what should it cover?

A short, stated window works for most freelance work: 14 to 30 days from acceptance for defects in the work as delivered. State it at close, in the same message that delivers the final record: what counts as a defect, how long the window runs, and how to report a problem inside it. The window covers the work as it was when it was accepted, in the conditions it was accepted in. It does not cover new requests, later edits by someone else, or things that broke because a platform or a third party changed after delivery. An unstated window is the problem, not a short one: with no line written down, every later request becomes a negotiation about what free means.

How do I reply to a months-later change request without sounding difficult?

Answer warmly, from the record, in one short message. Thank them, name the job and the date it was accepted, and say the delivered work is closed on the record. Then sort their request in their own words: this part is a defect in the delivered work and you will fix it at no charge if it falls in the terms you set, or this part is a change from what was delivered, so here is a price and a date for it as a small new stage. Attach or link the accepted record so the line is visible, not argued. Clients rarely object to paying for a change when they can see exactly what they already accepted. They object to a bare no, and to a vague yes that turns into unpaid weeks.

How do I close a job so the line on later changes already exists?

Close with three things in one place: the final delivery, the client acceptance on the record with its date, and one closing line that states the support window and that later changes are quoted as new stages. 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 new users get 20 free calls per day, then they upgrade when the job needs more. For $0.99, run the next job that way: get the Day Pass. A Day Pass covers 24 hours. Ongoing use is the Zambo Pass at $29 for 30 days (one payment) or $290 for 365 days, and $19 for 30 days for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related