How to Hand Over an AEO Programme
Hand over nine artefacts: the prompt set with the reason each prompt is in it, the sampling protocol including how many runs and when, the control set and why those topics were chosen, the recorded history with its raw rows rather than only charts, the metric definitions with any changes dated, the list of claims previously made and later revised, the technical fixes already applied, the competitor claim log, and the open questions. The one whose absence ruins the rest is the metric definitions with change dates — without it, a successor cannot tell whether a shift in the history is a real movement or a redefinition, and the entire recorded series becomes uninterpretable.
This is an unglamorous post and it is the one most likely to save someone a quarter. AEO programmes accumulate decisions that are invisible in the outputs: why that prompt, why that control topic, why that number changed in March.
The nine artefacts
| Artefact | Without it | Where it usually lives |
|---|---|---|
| Prompt set + rationale | Successor changes it and breaks the series | A spreadsheet or a tool |
| Sampling protocol | Runs are not comparable | Someone's head |
| Control set + why | No way to separate platform change | Someone's head |
| Raw recorded rows | Charts cannot be re-derived | A tool, maybe exportable |
| Metric definitions + change dates | The series is uninterpretable | Nowhere |
| Revised claims list | Old errors get repeated | Nowhere |
| Technical fixes applied | Work gets redone | Git history, partly |
| Competitor claim log | Stale claims stay published | A doc, if you kept one |
| Open questions | Successor rediscovers them slowly | Someone's head |
The prompt set needs its reasons, not just its contents
A successor who does not know why a prompt is in the set will reasonably improve it — and improving it breaks comparability with everything recorded before. Each prompt needs a line: which buying question it represents and when it was added. That is what makes the set stable across a handover rather than resetting the baseline.
Raw rows, not screenshots
Charts cannot be recomputed, re-segmented or checked. Hand over the rows — run, date, prompt, engine, whether cited, which URL — and the charts become regenerable. A history of screenshots is a record of what someone concluded, not of what was observed.
Hand over the mistakes too
The list of claims made and later revised is the most useful and least transferred artefact. Without it a successor repeats the same error, reports it confidently, and withdraws it again — costing the programme credibility twice for the same reason.
FAQ
How long does a handover take? — A few hours if the artefacts exist, and weeks of reconstruction if they do not. The real answer is to maintain them continuously, since every item on this list is something the programme should have anyway.
What if we are handing over to an agency? — The same nine, plus an explicit statement of what you will hold them to. An agency inheriting a programme with no baseline and no definitions will set their own, and every comparison to your prior period will then be meaningless.
What if none of this exists? — Then say so at the handover rather than letting a successor assume the history is comparable. An honest reset with a new baseline beats a series nobody can interpret.
Put this to work on your own website.
Fenn finds what your customers ask, drafts the articles and site fixes, and measures what ChatGPT, Claude, Gemini, Perplexity and Grok say about you — with every change waiting for your approval.