A content brief is the document that tells a writer, human or AI, exactly what a piece should accomplish before any drafting begins. A complete brief settles nine things: the intent it serves, the angle that makes it distinct, the audience it speaks to, the points it must cover, the sources behind those points, how it should sound, how it's structured, where it links, and how you'll judge whether it worked. Get the brief right and drafting becomes execution. Get it wrong, or skip it, and even the most fluent draft inherits the vagueness it was given.

Why the brief, not the drafting, is where quality gets decided is the broader case made in editorial planning for AI content: once a model can fill any brief you hand it, the brief sets the ceiling on the output. This piece takes that as given and gets practical: what goes into the document itself, and how to write each part so the draft has nothing left to guess.

What goes into a content brief?

A complete brief answers nine questions. Each one is a decision; every decision you leave blank is one the draft will make for you, usually by reaching for the generic default.

Element	The question it answers
Intent	What does the reader actually want when they arrive?
Angle	Why this piece, and why is it different from what exists?
Audience	Who is reading, and what do they already know?
Must-cover points	What claims must the piece make?
Sources	What evidence backs each claim?
Voice notes	How should it sound?
Structure	What is the order of the argument?
Internal links	How does this connect to the rest of the topic?
Success criteria	How will we know it worked?

You don't need a separate paragraph for each; a tight brief can settle several in a line. What matters is that none are left to chance.

Intent and angle: why the piece exists

Start with the job the reader is doing. Someone searching "how to write a content brief" wants a practical how-to with a template they can reuse, not a meditation on the philosophy of planning. Misread the intent and nothing downstream rescues the piece; the right answer to the wrong question still fails. (Diagnosing this is its own skill, covered in search intent explained.)

The angle is the piece's reason to exist when a dozen articles already cover the topic. It might be a sharper framework, original data, a specific audience the existing results ignore, or simply a clearer explanation than anyone has managed. If you can't state the angle in one sentence, the draft won't have one either. And a piece with no angle is exactly the wallpaper a model writes by default.

Audience and voice: who it's for and how it sounds

Name the reader and what they already know. "Marketing managers evaluating their first content process" and "experienced SEOs auditing an existing one" need different depth, different assumptions, and different vocabulary. Without this, the draft pitches to nobody in particular, which reads as bland to everybody.

Voice notes keep the draft sounding like you rather than like the model's default register. A line or two does it: "plain and direct, no hype; second person; short sentences; explain jargon the first time it appears." You're giving the writer guardrails, not a style bible.

Must-cover points and sources: the substance

Under each part of the structure, name the claims the piece has to make. This is where you transfer the knowledge the model doesn't have: your data, your hard-won opinion, the example only you can give. Spell these out and the draft spends its fluency on your substance rather than improvising padding to fill the gap.

For each point that needs support, name the source: a study, a benchmark, a customer story, a screenshot, a number you can stand behind. Naming sources up front does two jobs: it keeps the draft from fabricating support, and it surfaces the original, verifiable material that earns citations from answer engines. Never let a draft invent a statistic. If there's no source, soften the claim or cut it.

Structure, links, and success criteria

The structure orders the argument so it builds: one idea per heading, headings phrased the way readers actually ask questions where that's natural. A good outline is already a skeleton of the page: a reader skimming the H2s alone should grasp the shape of the answer. That same structure is what lets a retrieving model find the relevant chunk fast, which is the core idea behind generative engine optimization.

Decide the internal links before drafting so they're designed, not bolted on afterward: which pages this one links to, and which existing pages should link back to it. The mechanics deserve their own treatment in internal linking strategy.

Finally, write down what success looks like: the query the piece should rank or be cited for, the question it must answer better than the current top results, the action it should prompt. Vague goals produce vague content; explicit criteria give you and any reviewer a standard to hold the draft against.

An annotated example brief

Here's a complete brief for a hypothetical article, with notes on why each line earns its place.

Title (working): "Email Deliverability for Small Teams: A No-Jargon Guide"

Intent: Informational, leaning practical. The reader's emails are landing in spam and they want to fix it, not study the protocols. (Sets format: a troubleshooting guide, not a technical reference.)

Angle: Most deliverability content is written for enterprise email teams. This is the version for a two-person company with no dedicated email ops. (One sentence, genuinely distinct; this is the spine.)

Audience: Founders and marketers at small teams. Comfortable with tools, not with email infrastructure. Assume they've never heard of SPF or DKIM. (Sets depth and vocabulary.)

Voice notes: Plain and reassuring. Define every acronym on first use. No fear-mongering. Second person. (Keeps the draft from defaulting to a dry, technical tone.)

Structure:

What "deliverability" means and why mail lands in spam (answer-first definition)

The three records to set up: SPF, DKIM, DMARC (the core how-to)

Sending habits that hurt you (behavior, not config)

How to test whether it worked (closes the loop)

Must-cover points: SPF/DKIM/DMARC explained in one plain sentence each; the single most common cause is an unauthenticated domain; warm-up matters for new domains. (The non-negotiable substance.)

Sources: Link to the official DMARC spec for the authentication section; use our own support-ticket data only if a real number exists; otherwise say "a common cause," not a fabricated percentage. (Guards against invented stats.)

Internal links: Link to the broader "email marketing basics" pillar; link back from the "improving open rates" post. (Planned, not bolted on.)

Success criteria: Should rank for "why are my emails going to spam" and answer it in the first paragraph; a non-technical reader should be able to fix the problem without another source. (Checkable later.)

Notice what the brief does not do: it doesn't write the sentences. It settles every decision that determines whether the sentences will be any good, and leaves the prose to the draft. That division of labor is the whole point.

A reusable content brief template

Copy this, fill every field, and don't start drafting until none are blank.

Title (working):
Intent:            [what the reader wants; what format that implies]
Angle:             [one sentence: why this piece is different]
Audience:          [who they are; what they already know]
Voice notes:       [tone, person, jargon rules; a line or two]
Structure:         [H2s in order, one idea each]
  - Section 1 →    must-cover points + source
  - Section 2 →    must-cover points + source
  - ...
Internal links:    [pages to link to; pages that should link back]
Success criteria:  [target query; the question it must answer best; desired action]

The template is deliberately short. A brief is a decision-forcing tool, not a deliverable in its own right; if filling it takes longer than it would save, you're over-engineering it.

A quick content-brief checklist

Run any brief against this before drafting begins:

Is the intent named, and does the planned format match it?
Can you state the angle in one sentence, and is it genuinely distinct?
Is the audience specific, with their prior knowledge spelled out?
Do voice notes exist so the draft sounds like you, not the default?
Does every section carry must-cover points specific enough to block filler?
Is each important claim tied to a real source, and no fabricated stats invited?
Is the structure one idea per heading, in an order that builds?
Are internal links chosen deliberately, in and out?
Are there success criteria you could actually check later?
Could a stranger draft the right piece from this brief alone?

If every box is checked, the draft has nothing left to invent. If any are blank, that blank is where the generic will creep in.

Where to go next

A brief is the unit that turns a content plan into publishable work. To sharpen the decisions inside it:

Editorial planning for AI content: why the plan, not the draft, sets the ceiling on quality.
Search intent explained: how to diagnose what the reader actually wants, so intent and angle land.
Internal linking strategy: how to architect the links your brief should plan in advance.
Generative engine optimization: how a well-briefed, well-structured page becomes the source AI answers cite.

A brief this complete leaves the draft with nothing to invent but the prose. Hand a writer, human or model, a vague one instead, and no amount of fluency will rescue a piece that never decided what it was for.

How to Write a Content Brief That Produces Great Drafts