Collect decisions, not just keyword phrases
Start with the moments when a prospective customer hesitates: choosing a supplier, understanding a quote, preparing data or approving a launch. Capture the actual question and the situation that prompted it. A keyword tool can help investigate demand later, but it cannot tell you what happened in the buyer's project.
Use material you are entitled to analyze, such as your own enquiry categories and approved sales notes. Remove names, private project details and anything that would identify a customer before turning it into public content. Do not publish a private conversation as a case study simply because it contains a useful question.
For each candidate, record the audience, decision, existing answer, missing evidence and intended next step. A topic like “AI development” is too broad to brief effectively. “What documents should a company prepare before a knowledge-assistant pilot?” identifies a useful task and suggests a concrete deliverable.
Use a priority table the team can explain
| Criterion | Strong candidate | Reason to defer |
|---|---|---|
| Customer relevance | A recurring decision in real enquiries | A fashionable phrase unrelated to services |
| Distinct purpose | A question no existing page resolves | Another article with the same answer |
| Evidence available | A worked example or usable method | Only general claims and definitions |
| Maintenance | A clear owner and review trigger | No way to keep changing details accurate |
A simple high, medium or low assessment is often enough. Avoid a precise-looking score that nobody can explain. Review the top candidates together and record why an article deserves to exist. The backlog should support editorial judgment rather than replace it with arithmetic.
Turn one question into a usable brief
Consider this hypothetical question: “Why did two agencies quote very different prices for our website?” The reader needs help comparing scope, not a generic list of benefits of web development. The brief should require a comparison of page templates, content work, integrations, migration, testing and support. It should include an example of two quotes with different assumptions, clearly labelled as illustrative.
Define what the article must not claim. It should not state that the cheaper supplier is poor, or that a particular budget guarantees quality. Give the reader a worksheet to normalize scope and ask better follow-up questions. Link to the relevant service page only when the reader is ready to discuss their own requirements.
Before drafting, identify the one sentence that answers the main question. Then list the evidence needed to support it. This reverses the common habit of writing a long introduction and discovering the actual answer at the end.
Review outcomes and maintain the backlog
After publication, check whether the page is discoverable, whether relevant readers use it and whether it reduces recurring confusion in enquiries. Low traffic does not automatically mean the topic was wrong; investigate discovery and intent first. High traffic does not prove the article attracts suitable buyers.
Merge overlapping ideas before assigning more drafts. Update an existing page when its question is unchanged but the answer needs work. Retire items that the business cannot answer responsibly. Keep a separate list of content that requires client permission or specialist review, so a publication deadline does not become a reason to invent evidence.
Use the content-brief guide for drafting and intent-overlap review when two proposed articles look similar. Google's people-first content guidance is a useful external quality check.
A practical starting point
Work through these checks in order. Use the results to decide what needs to change in your own workflow.
- Review sales notes and support questions without exposing personal information.
- Group questions by the decision they support rather than by repeated words.
- Choose one clear reader outcome for each proposed article.
Questions about project cost may reveal uncertainty about scope, maintenance or ownership, requiring different answers.
A mistake to avoid
Do not publish confidential customer details as illustrative examples.
How to check progress
Track which articles sales and support teams actually use to answer recurring questions.
Your action checklist
Use this checklist while reviewing your own setup. Checkmarks are temporary and stay in this open page.
Further reading
Official background resources for this topic. The workflow above is general guidance, not a guarantee of a particular result.
AI-assisted editorial content. Examples are illustrative, not client case studies. Read our editorial policy or report a correction.
