Most of what I know about scheduling I didn't learn from a solver — I learned it from being scheduled, and then from doing the scheduling. I work as a part-time Sales Advisor at a ZARA store with a staff of around 150, and as Shift Coordinator I plan shifts through Orquest, Inditex's workforce-planning platform. In April 2026 we restructured how the whole store plans, and I wrote up the internal meeting report that this post is based on. No sales data and no individuals appear here — just the planning mechanics, which I think are genuinely instructive for anyone who builds or buys scheduling software.
Lesson 1: The contract is the atomic unit, not the shift
The redesign's core move was to stop managing part-time staff shift by shift and start managing them by two things only: their contract and their availability pattern. We defined a small set of contract types — 30H, 25H, 20H, 18H and 16H weekly hours — each with a fixed shape: how many days, how long a shift, where the mandatory one-hour break sits, and what flexibility (if any) exists. A 30H contract, for example, means five days of six hours, extendable to seven on one day only if another day drops to five.
The general rule became beautifully boring: almost everyone works a fixed 25H, and each department may pull one or two people up to 30H as anchors. The motivation was explicit — lower the hour budget and reduce the number of special cases the planner has to hold in their head.
Before this, every schedule was a fresh negotiation. After it, most of the schedule computes itself from contract + pattern, and human attention goes only to the residual. If you're designing a scheduling system, this is the first thing to get right: the fewer degrees of freedom per person, the more the planning problem collapses into something tractable.
Lesson 2: Hard floors are what make the system humane
The single most important rule in the whole document is one sentence: you can never go below a person's contract hours. A 25H contract never becomes 24; a 30H never becomes 28. If a change is unavoidable, the hours are rebalanced onto other days — the weekly total is a guarantee, not a target.
I had already internalized "hard constraints must never be traded away" as an engineering principle when I built a CP-SAT shift solver for a hackathon. But Orquest planning is where I understood why the principle exists. That floor isn't there for mathematical elegance. It's someone's rent. A scheduling system that treats contract hours as a soft preference to be optimized against is a system that quietly transfers business risk onto the lowest-paid people in the building. Encode it as inviolable and the trust problem largely solves itself.
Lesson 3: Publish once, then freeze — flexibility is where fairness dies
The new planning cycle: shifts are published monthly, in one shot, and each month's plan must be ready by the 10th of the previous month. After publication, there are no working-day changes. If someone can't come in without paid justification, those hours are not re-slotted somewhere else in the plan — the only escape hatch is a swap with a colleague.
My first reaction to this rule was that it felt rigid. My considered reaction is that it's the fairest rule in the system. Continuous rescheduling sounds employee-friendly, but in practice it rewards whoever pushes hardest and punishes whoever plans their life around the published schedule. A frozen plan with a swap mechanism keeps flexibility peer-to-peer — two people who both consent — instead of routing every exception through a planner who then has to unbuild the month.
There's a systems lesson in there too: a plan that changes daily can never be validated, budgeted, or trusted. Stability is a feature you trade flexibility for, and at store scale the trade is worth it.
Lesson 4: Budget the disruption, not just the plan
The plan runs on a fixed weekly hour budget — the same budget every week, every month, which is what makes year-ahead planning possible at all. On top of it sits a buffer of 500–600 hours reserved for exactly the things that wreck schedules: annual leave and sick reports. Changes beyond that buffer simply cannot be absorbed.
The report is equally blunt about timing: the critical months for annual leave are February, July and August, and if leave isn't planned into those windows, it spills into later months, drags contracted hours down with it, and the extra headcount need eats the budget. In other words: an unplanned vacation isn't a calendar event, it's a budget event with a two-month tail.
I now think any scheduling system that only models the happy path is half a system. The disruptions are not exceptions to the plan — they're a predictable annual load that deserves its own explicit capacity. We even carried a concrete number into planning: roughly 510 unused hours from one month had to be consciously reinserted into the following plans rather than silently lost.
Lesson 5: Moving a task means moving a constraint
One change in the restructuring looked small and wasn't: the women's department no longer comes in for the 7–8 am delivery truck. Delivery responsibility was redistributed to kids, men's and the tills, with morning support drawn specifically from people on the larger 30H/40H contracts.
On paper that's one line. In the schedule, it changes who must be available at 7 am, which contracts those people need to hold, and how each department's operational subtotals are counted. Watching that ripple taught me to distrust any "just move this task to another team" decision until it's been traced through the availability matrix. Tasks are not free-floating; every task is secretly a constraint on somebody's contract shape.
Lesson 6: Escalation paths are part of the schedule
The report ends with something that never appears in scheduling literature: named escalation rules. Operational fixes go through one designated manager; every other change request goes through another; no unauthorized changes, full stop. (The names stay in the internal document, where they belong.)
I used to read that kind of rule as bureaucracy. Running the plan taught me it's actually the schedule's immune system. A plan with a single unauthorized side-channel edit is no longer the plan everyone agreed to — and once people suspect the published schedule isn't authoritative, they stop planning around it, and you're back to daily chaos.
Why this matters to me as a builder
I sit on both sides of this: I coordinate real shifts in Orquest by day, and I've built an OR-Tools-based placement solver as a side project. The overlap changed how I write software. Every rule in this post — contract floors, frozen publishes, disruption buffers, swap-only changes — maps directly onto solver design decisions: which constraints are hard, what the objective may touch, what the API refuses to do even when asked nicely.
The uncomfortable summary is that the hardest part of workforce scheduling isn't the optimization. Orquest, or CP-SAT, or a spreadsheet can all produce a valid plan. The hard part is the rule system around the plan: the guarantees people can rely on, the freeze that makes the plan real, and the buffer that admits, in advance, that reality will not cooperate. Get those right and the algorithm is almost the easy bit. Get them wrong and no algorithm will save you.