Process Decomposition (L0–L3)

Process Decomposition (L0–L3) is a documentation standard for operational processes: one process, four artifacts, each written for a different reader. Level 0 is the cover sheet that gives the document an identity — owner, approvers, scope, revision history. Level 1 is the flow diagram that shows the entire process on one page. Level 2 is the step table that decomposes every Level 1 step into owned, timed, tool-bound sub-steps. Level 3 is the set of job aids and work instructions that the Level 2 table names.

The four levels. L0 says who owns it and what it is; L1 shows what happens, in order; L2 says how each step is done, in fifteen columns, with the job-aid column as the join key; L3 holds the exact instructions.

The levels are not the same content at four zoom settings; they are four different documents joined by exact cross-references, and the joining mechanism — one column in the Level 2 table — is what keeps a process library navigable as it grows.

The standard descends from production use in contact-center real-time operations (it was developed to document the processes of a Resource Optimization Center (ROC)), and from two older lineages: the quality-management documentation pyramid, which established the pattern of distinct document types per level, and structured analysis, which established the numbered-level decomposition with a context view at the top. It differs from a process classification framework such as APQC's, which taxonomizes what processes exist; this standard documents how one process runs. One deliberate departure from the structured-analysis lineage: there, Level 0 denotes the context diagram — the whole system in one view. This standard reassigns Level 0 to document identity and moves the whole-process view to Level 1, reserving the zero level for the artifact every document needs before anything is drawn.

The four levels

Level 0 — document identity

A form, not prose: procedure name, organization, document ID and type, category, owner, document home, publication and expiration dates, a two-to-three-sentence abstract stating purpose and scope, authors, peer reviewers, approvers, keywords, and a revision history. Every field is filled or explicitly marked TBD — an empty field is indistinguishable from a forgotten one. Level 0 takes minutes to complete; its function is to force scope agreement before any step is drawn — the abstract is where "what is this process for" gets settled.

Level 1 — the flow

A one-page flowchart of the major steps only, numbered with integers, each carrying a name and an owner. Decisions are diamonds phrased as questions ("Ticket created?") and receive their own step numbers; iteration is drawn as a loop, not implied in prose. Ten to fifteen steps is the healthy range — more suggests the process wants splitting, fewer suggests steps are hiding sub-processes. Level 1 exists to be read in thirty seconds by someone who will never open Level 2.

Level 2 — the step table

Every Level 1 step decomposes into sub-steps numbered parent.child — 1.1, 1.2, 4.5 — where the integer is the parent Level 1 step. The table has fifteen columns:

Column	Meaning	Example
L1 Step ID · L1 Step Name · Step Description	The parent step, carried on every row; one-sentence summary	6 · Conduct Fault Analysis · Diagnose the driver of the incident
L2 Step ID	parent.child	6.2
L2 Step Name / Short Description	The narrative column — what is actually done	Diagnose using the cause-and-effect diagram; four top-level causes
Dependent Steps (L1 or L2)	May reference either level; alternatives allowed	"3.1 or 4.5"
Tools Used	Named systems	Real-time dashboards
Ticketing Code · Ticket Status	Where a ticketing system is written to	No · Open
Step Owner (Group & Function)	Entered once per parent step	ROC Real-Time Team
Applicable Documentation	The L2→L3 join key — names the job aid	Job Aid: Real-Time Cause-and-Effect Diagram
Notification Required?	Group, function, and verbiage	Yes — fix agents
Approval Required? · Approvers	Yes/No · group and function	No · N/A
Step Duration	days / hrs / min; "Continuous" is legal on monitoring steps	Minutes–hours

Two conventions carry meaning. First, merging means constant: the parent-step columns merge vertically across a step's rows, and any attribute merged rather than repeated is asserted not to vary within the step. Second, decision steps put the question in the Level 1 row and the branches as Level 2 rows ("If yes, proceed to step 11").

Level 3 — job aids and work instructions

The documents the Level 2 table's Applicable Documentation column names: escalation charts, classification matrices, cause-and-effect diagrams, screenshot-level walkthroughs. Each anchors back to the parent-standard section it details. Level 3 is deliberately where thresholds, screenshots, and named systems live — which is why Levels 0–2 stay stable across tool changes while Level 3 revises often, and why they are separate artifacts rather than sections of one document. A Level 3 revision does not reopen Level 0 approval: the register row updates and the revision history notes it. Level 0 re-approval is triggered only by changes to scope, ownership, or the Level 1 flow.

The join key

The Applicable Documentation column is the mechanism that makes four documents one tree. Reading downward: any Level 2 row names the job aid that details it. Reading upward: every Level 3 document is reachable from the rows that depend on it, and anchors to a section of the parent standard. A process library built this way can answer "what breaks if this job aid changes" by searching one column, a property flat document folders do not retain.

What sits above Level 0

The framework assumes a parent standard: the document that owns all of a function's processes, gives each a section, and holds the shared material — definitions, severity models, escalation codes, metric glossaries. A decomposition package is the drill-down of one section of that standard. Decomposing a process without a parent standard works, but the shared material ends up duplicated into every process, and drifts.

Building order

Level 0 first — five minutes that force scope agreement. Level 1 with the process owner present. Level 2 one parent step at a time. Level 3 last: most of it already exists as scattered job aids, and the work is naming them in the table and anchoring them to the standard. In practice the sequence surfaces disagreements early and cheaply: two owners for one step, a decision nobody makes, a job aid that never existed.

Relation to other conventions on this wiki

The process levels here (L0–L3) are a documentation hierarchy — a different artifact per level — in the same family as the documentation ladder described on Capacity Planning Cycle, with Level 0 added as the identity layer. They are unrelated to the WFM Labs Maturity Model's organizational levels (as in Level 1 Process Templates, which are maturity-level-one starter SOPs). A worked example of the full standard is Incident Management for Contact Centers, and a deployable project setup for producing decompositions is Wiki:Packs/Process Decomposition (CP-OPS-001).

From standard operating model to automation

Decomposition does two jobs at once. It gives every team one way of working, and it shows which steps are written down and proven enough for agents to take, which need a person checking, and which stay with people.

The standard has a second use beyond documentation. A function assembled from several heritages needs one way of working before it can automate anything, and the decomposition is how that standard is produced: the same process written to L0–L3 in every team means the same thing everywhere (Standardize Before You Automate). Once written down, each L2 step carries the fields an automation decision needs — the tools it touches, who owns it, whether approval is required, how long it takes — and the level of documentation becomes the sorting rule of the three bands of work: a step is discretionary until it has an L1 flow, eligible to be overseen once it has an L2 row with a measured definition of done, and eligible for agentic execution once it has L3 instructions and a published catch rate. The agentic handover gate's first test is that a process is documented to this standard, and its permission map for an agent is read from the L2 tools column. Decomposing a function's processes is therefore not a preliminary to automating them; it is the step that reveals which pieces of the ecosystem can be specified and handed to agents, which need an overseer, and which must stay with people. The sequence in which a function moves through that is the agentic journey map.

Maturity Model Position

• Levels 1–2: processes live in heads and scattered documents; adopting Level 0 and Level 1 alone — identity plus a one-page flow — captures most of the early value.
• Level 3: the full four-level tree with a parent standard; real-time processes documented to Level 2, job aids anchored.
• Levels 4–5: the Level 2 tables become machine-readable inputs — owners, dependencies, and durations feeding process automation and conformance checking rather than existing only for human reference.

See Also

• Incident Management for Contact Centers — the worked example of this standard
• Capacity Planning Cycle — carries the companion documentation-ladder discussion
• Level 1 Process Templates — maturity-level-one starter SOPs (different "level" scale)
• Resource Optimization Center (ROC) — the operating environment the standard grew in
• WFM Processes — the process architecture these decompositions document
• Three Bands of Work — documentation level as the sorting rule for what agents may take
• The Agentic Handover Gate — the tests a documented process passes before agents run it
• Standardize Before You Automate — why one way of working comes before any automation
• The Agentic Journey Map — the stage sequence decomposition sits within
• The Automation Analyst — the role that reads the L2 table to specify an agent