How to Write a Content Brief That Produces Great Drafts

Most bad drafts trace back to a bad brief. Not a missing one, a bad one: a document that looks complete because it has a title and a topic, but settles nothing a writer actually needs to decide. Writing content briefs well means closing off every place a draft could default to generic, and the easiest way to see how is to look at one that doesn't. Everything below comes from reviewing briefs that shipped fine drafts against briefs that shipped forgettable ones, and tracing the difference back to what was actually written down, the kind of pattern-matching that shows up after enough editorial reviews rather than after reading one style guide.

The weak brief

Here's a brief you'd find in most content calendars, more or less verbatim. Anyone who's sat in on a content review has seen a version of it.

Title: Email Deliverability for Small Teams Topic: Write about why emails go to spam and how to fix it. Audience: Marketers Length: 1,200 words Keywords: email deliverability, why emails go to spam

Nothing here is wrong, exactly. It has a title, a topic sentence, an audience of sorts, a length, and a keyword. A model handed this brief will produce something. It'll open with a line about how email is still one of the most effective marketing channels, define deliverability in the abstract, list SPF, DKIM, and DMARC without explaining what any of them actually do for a two-person team, and close with a paragraph about best practices. It will be fluent. It will also be indistinguishable from the twenty other articles ranking for that keyword, because nothing in the brief told it to be otherwise.

The audience field says "marketers," which describes almost nobody in particular. A marketer running deliverability for a 400-person sales org and a solo founder sending a weekly newsletter from a brand-new domain are not the same reader, and they don't need the same article. The topic line says what the piece is about but not what it has to argue, which claim is the spine, or what makes it worth reading over the existing results. There's no source named for any claim, so the model will either hedge everything into vagueness or invent a number that sounds plausible and isn't. There's no structure, so the model imposes its own default order, usually the same one it always reaches for. And there's no way to check afterward whether the piece did its job, because nothing defined what "worked" would look like.

This is the brief that produces wallpaper. Not because the writer or the model is careless, but because a vague brief only has one honest response, which is a generic draft.

What the brief needs to settle

A brief earns its keep when it makes every one of those decisions instead of leaving them for the draft to guess at. In practice, that's a short checklist, not a mood board.

• Intent, named plainly enough that the format and depth match what the reader actually wants
• Angle, the specific claim or framing that makes this piece different from what's already ranking, which should include a quick look at the current top results and where they fall short, not just a topic
• Audience, specific enough that a stranger could picture the actual person reading it
• Must-cover claims, not just the topic the piece circles, each one attached to a real source if it needs backing
• Sourcing rule, stated outright: if a claim needs a number and there's no real number to hand, soften the claim rather than inventing one
• Voice notes, a line or two so the draft sounds like the publication rather than a model's default register
• Outline, one idea per heading, in an order that actually builds toward something
• Internal links, chosen in advance rather than bolted on after the draft exists
• Success criteria, a target query, a claim the piece needs to answer better than the current top result, or an action the reader should take next

None of this makes the brief long. It makes it specific. A brief that names the wrong audience is worse than no brief at all, because it gives the draft false confidence about who it's talking to. The intent and the angle are the two decisions that matter most, and they're also the two most often skipped, because they take actual thought rather than just topic selection. Diagnosing intent correctly is covered in more detail in search intent explained, and it's worth getting right before anything else on the list, since a well-structured piece answering the wrong question still fails. Part of getting the angle right is a quick pass on what's already ranking: what the top three or four results cover, what they skip, and where a genuinely different framing would beat them rather than just restate them.

The checklist above holds for a founder-facing troubleshooting piece, but it flexes for other formats. A comparison post needs the same nine items, except the must-cover claims usually center on pricing and feature parity rather than a technical process, and the sourcing rule matters more, not less, because pricing figures go stale and get misquoted constantly. A glossary entry or definitional page can settle intent and audience in a sentence each and skip most of the angle work, since the job there is clarity rather than differentiation.

Sourcing deserves the same discipline. If a claim needs a number and there's no real number to hand, the brief should say so, and the instruction should be to soften the claim, not fabricate a statistic to fill the gap. That single rule, named explicitly in the brief rather than assumed, is often the difference between a piece that holds up under scrutiny and one that quietly invents a "73% of marketers" statistic nobody can trace. For technical claims specifically, naming an actual primary source in the brief, a spec page, a vendor's own documentation, whatever's authoritative for that domain, does more work than any style guideline about "citing sources" ever will.

Not every brief needs the full nine items worked out in detail. A templated product update or a short internal FAQ can run lighter, with intent and audience settled in a line and the rest left to house style, because the risk of a generic draft is lower when the format itself is narrow. The discipline matters most where the topic is competitive or the claims are technical enough to get wrong.

Structure and links aren't afterthoughts either. A brief that specifies which pages this piece should link to, and which existing pages should link back to it, treats internal linking as an editorial decision rather than something to be added mechanically once the draft is done. The reasoning behind that ordering is laid out in internal linking strategy, and the same logic that helps a human reader skim an outline and grasp the shape of the answer is what helps a retrieving system find the right section fast, which is most of what generative engine optimization actually comes down to. None of this replaces planning at the level above the individual piece, which is its own discipline covered in editorial planning for AI content: the brief decides what one article does, the plan decides which articles get written at all.

The stronger version of a content brief

Here's the same email deliverability piece, briefed properly.

Title (working): Email Deliverability for Small Teams: Fixing Spam Placement Without an Ops Team

Intent: Practical and troubleshooting-led. The reader's mail is landing in spam right now and they want the fix, not a primer on email infrastructure.

Angle: Almost everything written on this topic assumes a dedicated email operations person. This is the version for a two-person company sending its own newsletter from a domain nobody's configured properly. The top-ranking results for this query are aimed at enterprise IT teams; none of them address a founder setting up DNS records for the first time, which is the gap this piece fills.

Audience: A founder or solo marketer at a small company, comfortable with SaaS tools generally, has never heard of SPF or DKIM and doesn't want a lecture on why they matter, just what to do.

Must-cover points:

• What SPF, DKIM, and DMARC each do, in one plain sentence apiece
• The single most common cause of spam placement for small senders, which is an unauthenticated new domain sending at volume before it's warmed up
• Why sending habits matter as much as the DNS records
• How this differs from advice written for teams with a dedicated deliverability specialist

Sources: the DMARC.org specification page for the DMARC record itself; the SPF record syntax defined in RFC 7208 for how the SPF check works; no invented percentages anywhere, if there's no real figure for how common a given cause is, say "commonly" and move on.

Voice notes: plain, second person, define every acronym the first time it appears, no fear-mongering about spam folders killing a business.

Structure: what deliverability means and why mail lands in spam, the three records to set up and what each does, sending habits that hurt a new domain, how to test whether the fix worked.

Internal links: link out to the site's broader email marketing guide; the existing post on open rates should link back in.

Success criteria: should answer "why are my emails going to spam" in the opening lines well enough that a non-technical reader can fix the problem without opening a second tab.

Set the two side by side and the difference isn't length. The weak version is four lines and a keyword. The strong version isn't dramatically longer, but every line in it makes a decision the draft would otherwise have to make on its own, usually badly. The angle sentence alone changes the entire piece: instead of a generic deliverability explainer, the model now has a specific reader to write for and a specific reason the piece exists that competitors haven't covered. The sourcing line stops a plausible-sounding but fabricated statistic before it ever gets typed. The success criteria give a reviewer something to check the finished draft against, rather than a vague sense of "does this seem good."

Naming two sources rather than one also does something the single-source version doesn't: it forces the brief writer to think about which claims are structural (how DMARC evaluates a message) versus which are mechanical (how an SPF record gets checked against a sending IP), and that separation usually improves the outline before a word of the draft gets written. A brief this specific also touches on adjacent workflow steps worth naming: a quick SERP analysis of the current top results informed the angle, and an editorial review pass against the success criteria is what catches it if the draft drifts back toward the generic version despite the brief.

The same logic holds outside email entirely. Take a brief for a piece on choosing project management software. A weak version says "compare the top PM tools for small teams." A properly briefed version names the angle: most comparison posts are written by the tools themselves or by affiliates with a financial stake in the outcome, so this piece is for a ten-person agency evaluating on price and onboarding time specifically, not feature count. It names the must-cover claims, attaches a source to any pricing figure since prices change and get misquoted constantly, and sets success criteria around whether a reader could make a shortlist decision without opening five more tabs. Swap the topic and the checklist above still holds.

Writing content briefs like the second version takes maybe ten more minutes than writing one like the first. What it buys is a draft that has almost nothing left to invent except the actual sentences, which is the only part a writer or a model should be doing anyway.