People spend hours refining prompts and minutes on the brief. It's backwards.
A prompt tells the model what to do. A brief tells it what it's making, who for, what it must contain, and what position it takes. The first is a delivery mechanism. The second is where the quality is decided — and no amount of prompt engineering rescues a piece that was never specified properly.
Eight inputs. Here they are, with a worked example.
The short version
| Input | What it prevents |
|---|---|
| 1. Reader and situation | Generic content addressed to nobody |
| 2. The question it answers | A survey of a topic instead of an answer |
| 3. Your position | Hedged, both-sides mush |
| 4. Source material | Invented facts |
| 5. What must appear | Missing the point you cared about |
| 6. What must not appear | Padding and clichés |
| 7. Structure | The default AI shape |
| 8. Voice reference | A model's register instead of yours |
Missing 3, 4, and 8 causes most of the disappointment.
1 — The reader, specifically
Not "small business owners." Somebody with a situation.
Weak: "for marketers"
Strong: "for a solo consultant whose client's emails started landing in spam last week, who has some technical confidence but has never touched a DNS record"
The specificity does real work. It sets the assumed knowledge, the tone, the urgency, and how much explanation each concept needs. Given only "for marketers," the model writes for an average marketer who doesn't exist.
2 — The question it answers
One question, phrased as a reader would ask it.
Weak: "an article about email authentication"
Strong: "why do my emails still go to spam when SPF and DKIM both pass?"
A topic produces a survey. A question produces an answer — and answers are what people search for and what gets quoted.
The test: could someone read the first paragraph and know whether this piece is for them? If your brief specifies a topic rather than a question, they can't.
3 — Your position
The input that most reliably separates useful output from filler.
Models hedge by default. They're trained toward consensus, so absent instruction they'll survey the possibilities and decline to conclude.
Weak: "discuss whether AI content ranks"
Strong: "argue that the human/AI distinction is the wrong frame — what predicts ranking is whether a page offers something a summary can't replace. Google's own guidance and the Ahrefs data both support this."
Write the position as a sentence you'd defend in an argument. If you can't, you may not be ready to write the piece — and that's useful to discover at the brief stage rather than after 1,500 words.
4 — Source material
The input that prevents invented facts.
Include everything you want it to draw on: your own data, quotes from sources you've verified, links to material you've read, notes from client work, relevant numbers.
And state the constraint explicitly: "Use only the sources provided. If a claim needs a statistic I haven't given you, flag it rather than supplying one."
That instruction genuinely helps. Models will flag gaps when told that's preferable to filling them — and a flagged gap is something you can fix, while a fabricated statistic is something you might not catch. The checking pass.
5 — What must appear
The specific things you'd be annoyed to find missing.
- A particular example or case
- A distinction you think matters
- A caveat that keeps the piece honest
- Your own data point
- A specific internal link
Why this matters: the model doesn't know which points you care about. Left to itself it produces the standard coverage, and the one insight that made the piece worth writing gets averaged out.
6 — What must not appear
Equally useful, and rarely specified.
Content exclusions: claims you can't support, competitor comparisons you'd rather avoid, advice outside your expertise.
Structural exclusions — the ones that fix the AI shape:
- No "in today's fast-paced digital landscape"
- No section restating the introduction
- No lists where every item is exactly three
- No "it's important to note that"
- No conclusion that summarises what was just said
Specifying what to avoid is often more effective than specifying what to do, because the defaults are strong and you're overriding them explicitly.
7 — Structure
Give it the actual shape.
Weak: "around 2,000 words with headings"
Strong: the H2s you want, in order, with a rough length for each.
Two benefits. You catch structural problems before drafting rather than after. And it prevents the uniform sectioning that's the most visible tell of unedited AI output — real articles have a 400-word section next to an 80-word one, because some points need more room.
Vary the lengths deliberately in the brief. It won't do it on its own.
8 — Voice reference
Style descriptions don't transfer voice. Examples do.
Weak: "conversational and authoritative"
Strong: two or three pieces of your own past writing, pasted in, with "match the rhythm, sentence length variation, and directness of these."
Build this once. A reference set of your best three pieces, reused across every brief, costs you nothing after the first time.
A worked brief
Piece: Why authenticated emails still land in spam
1. Reader: A marketing manager at a 30-person SaaS company. Set up SPF, DKIM, and DMARC six months ago following a checklist. Emails are still going to spam and they don't know why. Comfortable with technical concepts, has DNS access but doesn't use it daily. Frustrated, and suspicious that they've been sold a myth.
2. Question: Why do my emails go to spam when authentication passes?
3. Position: Authentication proves identity, not desirability. It's the price of admission, not the thing that gets you seated. The two factors that actually decide placement are list quality and sending behaviour — and the specific technical trap worth checking first is DMARC alignment, which fails while SPF and DKIM both pass.
4. Sources: [Google's sender guidelines, linked] · [my Deliverability Playbook Ch. 4, pasted] · complaint thresholds 0.1% and 0.3% from Google's published guidance. Use only these. Flag any claim needing a statistic I haven't supplied.
5. Must include: The alignment trap explained concretely, with the ESP-signs-under-its-own-domain example. The symptom-to-cause table. Internal links to /blog/email-authentication and /blog/email-list-building.
6. Must not include: No "in today's digital landscape." No section summarising the introduction. No claim that any specific ESP has better deliverability. Don't hedge the central argument.
7. Structure:
- Opening — the frustration, named directly (~150 words)
- What authentication actually proves (~400)
- The alignment trap (~350)
- The three factors deciding placement (~600)
- Symptom-to-cause table
- The fix order (~400)
- FAQ (4 questions, 40–55 words each)
8. Voice: Match [pasted: two of my previous articles]. Short paragraphs, occasional one-line emphasis, direct, no throat-clearing.
That's roughly ten minutes to write and it produces something you can edit rather than rewrite.
How long should a brief be?
Proportional to the piece, and shorter than you'd think. The example above is around 300 words for a 3,000-word article.
What makes it long is source material, which is fine — you're pasting, not writing.
What makes it good is specificity, not length. Three precise sentences about the reader beat two paragraphs of general description.
One efficiency: most of a brief is reusable. Reader profiles, voice references, and the exclusions list stay constant across a site. Build them once, and each new brief is really only inputs 2, 3, 4, 5, and 7.
Does a brief replace an outline?
No — the brief produces the outline.
Sequence: brief → outline → review the outline → draft section by section against the approved outline.
Reviewing the outline before drafting is the cheapest correction point you have. Fixing a structural problem at outline stage takes two minutes; fixing it after 2,000 words takes an hour.
Frequently asked questions
What goes in a content brief?
Eight inputs: the specific reader and their situation, the single question the piece answers, your position on it, the source material it must draw on, what must appear, what must not appear, the structure with rough section lengths, and voice reference examples. The three most often missing — and most responsible for disappointing output — are your position, the source material, and the voice examples.
How long should a brief be?
Shorter than most people expect. Around 300 words of actual instruction is enough for a 3,000-word article, plus whatever source material you're pasting in. Specificity matters far more than length — three precise sentences about the reader outperform two vague paragraphs. Most of a brief is also reusable, since reader profiles, voice references, and exclusion lists stay constant across your site.
Does a brief replace an outline?
No — the brief produces the outline. Work in sequence: brief, then outline, then review and correct the outline, then draft section by section against it. Reviewing at outline stage is the cheapest correction point in the whole process, because fixing a structural problem there takes two minutes while fixing it after 2,000 words of drafting takes an hour.
What to do next
Take the piece you're planning next and write just input 3: your position, as a sentence you'd defend in an argument.
If it comes easily, you're ready to write and the rest of the brief will take ten minutes.
If it doesn't, that's the most valuable thing you'll learn today — because a piece without a position produces a survey, and surveys are exactly what a model can generate without you.
Free: The content brief template.
Related guides
- AI content production without the slop — the full workflow
- Fact-checking AI output — verifying what comes back
- How to make AI writing sound like you — input 8 in detail
- Keyword research — choosing what to brief in the first place
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
What Marketing Automation Actually Costs at Scale
Nobody's automation bill jumps because they added more automations. It jumps because they added steps to workflows that were already running — a filter here, an enrichment lookup there, a second notification — and the billing model charges for every one of them, on every run. That's the mechanic behind almost every "why did this […]
One Workflow, Three Tools: A Build Comparison
Feature tables don't tell you what a tool is like to use. The only thing that does is building the same thing twice and noticing where you got annoyed. So here's one realistic workflow — lead routing with enrichment and conditional assignment — specified once and mapped across Zapier, Make, and n8n. What changes between […]
GoHighLevel: 7 Automation Workflows to Build First
GoHighLevel gives you a hundred things you could automate, which is exactly why most accounts end up with forty half-built workflows and no measurable result. Seven are worth building first. They're the ones tied directly to revenue — catching leads before they cool, recovering appointments that would otherwise vanish, and asking for reviews at the […]