How to write a content brief (with template and example)

When you ask someone to write an article, a topic and an outline can feel like enough to get started. You know why the subject matters to your company, and the headings seem to cover the main points. But some of what makes the assignment clear to you may never have made it into the document. The writer can see the subject without knowing which reader you have in mind or what that person needs help with.

Take an article about AI support-ticket triage: using AI to help decide a ticket's priority and where it should go. One writer might explain how the technology works. Another might compare products. A third might explain how to test a system before putting it into use. Each could reasonably follow the same broad topic. If you were hoping to help a support leader find out whether urgent tickets will reach a person, you would need to say so before the writer spends time on a general introduction to AI.

A content brief puts that context into the assignment. It explains who the article is for, the question it should answer, the evidence the writer can use, and what the reader should be able to do afterward. It also gives the editor something to review against. If the brief asks for a practical test, you can check whether the draft makes that test possible instead of judging it only by how polished it sounds or how closely it follows your headings. This applies whether a person or an AI marketing agent is doing the writing.

We'll use that support-ticket example throughout the guide. Ternfield is a fictional B2B SaaS company that sells AI-assisted ticket triage, and its editor is preparing an article for people evaluating the product. The company, research materials, and draft passage are invented for teaching, rather than drawn from real customer research. Following one assignment lets us look closely at how the sources lead to a brief, how the brief shapes the writing, and what an editor should do when the draft reveals a better way to explain the subject. There is a completed brief and a blank template you can adapt to your own work.

Where a content brief fits

A content strategy explains which audiences and subjects the company will spend time on and how that work should support the business. For Ternfield, the strategy might include helping support leaders evaluate AI before buying it. An editorial calendar would give one article an owner and a delivery date; our guide to content pillars shows how to build that calendar around a few recurring themes. The content brief explains what that particular article needs to accomplish, so the writer can act on the broader strategy without having to reconstruct it.

You may already have an SEO brief with a target query, notes on search intent, and competing pages. Keep that research: it can help you understand what someone searching for the topic expects to find. You will still need to decide which question your article can answer well and what evidence supports that answer. Similarly, a creative brief may provide the wider campaign message, visual direction, and channel requirements. The content brief carries the parts that affect this piece and adds the reporting and editorial decisions the writer needs.

The outline sits inside that assignment as a proposed order for the explanation. Its headings can tell a writer to include an evaluation section, but they do not explain which tests belong there or why. If you're assigning the work to an AI marketing agent, the prompt can include the content brief along with instructions about which sources it may access, what it should deliver, and what requires your approval. Ampere's agent briefing guide explains that part of the handoff.

The amount of detail depends on how much judgment the assignment requires. A familiar product update might need a few paragraphs and links to approved release notes. An article about the reliability of an AI product needs more: the writer has to understand the test conditions, what the results establish, and who can check the technical description. A brief is especially useful when that context is spread across several people or documents.

Begin with a reader in a situation

“Support leaders” is a reasonable starting audience, but it leaves the writer with a lot to work out. Someone learning about AI for the first time needs a different article from someone who has already seen a demo and is worried about a missed urgent case. Describe what brings the reader to this piece, what they already understand, and the decision they are trying to make.

For Ternfield's article, imagine a support operations lead who knows the current escalation process and is evaluating whether AI can help sort incoming tickets. Their concern is that an urgent request could receive a routine label and wait too long for attention. That gives the article a primary question: How can I test whether urgent cases still reach a person? A useful outcome would be that the reader can prepare an escalation test and knows what further evidence to ask for before adopting a tool. Naming that outcome helps the writer decide how much background to explain and where to spend the most time.

Search results for “AI ticket triage” might show explainers, product pages, and implementation advice. They can suggest possible intents, but cannot tell you who searched or what happened in their workplace. Ternfield's support leader is an editorial hypothesis. In a real brief, check the situation against documented customer questions, sales or support notes, and interviews; say what each source actually tells you.

As you gather material, keep track of why each source is useful. A support conversation may show that a customer struggled to understand escalation rules; a search-result review may show how other articles explain those rules. Your product documentation can tell you whether the company has something concrete to demonstrate. Taken together, these sources help you choose an editorial purpose, such as helping a buyer test the route an urgent ticket takes. Record the actual question and where it came from, so the writer can distinguish an observed concern from an assumption about the audience.

Google's people-first content guidance asks whether a reader leaves having learned enough to achieve their goal and whether the page adds original information, reporting, research, or analysis. Its AI features guidance says the same SEO fundamentals apply to AI features, with no special optimization requirement or guarantee of inclusion. For an editor, the practical question is whether the brief calls for a useful answer backed by evidence. An arbitrary word count, heading count, keyword density, or optimization score cannot answer it.

Turn source material into an angle the evidence can support

Once you understand the reader's question, decide how the article will approach it. This is the angle: the particular argument or explanation you plan to develop. “AI support triage” leaves many possibilities open. “Evaluate how a system handles urgent cases before comparing its speed” gives the writer a position to examine and a reason for choosing the examples. The sources need to be strong enough to support that position.

For Ternfield, imagine the editor has gathered the following fictional research packet. Some of it describes a product, some shows a limited demonstration, and some is still a research plan. Keeping those differences visible prevents unfinished work from turning into a confident claim in the draft.

The editor could commission “AI triage is faster than manual triage,” but the packet contains no comparative performance data. “Why every support team needs AI triage” would be harder to defend still: nothing here establishes that every support operation would benefit. “How to evaluate AI ticket triage when urgent cases matter” gives the writer a more useful assignment with the material available. They can explain the demonstrated route, show how a buyer might test it, and identify the questions the demonstration leaves unanswered.

In the fictional demo, one seeded urgent ticket followed the configured human-review route. That observation cannot establish reliability across other ticket types or customer environments. The team still needs product-owner sign-off and tests that look for urgent requests the system might miss. These misses are called false negatives. If the checks fail, revise the angle or postpone the piece instead of hiding the gap in a disclaimer.

Open the evidence-to-angle graphic at full size (opens in a new tab).

The article also needs something readers can learn from beyond a summary of the pages the editor found. That original contribution could be an interview that explains a difficult decision, a product test, a comparison using consistent criteria, or a completed example. Ternfield could contribute an escalation-test walkthrough if the product behavior is confirmed. Original work does not have to be a large research study; it does need to give the reader something specific to examine.

Make it easy for the writer to see how the evidence supports the proposed claims. Beside the sentence “the test ticket reached the review queue,” point to the relevant moment in the demo, record the configuration used, and name the person who checked it. If a source contradicts the proposed argument, include that too. A list of links without these notes leaves the writer to discover the limitations during drafting, when it may already be difficult to change the direction.

Write the decisions the writer needs, then leave room to write

An outline is useful when it shows how the explanation could unfold. For Ternfield, you might suggest opening with the urgent-ticket concern, explaining the routing rule, walking through a test, and then discussing what the result leaves unanswered. Explain why those parts matter. The test gives the reader something to try; the discussion of its limits helps them avoid treating one successful result as a reliability guarantee.

Then say which decisions the writer can revisit. They may discover that readers need to see the test before the routing explanation makes sense, or that two planned sections work better together. Those are ordinary editorial choices. Required product limitations, source attribution, and any approved legal qualification still need to appear wherever they are relevant. The brief should make that distinction clear so a writer can improve the explanation without accidentally dropping something essential.

Voice guidance works best when the writer can see what you mean. Attach an approved paragraph and explain why it is a good reference: perhaps it introduces technical terms patiently or describes a limitation without sounding evasive. The brand voice guide and messaging framework can provide the wider context. In this article, also point out that “human review” describes a process, while “guaranteed human oversight” makes a stronger promise. If the writer will compare competitors, give them a current competitor analysis with the same criteria applied to each company.

Ternfield's routing diagram has a specific job: show a submitted ticket, the urgency rule, the human-review route, and where the test can fail. Identify who will verify each label. Give the writer relevant internal pages and primary external sources, with a reason to use each link. After explaining the test, the article could offer a worksheet or a walkthrough of the escalation controls. The reader should be able to use the idea before being asked to book a demo.

Practical production details can change the assignment too. Tell the writer where the article will appear, whether it needs a downloadable worksheet, who will prepare accessible descriptions of the visuals, and when each reviewer is available. If there is a real space limit, explain it. Otherwise, give the writer enough room to answer the question instead of prescribing a word count or number of headings as a substitute for editorial judgment.

Completed content brief: Ternfield's escalation guide

This completed brief uses the invented Ternfield packet. For a real assignment, replace its sources with dated material the writer can inspect and get product facts checked before publication.

Assignment and status. Draft an educational Resource Hub article, working title “How to evaluate AI ticket triage when urgent cases matter.” The product specification is pending sign-off; publishing waits for that sign-off and representative testing.

Reader and situation. A support operations lead is assessing AI triage after seeing how costly an urgent ticket can be when it is treated as routine. This reader knows their current escalation process but needs a practical way to inspect a proposed AI route. This situation is an editorial hypothesis until customer conversations confirm it.

Primary question and outcome. How can the reader test whether urgent cases still reach a person? By the end, they can design a small escalation test, record exceptions, and ask a vendor for the evidence needed to assess reliability in their environment.

Business relevance and editorial purpose. Ternfield sells AI-assisted triage. If its controls pass verification, the article can show readers how to evaluate them. It must not imply that Ternfield never misses an urgent case.

Argument and angle. Before comparing promises about speed, help the reader understand what happens to an urgent ticket. Explain the routing rule and demonstrate it with a clearly urgent test case. The article should help a buyer ask better questions about the system's behavior.

Evidence and original contribution. Use the product specification for feature descriptions after the product owner has checked the wording. The internal demo supports a description of the one route it shows. Build the walkthrough around a clearly urgent test ticket and explain the setup well enough for a reader to repeat it. Label untested steps as proposed, and interview a support leader before describing the opening situation as customer experience.

Claim boundaries and open questions. Do not claim a miss rate, universal reliability, or faster resolution. Do not turn proposed interview questions into customer quotations. Verify the current configuration, who receives escalations, whether an exception can be audited, and what happens when confidence is low. If the product cannot demonstrate the route, change the angle to a vendor-neutral evaluation guide or pause the article.

Structure and writer discretion. Start with the concern about urgent tickets, explain the route to a reviewer, and show the test. End by explaining what a buyer still needs to investigate. The writer can change the headings and order, or add a test the research shows is necessary. Explain substantial changes in the handoff note so the editor can follow the reasoning.

Examples, visuals, and links. Use a labeled fictional ticket and a routing diagram checked against the specification after sign-off. Link only to current product documentation and relevant primary sources. Link the evaluation worksheet where the test appears; offer a product walkthrough after the reader understands the controls.

Voice and production. Write for a practitioner who understands support work but may be new to AI triage. Explain terms such as “false negative” when they first appear. Use the approved brand examples for tone and the checked specification for product names. Deliver the draft with the diagram's alt text and notes showing where its claims came from. The product owner checks feature descriptions before the editor signs off on the article.

Acceptance criteria. A reader can run the proposed test without guessing a step. The editor can find the approved documentation or observed behavior behind each product claim. The article answers the opening question early, explains what has been tested, and suggests a relevant way to continue the evaluation. It must not present invented material as customer evidence. Changes to the outline are welcome when they improve the answer and preserve these requirements.

Open the completed-brief graphic at full size (opens in a new tab).

What a useful brief adds to a keyword and outline

Consider the assignment “Keyword: AI support triage. Title: Benefits of AI support triage. Write 1,500 words. Cover benefits, features, and conclusion.” It gives a subject and a format. Keyword research picks the keyword, and the search intent behind it suggests what kind of page to make. The writer must still work out who has the problem, which claim to make, and what evidence could support it.

Ternfield's completed brief explains why the article exists. The support leader is worried about urgent tickets, so the writer knows to spend time on the route to a human reviewer. The demo supplies a starting example, while the limits of that demo tell the writer which claims would be premature. Those decisions change what belongs in the draft: a long list of AI benefits would do little to answer the question, but a carefully explained test would help.

They also make feedback easier to give. Instead of saying that the draft “needs more depth,” the editor can point out that it never explains how to tell whether the test ticket reached a person. If the writer adds a useful case that was absent from the outline, the editor has a reason to keep it. The question is whether that addition helps the reader do what the article promised.

Open the weak-versus-useful comparison at full size (opens in a new tab).

Copyable content brief template

You can copy this template into the document you already use to assign work. Fill it out in ordinary sentences where an explanation would help, and remove fields that have no bearing on the piece. You do not need a finished answer to every question before research starts. For anything still unknown, name the person who will check it and say whether the writer can proceed while that work is pending.

Piece and working title:
Status / owner / review date:

Reader and situation:
- Who is facing which decision? What do we know, and what is a hypothesis?
Primary reader question:
Useful outcome after reading:
Business relevance and editorial purpose:

Search and customer observations:
- Observed question or result, source, date, and what it cannot establish:
Chosen angle and central argument:
Original contribution:
- New analysis, interview, test, example, or artifact we can actually provide:

Evidence map:
- Claim → exact source or artifact → verification status → reviewer:
Claim boundaries and unresolved questions:
- What must not be said yet? What would change or stop the assignment?

What the article must explain:
Suggested structure (writer may revise unless marked required):
Examples and visuals (what each must show, source, verifier):
Voice, terminology, and approved references:
Links and why each helps the reader:
Next useful action:
Format, accessibility, deadline, and review owners:

Acceptance criteria:
- What must the reader be able to do?
- Which claims must trace to which evidence?
- What changes to structure are acceptable?

How the brief shapes a draft passage

The following excerpt is from the fictional Ternfield assignment. Its ticket, configuration, and behavior are invented; publishing a real version would require the checks named in the brief.

What happens when a routine label hides an urgent case? Begin in a test queue where you can inspect the result without affecting real requests. Prepare a ticket describing an outage that prevents customers from signing in, and decide which person or queue should receive it. Submit it through the normal triage process. Check whether the ticket reaches a person, and record its priority, the rule used, and where it arrived. In Ternfield's illustrative demo, the clearly urgent ticket follows the configured review route. That shows what happened in this setup; you still need to investigate other kinds of requests.

Now try an urgent request written less directly. For example, the ticket might describe several customers being stuck at sign-in without using the words “urgent” or “outage.” If the system leaves that request in the routine queue, you have found a false negative: an urgent case it did not recognize as urgent. Record the miss and ask the product owner how to investigate it and test any proposed change. This second case helps you understand a limitation that a successful demonstration with obvious wording could leave hidden.

Notice how the opening question leads into a procedure the reader can follow. The first paragraph names a test environment, describes the ticket, and tells the reader to decide the expected destination before checking the result. Those details put the brief's promised outcome into practice. The sentence about Ternfield's demo stays close to the observation it can support, rather than extending it to every ticket the product might receive.

The second paragraph goes beyond the brief's suggested test. The brief asked for one clearly urgent ticket; the writer adds a request whose urgency is less obvious and explains what a false negative means. In this fictional example, the writer's note to the editor would say that the first test covers only an easy case, while the reader's concern includes urgent requests that are difficult to recognize. That is a reason to expand the test and update the brief. The editor would still check the proposed procedure before approving it.

Open the brief-to-passage graphic at full size (opens in a new tab).

Review the draft against the reader outcome and evidence

Read the draft once from beginning to end before editing individual sentences. Keep the reader's situation in mind: would a support lead who had just seen a demo understand how to investigate the risk of a missed urgent ticket? After that first read, try to follow the proposed test. If you have to guess where to submit the ticket or what result to record, you have found a specific gap to send back to the writer. This is more useful feedback than asking for the piece to be “more actionable.”

On a second pass, check the claims against the sources. The evidence map should take you to the passage or demonstration behind each important assertion. Read enough of the source to understand its conditions: a demonstration with one ticket cannot establish how the system behaves across a queue. Check product statements with their owner if the documentation may have changed. In your notes, distinguish what was observed from the writer's interpretation, what still needs research, and what was invented as an example. That distinction should remain clear in the published wording too.

When you compare the draft with the brief, give the writer's choices a fair reading. A different order may help readers understand the test; a new example may expose a weakness the original outline missed. Ask what the change contributes and whether it preserves the required evidence and qualifications. If you keep it, update the brief or leave a decision note so another reviewer does not undo the change simply because it departs from the first outline.

Check the material around the prose too: exact terminology, visual labels and alt text, links, production requirements, and the next action. The Content Marketing Institute's creative-brief guidance includes angle, message, editorial purpose, resources, and commissioning responsibility. Its editorial guidelines ask contributors to submit original work with reliable sources and checked facts. The draft review should show where those requirements were met.

Revise the brief when the research changes the premise

Sometimes research changes more than a heading or an example. If Ternfield's product owner cannot confirm the escalation route, the editor needs to reconsider the planned product walkthrough. A guide to evaluating vendors may still be useful, provided it does not describe unverified Ternfield behavior. Alternatively, the editor may pause the article until a valid test exists. If interviews show that buyers are chiefly worried about tracing what happened after a ticket was routed, the article may need to focus on auditability instead.

When that happens, write down which source changed your understanding and how it affects the assignment. The writer and reviewers need to know whether the audience, argument, examples, or publication decision has changed. Give the revised brief a date and an owner so people can tell which version they are working from.

For your next article, start with the question you want the reader to be able to answer. Write a short explanation of why that question matters, then put the supporting material beside it and check what it actually establishes. You can use the template to fill in the rest of the assignment. By the time you hand it over, the writer should understand both the article you have in mind and the questions they still need to investigate.

Open the content-brief reference at full size to save or download (opens in a new tab). In a browser, open the image and save it with the browser's image-save command.

Sources and further reading

• Google Search Central: Creating helpful, reliable, people-first content — questions for evaluating usefulness, original contribution, and evidence.
• Google Search Central: AI features and your website — current guidance that ordinary SEO fundamentals apply to AI features, without a special optimization requirement or appearance guarantee.
• Content Marketing Institute: How to develop a great creative brief — commissioning angle, purpose, resources, and ownership.
• Content Marketing Institute: Writing guideline FAQs — contributor responsibility for originality, reliable sources, and checking facts.

Frequently Asked Questions

What is a content brief?

A content brief is the document that turns a topic into an assignment a writer can act on. It explains who the article is for, the question it should answer, the evidence the writer can use, and what the reader should be able to do afterward. The brief sits between the content strategy, which decides which audiences and subjects matter, and the outline, which only proposes an order for the explanation.

What should a content brief include?

Include the reader's situation, the primary question and the outcome the reader should reach, the business reason for the piece, and an angle the evidence can support. A content brief also needs an evidence map that links each claim to its source and verification status, the claims that must not be made yet, a suggested structure marking what the writer may change, voice and link guidance, production details, and acceptance criteria for reviewing the draft.

How do you fill out a content brief template?

Copy a content brief template into the document you already use to assign work, then fill it out in ordinary sentences where an explanation would help and delete fields that have no bearing on the piece. You do not need an answer to every field before research starts. For anything still unknown, name the person who will check it and say whether the writer can proceed in the meantime. The guide includes a copyable template covering the reader's situation, an evidence map, claim boundaries, and acceptance criteria.

What is an example of a content brief?

One example is a completed brief for a fictional B2B software company that sells AI-assisted ticket triage. Its reader is a support operations lead worried that an urgent ticket could be labeled routine, so the primary question is how to test whether urgent cases still reach a person. Because the product evidence is one recorded demo and a specification awaiting sign-off, the brief rules out claims about a miss rate or faster resolution. The writer may still reorder sections when that improves the answer.

What is the purpose of a content brief?

The purpose of a content brief is to close the gap between what the person assigning an article knows and what the writer can see. A topic and an outline name the subject but rarely say which reader the piece is for or which claims the evidence supports, so two writers can follow the same headings to very different articles. The brief also gives the editor a standard to review the draft against, so feedback can point to a missing step or an unsupported claim.

What is the difference between a content brief and a creative brief?

A creative brief sets direction for a wider campaign, while a content brief prepares one article. The creative brief may cover the campaign message, visual direction, and channel requirements. The content brief carries over the parts that affect its piece and adds the reporting and editorial decisions the writer needs: the reader's situation, the question to answer, the evidence available, and which claims that evidence supports.

What should a content brief include for SEO?

For SEO, a content brief should carry over the target query, search-intent notes, and competing pages from any search research, because they show what searchers expect to find. Search results cannot tell you who searched or what situation they were in, so the brief still has to choose a question the article can answer well and the evidence behind it. Google's guidance says the same SEO fundamentals apply to its AI features. No keyword density or optimization score can show whether an answer is useful.

What are common content brief mistakes to avoid?

Common content brief mistakes include handing over only a keyword, title, word count, and outline, which leaves the writer to guess the reader, the claim, and the evidence. Others are describing the audience with a broad label instead of a situation, commissioning an angle the sources cannot support, and listing links without saying what each one establishes. Without those source notes, the writer discovers the limitations during drafting, when changing direction may already be difficult.

How should you tailor a content brief for freelance writers?

Tailor a content brief for freelance writers by writing down the context they cannot see for themselves, since what makes the assignment clear to you may never have reached the document. Give sources the writer can actually open, an approved paragraph that shows the voice, and the product limitations and attribution that must stay. Mark which structural choices the writer may change, and ask for a handoff note explaining any substantial changes so you can follow the reasoning.