Demand-Matched Roster Builder
A draft weekly roster matched to your forecast demand and held inside the labour budget, with every shift checked against the Restaurant Award and anything risky flagged for the manager to fix before sign-off.
It reads your POS sales, bookings and trading patterns to draft a roster against forecast demand, then runs a deterministic award check and hands the manager a roster to adjust and approve.
Where this works well
The slow, invisible problem this makes visible is the gap between the roster a venue actually runs and the demand it actually serves. Labour runs near 40% of operating cost on thin hospitality margins, yet most rosters are rebuilt each week from last year's pattern and a manager's sense of a typical Saturday. The mismatch is rarely a whole-day problem — it's a day-part problem. A lunch peak short three staff costs you sales and waits; a 3–5pm lull carrying three surplus people costs you wages on Saturday penalty rates. Both happen on the same day, and a single headcount-for-the-day view hides them.
This earns its keep in a multi-venue café, restaurant or QSR group where a venue or area manager builds rosters weekly and has POS that records covers by time of day. It's most useful for the manager who is good at the people side but loses an evening a week to the spreadsheet — it gives that evening back and turns the roster conversation into "here's where the forecast disagrees with your draft," which is a faster conversation than building from blank.
Where it works badly
It is confidently wrong when the demand signal is thin or the day is genuinely unusual. If your phone bookings and walk-ins never reach the POS, the model under-forecasts your real peaks and will suggest trimming a shift that turns out busy. A one-off it has never seen — a nearby event, a road closure, a 40-degree day that empties the dining room or fills it — sits outside the four-week pattern it learns from, and the forecast for that day is a guess dressed as a number.
It is also not worth the effort where there is nothing to optimise: a single small site with a stable, mostly-permanent team rostered the same way every week has no demand curve to chase and no penalty-rate lulls to release. The honest test: pull last month's covers-by-hour against last month's rostered hours for one venue. If they already track each other closely, you don't have the problem this solves. If a Saturday lunch was short while the mid-afternoon was carrying people, you do.
What it doesn't do — and shouldn't
It drafts and checks; it does not publish, and it does not decide who works. It surfaces the forecast-versus-coverage gap per day-part, suggests where to move hours, and flags shifts that may trip an award rule — minimum engagement, the under-18 shift-length cap, an overtime threshold, a penalty-rate window. What it never does is judge that Jordan and Priya work well together on a hard Saturday, that a new starter shouldn't be left alone on the close, or that the casual who asked for Friday off should keep it. Those are the manager's calls, and they're most of what makes a roster good.
The award flag is deliberately a prompt to a person, never an auto-correction. Awards get interpreted, enterprise agreements override them, junior and casual rules change at the annual wage review, and getting it wrong is a wage-underpayment exposure, not a rounding error. So the tool cites the clause and stops; payroll or HR confirms and the manager signs off. The human-in-the-loop boundary here is the difference between a defensible roster and a confident liability.
What your data has to look like for this to work
The demand half needs POS that records covers or sales by time of day, not just a daily total — a day-part forecast can't be built from a single end-of-day figure. It needs enough recent history (the demo learns from roughly four weeks) that reflects how you trade now, not before you changed hours or menu. Bookings and known events (a local fixture, a function) help most when they reach a system the model can read; if they live on paper or in someone's head, the forecast is blind to them.
The award half needs the things compliance actually turns on, captured cleanly: each staff member's employment type, date of birth or age (for the under-18 shift-length rule and junior rates), and start and finish times precise enough to test against penalty-rate windows and overtime thresholds — plus the current Restaurant Award MA000119 rule set, kept up to date at each wage review. Most venues have some of this and not all of it: covers-by-hour but ages missing from the rostering system, or a POS feed that only syncs weekly. Fixing how that information is captured is usually the real first job, it's a matter of capture and integration rather than buying a new tool, and it's the part RMAI helps with — typically bigger and more valuable than the forecasting layer on top.
Could it tell me to cut staff from a shift that's actually going to be busy, and leave me short?
It can — a forecast is a forecast, and a one-off event it has never seen (a road closure, a sudden heatwave, a coach party that booked by phone and never hit the POS) will throw the demand curve off. That is exactly why it never publishes. It shows you the forecast covers per day-part against what you've rostered, so you can see why it suggests pulling two from the 3–5pm lull before you agree to it. The manager who knows Saturday is the one deciding, not the model.
Our POS exports are a mess and half our bookings still come in by phone on paper. Will this still work?
Partly, and it will tell you where it's guessing. The demand forecast is only as good as the trading history it can read — if walk-ins and phone bookings never reach a system, the model under-forecasts your real peaks. In the demo, days running on POS-only data are badged differently from days enriched with bookings and trading signals, precisely so you don't trust a thin forecast as if it were a rich one. Getting capture consistent is usually the first piece of work, and it is worth more than the roster tool.
Does this replace my venue manager doing the roster?
It replaces the hour they spend rebuilding the grid from last year's pattern, not the judgement about who works well together on a hard Saturday, who's training up, and who asked for the early finish. It drafts and checks; the manager adjusts for the things no data captures and signs off. Capacity comes back to the floor, not off the wage bill.
How current does the data have to be? We don't want it rostering off last quarter's trade.
It should read recent trading — the demo forecasts off roughly the last four weeks of POS plus weather and known events, so seasonal shifts and a new nearby venue show up. Stale data is the main failure mode: a forecast built on figures from before you changed your hours or your menu will quietly mis-staff every day. If your POS feed lags or only syncs weekly, fixing that cadence is part of the setup.
Where does our sales and staff data go, and who can see it?
It runs on your own Power Platform tenancy against your POS and rostering systems — the data stays in your environment, not a third-party roster cloud. Staff ages and availability are read only to apply award rules and check who can work a shift; they don't leave the workflow. We scope exactly which fields the agent reads and writes during setup so there are no surprises.
Can I trust its award compliance flags, or do I still need to check the award myself?
Treat the flags as a prompt to a person, not a ruling. The award check is deterministic — it applies the rules as configured (minimum engagement, junior shift limits, overtime thresholds, penalty rates) and cites the clause — but awards get interpreted, enterprise agreements override them, and the rules change at the annual wage review. A flag means 'look at this shift'; your payroll or HR person confirms it. The compliance accountability stays with a human.
Estimated build: 3–5 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.