Original, Revised, Projected, Actual

Most intraday screens show two numbers: what you planned and what is happening. That is enough to notice a problem and nowhere near enough to manage one, because it collapses four genuinely different questions into a single comparison.

The four columns are Original, Revised, Projected and Actual. Every mature intraday desk has them, whether or not the tool names them. Teams that only have two end up either fighting the plan or quietly rewriting it, and both are worse than the alternative.

What each column is for

The distinction that does the most work is Revised versus Projected. Revised is a decision: a human changed the requirement because a known event changed the demand or the supply. Projected is an inference: the day is tracking a certain way and the arithmetic extends it. Conflating them is how a desk ends up reforecasting in response to noise.

Original is immutable. This is the whole discipline.

The most common failure in intraday management is not a missed interval. It is a plan that gets quietly updated during the day until, by close, variance to plan is close to zero and nobody can explain why the day was hard.

Once Original moves, you have lost three things at once:

• Forecast accuracy. There is nothing left to measure the forecast against. Your MAPE is now the accuracy of your hindsight, which is excellent and useless.
• Adherence baselines. Adherence measured against a schedule that moved during the day is not adherence. Agents notice this faster than anyone, and it is the fastest way to lose their trust in the whole system.
• The learning loop. “We were 24% over on Tuesdays at 10:00 for six weeks” is a forecasting insight worth real money. It is invisible if Tuesday’s plan was rewritten every Tuesday at 10:15.

Worked example: the interval that went unstable

A single 30-minute interval. Here is what was planned:

• Original forecast: 250 contacts, 240s AHT → offered load 33.33 Erlangs
• Original requirement: 40 agents, for 80% answered in 20 seconds with an 85% occupancy cap
• At 40 agents that interval was planned to deliver 89.1% service level, 6.9s ASA, 83.3% occupancy

The interval arrives. Volume comes in at 310 contacts, 24% over forecast, which is a bad morning but not an extraordinary one. AHT runs at 255 seconds, 6% over, the kind of drift that follows a release or a policy change and often is not noticed at all.

Now run the arithmetic on what the original 40 agents will deliver against that demand:

Offered load has exceeded headcount. There is no service level to report, because there isn’t one. The queue is unstable: work is arriving faster than the team can physically complete it, the backlog grows for as long as the condition persists, and waiting time heads for infinity rather than settling anywhere. Every additional minute makes the recovery longer.

This is the single most important thing an intraday screen can tell you, and it is the thing most of them obscure. A tool that reports “service level 31%” here is reporting a number the model cannot produce. The truthful output is a different kind of statement altogether: this interval cannot be served by this headcount at any service level, and the damage is compounding.

The Revised requirement for the demand that actually showed up:

The gap is 12 agents on one half-hour. Demand rose 24% in volume and 6% in handle time; the requirement rose 30%. That non-linearity is the reason intraday escalations always feel disproportionate to the people receiving them: “it’s only 24% over” is a genuinely reasonable sentence that happens to be catastrophically wrong.

Note also which constraint binds. Service level is met at 50 agents. The requirement is 52 because of the occupancy cap. If you are in genuine crisis and consciously choose to breach the cap for one interval, that is a legitimate decision, but it should be a decision someone makes and records, not a constraint the tool silently drops.

The loop, in the order it actually runs

1. Observe. Actual versus Original, per interval, per queue. Volume, AHT and staffing separately: a volume miss and an AHT miss need different responses and averaging them hides both.
2. Classify. Noise, or signal? A single interval 15% over on a queue that swings 20% routinely is noise. Three consecutive intervals trending one way, or any interval where load approaches headcount, is signal.
3. Project. Extend the day’s observed pattern to the remaining intervals. This is arithmetic, not judgement, and it should update itself.
4. Decide. If Projected implies the rest of the day is under-resourced, act: overtime, break moves, off-phone work suspended, skills opened up. Each has a different lead time, and the lead time is usually what determines the choice rather than the cost.
5. Revise. Record the new requirement in Revised. Original does not move. What actually changed and who decided it is now on the record.
6. Review. Next day, compare Actual to Original for forecast learning and Actual to Revised for execution quality. These are two different scores for two different teams.

Projecting the rest of the day

If the 24% volume overage and the 255s AHT persist, every remaining interval carries the same shape. Planned at 250 contacts and 240s, each interval needed 40 agents and 57.1 rostered FTE at 30% shrinkage. At the observed run-rate it needs 52 agents and 74.3 rostered FTE, a 30% increase for the balance of the day.

Two useful habits here. First, project AHT and volume as separate series; they have different causes and different fixes, and a projection that blends them cannot tell you which lever to pull. Second, project the requirement, not just the volume, because of the non-linearity above, a 24% volume projection does not translate to a 24% staffing gap, and telling an ops director “we’re 24% over” when you mean “we need 30% more people” costs you credibility the moment someone checks.

What good looks like on the screen

• All four columns visible at once, per interval, not on four different tabs.
• Original visually locked, with an obvious marker when a Revised value exists and who set it.
• Instability flagged as its own state, never rendered as a very low service level.
• The binding constraint shown on the requirement, so “why 52” has an answer.
• Volume, AHT and staffing variance broken out separately.
• Projected updating without anyone pressing anything.

None of that is exotic. It is simply the difference between a screen that tells you a number and a screen that tells you what to do about it.