What to check in a Fiverr custom offer before you accept

The short answer

A custom offer is the moment your conversation becomes an order. Whatever the seller agreed in messages only binds the order if it is in the offer or in the thread you can point to later. So before you click Accept, read the offer against your brief, line by line.

Every order I have placed on Fiverr went through a custom offer, so this is the screen where my jobs actually became orders.

For an automation or AI job, check seven things: the scope matches the brief, the delivery time leaves room for your acceptance test, the revision count fits the work, the price makes sense for the size, milestones end in tests, the missing pieces (accounts, hand-over, maintenance) are agreed in writing, and the expiry is not pushing you into skipping all of this. If anything is off, use Ask for Changes. It costs a day, not a dispute.

What a custom offer contains

According to Fiverr’s help center (checked September 2026), a seller builds a custom offer from one of their gigs and sets:

Field	What the seller can set	What to look at
Description	The scope, in their words	Does it match your brief?
Price	$5 to $20,000	Sensible for the size of the job?
Delivery time	1 to 90 days	Room for your acceptance test?
Revisions	0 to 20, or unlimited	Enough for the kind of work?
Milestones	Optional, the work split into stages	Does each stage end in a test?
Expiry	Optional date	Time to read it properly?

The help center also notes that sellers can skip the gig’s usual requirements form in a custom offer. That form is often where a gig asks for your inputs and access, so if it is skipped, make sure that information is already in your messages.

As a buyer you have three buttons: Accept, Decline or Ask for Changes. The seller can withdraw the offer until you accept it or it expires.

The seven checks

1. Scope: the description matches your brief. Offer descriptions are often one or two lines. That is fine if it points to the brief (“as described in the brief in our messages on [date]”). It is not fine if it describes a smaller job than the one you asked for. Look for your goal sentence, the trigger, the tools and the output. If the offer says “Zapier automation” and your brief says “two workflows with a failure alert”, ask for the description to say so.

2. Delivery time: room for acceptance. An automation cannot be accepted on the day it is delivered. The acceptance checklist asks for three unattended runs on the real schedule, one forced failure and a duplicate test, which takes days. Also remember that duration on Fiverr runs from order to completion, including time the seller waits for you. If the delivery date assumes you reply within the hour, it will slip.

3. Revisions: the right number for the work. A fixed revision count suits a well-defined workflow. For a chatbot, where answers are tuned against real questions, a low number can run out before the bot is right. Agree in the messages what counts as a revision (it does not yet do what the brief says) and what counts as new work (it should now do something else).

4. Price: in line with the size. In the 317 automation reviews I read, 29% of orders were under $100, 39% were $100 to $400, 21% were $400 to $1,000, and 12% were over $1,000. Orders under $100 were mostly fixes and small additions. If your brief describes one workflow and the offer is well over $1,000, ask what is in it. If it describes a process across several tools and the offer is very low, the seller may not have read it. The pricing guide covers what moves the number.

5. Milestones: each one ends in a test. If the offer is split into stages, you are charged for each one as you approve the previous one and move on. So each stage should end in something you can run yourself, with a pass mark agreed before you approve. “Week 1, week 2” is a payment plan, not a milestone. The fixed price or milestones guide has a line to copy per stage.

6. What the offer does not say. A custom offer has no field for who owns the accounts, what the hand-over includes or who fixes it next month. Those belong in the messages, confirmed by the seller before you accept:

• the automation runs on accounts and keys you own
• delivery includes the workflow export or repository and a short run-book
• how fixes work after delivery, at what rate (the maintenance guide has six lines)

7. Expiry: a deadline to read, not to skip reading. An expiry date is optional for the seller. If the offer expires before you have checked it, ask for it to be sent again; that is a normal request. What you should not do is accept an offer unread because the clock is running.

A checklist to keep open next to the offer

When something is off: a reply you can copy

Use Ask for Changes, or reply in the thread, with the specific lines:

Thanks for the offer. Before I accept, could you adjust two things?

1. Please add to the description: “[goal sentence] — as in my brief of [date], including the failure alert.”
2. Could the delivery be [N] days, so I can run three scheduled tests before accepting? Also confirming what we agreed in messages: it runs on my accounts, delivery includes the export and a run-book, and fixes in the first 30 days are included.

Keep it short and concrete. A seller who already agreed these points in messages will usually resend the offer the same day. If you have not sent a brief yet, start there: the workflow automation brief has the fields, and the seller’s offer will be easier to check against it.

Where it goes wrong

• Accepting the first offer because it arrived quickly. Fast is good. Fast and missing half the scope is a revision argument waiting to happen.
• Agreeing things only on a call. If it is not in the offer or the message thread, it is hard to point to later.
• Treating the offer as the brief. The offer is a summary. Your brief is the detail. Link the two by date so both sides know which one decides.

Wrap-up

A custom offer is short by design. Your job is to make sure it points at the right, longer thing: your brief, your acceptance test, and the terms you agreed in messages. Read it against the seven checks, ask for changes when a line is missing, and accept only the version that matches what you will test.