Demand is a weekly template: for every shift time and skill, a minimum and a maximum per weekday. Staffing below the minimum is penalised by that band’s priority; the room between minimum and maximum is optional capacity that can stay open.
Each band states how many people a shift needs and how many it can use, day by day. The template repeats every week; one-off extras and cancellations override single dates.
An open slot below minimum on a required band outranks every soft trade-off. On a preferred band it is a weighted preference.
Bands carry a priority from 1 to 10. When not everything can be staffed, the night desk at P10 is filled before the P3 day shift.
A band’s required skill is hard: a shift that needs a nurse gets a nurse. A preferred skill is honoured when it can be.
Every employee works under a contract: hour caps and floors, rest, consecutive days, weekends and rotation patterns. Each rule is required or preferred per contract; required rules are never broken.
The same rule can be absolute in one contract and a preference in another. Required is enforced; preferred is minimised and reported when bent.
Weekly A/B rotation, forbidden sequences such as night into morning, shift pairings days apart, and split-day permissions are contract patterns the plan follows.
An unavailable day is hard. An undesired day is penalised, a desired day rewarded, both with weights you set.
No-nights flags and personal time windows sit on the employee, above the contract. A shift outside the window is never assigned.
Days before today are fixed, and the published roster is the baseline. When someone reports sick their shifts reopen, and the re-solve fills them with the least disruption to everyone else.
Everything before today is context, not decision. A re-solve only changes days still ahead.
Changes are scored against the published baseline: assignments that move cost the plan, so the repair stays small.
An employee reports sick, hands back a single shift, or requests a day off. Each reopens exactly that work for the next solve.
Any employee can be excluded for one solve to see how the roster holds without them.
Employees can mark their own calendar from the phone: days off, days to avoid, days they want to work. The solver takes every mark into account at once: unavailable days are absolute, desired and undesired days are weighted, and fairness keeps the load even while it honours them. All of it is optional: the roster solves just as well with few marks or none.
Unavailable is hard: no shift, ever. An undesired day is penalised and a desired day rewarded, with weights set per solve.
An employee requests a day off or hands back a shift; the mark enters the next solve. Self-service is a choice per team, not a requirement: planners can enter or override any mark themselves.
The plan weighs every employee’s marks together rather than first come, first served. A preference the plan had to work against is listed, not hidden.
Shift counts stay balanced across the team while preferences are honoured, so the quiet ones do not end up carrying the week.
Click an open shift and the engine recommends who should take it: every employee is scored as if actually assigned, under the full rule set, and ranked with the reason attached. Assigning the top candidate fills the slot.
Candidates are scored with the same constraints as a solve, including pins, frozen days and exclusions, and each carries the reason for its rank.
Shifts can be dragged between people or assigned from the list. A pinned shift stays with its holder through every re-solve.
A manual edit that breaks a hard rule is flagged on the board; one re-solve repairs the roster around what you placed.
Every solve is kept and can be compared against the baseline: filled, moved, dropped and cost, side by side.
The constraints above are the standard set. Rules specific to your operation are added to the model as hard or soft constraints with their own weight. The solver treats them like the built-in ones: hard rules are never broken, soft rules are traded off against the rest.
A custom rule is either absolute or a weighted preference. Absolute rules are never broken; preferences carry a weight you set per solve.
Custom rules are evaluated on every candidate roster while the solver searches, not checked afterwards. A roster that breaks one is never proposed.
Each rule reports its own contribution, so you can see what it costs the roster, retune its weight or switch it off.
You describe the rule the way your planners state it; it becomes a named constraint in the model.