Forecast Collision Calendar

Part of the Planning Week chain · previous: Forecast Lock Process · next: Event, Incident and Problem in Contact Centers Forecast Collision Calendar is the section of a function's standard that keeps one calendar of every event that will move demand or supply (go-lives, releases, campaigns, holidays across nodes, migration phases, training pulls, planned outages), entered the month it becomes known, each with an effect window and a grade, and checked for collisions before any forecast build reads it. It matters because a practitioner observation this wiki carries as Inferred, not measured, is that most forecast misses are explained by events the operation knew about and did not write down where the forecaster would read them. The page produces section S-3.1.3 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 calendar is the human face of the event ledger that The Intelligence Feed describes: the ledger is the append-only record an agent team reads and writes; the calendar is the same rows drawn on a timeline for the people who enter and read them. The page is shelf material and restates nothing its neighbors carry: the severity matrix and response protocol for conditions already degrading service are on Event Management; the typing, windowing, grading and match-to-miss rules on The Intelligence Feed; the pipelines that carry upstream signals on Workforce Demand Signal Architecture; peak and campaign staffing on Seasonal Staffing and Campaign Planning.

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 seat is a post on the org chart (a director-graded or manager-graded box, its scope and its sunset condition).

One calendar, entered when known

The section's rule is in its name. There is one calendar for every book and every node, not one per heritage, because a collision between two heritages' events is exactly the kind no single heritage can see. An event is entered the month it is known, not the month it happens, because the long-range and mid-term builds read the calendar months ahead and an event entered late is invisible to the horizon that needed it most. And an entry is a collision check, not just a record: before the row is saved, the calendar tests it against every row whose effect window overlaps, on the same book, the same node, or the same lock window, and flags the overlap for the forecaster.

An event carries the record The Intelligence Feed defines — type, date, effect window, grade and the misses it has been matched to — plus the two fields the calendar adds: the books and nodes it touches, and an owner. A known event is dated and belongs here; an occurrence already degrading service is an incident and belongs to Incident Management for Contact Centers, which names a collision calendar as the instrument that manages the first kind in advance. The calendar is where an incident is later matched to the event behind it, so that the post-mortem can say whether the event was on the calendar and, if it was, whether the build read it. The distinction between the three words is defined once, on Event, Incident and Problem in Contact Centers, and used here.

The effect window follows Box and Tiao; the regressor treatment follows Hyndman and Athanasopoulos; the three words and the change calendar are ITIL's; the driver list is the practitioner's.

Collision rules

A collision is two or more events whose effect windows overlap on the same book or node, or an event whose window overlaps a lock window. The rules do not resolve the collision; they make it visible to the person who can.

Collision	Rule
Two demand events in one window on one book	Both are applied in the build's event layer; the forecaster registers whether their effects add or overlap, as an assumption with a grade
A demand event and a supply event in one window	Flagged to the planner: the build must show both the demand adjustment and the supply adjustment, not their net
A holiday at one node and not another	Applied per node; a cross-node report for the window is marked as mixed
An event inside a lock window	The event does not move the locked version; it raises a variance through Forecast Lock Process
A migration phase and any other event on the migrating book	Flagged to the placement lead; the other event is deferred or the phase absorbs it, and the decision is recorded
An event entered after the horizon that needed it has locked	Recorded with its late-entry date, so the miss it causes is attributed to entry, not to the forecast

The ten blocks, filled

Purpose

Hold every known event in one place, dated and windowed, so that every forecast build at every horizon reads the same events, so that collisions are seen before they are felt, and so that a miss can be matched to the event that caused it.

Inputs

Events from every interface on the register of Interconnected Workforce Management: Operations (go-lives, service breaks, training pulls), Technology (releases, planned outages, migration phases), Commercial (campaigns, client announcements), Human resources (holidays by node, policy dates), Delivery partners (their own calendars). Business asks enter as events on the rule The Intelligence Feed states. External events (weather with lead time, public holidays, regulatory dates) arrive through the intelligence feed.

Outputs

The calendar, read at Three-Step Forecast Build step 6 at every horizon; the collision flags to the forecaster and the planner; the late-entry log; the match between an incident and its event, written to the incident record.

Roles

Every interface owner enters its own events; the forecaster reads them; the scout role (a person with a form at first, the agent later) gathers external events and proposes them; the standardization lead owns the calendar's rules; the planner decides a flagged collision for the book, and the placement lead decides one that touches a migration phase.

Method

The L1 flow is one page, twelve steps, three decisions.

L1 flow, section S-3.1.3 Forecast collision calendar

#	Step	Owner	Next
1	Receive a known event from an interface or the feed	interface owner or scout	2
2	Type it (demand, supply, system, migration); date it; set the effect window; grade it; name the books and nodes	interface owner	3
3	Does its window overlap another event's on the same book, node or lock window?	the calendar (rule)	yes → 4 · no → 5
4	Flag the collision to the forecaster and the planner with the rule that applies	the calendar	5
5	Save the row	interface owner	6
6	Has the horizon that needed this event already locked?	the calendar (rule)	yes → 7 · no → 8
7	Log the late entry with its date; raise the variance through Forecast Lock Process	interface owner	8
8	Read the window at every forecast build (step 6 of the build)	forecaster	9
9	After the window closes, match any miss or incident in it to the event, as an association and not as a cause	forecaster; real-time lead	10
10	Was the event on the calendar before the horizon that missed it locked?	forecaster	yes → 11 · no → 12
11	Attribute the miss to the layer that applied the event; record it against the build's vintage	forecaster	12
12	Update the event's grade from what arrived; close the row, and where step 10 answered no, close it in the late-entry log	forecaster	End

The L2 step table runs about twenty-five rows on the fifteen columns of Process Decomposition (L0–L3) and is produced by the pack. Its job aids are the entry form, the collision rule table and the matching procedure.

Metrics

Events entered before the horizon that needed them (a proportion); collisions flagged and decided before the lock; misses matched to an event; misses attributed to late entry. The first three belong to Level 3; a feed that proposes events before an interface owner enters them belongs to Level 4.

Tools

The event ledger on the data core; the reporting platform for the timeline view; the short-term WFM engine and the long-term capacity engine read the calendar at their builds; the Python analytics platform for the matching.

Controls

One calendar, no private lists; an event with no owner is not saved; a locked window is read-only for the locked version; the acceptance gate the section passed.

Maturity

Level 1: events are remembered. Level 2: each heritage keeps its own list, read by its own forecaster. Level 3: one calendar with effect windows and grades, entered when known, read at every build. Level 4: the feed proposes events and matches misses; the planner confirms. Level 5: the calendar drives reforecast on trigger within governance bounds.

Node attribute and vendor paragraph

All nodes. A partner supply seat (a partner capacity block: one supplier, one body of work, one commercial form) enters its own events (its holidays, its site moves, its training pulls) through its oversight owner, and reads the calendar for the books it serves; it never reads another node's rows.

Worked example

The chain's function's calendar for 2026, six rows, dated and calendar-checked. The migration is the worked example's phased servicing-platform migration, referred to only that way.

Six rows of the calendar. Effect windows and grades are the example's [A].

ID	Event	Type	Date	Effect window	Books, nodes	Entered	Collision
CAL-001	the migration, phase 2 go-live	migration	Mon 30 Mar 2026	open from the date	the migrating book, all nodes	Fri 27 Mar 2026 (late, after the March lock)	—
CAL-002	the migration's service break	supply and demand	Wed 8 Apr 2026	Wed 8 to Fri 10 Apr	the migrating book, hub and partner	Fri 27 Mar 2026	with CAL-001; absorbed by the phase
CAL-003	public holiday at one node	supply	Mon 25 May 2026	the day	all books, one hub	Thu 23 Apr 2026	none; cross-node reports for the week marked mixed
CAL-004	a release	demand	Thu 9 Jul 2026	Thu 9 to Fri 10 Jul	two books, all nodes	Wed 24 Jun 2026	inside the short-term lock window; variance raised
CAL-005	the second book's migration window opens	migration	Mon 14 Sep 2026	open from the date	the second book, all nodes	Tue 30 Jun 2026	—
CAL-006	a release	demand	Wed 16 Sep 2026	Wed 16 to Thu 17 Sep	the second book	Fri 25 Sep 2026 (late)	with CAL-005; flagged at entry; recorded in the late-entry log

The row that explains the early-March miss on the migrating book is the phase 1 go-live of Mon 2 Mar 2026, which The Short-Term Forecasting Loop with an Agent Team scores at voice handle time 452 seconds [M] against 412 seconds [C], the 412 then relabeled carried [A]; CAL-001 is the phase 2 row entered on the same late footing. CAL-004 is the row the calendar exists for: a release proposed into a week that had already locked, caught at entry because step 3 tests every window against the lock, and raised as a variance rather than found afterward in the actuals. CAL-006 is the counter-case and the reason the late-entry log exists: entered nine days after its own date, it reached the log rather than the build, and its collision with CAL-005 was decided after the fact instead of before. The rows are the example's, not a measured record.

The artifact this page produces

Section S-3.1.3 on the ten-block template, template SS, and the calendar, whose entries are keyed CAL-nnn. One filled example row:

ID	Event	Type	Date	Effect window	Grade	Books, nodes	Owner (seat)	Entered	Collision
CAL-004	a release	demand	Thu 9 Jul 2026	Thu 9 to Fri 10 Jul 2026	[A]	two books, all nodes	the technology interface owner	Wed 24 Jun 2026	inside the short-term lock window; variance raised

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 most misses in a service operation are matched to events that were knowable in advance, and therefore that one calendar entered when known removes a large share of them. That claim is Inferred, not measured, and The Intelligence Feed grades it the same way. If, after two quarters on the calendar, the matching step found that most misses matched no event, or matched events that had been on the calendar before the lock and were read by the build, the calendar would not be the instrument the misses need and the claim would be refuted. The matching log is the observation; the share of misses matched to a late-entered event is the number to watch.

How this connects

• Previous in the chain: Forecast Lock Process — the lock window an event may not move
• Next in the chain: Event, Incident and Problem in Contact Centers — the three words this page uses, defined once
• Read by: Three-Step Forecast Build (step 6, the event layer at every horizon)
• Defers to: Event Management (the severity matrix and response protocol for conditions already degrading service) · The Intelligence Feed (the event record, effect windows, grades, business asks and the match-to-miss rule) · Workforce Demand Signal Architecture (the pipelines that carry upstream signals) · Seasonal Staffing and Campaign Planning (planning for the peaks the calendar marks)

Maturity Model Position

A shared calendar of known events is Level 2 on the WFM Labs Maturity Model™; one calendar with effect windows, grades, collision rules and matching, entered when known, is the Level 3 section this page defines. 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 Lock Process
• Incident Management for Contact Centers — where an incident is matched to its event
• Human Gates and Number Grades — the number grades used on this page