C
Roster Copilot Prototype
Enter the password to continue
Roster Copilot · POC 2 · Crown Melbourne {{ viewTitle }}
● BACKTESTED DATA
Demo journey · 14 min
What this proves: twelve months of your own Zone B, priced hour by hour. Every forecast on this screen resolves into a rostering consequence in dollars — hours over, hours under, wages recoverable, revenue at risk. The forecast is never the end product.
The money chart · V1
Where the roster leaks money, by day of week
Zone B · venue × daypart · 12-month backtest · model v0.9
Amber above the line: overstaffed wages. Red below: understaffed revenue-at-risk. Click a day to drill into it.
A$12k over— 0 —A$13k at risk
Weekdays leak wages, weekends leak revenue. One structural story, priced from your own data — not an intuition.
Program bridge · V2
From the A$600M EA base to A$12–24M/yr
Four levers stack to the program range. Solid = conservative case; pale = upper range. Every 1 point of the base = A$6M.
0 6 12 18 24 Overtime & penalty rates: A$3–6M/yr. Benchmark: penalty-rate and overtime audit, EA economics interviews. A$3–6M Over-rostered hours: A$6–12M/yr — the largest brick. Zone B measured slice: A$1.2M/yr, Finance-reviewed. A$6–12M Casual & agency premium: A$2–4M/yr. Benchmark: casual loading ~+50%, agency premium audit. A$2–4M Reinvested peak coverage: +A$1–2M/yr — savings put back into the right tables open at peak. Revenue, not just cost. +A$1–2M Program range: A$12–24M/yr, i.e. 2–4 points of the A$600M EA base. A$12–24M Overtime & penalty rates Over-rostered hours ▪ Zone B measured: A$1.2M Casual & agency premium Reinvested peak coverage Program range 2–4 pts of the A$600M base A$M / yr
Every 1 point of the base = A$6M. The pilot zone is priced honestly; the range is not claimed until Finance co-signs.
Benefit governance
Tracked where Future Fit already looks
Benefits land in the same run-rate dashboard the Future Fit office uses today — additive to the ~A$91M already claimed, never double-counted. Methodology and extrapolation logic sit behind the drill link, one click away, not in a backup slide.
Overtime & penalty auditReviewed ✓
Loaded wage rates (incl. penalties)Reviewed ✓
Contribution per open positionPending Finance
Intraday curve · V3
{{ dayTitle }}
{{ grainLine }} · hourly density polls today, 15-min polling desired in pilot
Compare
{{ intradayChart }}
Published roster (blocks) Forecast required · P50, P10–P90 band Optimised roster · EA-feasible, staffed to P75 at peak Actual worked (backtest) Binding EA constraint
Rosters move in blocks; demand moves in curves. The gap between them is the money. Overstaffing priced at loaded wage incl. penalty rates; understaffing at contribution per open position (21% table-games tax rate).
Week heatmap · V5
{{ heatTitle }}
{{ grainLine }} · ▲ marks an event-driven spike from the layered events calendar · click a cell to open that day
Mon
Tue
Wed
Thu
Fri
Sat
Sun
{{ c.name }}{{ c.hours }}
Every venue peaks differently · V6
One property-wide intuition cannot schedule 20+ outlets; a hierarchical model schedules each at its own grain.
{{ s.name }}
{{ s.shape }}
10ampeak shape2am
Fan chart · V7 · 14 days forward
Forecast with uncertainty stated, not euphemised
{{ grainLine }}
{{ fanChart }}
First Crown Live concert weekend under the new table configuration — the model is telling you it is less certain. Staffing recommendations state which quantile they staff to (P75 at peak) and why: under-staffing costs more than over-staffing at a 21% table-games tax rate.
Driver decomposition · V8
Why {{ dayLabel }} looks like this
SHAP output rendered for operators, not data scientists. Index: baseline weekday = 100.
{{ r.label }} {{ r.val }}
{{ r.gloss }}
Decomposition · V9
The normalisation the data has lacked
Dynamic harmonic regression split: baseline vs seasonal vs event demand, quantified instead of living in planners' heads.
{{ p.name }}{{ p.note }}
Forecast-to-roster translation
The forecast is not hand-waved into headcount
4,860
forecast hands, 7–10pm peak (P75)
÷
102
hands per dealer·hr at 68% table density — density-adjusted hand-rate model
=
47.6 → 48 dealers
rounded up to EA-feasible shift blocks; F&B uses covers per server standard
The trust chart · V10
Actual demand vs the forecast made 2 weeks earlier
8 backtest weeks · target accuracy band 92–96% at venue × daypart
{{ w.err }}
{{ w.wk }}
Actual covers/demand Forecast, 14 days ahead Label = weekly accuracy; red = below the 92% target floor, shown, not hidden.
Baseline table · V11
Beat the baseline, or say so
WAPE by horizon — lower is better. Green only where this model wins.
Method 1 day 7 days 14 days 14 d · event days
This model (v0.9) 5.2% 6.1% 7.4% 11.4% · baseline wins
Seasonal naive 8.9% 10.4% 12.1% 11.1%
Current planner practice 11.8% 12.6% 13.0% 14.7%
The model loses one cell and the screen says so. "The model must beat how rosters are set today, or the POC reports that honestly."
Error by segment
"Fine on a quiet Tuesday — what about event weeks?"
Accuracy sliced by daypart and by event vs non-event days. Event days are harder; the band widens rather than the number hiding.
{{ s.name }}
{{ s.v }}%
Sources in
Carded-play volumes (near-100% rated) · F&B covers & POS · hotel occupancy on books · events & holidays calendar · reservations & GA clickstream · weather. Snapshot: 18 Jul 2026.
Known caveats
Melbourne hourly density polls vs Sydney per-hand data; covers reliability varies by venue. Structural breaks handled: Dec tax change, offer restructure (changepoint features, retrain windows).
Model lineage
Hierarchical GBM + time-series ensemble: dynamic harmonic regression (Fourier terms), LightGBM quantile objectives P10/P50/P90, hierarchical reconciliation so property, zone, game type and hour sum coherently.
Override the recommendation
The roster remains yours. A reason is required before dismissal — the system keeps the memory.
Reason category
Justification (required)
Veto budget this cycle ⓘ {{ vetoUsed }} of 4
Cancel Log override
This roster cannot be published
The variant includes a 2.5-hour shift — below the 3-hour minimum engagement.
EA clause category: Minimum engagement · hard constraint
EA and union rules are encoded as hard constraints in the optimiser. It will not produce — or accept — an EA-infeasible roster. Compliance is demonstrated, not asserted.
Back to the compliant roster
{{ toastMsg }}