Briefing AI the Way You’d Brief a Good Freelancer

There’s a version of this job where you spend six months collecting prompt techniques. Chain-of-thought. Few-shot examples. Role assignment. “You are a world-class B2B content strategist with 20 years of experience.” I’ve watched content leads build Notion databases of these things, tagged and rated, and still ship drafts that read like a competitor’s blog from 2021 run through a thesaurus.

The techniques aren’t fake. They’re just fighting for a few percent at the margins while the thing that actually determines output quality sits untouched. That thing is the brief.

Here’s the test I use with teams who ask me how to brief AI for writing: take the prompt you’re about to send to Claude or ChatGPT, strip the “act as” line and the formatting instructions, and email what’s left to a freelance writer you rate at £450 a day. Would they accept the job? Or would they reply within the hour asking six questions?

If they’d ask questions, the model won’t. It’ll guess. And its guesses average out to the mean of everything ever written on your topic, which is precisely the generic output you’re trying to avoid.

What a good freelancer actually needs

I ran a small test on this in March with a four-person content team at a UK fintech. Same topic, same model (Claude Opus), same writer doing the editing. Two briefs.

Brief A was the prompt they’d been using: topic, keyword, word count, tone (“professional but approachable”), three competitor URLs to “beat”.

Brief B had five things in it. Audience state. The argument. Out of scope. Sources. Proof.

Brief A’s draft took 2 hours 40 minutes of editing to reach publishable. Brief B’s took 35 minutes. Same writer, same standard, measured with a timer because I didn’t trust anyone’s estimate including my own. The interesting part wasn’t the time saved, it was what the editing consisted of: Brief A’s edits were almost entirely adding things the draft didn’t know. Brief B’s were line-level.

Those five components are worth being precise about, because “write a better brief” is advice nobody can act on.

Audience state. Not a persona. A persona tells you someone is called Marketing Martha, is 34, and enjoys podcasts. Useless. Audience state is what the reader currently believes, what they’ve already tried, and what they’re about to do. “Head of content at a 40-person SaaS company. Has already tried AI for first drafts and been disappointed. Currently believes the output problem is a model problem and is considering whether to pay for a better model. Will make a tooling decision in the next quarter.” That’s a brief a human can write from. The model can too.

The argument. One sentence, stated as a claim someone could disagree with. Not “explain the benefits of X”. If you can’t write the argument, you don’t have an article, you have a topic, and no amount of briefing will save it. This is the single highest-leverage line in the whole document and it’s the one most often missing.

Out of scope. Explicitly listed. Models pad. Left alone, a piece on briefing will grow a section on prompt engineering basics, a section on which model to choose, and a paragraph about how AI is changing everything. Every one of those is a paragraph you’ll delete. Naming them upfront costs you thirty seconds and saves you the deletion plus the risk that a tired editor leaves one in.

The sources. Actual URLs, actual PDFs, actual pasted transcripts. Not “research this topic”. When you tell a model to research, it reconstructs plausible-sounding claims from training data, and roughly one in five of those will be subtly wrong in a way that survives a casual read.

The proof. Your numbers. Your customer quotes. The thing the model cannot invent because it doesn’t have access to it. This is the only part of the article that can’t be reproduced by a competitor running the same prompt, and it’s where the entire competitive value of the piece lives.

A worked example

Here’s a real brief, lightly anonymised, that produced a 1,400-word piece needing about 20 minutes of editing.

ARGUMENT
Most warehouse ops teams measure pick accuracy at the wrong point in
the process (at dispatch, not at pick confirmation), which is why
their error rates look fine and their returns don't.

AUDIENCE STATE
Ops manager, 3PL or in-house fulfilment, 15-80 warehouse staff.
Already tracks pick accuracy and reports it monthly. Believes their
number (typically 99.2-99.6%) is healthy. Has a rising returns rate
they currently attribute to customer behaviour or courier damage.
Is not looking for new software. Is looking for a diagnosis.

OUT OF SCOPE
- Anything about WMS selection or vendor comparison
- General "why accuracy matters" framing (they know)
- Robotics, automation, AI in the warehouse
- Definitions of basic terms (SKU, pick path, wave picking)

SOURCES (use only these; do not add statistics from memory)
- [attached] Our 2025 client benchmark PDF, pp. 12-18
- [attached] Transcript, interview with James H. (ops director,
  client, 41 mins)
- https://www.gov.uk/... [ONS retail returns data]

PROOF TO USE
- 14 of our 31 benchmark clients measure at dispatch only
- Those 14 average 4.1pp higher returns rate than the 17 who
  measure at pick confirmation
- James H. quote at 22:14 in transcript re: "we were measuring
  the wrong end of the process for four years"

STRUCTURE
Open with the measurement gap, not with the returns problem.
The returns problem is the payoff, not the hook.

DO NOT
Do not soften the argument with "of course, every warehouse is
different". Commit to the claim.

Note what’s not in there. No “you are an expert copywriter”. No tone adjective. No “make it engaging”. The tone comes from the argument being specific and the constraints being tight. A confident brief produces a confident draft, more or less mechanically.

Note also the “use only these” line on sources. That instruction, plus attaching the actual documents, is what stops the fabricated-statistic problem. It doesn’t stop it completely. You still check. But the failure rate drops sharply, and the failures become obvious rather than plausible.

Where the time actually goes

The objection I get, every time, is that this takes longer than writing the thing yourself. Sometimes it does. Here’s a rough breakdown from the fintech team’s second month, averaged across 11 pieces of 1,200 to 1,800 words:

Half the time, and the half that remains is the half worth doing. The 45 minutes of briefing isn’t wasted effort either: for about a third of the pieces, writing the argument line killed the article. It turned out there wasn’t one. That’s a win you can’t measure but should count.

One more thing that breakdown hides. The full-brief pieces were reusable. A brief with audience state, sources and proof written out can be handed to a freelancer, a junior writer, or a different model, and it works. A thin prompt is only ever a thin prompt.

The bits that go wrong

Briefs fail in predictable ways once teams start writing them properly.

The most common: the argument is actually a topic wearing a disguise. “The importance of first-party data” is a topic. “Most first-party data programmes fail because they’re built by the analytics team rather than the people who’ll use the output” is an argument. If the sentence contains “the importance of”, “a guide to”, or “everything you need to know”, rewrite it.

Second: proof that isn’t proof. Publicly available statistics that any competitor can cite are context, not proof. If your only numbers came from a Statista page, the piece has no moat. Go and get one internal number, even a scrappy one. “We looked at our last 60 onboarding calls and 38 of them mentioned the same thing” is worth more than a well-sourced industry figure, because nobody else can write that sentence.

Third, and this one’s subtle: over-specified structure. If you dictate the H2s, you get an article that follows your outline and says nothing you didn’t already know, because you wrote the outline from what you already knew. Give the opening move and the argument, let the model find the middle, then restructure in editing. You’ll get one or two framings you wouldn’t have reached.

Teams that get good at this tend to arrive at a shared brief template inside a month, usually living in Notion or Airtable, with the five fields as required and everything else optional. The template matters less than the discipline of not skipping a field because you’re in a hurry. The field you skip is the field the model guesses at.

Fitting it to the rest of the workflow

Briefing sits at the front of a chain, and it doesn’t fix everything downstream of it. A strong brief gets you a structurally sound draft with the right argument and real evidence in it. It does not get you brand voice, which is a separate problem solved with style guides and reference documents, nor does it replace the editing pass where a human decides what to cut. If you want the fuller picture of how briefing, voice calibration and editing fit together as one system, the drafting, brand voice and editing workflows pillar covers the stages either side of this one.

What briefing does do is change what editing is for. When the brief is thin, editing means research, fact-checking, restructuring and rewriting, all at once, by one person, usually at 4pm. When the brief is strong, editing means voice, cuts and the last 10% of polish. Those are different jobs requiring different amounts of energy, and only one of them is sustainable at four pieces a week.

Try this on the next thing you commission. Write the brief as though you’re paying someone £450 a day to execute it, then send that brief to the model instead. Keep a timer running on the edit. The number that comes back will tell you more about your AI workflow than any prompt library ever will.