Expanding Intraday Automation

From WFM Labs

Part of the Planning Week chain · previous: Launching an Analytics Notebook Platform · next: Systems Administration for WFM Platforms Expanding intraday automation is the method by which a workforce planning function grows intraday automation from the pockets where it already runs into a governed layer across the estate, in an order set by how well the work is specified rather than by what the platform can do. It matters because the intraday day is where a wrong action is felt within the hour, and because an automation program that releases actions before it has measured how often its rules are wrong has removed a human check without anyone deciding to. The page produces the intraday sub-plan shell (SP-003) and is worked in a session with Wiki:Packs/Technology Plan (CP-WFM-016).

The page is walked on Day 3 afternoon as the fifth chapter of Technology Migration Plan for a Workforce Function, ten minutes. The layer itself is described on Level 3: The Automation Layer (where it sits, its metrics, its rule lifecycle and why trust is its binding constraint), the intraday cycle on Intraday Management, and the levers on Real-Time Schedule Adjustment; none is restated. Where products are compared, Real-Time Automation Platforms Comparison carries the comparison, and this page names no product.

Start from what already runs

Most estates that have bought intraday automation run it in pockets: one site's break rules, one channel's voluntary-time-off offers, one team's training delivery into lulls. Each pocket was configured for a good reason by people who knew the work, and each carries its own thresholds, its own definitions of a state and its own idea of what an acceptable action is. The first act of expansion is an inventory, not a purchase.

Field Holds Why it matters for expansion
Rule What the rule does, in one sentence The candidate set for the layer
Trigger The signal and threshold it fires on, and which system's definition of the signal Two pockets firing on two definitions of "available" act on two fictions
Action class Trigger · notify · offer · action, per the expansion order below Where the rule sits today on the ladder
Guardrail The bounds inside which it may act without a person What a release widens
Owner and metric The seat that owns it and the metric it is tied to A rule tied to no metric is an orphaned automation
Acceptance rate The share of its offers accepted, where it offers The trust readout; a low rate is a design signal, not an agent failure

The inventory usually finds that the pockets disagree with each other and with the short-term WFM engine about what a state is; that is the definitions problem of The Definitions Register appearing in the real-time layer, and it is why intraday automation is the component at which Technology Journey from Level 2 to Level 5 says the data core stops being optional.

The expansion order

Automation authority is placed by consequence: the machinery may go as far as the stage before the one whose error is costliest, and no further, until its reliability is measured.[1] The four action classes are that principle applied to the intraday day, and the ladder of levels of automation the human-factors literature has used for decades runs the same way, from the machine informing a person to the machine acting and reporting.[2] What decides which class a piece of work may reach is not the platform's capability but the work's specification.

Class The machine… Admitted when the work is… Evidence required
Trigger Detects and records: a threshold crossed, a pattern seen, an interval variance written Anything; detection is never withheld A control chart that separates a special cause from common-cause variation[3]
Notify Tells a named person, with the evidence attached Documented to L1 (the one-page flow) so that the recipient knows the process the notice belongs to The alert classes and escalation protocols of Real Time Threshold Alerts and Escalation Protocols
Offer Proposes an action to the agent or the analyst, who accepts or declines; the decline is a timing signal Documented to L2 (the step table) with the step's owner named; not yet through the acceptance gate An acceptance rate, published per rule
Action Executes inside guardrails and writes back Highly specified: work whose resolution path is written to L2 before the interaction starts, whose L2 has passed the acceptance gate, and whose step ownership and active-voice criteria are met (Process Standardization Lifecycle defines it) A catch rate published for the class of action

"L1" and "L2" here are the documentation levels of Process Decomposition (L0–L3). The order is the process lifecycle's own: the two acceptance-gate criteria that Process Standardization Lifecycle names as the entry test for automation are the criteria that admit work to the action class, so that the standards committee's queue and the automation program's release list are one list read from two ends.

The catch rate before any action class

No action class is released on a maturity level. It is released for a class of action when a catch rate has been published for it: the proportion of known errors in the rule's output that the routine verification step detects, where the known errors are those seeded by deliberate error injection plus those found by independent deep verification of a random sample, reported per process per period with the injection rate and the sample size beside it, as The Agent Overseer defines it. Human Gates and Number Grades states the release condition once for the whole wiki — released per class of action on a published catch rate, not at a maturity level — and records that the level pages now state the same condition, first met by routine micro-moves and extended class by class from there; this page points at that sentence and names no level.

The reason is the oldest one in the automation literature: an operator left with only the cases the automation could not handle, and deprived of the routine that built the competence to handle them, is worse placed than before, and a rule that acts before its error rate is known removes the routine without anyone knowing the price.[4] Error injection is also what keeps the human check alive once an action class is released: a verifier who knows that some fraction of what they review is deliberately wrong cannot rubber-stamp.

The real-time team writes first

Where an agent team joins the intraday day, its first form writes and does not act. Real-Time Agents gives the three roles (monitor, detector, issuer) and what they write: an interval variance record, a detection with its matched events and a proposed severity, an incident issued into Incident Management for Contact Centers with the evidence attached, an event proposed into the intelligence ledger, and a reoptimization proposal carried to the action gate where a real-time analyst decides. That is the trigger and notify classes done by agents, plus the offer class with a person at the gate; the action class waits for the catch rate the gate's outcome record produces. The expansion order on this page and the ladder on The Agent Team Ladder: Alpha to Production are the same discipline seen from the layer and from the team.

Two things the writing produces are worth the wait. Incidents arrive with the evidence rather than a time and a symptom, so the post-mortem starts from the record. And the day's events reach the forecaster: an outage at 10:20, a client's release, a weather day, each proposed with an effect window and confirmed by a person, which closes the loop from the day back to the forecast that most functions leave open.

Cross-node reallocation as a placement horizon

A node is a place work can sit: a hub, a service center, a partner, or automated. Moving supply between nodes during the day (overflow to a partner, a service center picking up a hub's queue, an automated node taking a class of contacts) is not a lever like a break move. It is placement at the intraday horizon, and it belongs to the placement engine's last step (Placement Engine Build Path): the engine recomputes where supply should sit when a trigger fires, and intraday automation executes the move inside guardrails the constraint register sets. The node owner, the owner of the body of work placed at a node and never the operator of the node, decides; the function owns the method. An intraday reallocation that crosses a partner boundary is also a routing change touching a partner node, and Vendor Change Control for Routing governs it. Nothing here changes the lever taxonomy Real-Time Schedule Adjustment describes for moves inside one node; it draws the line at the node boundary, where a move becomes a placement.

The overseer

For every released action class the layer needs an overseer: the accountable person each rule's identity resolves to, who runs the error-injection and sampling program that produces the catch rate, reviews the exception queue, and decides whether the class is still fit to run without a person. The Agent Overseer defines the role; here it is noted only that the overseer is sized by exceptions and stakes, not by rule count, and that the real-time analyst who becomes the automation orchestrator on Level 3: The Automation Layer is often the first overseer.

Worked example

The series example's intraday day is Wednesday 8 April 2026: staffing 11 percent under schedule from 09:00 [M], the voice service level below target from 09:15, the detector's severity 2 proposal, the issuer's incident with arm 1 of the fishbone indicated and arm 3 ruled out, and the break shift for nine agents (proposal R-044) approved by the real-time analyst at the action gate at 09:24 and executed by the platform. On Day 3 afternoon, Wednesday 22 April 2026, the room opens SP-003 with the inventory as its first deliverable: the pockets running today counted and their triggers mapped to the register's state definitions, by Tuesday 30 June 2026. The first candidate for the action class is break resequencing, the cost-neutral and lowest-risk lever; it is not released until its catch rate is published. The real-time team is at its beta rung when the week opens: its issuer has been writing incidents and events beside the analyst since Wednesday 8 April 2026, and beta is the rung on which the catch rate is measured by error injection. What the week decides is the next rung and the clone onto a second book; the first action class is released not before Q4 2026, per class and per catch rate, on the ladder The Agent Team Ladder: Alpha to Production carries. The training pull of 14 agents [M] on 8 and 9 April, an event the collision calendar did not yet hold, is the example the room uses for why the layer's first value is what it writes.

The artifact this page produces

The sub-plan shell (SP), one row for intraday automation. One filled example row:

ID Sub-plan Owner (seat) First three deliverables Depends on (build-order step) Measure Quarter
SP-003 Intraday The real-time standards seat; the first overseer named per released class The rule inventory with triggers mapped to register states (by Tue 30 Jun 2026); the expansion order applied to every inventoried rule with its class; the first action class released on a published catch rate (not before Q4 2026) Step 1 (state definitions in the register); step 4 for cross-node reallocation Acceptance rate per offering rule; catch rate per released class with injection rate and sample size; days-to-detection Q2 2026 to Q4 2026 for the first release (the example's quarters)

Produced in a working session with Wiki:Packs/Technology Plan (CP-WFM-016); the filled set is part of blueprint v0.1.

What would change this

The page claims that releasing an action class before its catch rate is published removes a human check at an unknown price, and that the specification of the work, not the platform's capability, decides the class. The observation that would overturn it is an estate that released action classes on platform capability alone, without catch rates or L2 documentation, and whose incident record over a year shows no class of error the human check would have caught. If that estate exists, the catch-rate bar is caution rather than necessity and the expansion order can run on acceptance rates alone.

How this connects

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. This page uses Process Decomposition (L0–L3)'s documentation levels for the expansion order and the WFM Labs Maturity Model™'s Levels 1–5 here. The inventory and the trigger and notify classes are Level 2 work; the layer with offers and released actions is Level 3; automation that runs the analytical layer's rules and returns telemetry the notebooks read is Level 4. Which level releases a gate is not stated here; the evidence releases it.

See Also

References

  1. ↑ Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). "A model for types and levels of human interaction with automation". IEEE Transactions on Systems, Man, and Cybernetics — Part A 30(3), 286–297. doi:10.1109/3468.844354.
  2. ↑ Sheridan, T. B., & Verplank, W. L. (1978). Human and Computer Control of Undersea Teleoperators. MIT Man-Machine Systems Laboratory, Cambridge, MA. Technical report.
  3. ↑ Montgomery, D. C. (2019). Introduction to Statistical Quality Control (8th ed.). Wiley. ISBN 978-1-119-39930-8.
  4. ↑ Bainbridge, L. (1983). "Ironies of Automation". Automatica 19(6), 775–779. doi:10.1016/0005-1098(83)90046-8.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Expanding_Intraday_Automation&oldid=4734"