SpyderBot Documentation
Turn SpyderBot recommendations into an action plan
You have findings and recommendations, but your team needs to know what to do next. The challenge is choosing work that is supported, relevant, and possible with the people and resources available.
Your outcome: an actionable task with evidence, an owner, a completion check, and a later outcome check where appropriate.
Start where the recommendation already exists
Use Priority Actions in Brand Insights, Next Best Actions or Opportunities in Prompt Universe, or the findings and actions in AI Traffic. Work from the product containing the evidence. You do not need to assemble a new master score from every module.
If you are still deciding which questions to investigate, use Decide which AI questions to investigate and monitor first. This article starts when you have a finding or recommendation to evaluate.
1. Choose a recommendation tied to a current decision
Read the recommendation and its explanation. Confirm that its Context, customer need, or affected page matches your business priority.
Use SpyderBot's proposed order as the starting point. Adjust it for information the product may not know: a launch deadline, an asset scheduled for retirement, an unavailable owner, or an implementation dependency. State the reason for the adjustment instead of inventing a second scoring formula.
If several recommendations concern the same outdated fact or page, inspect whether one coherent repair can address them. Combine work only when the underlying issue and acceptance check are shared; retain links to the original findings.
2. Decide whether to implement or investigate
Open the evidence relevant to the proposed change. The question is whether you can justify this task, not whether you have reviewed every response.
| Situation | Assign this kind of work |
|---|---|
| A specific factual error is verified against current product information | A correction, with the accurate replacement and source |
| An observed gap is relevant, but the reason remains uncertain | An investigation with a question to resolve |
| A technical finding identifies an affected page and a supported issue | A technical task with a testable acceptance check |
| Measurement is unreliable | A measurement repair before performance interpretation |
| The recommendation concerns a requirement the product does not meet | A product decision or audience-fit review |
| The issue is outside current scope or no longer relevant | Defer or dismiss with a reason and revisit condition |
One verified outdated claim can justify fixing that claim. A major campaign or site-wide rewrite requires stronger support than a narrow factual correction. Match the evidence review to the consequence of the decision.
3. Name the deliverable and owner
Turn "improve integration visibility" into a deliverable someone can complete: "Update the integration page with current capability, plan conditions, and setup instructions; align the related help article."
Specify who owns the work and who confirms the facts. A content owner may need Product to validate capability. A marketing owner may need Engineering to confirm access behavior. If the required owner is unavailable, keep the dependency visible rather than assigning a deadline the team cannot meet.
Use an action in the relevant SpyderBot workflow where available. Otherwise, add the task to your existing issue tracker with a link to the finding. This playbook does not require a separate tracking system.
4. Separate completion from effectiveness
Define two checks when the task requires both:
- Completion: was the intended change implemented correctly?
- Outcome: did the relevant observed result later improve under comparable conditions?
For a factual correction, completion means the approved information is published and accessible. The later AI outcome is whether comparable answers describe the capability accurately. Active recommendation can remain a separate question.
Before implementation, preserve the relevant existing observation reference and scope. Record the actual completion date afterward. You will need both to evaluate progress.
5. Make a plan the team can execute
Illustrative example. A team receives three relevant recommendations but can implement only one this week:
| Candidate | Decision | Reason and next checkpoint |
|---|---|---|
| Correct an obsolete integration claim on an owned page | Implement now | The fact is verified, the page owner is available, and the customer requirement matters to the current launch. |
| Investigate a new competitive gap in one system | Assign a focused investigation | Evidence identifies the gap but does not establish what to change. |
| Expand an enterprise content cluster | Defer | Enterprise is outside the current launch scope; revisit during the next market review. |
The resulting handoff for the first task is short:
Decision: correct the integration information now.
Evidence: the linked recommendation and affected responses.
Deliverable: updated integration page and aligned help article.
Owner: product marketing; integration lead approves facts.
Completion check: accurate capability, conditions, and setup details are published.
Outcome check: review portrayal in the next eligible comparable observations.
If unchanged: inspect the continuing claim and sources before repeating the same edit.
If no candidate is ready for implementation, the plan can consist of a measurement repair or a focused investigation. A list of unsupported tasks is not progress.
You are done when the owner can explain what to deliver, why it matters, and how completion will be checked without asking you to reinterpret the finding.
Next: use Turn an AI visibility opportunity into a content brief for writing work, Fix issues affecting important pages for technical work, or Evaluate progress after an improvement after implementation.