Anatomy of a ROC Standard

Part of the Planning Week chain · previous: The Agent Team Ladder: Alpha to Production · next: Three-Step Forecast Build Anatomy of a ROC Standard is the document pattern by which a workforce function issues its standard: one document that owns every process the function runs, gives each process a section, and holds the shared material the sections draw on. It matters because a function assembled from several heritages otherwise carries its method in people, spreadsheets and platform defaults, none of which can be audited, cited or handed to an agent team. The page produces the Standard front matter and the §2 function catalog (template SD), one catalog row per function keyed by its section number, and is worked in a session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003).

It is issued by a global ROC, the shared service that owns the methodology for forecasting, scheduling, real-time steering and work placement across every node. A node is a place work can sit: a hub (in-country depth), a service center (badged arbitrage at scale), a partner (speed, market access, flex), or automated. It binds the function, and binds a node owner (the owner of the body of work placed at a node, never the operator of the node) only where Decision Rights by Planning Horizon makes the node owner accountable. Two more terms recur: the gate is the six-test, five-outcome check a placement question runs through, on The Placement Gate; the registers are objectives, constraints, definitions, the counterfactual record and the executive issue register, under one steward.

A practice standard, a certification standard and a document pattern

Three things on this wiki are called standards, and they are different objects. The Future WFM Operating Standard is a practice standard: what a function should do, pillar by pillar, with its elements activated level by level; Workforce Management Standard Introduction sets out the traditional contact-center practice that standard builds on. The COPC Standard is an external certification standard: certified auditors verify an operation against published, auditable items. This page is neither. It is the form of the document a function writes for itself, recording which practice it has adopted, for which processes, at what level of conformance, and who owns each section. A function adopts the practice standard by issuing a document in this pattern, and seeks certification by mapping the document's sections to the certifier's requirements. The chain reaches this page on Day 2 afternoon, after Process Shells for a Workforce Standard and Process Standardization Lifecycle, and returns on Day 4 morning to issue version 0.1.

The pattern also has a place in the wiki's documentation ladder. Process Decomposition (L0–L3) describes four artifacts per process (cover sheet, one-page flow, step table, job aids) and names a parent standard above them. This page is that parent: a decomposition package is the drill-down of one section, and the section's Method block is where the L1 flow lives and the L2 table is named.

The front-matter fields and the expiry rule follow ISO 10013; the separation of requirements from their verification follows the ISO/IEC drafting directives; the certification mapping is to the COPC form; the incident and change practices are ITIL's; the catalog convention is APQC's.

What the pattern keeps and what it changes

Three properties of a standard document are worth keeping whatever the estate, and the pattern keeps them. Front matter with an expiry, because the expiry is what forces the annual review; a standard without one is reviewed when someone remembers. A function catalog sorted by class, where every function is strategic (it sets the plan), real-time (it steers against the plan), both, or supporting (it serves the others) — a distinction that survives any org chart, because it describes what a function does to the plan rather than where it reports. And one detail section per function in one fixed shape, so that a reader who has read one section can read them all.

Three properties are worth replacing, because each fails on an estate of several platforms and more than one channel. A toolset written around named products dates the document to its next migration, so the toolset here names capabilities and the products sit in a reissuable annex. A metrics section fixed to a list of voice-queue measures cannot carry a chat or an email operation and states no outcome at all, so the metrics here are channel-neutral and an outcome band sits above the operational band. And a validation clause with no owner, no cadence and no scale cannot be run, so conformance is asserted rather than checked; §6 names all three.

One property is kept and corrected. Publishing the shape before it is filled is right: a standard that waits for completeness is never issued. But a placeholder with no owner and no date is a wish, and the section behind it does not get written. Every placeholder in this pattern carries an owner and a date, which is the substance of the chain's decision D-11.

Front matter

The front matter is a form. Every field is filled or marked to be filled with an owner and a date; an empty field is indistinguishable from a forgotten one.

Field	Rule
Title	The function's name and the word Standard; no platform, no estate identifier
Abstract	Two or three sentences: what the document is, who it binds, where its method pages live; written last
Point of contact	A seat (a post on the org chart: a director-graded or manager-graded box, its scope and its sunset condition), never a name; the methodology steward on the chain
Contributors	Seats, listed by section
Release version, date, expiry	0.1 on issue; the expiry is twelve months from issue and is the review trigger
Approvers by title	The function's leader, its council, a finance partner for §5
Confidentiality	Internal; the method pages it cites are public
Approvals · change history · references	The change history starts at 0.1; references cite the wiki's method pages by title, never restated
Index keywords · glossary · contents · figures · tables	The glossary starts from the chain's vocabulary

§1 Scope and the conformance scale

§1 says what the Standard is, who it binds, and how conformance is read. Each function conforms at a level of the five-level ladder, by the level's canonical name and number (1 Initial · 2 Foundational · 3 Progressive · 4 Advanced · 5 Pioneering), recorded by the certification clause in §6, and stated as a band, never a point, until the validation circuit has run. §1 also lists the temporarily accommodated variations: the places where a heritage still runs its own method, each with the date on which the accommodation expires, the same date as the "skeleton until" date of the section that replaces it. A variation accommodated temporarily but without a date is accommodated permanently; the date is what makes the word mean anything.

§2 The function catalog

§2 is a table with one row per function: section number, function, class, owner (a seat), and the date until which the section is a skeleton. Each row is keyed by its section number — S-3.1, S-3.1.2 — and names the L0 process card that decomposes it; Process Shells for a Workforce Standard defines the shell and the card in full.

The generic function catalog. Classes are the wiki's; a function's owner and skeleton date are local.

§	Function	Class
§3.1	Forecasting (long-range, mid-term, short-term)	strategic; the short-term step is both
§3.2	Capacity planning and the monthly cycle	strategic
§3.3	Scheduling	both
§3.4	Real-time performance and automation	real-time
§3.5	Intake and the register	supporting
§3.6	Incident management, with the continuity wire	real-time
§3.7	Work placement: the gate, the registers, the forum	both
§3.8	Reporting, metrics and analytics	supporting
§3.9	Data definitions and governance	supporting
§3.10	Routing and the capability layer	real-time in operation; strategic in design
§3.11	Business improvement and best-practice sharing	supporting

Two rules govern the catalog. First, vendor governance is not a function and has no section. A standard that gives vendor management a function of its own has to bolt vendor forecasting, vendor routing and vendor change control onto each core function as an exception, and the exceptions multiply with every node added. Here every section carries a node attribute (which nodes the function runs on) and a vendor paragraph (what changes when the node is a partner supply seat, a partner capacity block: one supplier, one body of work, one commercial form). Second, a function with more than one distinct process nests them: §3.1.1, §3.1.2 and §3.1.3 are three ten-block sections under §3.1, and nothing is inherited silently; a block that is the same as the parent's says so.

A standard section and an L0 process card are different objects, and the chain keeps their keys apart. A section is keyed by its section number — S-3.1.1, S-3.1.2 — and is a part of this document. An L0 card is keyed P-nnn, is the identity sheet of a process, and is defined on Process Shells for a Workforce Standard; one card may stand behind two sections, as the card for the short-term forecast build and its lock stands behind S-3.1.1 and S-3.1.2.

§3 The ten-block section

Every §3.x has the same ten blocks in the same order. The Method block is where the content lives; the other nine frame it.

Block	What it carries
Purpose	One paragraph: what the function is for, in scope terms
Inputs	What arrives, from which interface, on what cadence; cites the interface register row of Interconnected Workforce Management
Outputs	What leaves, to whom, in what form
Roles	Who does it, who owns the method (the function), who owns the decision (the RACI row)
Method	The L1 flow (numbered whole steps, decisions as questions, one page); the L2 step table named, never reproduced; the job aids named
Metrics	The function's rows on the scorecard, with the level each belongs to
Tools	Platform-neutral capabilities used; the annex maps them to products
Controls	The acceptance gate the section passed; the change-control path; where a step executes without approval, the published catch rate that released that class of action, in the terms Human Gates and Number Grades states and the wiki's level pages agree on
Maturity	One line per level; where it is today, as a band
Node attribute and vendor paragraph	Which nodes; what differs at a supply seat

The chain's shelf fills the ten blocks for six functions: Three-Step Forecast Build, Forecast Lock Process and Forecast Collision Calendar under §3.1; Activity-Code Consistency under §3.3; Call-Sharing Models and Cost Allocation and Vendor Change Control for Routing under §3.10. The incident set fills §3.6: Event, Incident and Problem in Contact Centers (definitions), Contact-Center Incident Severity Matrix (controls), Incident Management for Contact Centers (the process itself), Real-Time Cause and Effect Fishbone (the diagnostic frame) and Post-Mortem and RCA for Workforce Operations (the learning loop). The standards committee authors the rest in the queue order Process Standardization Lifecycle sets.

§4 Toolset, §5 metrics, §6 validation

§4 Toolset names capabilities: the long-term capacity engine, the short-term WFM engine, intraday automation, the Python analytics platform, the reporting platform, the data core, the event ledger and the register. A tool-mapping annex is the only place a product name appears, so the Standard outlives any one platform. The eight lifecycle facts Incident Management for Contact Centers requires at closure — start, detected, fix agents engaged, customer impact, probable cause, mitigation, diagnosed, repaired — are kept here as a job aid, with one addition this Standard makes: each carries its time zone, because a bare clock time reads differently at every node.

§5 Metrics has two bands. The outcome band pairs a quality score with a customer-experience index and a cost per unit of value, in the sense Quality Score and Customer Experience Index defines, paired and never blended. The operational band is channel-neutral by construction — contact rate, offered, handled, abandoned, handle time, speed of answer, resolution, service level, transfers — each stated once for every channel rather than once for voice. Every metric names its instrument, its resolution and what it is paired with, and reads its definition from The Definitions Register; the six core definitions are the register's, not the Standard's.

§6 Validation and certification names an owner (the methodology steward), a cadence (annually against the expiry; per function when a section leaves skeleton status) and a scale (the five-level ladder, one line per function), and checks process use to the L2, toolset and configuration to the annex, the register's readout times, the severity definitions and the cross-node reviews taking place. The steward is deliberately not the standardization lead: a seat that carries a book migration must not certify the standard the migration is measured against. The separation is what lets one seat own the forecasting, scheduling, real-time and placement standards and lead the migration of the largest book without the migration owning the standard. The appendices carry the ownership map (local), the glossary of node names and the interface table.

Worked example

The chain's function, a workforce planning function formed from three heritages, roughly 40–50 planners [E] serving about a dozen books of business across voice, chat and email, at maturity level 2 as a band [A], issued its Standard v0.1 on Thu 23 Apr 2026, the last morning of a planning week that ran Mon 20 Apr to Thu 23 Apr 2026. Decision D-11 was one act: owner (the methodology steward), approvers, expiry Fri 30 Apr 2027, and an owner and a date against every skeleton section. The catalog had eleven rows and no filled section. The first three sections queued were S-3.1.1 (the three-step build), S-3.1.2 (the lock) and S-3.1.3 (the collision calendar), with "skeleton until" Fri 25 Sep 2026 for the short-term step and Thu 31 Dec 2026 for the mid-term; the routing sections S-3.10.1 and S-3.10.2 and the activity-code section S-3.3.1 carried Wed 31 Mar 2027. Three accommodated variations were listed: two heritage forecast calendars (expiring with the single calendar of D-08, pencils down Tue 9 Jun 2026) and one heritage activity-code set (expiring Wed 30 Jun 2027 with the second platform instance). The validation circuit closed Fri 8 May 2026 and corrected two owners. The counts are the example's, graded [A].

The artifact this page produces

The Standard front matter (the table above, filled) and the §2 function catalog, template SD, one row per function. One filled example row:

ID	§	Function	Class	Owner (seat)	L0 card	Skeleton until	Lifecycle status
S-3.1.1	§3.1.1	Three-step forecast build	strategic; short-term both	the standardization lead	the short-term forecast build and lock card	Fri 25 Sep 2026	skeleton; authoring queued

Produced in a working session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003); the filled set is part of blueprint v0.1.

What would change this

The page's central claim is that a function which issues its standard with an expiry, a seat and a date against every section completes the sections, and one that issues placeholders without them does not. If, at the first expiry, sections carrying an owner and a date were no more likely to have left skeleton status than sections carrying neither, the owner-and-date rule would be decoration and the pattern would reduce to a published table of contents. The §6 certification at the first expiry records the observation.

How this connects

• Previous in the chain: The Agent Team Ladder: Alpha to Production — the rungs an agent team climbs on a written-down section
• Next in the chain: Three-Step Forecast Build — the first §3.x section, filled
• Walked with: Process Shells for a Workforce Standard (the T4 shell) · Process Standardization Lifecycle (the acceptance gate every section passes) · Instantiating the GRPI-T Framework (the Processes pillar)
• Defers to: Future WFM Operating Standard (the practice the document records) · Workforce Management Standard Introduction (the traditional practice) · COPC Standard (external certification) · Process Decomposition (L0–L3) (the four artifacts below each section) · Incident Management for Contact Centers (the real-time process, its severity codes and the eight lifecycle facts it closes on)

Maturity Model Position

Issuing the document is a Level 2 act on the WFM Labs Maturity Model™: what a function with documented processes does to make them one set. Certifying each function at a level, and running the sections through an acceptance gate so an agent team can be handed them, is its Level 3 use. Four scales on this wiki use the word "level"; Planning Week for a Workforce Function states which is which. This page uses the documentation levels for the sections and the maturity Levels 1–5 for the conformance scale.

See Also

• Planning Week for a Workforce Function
• Process Shells for a Workforce Standard
• Process Standardization Lifecycle
• Human Gates and Number Grades — the number grades