Feeding UKG Forecasting: Volume Actuals Done Right

“The auto-scheduler is bad.” I hear some version of that sentence in most first conversations about demand-driven scheduling, and it’s almost never where the problem lives. Schedule quality traces back through labor standards to the demand forecast, and the forecast traces back to one thing: the volume actuals you feed it. When I dig into a “bad engine,” what I usually find is a bad feed that’s been quietly poisoning the engine’s view of history for months.

That’s worth taking seriously, because the forecast engine itself generally does its job. Give UKG Pro WFM’s forecasting clean, complete, correctly-bucketed history and it finds the weekly and seasonal patterns it was built to find. The engine doesn’t get to see your stores, though — it only sees the history you deliver. Feed it distorted history and it doesn’t crash or warn; it produces a plausible forecast of a business that doesn’t quite exist. Managers notice the schedules don’t match reality, start editing around them, and trust erodes one override at a time — which is how a six-figure scheduling investment turns back into gut-feel scheduling with extra steps.

What does the engine actually need from your actuals?

The shape sounds simple: volume, per stream, per business-structure node, per interval. The volume streams are whatever drives your labor — sales, transactions, units, traffic. The grain is fine: at fifteen-minute intervals, a 500-site operator with three volume streams is delivering just over a million interval records a week. None of that is technically hard. What’s hard is that three details carry all the risk:

The business day is not the calendar day. Any operation open past midnight closes its business day sometime in the early morning — 3 a.m., 4 a.m. — and the 1 a.m. rush belongs to Friday’s business day, not Saturday’s. If the feed buckets volume by raw calendar timestamp while the sites think in business days, every late-night pattern smears into the wrong day’s history, and weekend forecasts inherit weekday tails. This is the single most common defect I find in existing feeds.

The mapping ages. POS stores and departments have to map to the business-structure nodes the forecast is configured against. That mapping is correct the week it’s built, and then the organization keeps moving — sites open, close, remodel, re-department, reorganize. Without an owned, versioned mapping (and an alert when an unmapped source shows up), volume starts landing on the wrong node or silently nowhere.

Zeros that aren’t zeros. A closed store did zero sales. A broken feed reported zero sales. Those are different facts, and only one of them belongs in forecast history. Load a missing day as zeros and you’ve taught the engine that Tuesdays are dead; monitoring has to distinguish no-volume from no-data, per site, per day, and hold back what it can’t vouch for.

Restatements: the part everyone skips

Here’s the assumption that sinks otherwise-solid feeds: that an interval, once sent, is final. POS actuals get restated after the fact — post-close corrections, returns, audit adjustments, a register that synced late. If your integration is fire-and-forget, the forecast history diverges from financial truth a little more each week, and nobody notices until someone reconciles labor plans against finance and asks why the volumes disagree.

A feed that handles reality re-sends corrected intervals as a matter of routine. That means idempotent loads — keyed by node, stream, and interval, so a resend updates rather than duplicates — and an explicit restatement window: how many days back you sweep for changes on every run. I’ve built volume feeds into Pro WFM forecasting from POS platforms, traffic counters, and production systems, and I now treat the restatement design as the first conversation, not a hardening task for later — it’s the difference between a feed that’s trustworthy in month twelve and one that was only correct in week one. It’s the same production-middleware discipline — idempotency, retries, monitoring that pages someone — that I bring to real-time integration work, applied to a pipeline where correctness, not latency, is the point.

One more thing the history needs: honesty about special days. The engine has provisions for events — holidays, promotions — but only if they’re identified as events. An unflagged promo spike just becomes baseline, and next month’s ordinary Tuesday gets staffed like a sale.

How fresh do actuals need to be?

Fresh enough for the destination — and the forecast is not always the only destination.

If forecasting is the only consumer, this is one integration where I’ll often talk a client out of real-time. The engine consumes completed history, so daily latency — which is still my minimum recommendation — serves a weekly forecasting cycle exactly as well as a streaming pipeline, at a fraction of the operational burden. Freshness climbs the priority list when you reforecast intraday, adjusting tonight’s staffing from this morning’s actuals — then intervals need to arrive within minutes of close, and the reliability burden rises accordingly.

But the same volume stream often has a second consumer where real-time is exactly the point: custom reporting and apps. A manufacturer that wants a live floor view of what’s being produced against plan, in a screen supervisors keep open — or a retailer watching today’s sell-through against today’s schedule. I’ve built volume feeds real-time for precisely that reason: the forecast never needed the speed, the custom report did. When both destinations exist, design one pipeline with two consumers — stream to the operational view, consolidate daily into forecast history. The test is the same one I use for every integration latency decision: what does stale data cost, at each destination? If the answer everywhere is “nothing before tomorrow,” spend the engineering budget on restatements and gap detection instead. That’s where the accuracy lives.

What this looked like in the field

A multi-site restaurant group with late-night locations had stopped trusting its forecasts entirely — managers were rebuilding schedules from scratch every week. The engine had been tuned twice. The actual defect: locations closed their business day around 4 a.m., the volume feed bucketed by calendar date, and years of late-night volume had posted to the following day’s history. We rebuilt the feed on the POS business-day calendar, added idempotent restatement with a rolling correction window, put per-site completeness checks in front of the load, and reloaded corrected history. No engine changes. Worth saying plainly: that diagnosis — the forecast analysis itself — is work I take on as an engagement in its own right, no build attached. Within a few forecast cycles the generated schedules started matching how the sites actually traded, and the weekly rebuild-from-scratch habit faded.

When NOT to build this

• You don’t schedule to demand. If your sites run on static templates and nobody plans to change that, a forecasting feed is plumbing to nowhere. Solve the scheduling philosophy first.
• The source data is the problem. If POS volume itself is unreliable — unrecorded transactions, sites on different systems with different definitions — no pipeline downstream can restate data nobody captured. Fix the source first.
• A standard nightly file already fits. If a supported interface covers your stream, your grain, and your business-day calendar, and you forecast weekly — use it. The custom build earns its keep on restatements, unusual sources, and intraday cycles, not on moving a clean file you could move the standard way.

---

Forecast that nobody trusts? Before anyone re-tunes the engine, send me a note — the feed-and-forecast analysis is an engagement I take on by itself, and it’s where I’d start.