Runbooks, Playbooks and Work Instructions

Runbooks, Playbooks and Work Instructions is the convention that fixes the three forms an L3 job aid may take beneath a workforce standard: the work instruction for a recurring, deterministic operations step; the playbook for a judgement-bearing situation with options and a decision rule; and the runbook for a break/fix or degradation sequence with an entry condition, steps, verification, rollback and exit. It matters because Process Decomposition (L0–L3) places thresholds, screenshots and named systems at L3 so that L0 to L2 stay stable across platform changes, and a function whose job aids have no fixed forms ends up with twenty-page playbooks nobody opens during an incident and one-line work instructions that hide the threshold in someone's head. The convention is part of Process Standardization; every generic process card's L3 register names its job aids with one of these forms, and the four process types of Process Inventory for a Workforce Function decide which form a card's aids mostly take.

The three forms descend from different lineages that reached the same shape. The work instruction is the quality-management tradition's document for how a single task is done. The playbook and the runbook are the reliability-engineering tradition's instruments for an on-call responder: a written response for a known alert, short enough to be used under load, revised after every use. What the traditions share is the specification rule: work written down as to content, sequence, timing and outcome, so that a deviation is visible as it occurs.

Three forms

Form	Situation	Is the next step known before the situation starts?	Reader	Process type served
Work instruction	a recurring operations step: a query, a reconciliation, a publication, a verification	yes, always; the instruction is deterministic	the seat that runs the step, including a new occupant on day one	operations; the steps of a change
Playbook	a situation with more than one legitimate response: a volume spike, a mass absence, a gap outside the band	the options are known, the choice is not; a decision rule picks	the seat at the tier that may choose	break/fix where judgement is needed; the exception path of an operations process
Runbook	a degradation or a one-time scripted change: a platform outage, a cut-over, an instance consolidation	yes, as a sequence with a verification at each step and a way back	the seat that holds the degradation, at the tier the entry condition names	break/fix; method of procedure

The middle column sorts a job aid into its form. A next step known and the same every time makes a work instruction, and a playbook written for it is padding; options known but the choice situational makes a playbook, and a work instruction written for it hides a decision in a step; a failure or a pending change, with each step verified before the next and reversed if it fails, makes a runbook. A playbook may hand off to a runbook (the system-outage response on Real-Time Exception Handling Playbooks hands the technical recovery to the platform owner and keeps the staffing response), a runbook may call a work instruction for a step, and a work instruction never calls either.

Anchoring

Every L3 document anchors twice, and both anchors are fields on the document: upward to the section of the parent standard it details, by section number as Anatomy of a ROC Standard keys them, and sideways in the Applicable Documentation column of the L2 step table, the join key of Process Decomposition (L0–L3), in every row that depends on it. Together they answer the two questions a job-aid library is for: "what breaks if this aid changes" is a search of the join-key column, and "which standard does this aid implement" is the section number. The same column is what the SET LOCALLY mark of Standard and Variant in Process Documentation points at: an L2 row that reads SET LOCALLY names, in its join key, the aid where the local value lives.

Minimal templates

A function may add fields; it may not remove these. The WI-, PB- and RB- prefixes are illustrative.

Work instruction

Field	Content
ID and title	WI-nnn; the verb and the object ("Roll the roster forward")
Anchored to	the standard's section number; the L2 rows that name it
Trigger and owner	the L2 step or calendar point that invokes it; a seat, never a name
Preconditions	what must be true before step 1 (the actuals closed; the lock in force)
Steps	numbered; one actor, one verb, one object per step; the screenshot beside the step it illustrates
Values	the thresholds, codes, calendars and tolerances the steps use, each with its grade and its SET LOCALLY owner
Systems	the named platform and screen
Definition of done	what a reviewer checks to confirm the step ran; the output and its record
Review	the review date and the trigger that forces an earlier one (a platform release)

Playbook

Field	Content
ID and situation	PB-nnn; the exception type and its written entry criteria
Anchored to	section number; L2 rows
Owner and tier	the seat that runs it and the tier that may choose (Decision Authority Tiers in Workforce Operations)
Options	a table: option · condition under which it applies · cost · tier required · time to take effect
Decision rule	ordered: the first option whose condition holds is taken; what to do when none holds
Communications and timer	who is told, at which step, with the verbiage; the interval at which the rule is re-run
Exit and hand-off	the state that ends the playbook; where it hands off (incident management, a runbook, the step-down check)
Last exercised and review	the last real use or tabletop exercise; the rule that every use at the top severity rows produces an update

Runbook

Field	Content
ID and degradation	RB-nnn; what has failed or what is being changed
Entry condition	the written criterion that opens the runbook, and the tier that may open it
Anchored to	section number; L2 rows
Owner and tier	the seat that holds the sequence
Pre-checks	what is confirmed before step 1 (the backup route exists; the notice period has been served)
Steps with verification	numbered; each step carries the check that confirms it worked before the next is taken
Rollback	per step, how it is undone; the point past which rollback is no longer available, named
Exit condition	the state that closes the runbook, and the reverse check before normal operations resume
Record	what is written at closure (for an incident, the nine-field record of Contact-Center Incident Severity Matrix)
Last invoked and review	date; an annual tabletop exercise where the entry condition has not fired

The options table is the field a function most often omits and most often regrets: a playbook with steps but no options is a work instruction that will be followed into the wrong response, and one with options but no decision rule returns to the analyst the judgement it existed to pre-make. The checklist literature's recommendation is the same: a short aid used at the moment of action, its length set by the situation's load rather than the author's thoroughness.

What lives here and nowhere above

Thresholds, screenshots and system names live at L3 and never at L2. The rule is the one Process Decomposition (L0–L3) states, and the templates enforce it: the Steps, Values and Systems fields of a work instruction, the Steps and Options of a playbook and the Entry condition and Steps of a runbook are the only places a number, a screen or a product appears; an L2 row that needs one writes SET LOCALLY and names the aid in its join key. The reason is stability: a migration, a recalibration or a new screen changes the L3 document and its register row and nothing above, so L0 approval is not reopened and the L2 table an automation rule was specified from is unchanged. A function that lets a threshold into an L2 row discovers it at the next migration, when every table that carried the number has to be re-approved.

Expiry and review

An L3 document carries a review date and expires with the standard it anchors to; the compliance step of the Process Standardization Lifecycle reports an expired aid as it reports an expired package, and an L3 revision updates the register row without reopening L0 approval. The cadence follows the form: a work instruction is reviewed at each platform release that touches its screens and at the standard's annual expiry; a playbook after every use at the top severity rows and at least quarterly, the cadence Real-Time Exception Handling Playbooks sets for contact lists and escalation paths; a runbook after every invocation and, where it has not been invoked, by an annual tabletop exercise, because a runbook that has never run is a guess.

The catch-rate verification step is a work instruction

Human Gates and Number Grades releases an automation rule for a class of action on a published catch rate, and The Agent Overseer carries the program that produces it. The verification step itself is a recurring, deterministic operations step, and so it is written as a work instruction on the template above: its Steps are the sample and the comparison, its Definition of done is the period's catch rate published per class of action and per variant, and its Review trigger is a change to the rule's specification. Writing it as a work instruction is what makes the catch rate reproducible by a second overseer; a catch rate only one person can produce is not published.

The "Level" collision

L3 on this page is the third documentation level of Process Decomposition (L0–L3), the job aids beneath an L2 step table. It is unrelated to Level 1 Process Templates, whose Level is maturity level one on the WFM Labs Maturity Model™ and whose templates are one-page starter procedures for a function that has none; in this page's terms they are work instructions without a parent standard.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ job aids that exist, are anchored and carry a review date are Level 2 practice; most already exist at that level and the work is sorting them into the three forms and naming them in the join key. The catch-rate work instruction and the options table as the specification a rule is built from are the Level 3 form; at Level 4 the runbook's entry condition is a detector's pattern and the playbook's decision rule is a proposal the action gate presents to the tier that may sign it.

See Also

• Process Standardization — the hub this convention belongs to
• Process Decomposition (L0–L3) — L3 and the join key
• Process Inventory for a Workforce Function — the four process types the forms serve
• Decision Authority Tiers in Workforce Operations — the tier a playbook or runbook names
• Standard and Variant in Process Documentation — SET LOCALLY, and where the local value lives
• Real-Time Exception Handling Playbooks — six exception types and the four-phase playbook structure
• Human Gates and Number Grades — the catch rate the verification work instruction produces
• Level 1 Process Templates — maturity-level-one starter procedures, a different "level"