A content brief should explain the decision the article helps a reader make. “Write 1,500 words about technical SEO” describes a production quantity, not a useful result. Add the audience, problem, scope, and concrete output the reader should leave with.
Then write an acceptance test. A reviewer should be able to assess whether the finished article delivers the promised explanation, example, or tool. The test should be specific enough to reject a fluent draft that never answers the question.
The following is an original brief for a hypothetical migration-planning article. It is a commissioning template, not evidence of a completed client project.
Use a complete example brief
| Field | Hypothetical brief |
|---|---|
| Reader | A marketing owner preparing a small site migration with an engineer |
| Decision | Choose appropriate destinations for old URLs |
| Original contribution | A reviewable mapping table with three difficult examples |
| Evidence | Current primary migration guidance and the actual source inventory when available |
| Scope | Mapping and acceptance; exclude a full hosting tutorial |
| Acceptance | The reader can classify keep, move, consolidate, retire, and unresolved rows |
| Review trigger | A material change in migration guidance or the worksheet's assumptions |
The brief does not require a fictional success story or a promised ranking improvement. Its contribution is the decision method and worked examples. A real project example can be added only when the facts and permission exist.
Name the nearest existing resource
Before commissioning, inspect the archive for articles that already serve this decision. Record the nearest existing page and explain what the new piece adds. If the contribution is only another introduction to the same topic, improve the existing resource instead.
For the hypothetical migration piece, a broad launch checklist may already exist. The new article earns its place by working the old-to-new URL decisions in depth, including the difficult retirement and consolidation cases.
Also identify where the new article should receive a contextual link. Discovery is part of publishing the resource, not an afterthought left to an archive page.
Make evidence requirements concrete
List changing claims that require fresh verification and original examples that need clear hypothetical labels. If the article names a product capability, specify the primary source needed. If it uses arithmetic, require the inputs, units, and independent calculation check.
Do not fill a source list with impressive but irrelevant links. Each source should support a particular claim. The brief can identify likely sources while leaving the writer responsible for inspecting the actual current material.
Mark unavailable evidence as a boundary. A missing customer dataset should change the scope or leave a draft incomplete; it should not prompt invented results.
Review against the promise
Ask a reviewer to perform the stated task using only the article. Can they classify the example mapping rows and explain the exceptions? If they still need the writer to explain the method verbally, the article may need a clearer example or missing step.
Check the introduction, heading structure, examples, and final action against the same decision. Remove sections that add length without helping the task. Add detail where a real implementation choice remains unclear.
Use the content-gap review to choose briefs worth funding. A strong brief makes useful work easier to commission and makes completion something more concrete than reaching a word count.