A decision-first content brief template, completed example, and five-minute test for turning an assignment into an executable handoff.
Start a content brief by resolving the decisions a writer cannot safely guess. Do not begin with a giant checklist of headings, keywords, and word counts. If the audience, desired outcome, evidence standard, scope, and approval boundary are unclear, more instructions only make the uncertainty longer.
A content brief is a compact handoff document that tells a creator who the content is for, what outcome it must achieve, what evidence and boundaries apply, and how the finished piece will be judged—while leaving room for the creator to make execution choices.
The brief can be a page, a database record, or a task in a project system. Its value is not its format or length. Its value is that a capable creator can read it, identify the real assignment, and begin useful work without reconstructing the request from chat messages and meetings.
Define the brief by the decisions it carries
A weak brief names a topic: “Write about expense tracking.” A useful brief identifies the person, situation, change, and constraints: “Help a new US freelancer choose a weekly expense-recording routine before tax time; show a spreadsheet method and an app method; do not give individual tax advice; support tax-record claims with primary sources.” The second version gives the writer a basis for deciding what belongs.
That decision-first view aligns with practical industry guidance without treating any vendor’s field list as universal. Ahrefs describes a brief as the document that gives a writer the goal, context, and key points, while warning against drowning the writer in SEO jargon in its content-brief guide and templates. Semrush’s step-by-step brief guide includes audience, format, search context, metadata, and links, but also cautions against making the instructions so granular that the writer has no room to work.
A brief is therefore a handoff contract, not a miniature draft. It should answer five questions:
- Why does this content need to exist?
- Who needs it, in what situation, and what should they be able to do afterward?
- What must the deliverable cover, prove, avoid, and connect to?
- What can the creator decide?
- Who accepts the work, using which criteria and by when?
Separate the brief from nearby planning documents
Several documents may contain an audience, goal, or deadline. They are not interchangeable. Use the artifact whose decision level matches the work.
| Artifact | Decision it carries | Typical scope | What it should not become |
|---|---|---|---|
| Content strategy | Which audiences, needs, content systems, and outcomes the organization will support | Portfolio or program | A list of article ideas |
| Editorial calendar | What is scheduled, when, where, and by whom | Publishing pipeline | The assignment specification |
| Content brief | What one deliverable must accomplish and the boundaries of the handoff | Single deliverable or tightly related set | A word-for-word script |
| Outline | One proposed sequence for presenting the answer | Draft structure | A substitute for audience and outcome decisions |
| Creative brief | Shared direction for a broader creative project, often involving multiple assets and disciplines | Campaign or creative project | A writing-only checklist |
| AI prompt | Instructions and context for one model interaction or workflow | Execution step | The durable source of approved decisions |
If the organization has not decided what audience and content system it will serve, set the content strategy before briefing individual assignments. Once an assignment is approved, schedule approved assignments in a content calendar. A multi-quarter initiative needs a different level of planning; compare the brief with an outcome-based product roadmap before forcing many deliverables into one brief.
A creative brief overlaps more heavily with messaging, assets, stakeholders, distribution, budget, and campaign goals. Asana’s creative-brief guide treats it as a shared plan for cross-functional creative work. A content brief can sit beneath that plan and specify one article, video script, help page, or report.
Use the minimum viable content brief template
Copy the template below, then delete fields that do not change the work. A brief should be complete enough to execute, not complete enough to describe every possible editorial preference.
| Field | What to write | Failure signal |
|---|---|---|
| Assignment and outcome | Deliverable plus the observable change it should enable | Only a topic or keyword is named |
| Reader and situation | Relevant knowledge, constraint, trigger, and decision | A demographic label with no task |
| Scope | Required questions, examples, and explicit exclusions | “Cover everything” or a copied competitor outline |
| Evidence | Claims needing proof, preferred source types, freshness, and citation rules | “Add statistics” with no quality rule |
| Constraints | Legal, safety, brand, localization, accessibility, or product boundaries | Hidden requirements appear during review |
| Search and distribution | Query, channel, format, and metadata only where they affect the deliverable | A keyword dump replaces reader intent |
| Connections and next action | Internal resources, CTA, related asset, or handoff after reading | The piece ends without a useful route |
| Deliverable | Format, approximate depth, assets, file or CMS destination, and due date | “Write a blog post” is the whole specification |
| Ownership and acceptance | Creator, subject reviewer, approver, and acceptance criteria | Everyone can comment but no one can accept |
| Open questions and changes | Unresolved decisions, owner, answer date, and version notes | Guesses silently become requirements |
Describe the reader through a real need, not an invented persona biography. The GOV.UK design principles begin with identifying user needs and understanding context. For a brief, that means recording what evidence supports the need and what successful task completion looks like—not merely age, job title, or traffic potential.
Mark non-negotiables and creator choices
Every important field needs a decision owner. Mark each item fixed, propose, or open:
- Fixed: the creator must follow it. Use this for verified product facts, legal boundaries, required audience, promised deliverable, approved positioning, and source standards.
- Propose: the creator recommends an answer and the named owner approves it. Use this when expertise is part of the assignment, such as the most useful example or sequence.
- Open: the creator owns the choice. Use this for wording, transitions, analogy, and section order unless a genuine constraint makes them fixed.
A useful test is reversibility. If a choice can change during drafting without breaking the promise, evidence, risk boundary, or delivery channel, it probably does not need to be fixed in the brief. If changing it would invalidate approval or expose the organization to harm, name it before work begins.
This boundary matters when AI assists the draft. The brief remains the approved source; the prompt is an execution artifact. After the decisions are stable, turn approved decisions into a structured AI prompt, then verify the output against the brief rather than treating fluent text as evidence of compliance.
Fill the template for one real assignment
Here is a compact content brief for a fictional article. Notice that it provides a destination and guardrails without dictating every heading.
| Assignment and outcome | Article: “How to Track Business Expenses as a New Freelancer.” After reading, a US freelancer should be able to start a weekly capture-and-review routine and identify records that need professional tax guidance. |
|---|---|
| Reader and situation | First-year solo freelancer; receipts are split across email, cards, and paper; has not chosen accounting software; wants a simple routine before filing season. |
| Scope | Explain capture, categorization, business-purpose notes, weekly reconciliation, storage, and escalation. Show one spreadsheet route and one app route. Exclude entity selection and personalized deduction advice. |
| Evidence | Use current IRS material for federal recordkeeping claims; use product documentation for product behavior; date all changeable claims. Do not invent savings figures. |
| Constraints | State that tax treatment varies by facts and jurisdiction. Make the routine usable without purchasing software. Use plain English. |
| Search and distribution | Primary query: “how to track business expenses.” Search article plus onboarding-email excerpt. Answer the basic method before discussing tools. |
| Connections and next action | Link to receipt organization and quarterly-tax planning resources. CTA: complete the first 15-minute weekly review. |
| Deliverable | 1,600–2,100 words; one workflow diagram; one field template; draft in CMS by August 25. |
| Ownership and acceptance | Writer: assigned editor. Fact reviewer: US tax specialist. Accept when every required step is actionable, sourced, scoped, and usable without paid software. |
| Open questions | Reviewer decides by August 21 whether to include a state-level caveat. Writer proposes the spreadsheet fields. |
For a scholarly deliverable, the evidence field becomes more demanding: research question, databases, source inclusion rules, claim-to-citation expectations, and review method may all be fixed. In that branch, use a research-paper workflow for evidence-heavy assignments rather than expanding a generic marketing brief until it becomes unrecognizable.
Add SEO and distribution fields only when they change the work
An SEO content brief may need a primary query, searcher situation, likely competing interpretations, title constraints, internal links, and existing pages that must not be duplicated. It does not need a long list of semantically related words for the writer to insert mechanically.
Google’s people-first content guidance asks whether content serves an existing audience, demonstrates first-hand or substantive expertise, and leaves the reader feeling that they learned enough to achieve their goal. Those are useful review questions. They do not replace research into the site’s audience or the assignment’s actual outcome.
Internal links should also carry a reader job. Google’s link guidance recommends crawlable links with concise, descriptive anchor text and says internal links help people and Google understand the site. In a brief, do not merely paste destination URLs. State why the reader needs each destination and where that transition belongs.
Tool requirements come last. Once the brief identifies research, optimization, asset, and workflow needs, compare content marketing tools by the job they support. A tool cannot repair an absent audience decision or approve an unsupported claim.
Run the five-minute handoff test
Give the brief to a capable person who did not attend the planning conversation. They should be able to answer all seven questions in five minutes:
- Who is this for, and what situation triggers the need?
- What should the person understand, decide, or do afterward?
- What must be included, and what is explicitly out of scope?
- Which claims need evidence, and what sources are acceptable?
- Which requirements are fixed, and which choices belong to the creator?
- What exactly must be delivered, to whom, and by when?
- Who can accept the work, and what would make them reject it?
Score each answer 0, 1, or 2: 0 means absent, 1 means implied or ambiguous, and 2 means explicit and usable. Do not use the total as a quality badge. Use every 0 as a stop signal and every 1 as a named question for the correct decision owner. A brief with 14 points can still be wrong if its audience assumption is unsupported, but it is at least inspectable.
Keep the brief alive without turning it into the draft
Freeze a version when drafting begins. After that point, change the brief only when the assignment changes—not when the writer finds a better phrase. Record the change, owner, date, and effect on scope or deadline. This prevents review comments from quietly rewriting the contract after the work is done.
When updating an existing page, begin with evidence of what is stale, missing, duplicated, or no longer useful. Then turn refresh findings into a bounded update brief. Do not ask a writer to “refresh everything” while preserving every old section.
For repeatable production, map ownership and status into the content management system so the brief, draft, approval, and publication states remain visible. Store durable definitions, source policies, product facts, and escalation rules separately; keep reusable editorial decisions in a governed knowledge base instead of copying them into every assignment.
The final decision rule is simple: put a fact in the brief when the creator cannot safely infer it and changing it would alter the promise, evidence, risk, distribution, or acceptance of the work. Leave it out—or mark it as the creator’s choice—when it only controls how a capable person expresses the answer. That boundary produces a brief that is specific enough to execute and open enough to create.
