By INTSEO Media Partnerships Team · 7 April 2026 · 6 min read
A good brief to an outsourced SEO team states the goal, the audience, the constraints, the definition of done, and one example of quality. A bad brief states a keyword and a due date, then expresses surprise when the draft is generic.
Table of contents
- Bad briefs are the most expensive part of outsourcing
- The minimum fields every SEO brief should contain
- Briefing technical work differently from content work
- Feedback loops that improve the next brief
- How much briefing time is rational
- Closing takeaway
Bad briefs are the most expensive part of outsourcing
This article is for account managers and in-house leads who already bought fulfilment capacity and are tired of paying for revision loops that were avoidable at the briefing stage.
Briefing is not bureaucracy. It is how you transfer the judgement you keep in-house into production you do not want to supervise line by line.
If you are still deciding what to keep internal, read when to outsource SEO and when to keep it in-house before you rebuild your templates.
The minimum fields every SEO brief should contain
Start with context the producer cannot guess: client industry, offer, geographic focus, sensitive claims, and competitors you refuse to imitate. Then add the task type: technical ticket, article, local page, link prospecting list, or report narrative.
State search intent in human language. "Someone comparing payroll software for teams under fifty people" is usable. "Informational" alone is not.
Define must-include entities, must-avoid claims, internal links, and the primary URL. Attach two examples of writing or recommendation style you consider acceptable. Examples beat adjectives.
Close with definition of done. What does "finished" mean before QA? Word range, required sections, ticket acceptance criteria, or number of vetted prospects are concrete. "Make it great" is not.
| Brief field | Why it exists | Failure if missing |
|---|---|---|
| Client context | Prevents generic tone | Wrong audience voice |
| Intent statement | Shapes structure | Introduces fluff |
| Constraints | Protects risk | Unsafe claims |
| Examples | Calibrates quality | Endless taste debates |
| Definition of done | Ends revision ambiguity | Scope arguments |
Briefing technical work differently from content work
Technical briefs should include environment notes, CMS limits, who implements, and what "validated" means after release. A crawl finding without implementation context becomes a PDF nobody acts on.
Content briefs should lock the angle before drafting. If stakeholders are still arguing about the angle, you are not ready to spend writer time. Locking late is how you buy two articles and publish one.
Link building briefs should state risk tolerance and approval gates. "Get links" without publisher standards is how you inherit a cleanup project. Pair this with the standards on outsourced link building.
Feedback loops that improve the next brief
When work comes back wrong, annotate the brief, not only the draft. If the brief allowed the mistake, the system failed upstream.
Keep a living FAQ per client: recurring preferences, banned phrases, product names, and legal sensitivities. Partners should not rediscover those monthly.
Schedule a short retrospective after the first two cycles with a new partner. The goal is template improvement, not blame theatre.
How much briefing time is rational
A thirty-minute brief that prevents four hours of revision is cheap. A three-hour brief for a thin blog post is not. Match briefing depth to risk and cost of error.
Senior people should design templates. Junior people can complete them. If seniors fill every brief from scratch, you have a scaling problem disguised as quality culture.
For sequencing what to outsource as volume grows, see scaling an agency without hiring.
Closing takeaway
Brief for intent, constraints, examples, and done. Everything else is optional decoration. If your outsourced work is chronically mediocre, audit the brief quality before you audit the partner's talent.
A reusable brief skeleton you can paste into Notion or your PM tool
- Client one-liner and offer. 2. Audience and geography. 3. Task type and primary URL. 4. Intent in a sentence. 5. Must include / must avoid. 6. Examples (links or attachments). 7. Definition of done. 8. Due date and reviewer name. 9. Risk notes (legal, claims, competitors). 10. Questions the partner must ask before starting if anything is unclear.
Require partners to ask clarifying questions within one business day when a brief is incomplete. Silence is not consent to guess.
Worked example: content brief versus "keyword + words"
Weak brief: "Write 1,500 words on payroll software. Include SEO keywords." Strong brief: "Audience is finance leads at companies with 10-50 staff evaluating payroll tools. Primary query intent is comparison before shortlisting. Must include compliance considerations at a high level without legal advice. Must avoid inventing customer counts. Internal links to pricing and integrations pages. Tone like our attached sample: calm, specific, no hype adjectives. Done means draft in Google Doc with H2s matching outline, sources linked for any statistic, ready for editor."
The second brief takes longer to write once. It saves a rewrite cycle almost every time.
Worked example: technical ticket brief
Weak brief: "Site is slow, please fix Core Web Vitals." Strong brief: "Template type: category pages on Shopify. Priority URLs attached. LCP issue suspected on hero image. Staging access available. Implementing party is client developer. Done means diagnosis with ranked fixes, ticket text the developer can execute, and a validation plan after release. Out of scope: redesign of theme aesthetics."
When not to brief yet
If the client has not approved the angle, if legal review is pending on claims, or if access is missing, do not start the clock on the partner. Briefing into a blocked environment creates fake urgency and real waste. Park the task with a blocker note instead.
Tools and channels that keep briefs from rotting in Slack
Put briefs in the same system as tasks. Slack is for clarification, not as the system of record. When the brief lives in a ticket, revision debates can point to a timestamped source.
If your partner uses a different PM tool, agree on one source of truth anyway. Dual systems create dual forgotten fields. Export or mirror, but do not pretend two half-briefs equal one complete brief.
Name reviewers explicitly. "Someone on our side will look" delays cycles. "Alex reviews by Thursday 16:00" ends ambiguity.
Written by the INTSEO Media Partnerships Team.