A useful content brief helps a writer make decisions. It explains who the reader is, what they need to understand, which claims can be supported and what the finished piece should help them do.

A title and a word count leave most of those decisions unresolved. Use the following brief for a guide, service article or campaign page, and remove fields that do not help the assignment.

Start with a reader and a decision

Describe the reader’s situation rather than listing a broad demographic. “Small-business owner” is less useful than “an owner comparing two service proposals who cannot tell what is included in either price.” The second description gives the writer a problem to solve.

Then name the decision. Is the reader choosing an approach, preparing information, checking a result or understanding a limitation? One article can support related questions, but it needs a clear primary job.

Use this compact brief template

Separate facts from ideas that need checking

Do not put an attractive claim in the brief as if it were already established. Label it “verify” and say what evidence would make it usable. A writer should be able to distinguish an approved product specification from an interview suggestion or a rough estimate.

For each important statistic or quotation, keep the original source and enough context to interpret it. Record the date and population behind a statistic. A result from one campaign should not become a promise about every business.

If the evidence is unavailable, change the claim or omit it. A practical example can explain a method without pretending to be a customer success story.

A worked example: preparing for a workshop enquiry

Consider a hypothetical training provider preparing a guide for team managers. Its brief might read as follows:

• Reader: A manager arranging a first workshop for a mixed-experience team.
• Question: What information should I prepare before requesting a proposal?
• Outcome: The reader can assemble a short, useful enquiry.
• Scope: Cover audience, work task, expected output, delivery constraints and review process. Leave software comparisons to a separate guide.
• Evidence: Use the provider’s approved programme outline and actual proposal requirements. Do not invent client names or results.
• Example: Show a clearly labelled fictional enquiry for a team improving its reporting workflow.
• Next step: Submit the relevant details through the enquiry form; do not imply immediate availability.

This brief gives the writer choices they can defend. It also gives the reviewer a concrete standard: does the article help the manager prepare the enquiry?

Give structure without scripting every sentence

List the questions that need answers, then let the writer organise them into a readable sequence. Request a table only when readers need to compare parallel options. Request a checklist when they need to perform or verify steps.

Use length as a planning constraint rather than a target to fill. A short task may need a short answer. A complex decision may need examples, limitations and supporting material. Remove repeated introductions and unsupported general claims before adding more words.

Review against the brief before polishing style

Read the draft once for purpose and accuracy. Does it answer the primary question? Are its claims supported? Does the example clarify the method? Is the next step relevant and available? Resolve these issues before spending time on sentence-level preferences.

If the article misses the intended job, revise the structure or the brief. Record what changed so the writer is not working against two different sets of expectations.

For bilingual assignments, add a shared facts sheet and a language review. The same offer, dates and commitments should survive every version. A completed brief becomes a useful reference when the content later needs updating.