Ask a tool to "write an article about invoicing software" and it will produce competent, forgettable text. It has no idea who is reading, what the reader already believes, what proof you actually have, or where the piece sits in your site. None of that is the tool's fault — nobody told it. A brief is how you tell it, and unlike a clever prompt it survives contact with a team, a freelancer and a second draft.
Why a brief beats a prompt
A prompt is written once, for one output, and lives in a chat window. A brief describes the assignment, so it can be reused: given to a freelancer, pasted into a tool next month, or handed to a colleague who has never written about the topic. It also forces a decision you would otherwise make badly at the editing stage — namely what success looks like. Over thirty days of testing, the single biggest difference in output quality was not the tool, it was whether the brief contained real specifics or just a topic.
The template
Copy this. Replace every [bracket] — a bracket left in is a field you have not decided, and the draft will quietly decide it for you.
1. Assignment
- Title (working): [title, changeable]
- URL slug: [slug]
- Format: [how-to / comparison / list / opinion / case study / pillar]
- Target length: [words] — set as a range, not a number to pad towards
- Existing page to update, if any: [url] — this changes everything about how you write it
2. Reader
- Who: [role, company size, situation] — one person, not an audience segment
- What they already believe: [the thing they think now, stated fairly]
- What they need to leave with: [a decision, a set of steps, a number]
- Where they are in the process: [just realised / comparing / about to buy]
- What makes them close the tab: [generic advice, no prices, vendor tone]
3. Search intent
- Primary query: [the phrase, written as a person types it]
- Secondary queries: [two or three]
- What the current results do well: [named observation, not a complaint]
- What we can add they do not have: [one specific thing — data, a test, a counterexample]
That fourth line is the one that decides whether the page is worth publishing. If you cannot fill it in, you are writing another version of a page that already exists.
4. Content requirements
- Must cover: [four to seven points, each answerable]
- Must include: [specific entities, product names, standards, terms]
- Must not claim: [anything you cannot evidence]
- Evidence sources: [files you own, pages you will cite, data with dates]
- Numbers available: [the actual figures, pasted in — not "insert stat here"]
5. Structure
- Section headings, in order: [H2 list, with one line on what each must accomplish]
- Opening requirement: [the specific hook type and the promise it must make]
- Internal links: [three to five target URLs, with the anchor context]
- Closing requirement: [what the reader does next]
6. Voice and constraints
- Voice: [three adjectives plus one example paragraph in the right voice]
- Words to avoid: [the ones your industry overuses]
- Second person or third: [pick one]
- Reading level: [plain / professional / technical]
- Hard limits: [claims requiring legal review, anything off-limits]
The five fields people leave out
These are the omissions that show up as editing work later. "What they already believe" — without it the draft explains things your reader knows, which is the fastest way to lose a professional audience. "What makes them close the tab" — without it you get the conventions of the category rather than an argument. "Numbers available" — leave this blank and the model supplies its own numbers, which is how invented statistics get into published pages. "Existing page to update" — rewriting instead of updating is how sites end up with six pages competing for one query. "Hard limits" — a tool will happily draft the sentence your legal reviewer will delete.
What this costs, from our 30-day benchmark
Our 30-day test measured roughly 22 minutes of editing per 1,000 words on the low-cost dedicated writer against about 8 minutes on the general assistant — near $7 per piece of your time at $30 per hour. Writing the brief takes around ten minutes and pulled the low-cost tool's editing figure down noticeably, because most of what gets edited is a decision the brief should have made.
A workflow that holds up
Fill the brief before you open any tool, and paste it in whole rather than summarising it — models attend to whatever is in front of them, and a summary loses the specifics that do the work. Check the draft against the brief section by section: does each heading do the job it was given? If a section drifted into general background, delete it rather than editing it. Keep the briefs in a folder, because after ten you will see your own patterns — usually the same two fields get skipped, and those are exactly the ones causing the rewrites. And when a draft surprises you by being good, read back which line of the brief did it; that is the field to keep investing in.
Write the brief, then generate
Ten minutes of specification beats an hour of editing. Start on the low-cost plan and test it on real work.
Try Rytr →Frequently Asked Questions
How long should a content brief be?
One page is usually enough. Six sections with real specifics beats a five-page document nobody fills in properly — the cost is in the decisions, not the length.
Can I use the same brief for AI tools and human writers?
That is the main benefit. A brief describes the assignment rather than the tool, so it works for a freelancer, a colleague and a generator alike.
Why does my draft contain statistics I did not supply?
Because the brief had no "numbers available" field. Given a gap, a model fills it with something plausible. Paste the real figures in or delete the sentence.
Should I include search keywords in the brief?
Include the actual phrases people type, with your observation about current results. Keyword lists without intent tend to produce pages that rank for nothing.