Intraday Reforecast (generic process)

Intraday Reforecast (generic process) is the generic process card, GP-104, for the event-driven process by which a workforce function revises the remainder of the day's forecast when actuals have left the band around the forecast of record, and hands the revised interval forecast to the real-time function. The trigger is a deviation beyond a band held for a number of consecutive intervals, both SET LOCALLY; the output is a revised interval forecast for the rest of the day, with the requirement recomputed, handed to the daily ROC routine for the lever decisions of GP-302. The reforecast-or-hold test, the three methods and the configuration guidance are on Intraday Reforecasting Methods; the calculations and the downstream chain on Intraday Reforecasting and Real-Time Forecast Updates. Neither is restated here. This card carries the L0 profile, the variant classes, the L3 job aids and the automation candidates. It is part of Process Standardization and sits under the forecasting section of the function catalog in Anatomy of a ROC Standard, where it is the one forecasting process consumed inside the real-time section.

The process exists because the morning forecast is strictly less informed than one that has seen several hours of the day's actuals, and because a revised forecast is only worth producing while there is still time to act on it. The arrival process it revises is time-varying within the day and its rate is itself uncertain, which is why a forecast fixed in the morning cannot be the last word. It revises the prediction; the response to a queue is another process.

Process profile

The profile extends the L0 identity fields of Process Decomposition (L0–L3) with the process-level facts a standards committee needs before any step is drawn. Local values are held by the deploying function and marked SET LOCALLY.

Field	Generic value
Card	GP-104 · local card id assigned by the standards committee at deployment
Class	real-time, in the catalog's four-class vocabulary (strategic · real-time · both · supporting)
Trigger	a sustained deviation of actual volume or handle time from the day's forecast of record beyond a band for a number of consecutive intervals (both SET LOCALLY), or a known causal event, raised by a threshold alert (GP-304) or by the ROC's monitoring rotation
Cadence	event-driven within the operating day; not before a minimum of actuals has accumulated and not after the point at which no lever can still act (both SET LOCALLY); capped per day at a count the function sets
Scope in	the revised interval forecast for the remainder of the day for the affected client portfolios; volume and handle time, reforecast separately; the requirement and gap by interval; the hand-off to the real-time function; the reforecast log
Scope out	the lever decision (GP-302); the alert architecture (GP-304); the weekly forecast and anything beyond today (GP-103); the incident process; the scoring of reforecast accuracy (GP-106)
Inputs	the day's forecast of record by interval (GP-103's vintage); actuals to the current interval; the alert or rotation note; the cause note; the band, minimum-actuals and cap table; the intraday curve for the client portfolio
Outputs	the revised interval forecast, stamped as an intraday version; the recomputed requirement and gap by interval; the hand-off note to the ROC with the cause class and the action lead time; the reforecast log entry (time, trigger, method, lead time)
Upstream	GP-103 (the forecast of record); GP-304 (the trigger); the ROC's monitoring rotation; the incident process when the cause is an outage
Downstream	the daily ROC routine and GP-302 (the lever chain); GP-106 (reforecast accuracy scored separately from the morning forecast); Variance Harvesting
Resources	the real-time monitoring feed; the platform's reforecast function or a ratio model; the staffing model; the vintage store; the ROC channel. Platforms are named at L3, never here
Decision points	reforecast or hold? is the cause known and temporary? volume, handle time, or both? is there still lead time for a lever? release as information or as a recommended action set?
Authority tier	tier 1, the real-time analyst inside guardrails, raises, produces and releases the reforecast; a reforecast whose implied adjustment is major in the daily ROC routine's minor-or-major split goes to tier 3, the ROC duty lead, before release; the forecast itself never goes above tier 3, though the lever it implies may escalate under GP-302
Risk and compliance flags	same-day schedule changes inside a statutory notice window; over-reaction to noise, whose cost is the disruption of the actions taken; a reforecast released without action authority, which is information nobody can use
Variant-prone steps	the band and cap; the hand-off where a partner site runs its own real-time desk; client portfolios whose platform cannot reforecast handle time; client portfolios with no real-time state
Automation candidates	four sub-steps (four ranks), listed below; the L2 rows are the method pages' stages, copied by the deploying function

L1 and L2

The trigger, the reforecast-or-hold test and the method choice are on Intraday Reforecasting Methods, the requirement recomputation and the downstream chain on Intraday Reforecasting and Real-Time Forecast Updates, and a deploying function copies those stages into its own L1 and L2 artifacts through Wiki:Packs/Process Decomposition with the band, the interval count, the minimum actuals and the daily cap written as SET LOCALLY and "hold" recorded as a decision branch with an owner and a logged reason, because an unlogged hold cannot be scored.

Variants

The known variant classes for this process, recorded per Standard and Variant in Process Documentation:

• Statutory. Where same-day schedule changes trigger predictability pay or require notice, the reforecast is unchanged and the hand-off note carries a flag that the action set is restricted: a parameter of the release stage, SET LOCALLY. The restriction on the levers belongs to GP-302.
• Contractual. A partner site that runs its own real-time desk under contract receives the reforecast as a notification rather than a recommended action set. The release stage changes its output and its recipient, so it takes a variant row, owned by the placement lead and reviewed at contract renewal.
• Structural. A client portfolio with no observable real-time state, such as an asynchronous channel, has no intraday reforecast; that is a scope exclusion on the catalog row, not a variant. A platform that cannot reforecast handle time varies the handle-time stage, run by hand on a ratio, under a row reviewed when the platform changes.
• Transitional. A unit from a predecessor organization whose monitoring feed is not yet on the shared platform raises the trigger by hand from the site's own reports: a variant row with expiry at cut-over, whose automation effect reads blocks against rank 1 for that unit.

L3 register

A localizing team writes these job aids against the generic L2; names only, the content is the function's. The band, count, minimum actuals and cap are L3 values marked SET LOCALLY in the L2 row.

Job aid	Anchored to	Form
The band, consecutive-interval count, minimum-actuals and daily-cap table	the trigger and the hold test	work instruction
The reforecast-or-hold checklist	the hold test	work instruction; conditions on Intraday Reforecasting Methods
The cause classification list (outage burst, campaign, external event, supply break, unknown)	the cause stage	work instruction
The method per client portfolio and the validation of the platform's reforecast against a ratio baseline	the method stage	work instruction
The handle-time reforecast and the requirement recomputation	the handle-time and requirement stages	work instruction; arithmetic on Erlang C
The hand-off note to the ROC: cause class, lead time, information or action set	the release stage	work instruction
The reforecast log layout	every stage	work instruction
The minor-or-major release rule and the duty-lead path	the release stage	playbook; split on Daily ROC Routine
Reforecasting when the monitoring feed is dark	the trigger stage	runbook

Automation candidates

Flagged at L2 per the method on Process Decomposition (L0–L3); released per class of action on a published catch rate per Human Gates and Number Grades, never on a maturity label. The list is ordered by how easy a catch rate is to publish; each item names the L1 stage of the method pages it belongs to.

1. Trigger detection (L1 stage: detect the trigger): the sustained-deviation test is deterministic given the band and the count, and every missed or false trigger is visible the same day; Real Time Threshold Alerts and Escalation Protocols already treats it as a rule.
2. The statistical reforecast (L1 stage: run the method): a ratio adjustment first, the platform's own method only after it has been validated against the ratio baseline on a sample of days, as the method page advises; it ranks after trigger detection because its catch rate is the reforecast accuracy GP-106 scores, which takes weeks of days to accumulate.
3. The requirement and gap recomputation (L1 stage: recompute the requirement): deterministic given the staffing model and the register's definitions; it ranks after the reforecast because its correctness is conditional on the forecast it is computed from.
4. The hand-off packet and the log entry (L1 stage: release): assembled, not decided; last because an error here is caught by the ROC's acknowledgement rather than by a rate of its own.

Two stages are not candidates. The cause check is not, because whether a hot morning was an outage burst that will clear or a campaign that will persist is not in the feed; it is known to the person who reads the incident channel. The release of a reforecast that implies a major adjustment is not, because it is the stage before the one whose error is costliest, the lever that changes what the floor does, and a supervisor who merely acknowledges a reliable automation stops checking it. A release inside guardrails, a minor adjustment, is a class of action that may be released whole once the chain's catch rate is published, the condition Expanding Intraday Automation states for routine micro-moves.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a function that reforecasts on a documented trigger with a logged hold decision and a separate handle-time update is at Level 2; one that has released ranks 1 to 3 above on a published catch rate and scores reforecast accuracy separately from the morning forecast is at Level 3; one in which the whole chain runs as a released class of action inside guardrails, with the analyst overseeing the catch rate rather than producing each reforecast, is at Level 4.

See Also

• Process Standardization — the hub and the inventory this card belongs to
• Intraday Reforecasting Methods — the triggers, the hold test, the three methods and the configuration guidance
• Intraday Reforecasting and Real-Time Forecast Updates — the calculations and the downstream chain
• Weekly Rolling Reforecast (generic process) — the forecast of record this process revises
• Daily ROC Routine (generic process) — the routine that receives the reforecast
• Real-Time Lever Deployment (generic process) — the levers the reforecast may trigger
• Threshold Alerts and Escalation (generic process) — the trigger mechanism
• Intraday Management — the operating context
• Standard and Variant in Process Documentation — how the variants above are recorded
• Wiki:Packs/Process Decomposition — the pack that localizes this card (CP-OPS-001)