Asking for changes after delivery without starting over

The short answer

What you can ask for, and how, depends on two things: whether the order is still open, and whether the thing you want was in the brief.

While a regular order sits in Delivered, you have three days to accept, request a revision or ask for more time, and you can extend the review by up to five days. Anything that does not match the brief belongs in a revision then. Once the order completes, revisions are gone. From there, a problem with what was promised is a fix under whatever maintenance terms you agreed, and something new is a change: ask the freelancer for a custom offer in the inbox. It is a small new order, not a new project.

Whichever it is, write the request so the freelancer knows what must stay the same. That one line prevents most of the trouble.

The window you have on Fiverr

Order status	What you can do	Source
Delivered, within three days	Accept, request a revision, or ask for more review time	Fiverr help center
Review extended	Up to five extra days to test	Fiverr help center
No action after three days	The order completes automatically	Fiverr help center
Completed	No revision or cancellation through the order; message the freelancer, who can send a custom offer	Fiverr help center

How many revisions you get depends on the gig package or the scope you agreed in the offer. Milestone orders review each stage separately; fixed price or milestones explains how.

Revision, fix or change

Most arguments after delivery come from calling one of these by the wrong name.

If you are unsure, read your brief out loud. If the sentence is in there, it is a revision or a fix. If it is not, it is a change, and paying for it keeps the relationship good for the next one.

For a chatbot, the line is blurrier: tuning answers against real questions is part of the work, and new topics are a change. Agree in the offer what counts as tuning, and see checking chatbot milestones for how to test each round.

Why a small change breaks something else

A change request is risky in a way the original order was not: the thing already works, and the change touches only one part of it. The parts it does not mention are the ones that break.

I have done this to my own setup. I changed the format of the content my publishing pipeline produces. The nightly job that prepares items was switched to pick up the new format, but its render step still called the renderers for the old one. Every new item failed to render and was left out of the queue, so from the 21 slot on September 13 the publisher found nothing to post, until I found it and fixed it the next day (the full note). The change itself was correct. The part downstream of it was never told.

A second one, smaller: a step in a content queue of mine that updated each item’s status rewrote the whole cell, and erased the open questions another step had written into it. The step did its own job exactly as designed, and wiped someone else’s.

Both are the same lesson. A change request has to name what must keep working, and the test after the change has to cover the whole chain, not only the part that changed. Why an AI-built app breaks every time you change it goes further for apps.

A change request you can copy

Send this in the inbox. If the order is completed, ask for a custom offer at the end.

I’d like one change to what you delivered.

1. Now: [what it does today, with one real example].
2. Wanted: [what it should do instead, with the same example].
3. Must not change: [the parts that must keep working, e.g. the schedule, the existing channel, the format of the sheet].
4. How I’ll test it: [the check you will run, e.g. three scheduled runs, or these five questions to the chatbot].
5. Where it lives: the change goes into my [repository / workflow account], with a one-line note of what was changed.

Could you send a custom offer for this, or tell me if you see it as part of the original scope?

Line 3 is the one most buyers leave out. Line 4 gives you the same acceptance test the original order had; the acceptance checklist is a good source of tests to reuse. For an AI-built app, the AI coding brief already asks for a note per fix; ask for the same with every change.

Going back to the same freelancer is usually cheaper

In my own orders, asking for changes after delivery has been routine, not a sign that something went wrong. I have not used the review extension myself; it matters most when the delivery is a scheduled job that has to run a few times before you can judge it. When I went back to the same freelancer for a second order, the conversation was shorter: no sizing each other up, no explaining the basics again. A change request is the cleanest version of that. Once a project is built, I keep using the same developer, because maintenance work follows. Going back to the same seller covers when that is the right call.

On Fiverr, a buyer who does not see the right package on the gig can use Request a Quote to ask for a custom offer, and you can accept, decline or ask for changes to the offer before paying. Check the offer the same way as the first one: scope matches your request, delivery time leaves room to test, and the revision count fits. What to check in a custom offer has the full list.

Where it goes wrong anyway

• The three days ran out while you were busy. It happens. The work is not lost; it just moves from revision to fix or change. Be honest about which one it is when you message.
• Every change is called a fix, or every fix a change. Go back to the brief. If the brief is vague, agree the difference in writing now, for next time.
• A stack of small changes. Five one-line requests in a week cost more than one batched request. Collect them and send one list.

Wrap-up

Test inside the window, and extend it if the job needs a few days to show itself. After that, call the request by its right name: a fix if it broke, a change if you want something new. Write down what must stay the same, reuse the original test, and ask for a custom offer. A change after delivery is then a short order with someone who already knows the project, not a fresh start.