A runbook is most useful when the person who wrote it is unavailable. That is also when its missing steps become expensive to discover.
The exercise: choose one routine support task and one permitted training setup. Ask a trained colleague, not the builder, to perform the task by following the runbook. The builder observes and takes notes. Nothing else.
Watch where the colleague pauses. Each pause is a finding. Distinguish two kinds: missing access versus missing instructions. If the runbook names the dashboard but not the expected arrival time, the healthy state, or the escalation contact, those are instruction gaps. If the colleague needs the builder's personal password to continue, that is an access design flaw. Stop at the boundary and record it. Never publish private infrastructure details or credentials.
For example, tracing a missing test report might reveal all three gaps at once: no expected arrival time, no definition of normal, no escalation contact. Each gets added in the smallest possible revision. Then the colleague repeats the failed step to confirm the fix.
Include restoration evidence in the runbook, not just menu screenshots: how to confirm the result, what the healthy state looks like, and who to contact when it isn't. Then repeat the rehearsal on the next routine task.
The finish is independently tested instructions. Another person ran the process, found the gaps, and the gaps got repaired. That is the handoff.
Have the receiving operator demonstrate one routine support task, end to end, before you accept the handover as complete.