SpyderBot Documentation
Turn an AI visibility opportunity into a content brief
You have identified a relevant gap, but "write more content about this topic" is not enough for a writer to act on. A useful brief connects the customer need, the observed problem, the verified information, and the asset that should deliver it.
Your outcome: a content brief ready for assignment, with factual acceptance criteria and a separate plan for evaluating later AI behavior.
Check that content is the right next step
Start with a supported opportunity from Opportunities, Decision Intelligence, portrayal evidence, or an inspected source. If the evidence only suggests a possible gap, resolve the uncertainty before commissioning a large piece.
| Situation | Best next step |
|---|---|
| Relevant information is absent or unclear on an owned asset | Build the brief below. |
| Information is already complete, but retrieval is problematic | Investigate the page's access or readability. |
| The gap is in external information | Use the source-and-channel playbook. |
| The product does not meet the need | Take the requirement to Product; do not write an unsupported claim. |
SpyderBot provides the intelligence and evidence used in the brief. Your content workflow handles drafting, factual approval, and publication.
1. State the customer decision
Read the opportunity explanation and identify the decision the content should support. Include the requirement that changes the answer.
For example: "A small business needs to know whether it can reconcile transactions automatically with its existing accounting software." This is a stronger brief foundation than "write about accounting integrations."
Open supporting responses or source evidence to verify the issue that matters. Use those observations to frame the problem, not as authoritative product facts.
2. Choose update, consolidate, or create
Review the relevant existing asset with its owner. Search your own content inventory or website where necessary; do not assume an opportunity means no page exists.
| Existing content | Decision |
|---|---|
| The right page exists but misses an important fact or example | Update it. |
| Several assets give conflicting or fragmented instructions | Align or consolidate them, preserving necessary routes and links. |
| A distinct customer task has no suitable destination | Create an asset for that task. |
| The information is accurate and sufficient | Investigate another cause before creating more content. |
One well-designed asset can answer several related prompt variations. Create a separate page only when it serves a distinct need or audience, not because each wording appears as a separate question.
3. Define what the content must prove
List the claims the reader needs to evaluate, their authoritative sources, and any limitations. Ask Product or the appropriate owner to confirm capabilities, conditions, and examples before drafting.
Use a practical structure for the chosen task: a direct answer, relevant conditions, supporting explanation or demonstration, limitations, and the next useful step. Choose the format that serves the reader-an integration guide, product explanation, comparison, or troubleshooting article. No fixed word count or schema addition guarantees an AI citation.
4. Give the writer a complete brief
Illustrative brief for an integration page update. This is a template for your content tool, not an automatic SpyderBot output.
| Field | Example instruction |
|---|---|
| Customer and decision | Small businesses checking whether automated accounting sync meets their workflow |
| Intelligence behind the work | Linked observations describe the integration as manual export in the selected scope |
| Asset decision | Update the existing integration page and align the linked setup guide |
| Main answer | Explain the actual supported sync behavior using approved product documentation |
| Required facts | Supported objects, sync direction, plan and market conditions, setup requirements, and limitations |
| Evidence to supply | Product-approved capability reference and a verified example or demonstration |
| Suggested structure | Direct answer â requirements â supported behavior â setup example â limitations â next step |
| Next step for the reader | Open setup instructions or check plan eligibility, as appropriate |
| Claims to avoid | Unsupported automation, universal compatibility, or guaranteed business results |
| Owners | Content writer, product fact-checker, and publishing owner |
| Acceptance | Facts match current capability; related pages agree; essential content is accessible; links and instructions work |
| Later observation | Whether comparable AI answers describe the integration accurately; recommendation is a separate outcome |
The writer should be able to draft without deciding what the product actually does. If that fact is unresolved, resolve it with the product owner first.
5. Review the asset before measuring the outcome
After drafting, compare the content with the brief. Check factual accuracy, necessary qualifications, and whether a customer can answer the original decision question. After publication, confirm the intended URL and essential content are available. Use a relevant audit when there is a concrete access or readability concern.
Record the publication date and baseline evidence reference. Then review later comparable observations for the targeted need. If the asset is correct but the old claim persists, inspect the remaining response and source evidence before commissioning another near-duplicate page.
You are done when the brief states the decision, asset, verified claims, owners, and acceptance criteria clearly enough for the writer and reviewer to work independently.
Next: use Evaluate progress after an improvement after the asset is implemented.