Forecast Lock Process

Part of the Planning Week chain · previous: Three-Step Forecast Build · next: Forecast Collision Calendar Forecast Lock Process is the section of a function's standard that defines the lock: the published moment at which a forecast for a target period freezes, after which any change is a variance that travels a door with sign-off rather than an edit. It matters because the lock is the interface between the forecast and everyone who acts on it (recruiting, training, finance, partners), and an unlocked forecast gives none of them a date they can plan to. The page produces section S-3.1.2 of the Standard on the ten-block template (template SS) and is worked in a session with Wiki:Packs/ROC Standard Authoring (CP-OPS-003).

The page is shelf material for the standards committee, not a chain block of its own, and it restates nothing the pages it cites carry: the capacity cycle's pencils-down and its business-day calendar are on Capacity Planning Cycle; the governance of revisions and the typical lock horizons on Reforecast and Rolling Forecast Methodology; the storage of what was locked on Forecast Vintages.

The vocabulary is the chain's: 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; a supply seat is a partner capacity block (one supplier, one body of work, one commercial form); the capacity cycle is the six-stage monthly cycle of Capacity Planning Cycle, in which clearing is the stage and netting the computation inside it.

The lock as a calendar

A lock is not an event but a published calendar: for each horizon, what freezes, at what moment, with how much lead time, and who owns the door afterward. The calendar is published a year ahead with an owner, which is the chain's decision D-08 applied to every book on one calendar. Three properties make it usable.

• Lead time is set by the slowest consumer. Each interface that consumes the lock has a lead time: recruiting's source-plus-train-plus-ramp, training's cohort schedule, a partner's schedule-publication clause. The lock moment sits before the longest of them, so that a lock is never published later than the earliest consumer needs it. The interface register of Interconnected Workforce Management does not carry a lead-time field; what it carries on each row is the quantity the lead time is computed from — time to fill on the recruiting row, the cohort schedule and ramp curves on the training row, contract terms on the delivery-partner row — and the owner who can state it. The calendar's lead-time column is obtained from that owner and recorded, never assumed by the forecaster.
• The offset rule. Each horizon's lock sits at a fixed offset from the lock above it and never before it. The mid-term lock is the capacity cycle's pencils-down, BD+7 on the cycle's calendar; the short-term lock sits inside the locked month and may redistribute across weeks and intervals but may not change the month's total; the long-range lock is the budget submission and is the envelope the mid-term lock sits inside. A short-term lock that changes the month is not a lock but a breach, and it goes up through the mid-term door.
• One door after lock. What happens to a change after the lock is Capacity Planning Cycle's stage 5 rule, and this section does not restate it: a change is a variance on an exception path with sign-off, never a silent edit, and a change above a published threshold moves the decision up automatically. What this section adds is that the door has a named owner per horizon, printed in the calendar beside the lock moment, so that a forecaster never has to ask whose door it is.

The mid-term lock mirrors the sales-and-operations-planning lock; the requirement that every revision carries a documented reason above a stated threshold is Reforecast and Rolling Forecast Methodology's, with its source there, and the variance log is what enforces it; the origin and horizon are Hyndman and Athanasopoulos's; the lead times are the practitioner's.

The ten blocks, filled

Purpose

Give every consumer of the forecast a dated commitment at each horizon, so that recruiting, training, finance and partners plan to a number that will not move under them, and so that every change after the commitment is visible, owned and priced.

Inputs

The approved forecast version from Three-Step Forecast Build step 12; each lead time, obtained from the owner of the Recruiting, Training, Finance or Delivery-partner interface on the register; the capacity cycle's business-day calendar; the variance threshold table.

Outputs

The published lock calendar; the locked version, stamped as a vintage; the two partner views (below); the variance log with reason, size, signer and date for every post-lock change.

Roles

The standardization lead owns the calendar; the planner who owns the book signs the lock; the owner of the breached horizon signs a variance; the node owner (the owner of the body of work placed at a node, never the operator of the node) is informed of every lock and consulted on every variance that touches its node.

Method

The L1 flow is one page, eleven steps, four decisions.

L1 flow, section S-3.1.2 Forecast lock

#	Step	Owner	Next
1	Publish the lock calendar for the year ahead, one row per horizon with lead time and door owner	standardization lead	2
2	On the lock date, receive the approved version for the target period	planner	3
3	Is every interface's lead time met by this lock date?	standardization lead	yes → 4 · no → 11
4	Freeze the version; stamp it as the vintage for this horizon	forecaster	5
5	Publish the lock to every interface on the calendar; at a supply seat, publish the billable view and the operational view	standardization lead	6
6	Has a change been requested before the target period opens?	door owner	yes → 7 · no → End; the lock stood and the vintage is the record
7	Does the change exceed the horizon's threshold?	door owner	yes → 8 · no → 10
8	Escalate to the owner of the horizon above; hold the change	door owner	9
9	Does that owner approve the change?	the owner of the horizon above	yes → 10 · no, declined or deferred to the next lock → 6, the decision and its reason recorded
10	Record the variance with reason, size, signer and date; apply it as a new version, never as an edit	forecaster	6
11	Move the lock date earlier or register the interface's shortfall as a dated accommodation	standardization lead	1

The L2 step table runs about thirty rows on the fifteen columns of Process Decomposition (L0–L3) and is produced by the pack. The job aids it names are the calendar template, the variance form and the two partner views.

A partner that receives only a volume number can neither staff nor invoice to it, so the lock is published to a supply seat in two views. The billable view carries productive hours, billable shrinkage hours, total billable hours, training charges and ancillary charges. The operational view carries the handle-time target by book, contacts by book, the occupancy target, the workload capacity and the service-level target. The shrinkage figure in the billable view is the register's definition with its grade and its range; a single customary percentage, quoted without either, is not a basis on which a partner can be asked to staff.

Metrics

Locks published on the calendar date (a proportion); variances after lock by horizon, count and size; the share of variances with a recorded reason; lead-time shortfalls registered. All belong to Level 3; a predicted breach raised before the lock date belongs to Level 4.

Tools

The long-term capacity engine holds the long-range lock; the short-term WFM engine holds the short-term lock and the loaded file; the reporting platform publishes the calendar and the variance log; the data core holds the vintages.

Controls

No edit to a locked version, enforced in the platform's permissions where it can be and in the version log where it cannot; the variance threshold table published with the calendar; the acceptance gate the section passed.

Maturity

Level 1: no lock; the forecast is whatever was last loaded. Level 2: a lock per heritage on its own calendar, often observed and sometimes edited around. Level 3: one calendar for every book, published a year ahead, one door, variances logged. Level 4: the breach is predicted from the daily loop before the lock date and the variance is raised by the team, signed by the planner. Level 5: locks are set by policy and moved by governance bounds, not by hand.

Node attribute and vendor paragraph

All nodes. At a partner supply seat the lock is also a commercial event: the two views are the partner's staffing and invoicing basis, a partner's lead-time clause is a row in the calendar, and a variance that changes the partner's billable hours is also a change-control item under Vendor Change Control for Routing.

Worked example

The chain's function published its first single calendar after decision D-08 on Day 2 afternoon of the planning week (Mon 20 Apr to Thu 23 Apr 2026). Three rows, dated for 2026 and calendar-checked:

The lock calendar, three rows. Lead times are the example's [A]; the offsets are the section's rule.

Horizon	What freezes	Lock moment	Lead time it gives	Door owner
Long-range	the 2027 envelope by month and book	Fri 30 Oct 2026, budget submission	about nine weeks to the year [A]	the function's leader
Mid-term	July 2026	Tue 9 Jun 2026, pencils-down BD+7 of the June cycle	three weeks to month start; recruiting's need-by dates back-computed	the standardization lead
Short-term	the week of Mon 6 Jul 2026	Fri 26 Jun 2026, noon	ten calendar days; the partner's schedule-publication clause is ten days [A]	the planner for the book

One variance followed. On Wed 1 Jul 2026 a partner asked to move 22 FTE of scheduled hours [A] between two weeks inside July; the change was inside the short-term threshold, was signed by the planner, and became version 2026-07-01.v1 with the reason recorded. It did not change the July total and so did not reach the mid-term door. Had the partner asked to add hours to July, the request would have gone to the standardization lead as a breach of the locked month. The numbers are the example's.

The artifact this page produces

Section S-3.1.2 on the ten-block template, template SS, and the lock calendar. One filled example row of the calendar:

ID	Horizon	What freezes	Lock moment	Lead time	Door owner	Threshold
S-3.1.2	short-term	week of Mon 6 Jul 2026	Fri 26 Jun 2026, noon	10 days [A]	the planner for the book	5 percent of the week's hours [A]

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 section claims that one published calendar with one door reduces post-lock changes and makes the remainder visible, and that the offset rule keeps the three horizons consistent. If, after a year on the calendar, the variance log showed as many post-lock changes as the heritage calendars had produced, or showed short-term variances routinely changing month totals without reaching the mid-term door, the calendar would be a publication and not a lock, and the door would be the thing to fix, not the dates. The variance log is the observation; it exists from the first lock.

How this connects

• Previous in the chain: Three-Step Forecast Build — the version that is locked, and the door steps 9 and 10 of that flow use
• Next in the chain: Forecast Collision Calendar — the events that arrive after a lock and the reason a variance is usually raised
• Defers to: Capacity Planning Cycle (stage 5, pencils-down and the business-day calendar) · Reforecast and Rolling Forecast Methodology (revision governance and the typical lock horizons) · Forecast Vintages (the locked version as a vintage)
• Also used by: Vendor Change Control for Routing (a variance that changes a partner's hours)

Maturity Model Position

One calendar, one door and a variance log are Level 3 on the WFM Labs Maturity Model™; a Level 2 function usually has a lock per heritage and adopts the section by publishing the calendar first and enforcing the door second. 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 its flow and the maturity Levels 1–5 in the Maturity block.

See Also

• Planning Week for a Workforce Function
• Anatomy of a ROC Standard
• Three-Step Forecast Build
• Forecast Collision Calendar
• Interconnected Workforce Management — the lead times come from its register
• Human Gates and Number Grades — the number grades used on this page