Feature
One rota screen for every store you run.
Scheduling one location is a spreadsheet problem. Scheduling eight, with people who float between them, is a different job: you need to see several stores at once, move a shift across a boundary without retyping it, and know before Monday whether the person you put on Saturday has actually read it. That's what this builds.
01 — How it works
Person per store, week at a time
A checkbox store picker at the top — pick two stores, pick all of them. Each selected store gets its own editable week grid with its own publish state, stacked down the page, sharing one set of tools.
- Draft, then publishA week you're building isn't a week anyone can see. Publish makes it visible on phones. Editing a published shift re-drafts it, so there is never a state where staff are looking at something other than what you decided.
- Copy week, without doubling itMost weeks are last week with two changes. Copy-week brings the whole pattern forward and dedupes against what's already there, so hitting it twice doesn't give you two of every shift.
- Drag to move, alt-drag to copy, clip to paintDrag a chip to move it. Hold Alt or Ctrl on the drop to copy instead. Or hit the clip button on a shift and click cells to paste-paint it — across days and across stores, which is how a weekend of identical 9-to-5s actually gets built.
- Time-off conflicts on the cellIf someone has requested that day off, the grid says so while you're placing the shift. Discovering it on Saturday morning is the failure this closes.
- Totals across everything selectedA card above the grids adds up hours for every store in the selection, and prints how many of the selected stores it actually counted — so a store that failed to load can't silently deflate your number.
02 — Confirmation
Red dot until they confirm
Publishing a schedule is not the same as somebody reading it. Every published shift carries a confirmation state: on the phone the employee sees a red “Confirm shift” button on their next shift and taps it once; on the grid the chip wears a red dot until they do, then a green one. There's a legend, because a manager should not have to remember what a dot means. The rule that makes it trustworthy is the boring one — editing a shift clears its confirmation and puts it back in draft. Nobody is ever recorded as having agreed to a shift that changed afterwards.
The phone side is the same portal employees use to set their time-clock PIN, sign documents and message the office, so there is nothing new for anyone to install — the shift card just sits at the top of the home screen. That portal, the PIN time clock and the rota are one product, which is the whole reason the next part works.
03 — Scheduled vs actual
The rota is half of a timesheet
Published hours carry straight into timesheets, where each person's week shows two sub-rows: what you scheduled and what they punched. You aren't comparing two systems or eyeballing an export — the rows sit on top of each other and the difference reads itself. Scheduled hours are keyed to the employee and the store, which matters more than it sounds: we shipped it keyed to the employee alone and a person working two locations had their entire cross-store rota land on one store's timesheet. It's fixed, tested, and worth saying out loud because most tools in this category get it wrong the same way.
For salaried people, scheduled hours are what the payroll sheet uses — a salaried row's hours in the weekly workbook come from the published rota at that store, not from punches. Salary is a per-store fact here: someone can be salaried at three locations and hourly at a fourth, and the rota classifies them per store using exactly the same rule payroll does.
An owner also gets the split. The totals card breaks selected-store hours into salary and hourly. A GM or manager gets plain hours and nothing else — the endpoint returns no pay-adjacent data at all for non-owners, so the salary tag on the grid simply isn't there to leak. Store scope is enforced the same way: a manager builds rotas for the stores the owner assigned them, checked on the server, not hidden in the menu. See staff roles & permissions.
04 — Questions
Straight answers.
How do employees find out they're scheduled?
Publishing makes the week visible in each person's phone portal, where their next shift sits at the top of the home screen. An unconfirmed published shift carries a red dot on the grid and a red Confirm button on the phone; tapping it turns both green. Editing a published shift clears the confirmation and re-drafts it, so nobody is counted as having agreed to a shift that changed after they looked.
Can one person be scheduled at more than one store?
Yes. An employee has a home store and can be attached to any number of others; every store's roster is the union of both. Dragging a shift from one store's grid to another copies it rather than moving it, and each store's hours stay attached to that store all the way through timesheets and payroll.
What happens if I schedule someone who requested that day off?
The conflict is surfaced on the grid cell as you build the week, not discovered on the day. Approved and pending time off both show, because a pending request is exactly the case where scheduling over it causes an argument.
Who can see the salary versus hourly split?
The owner only. The totals card breaks the selected stores' hours into salary and hourly for owners; for a GM or manager the endpoint returns no pay information at all, and the salary tag on the grid disappears with it. Plain hours totals still show for everyone.
05 — Next step
Build next week in the demo.
Twenty minutes. Pick three stores, copy a week forward, drag a shift across a store boundary, publish it, and watch it appear on a phone.
Workforce & ops pricing is quoted per site and headcount — see pricing · no contracts