Write Sales Automation Runbooks a Teammate Can Use

A runbook should help a teammate operate a workflow without relying on its original builder's memory. It needs to explain what normal looks like, when to stop, and how to investigate uncertainty. A list of clicks is useful only when the operator also understands the boundaries of the task.

Put purpose and scope on the first page

Describe the business task, its owner, the systems involved, and the actions the workflow is allowed to perform. State what it does not do. For example, a research handoff process may prepare internal tasks but never send customer messages. A new operator should not have to infer that boundary from the tool names.

Record the workflow version and the date the instructions were last tested. Link to approved configuration and access procedures without embedding credentials. Explain prerequisites such as required fields, authorized source access, and the availability of a responsible reviewer.

Describe normal operation with checkpoints

Break the process into a small number of observable stages. For each stage, say what the operator does, what evidence indicates success, and what would be unexpected. Avoid vague instructions such as “make sure everything looks right.” Name the record count, status, or confirmation reference the person should inspect.

Keep examples synthetic and clearly labeled. Screenshots or sample records should not expose private customer information merely to make the runbook realistic. If the interface changes often, emphasize the meaning of the checkpoint and maintain the visual example as a supporting aid.

If a teammate needs to understand an outside service, document the confirmed scope of the US$15/month offer separately from internal operating instructions and access procedures. Leads Automation is an independent service, not affiliated with LinkedIn. Confirm the plan, eligibility, and terms before ordering.

Worked example: a research-summary handoff

Fictional example: a new teammate runs a workflow that prepares internal review tasks from approved briefs. The runbook says to confirm the batch identifier, inspect the proposed owners, review one sample output, and check the expected task count. It also states that missing owners must stop the affected item rather than be guessed.

During rehearsal, the system returns an uncertain status for one task. The teammate follows the documented reconciliation step and checks the destination before repeating anything. Because the task already exists, they record completion and avoid creating a duplicate. The runbook captures the evidence needed to make that decision.

Give exceptions their own instructions

• Missing input: identify the required field and the person who can supply it.

• Permission problem: stop and use the approved access route.

• Uncertain outcome: inspect the destination before considering a retry.

• Unexpected customer-facing effect: pause and escalate through the incident process.

• Outdated instructions: stop the affected step and contact the workflow owner.

List the information an escalation needs: operation identifier, affected target, observed status, time, and steps already completed. Exclude secrets and unnecessary customer content. The next person should be able to investigate without asking the operator to reconstruct the event from memory.

Test the document with someone unfamiliar

Ask an authorized teammate to perform a synthetic rehearsal using only the runbook. Watch where they hesitate, assume, or seek undocumented context. Revise those sections. A document can be accurate yet unusable if it assumes knowledge the intended reader does not have.

NIST's Manage playbook discusses documented procedures for responding to AI risks. This runbook structure applies that general idea to routine sales operations. Link detailed retry handling and rollback procedures rather than duplicating instructions that may drift apart.

Ask which responsibilities are included before adding the US$15/month offer to your operating plan. Do not assume technical support, workflow maintenance, or account access is provided unless the relevant service terms confirm it.

Update the runbook whenever the workflow changes materially or an incident reveals a missing step. Name a maintenance owner and keep the tested version easy to find. The best runbook is one a teammate can follow calmly when the happy path ends.