The brief an automation freelancer can quote from

The short answer

A good brief is one two sellers would quote the same way. That takes nine fields: goal, trigger, inputs, output, rules, failure behaviour, hand-over, acceptance and maintenance. The workflow automation page has them as a copyable template. This guide explains what to write in each, and where briefs go wrong.

I write briefs most days, not to freelancers but to an AI coding tool that builds my own automations. The failures are the same: the tool, like a seller, builds exactly what the brief says. Every mistake below is one I made.

Why this matters more now

Some sellers on Fiverr now say in their gigs that they build with AI coding tools such as Claude Code or Cursor, and more will. That makes them fast, and it makes the brief more important, not less. A person reading a vague brief asks questions. A person working fast with an AI tool is more likely to fill the gaps with a reasonable guess, and it will look finished.

A quote is also only as accurate as the brief. “Automate our reporting” can honestly be quoted at a small fixed price or as a large project, because the two sellers are guessing at different jobs.

A vague brief gets quotes for different jobs

Illustration: the same request, sent to two sellers.

"Automate our reporting"

Seller A guesses one small report→small fixed price

Seller B guesses a whole reporting system→large project

"Weekly sales figures in the team sheet every Monday by 9am"

Both sellers read the same job→quotes close together ✓

The nine fields

The nine fields on one page

Fields 1–5 describe the job. Fields 6–9 say what happens after it is built.

1. GoalOne sentence you can check yes or no
2. TriggerWhat starts a run, how often
3. InputsExact sources, whose logins, real examples
4. OutputWhere it goes, an example of it
5. Rules3–5 decisions, an example each
6. FailureRetry, skip or stop, and who is told
7. Hand-overExport, your accounts, a run-book
8. AcceptanceThe tests before you pay
9. MaintenanceWho fixes it later, at what rate

1. Goal: one measurable sentence. “The weekly sales figures are in the team sheet every Monday by 9am.” Not “better reporting”. This sentence becomes the acceptance test, so write it as something you could check with a yes or no. If you are not sure which task to start with, what to automate first has three tests.

2. Trigger: what starts a run. A schedule, an incoming email, a form submission, a file landing in a folder. Say how often, and what should happen if two arrive at once.

3. Inputs: exact sources, and who owns the logins. Not “our CRM” but which CRM, which fields, and whose account. Attach a real example of each input.

4. Output: where the result goes and what it looks like. A row in a sheet, a message in a channel, a file in a folder. Attach an example of the finished output, even a mock-up by hand. Include how it will be opened: my tool once built me a spreadsheet whose numbers were all correct and which would not open in Excel, because one text cell began with an equals sign. “Opens in Excel without errors” belonged in the brief.

5. Rules: the three to five decisions, each with an example. Every “then I decide whether…” in the task becomes a rule here. “If the order is over $500, flag it to the manager. Example: order 1234, $720, flagged.” Examples settle what words cannot.

A rule is a decision plus one real example

If the order is over $500→flag it to the manager→Example: order 1234, $720, flagged ✓

6. Failure behaviour: what happens when a step fails. Retry, skip, stop, and who gets told. Most briefs leave this out, which is why most automations fail silently. The acceptance checklist shows what silent failure looks like.

7. Hand-over: what you receive. The workflow export or code in your repository, credentials in your accounts, and a short run-book: how to restart it and where the logs are.

8. Acceptance: how you will decide to pay. For example: three unattended scheduled runs, one forced failure that alerts you, one duplicate-run test. Writing this before the quote changes the quote, and it should.

9. Maintenance: who fixes it later. Rate, response time and length of the terms. Put maintenance in the contract has six lines to agree.

A filled-in example

Here is the brief for a small, common job, written the way I would send it:

Goal. Every new website enquiry is in our CRM, assigned to a salesperson, within five minutes.

Trigger. A new submission of the contact form on our site (about 40 a week; sometimes two arrive in the same minute).

Inputs. The form tool’s submissions (my account), the CRM (my account). Example submission attached.

Output. A new contact and a new deal in the CRM, with the message in the notes. Screenshot of a correct record attached.

Rules. 1) If the email already exists, add a note to the existing contact instead of creating a new one. Example: [email protected], existing, note added. 2) If the company field mentions “partner”, assign to the partnerships lead; otherwise rotate between the two sales reps.

Failure behaviour. If the CRM rejects a record, retry once, then email me the submission. Never drop a submission silently.

Hand-over. Workflow export, all connections on my accounts, a one-page run-book.

Acceptance. Five real submissions arrive correctly on their own, one duplicate email is handled by rule 1, and one forced failure emails me.

Maintenance. 30 days of fixes included; a rate for fixes after that, agreed before ordering.

That is about 170 words, and two sellers reading it would quote the same job.

The same brief, field by field

The part of each field a seller can quote from and you can test.

Goal

In the CRM, assigned, within five minutes

Trigger

About 40 a week; sometimes two in the same minute

Inputs

Form tool and CRM, both my accounts; example attached

Output

New contact and deal; screenshot of a correct record

Rules

Duplicate email → note on the existing contact; "partner" → partnerships lead

Failure

Retry once, then email me. Never drop one silently

Hand-over

Workflow export, my accounts, a one-page run-book

Acceptance

5 real submissions, 1 duplicate, 1 forced failure

Maintenance

30 days of fixes; a rate after that, agreed up front

One field people forget: what already exists

If there is a spreadsheet, a half-built workflow, or a page you like, say so and attach it. Otherwise it may be rebuilt from scratch.

I nearly lost a good design this way. I asked my tool to make a page that refreshes with new data. It built a new, plainer page from a blank file, when the page I already had was better and only needed the data slotted in. I had not said “start from this”. Add a line to the brief: “Existing work to build on”, with links.

Where briefs go wrong

• Describing the tool instead of the result. “Build an n8n workflow” is a solution. “New form entries appear in the CRM within five minutes” is the job. Let the seller propose the tool, then ask why; n8n, Make, Zapier or code covers what to ask.
• Hiding the edge cases. The two strange cases a month are where the time goes. Put them in the rules with examples.
• Leaving ownership open. If the brief does not say the accounts are yours, they will often be the seller’s, because that is faster for them.

Three ways a brief goes wrong, and the fix

The tool, not the result

• "Build an n8n workflow"
• "New form entries appear in the CRM within five minutes"

Edge cases hidden

• Only the normal case described
• The two strange cases a month, in the rules, with examples

Ownership left open

• Accounts not mentioned
• "All connections on my accounts"

Wrap-up

Copy the template from the workflow automation page, fill each field with something checkable, attach real examples of the inputs and the output, and add what already exists. Send the same brief to two or three sellers. If the quotes are close, the brief is working. If they are far apart, the brief is still vague; find the field they read differently and tighten it.