A clear pause, triage and recovery record for a limited automation trial.
FREE OFM FIELD KIT
A first-week AI operator runbook
Three operating documents for a small, controlled trial: an owner map, a daily review and a pause-and-recovery record. These are editable plans, not proof that a system is ready.
Keep duties narrow enough that each person knows what they own.
ACCOUNT OWNER: approves scope and access
TRIAL OPERATOR: runs the defined workflow and records observations
REVIEWER: checks outputs against approved facts and boundaries
ESCALATION OWNER: resolves exceptions the tool may not decide
RECOVERY OWNER: can pause, revoke access and authorise restart
FOR EACH ROLE: name / available hours / backup / approved permissions
BEFORE START: run a test handover and confirm the recovery owner can actually use the stop controls.
02
Run a daily evidence review
Review exception cases as well as ordinary replies. Volume alone can hide failures.
DATE / WORKFLOW VERSION:
SCOPE ACTUALLY USED:
ORDINARY CASES REVIEWED:
CORRECTIONS OR UNSUPPORTED FACTS:
HANDOVERS AND TIME TO ACCEPT:
PAUSES / DUPLICATES / MISSED STOP CONDITIONS:
BILLING ITEMS THAT NEED EXPLANATION:
CHANGE PROPOSED AND OWNER:
RETEST REQUIRED BEFORE RESUMING:
Keep the sample method explicit. A selected set of cases is not a measured whole-account error rate.
03
Pause, investigate, restart
A sequence for the authorised operator; use only the provider’s supported controls.
1. PAUSE the affected workflow and inspect pending actions.
2. REVOKE access if the pause does not contain the problem.
3. PRESERVE the minimum authorised evidence: event, time, rule version and observed effect.
4. IDENTIFY affected conversations and assign an operator to handle them.
5. CORRECT the fact, permission or rule that caused the issue.
6. REPEAT the failed test and record the outcome.
7. RESTART only the approved scope, with an owner and review time.
Do not declare recovery from a green dashboard alone.
These are illustrative planning scenarios, not reports of vendor tests or customer outcomes. Adapt the examples to an account you are authorised to operate. Use the field guide for the underlying method and the interactive tool for your own inputs.
An operator sees an output that exceeds the authorised account brief.
Work through it
Pause the affected workflow, preserve the relevant event reference and assign the correction to the account owner. Inspect whether similar actions remain queued.
What to check
Do not assume editing the brief changes messages already prepared or sent.
02
THE SITUATION
A duplicate send appears
The same intended action reaches the recipient more than once.
Work through it
Record event IDs, timestamps and the observed order. Check retries and duplicate handling through the provider’s supported controls.
What to check
Resume only after the relevant test demonstrates that the duplicate condition is handled.
03
THE SITUATION
The operator loses access
The person responsible for the trial cannot reach the normal dashboard.
Work through it
Use the documented secondary contact and access-revocation route. Transfer responsibility to the named backup owner.
What to check
A recovery plan that depends on the unavailable operator is incomplete.
YOUR WORKING DOCUMENT
Keep the decision with the evidence.
Use the plain-text worksheet in your own approved system. It contains headings only, so you control which information is recorded and where it is stored. Nothing entered in a downloaded file is returned to this publication.
INCIDENT RECORD
Time / time zone:
Account and workflow reference:
Reported by / incident owner:
Observed issue:
Scope currently known:
Pause action and confirmation:
Pending actions inspected:
Evidence references:
Human correction owner:
Cause / provider response:
Retest evidence:
Resume decision and reviewer:
Common mistakes to avoid
Calling a completed checklist a compliance certificate.
Starting without a backup owner for the stop procedure.
Restarting after an incident because the dashboard looks normal without checking the cause.
Before implementing a workflow, confirm that it is supported by the chosen product and permitted under current platform rules. A planning example does not establish either. OnlyFans terms.
Check a bot’s stop control against queued, running and future actions, with a bounded test plan and evidence that distinguishes paused from fully stopped.
Write an incident review with a factual timeline, bounded impact, explicit uncertainty and corrective actions that can be tested before resuming the workflow.