Short answer. A need per slot and position, computed from past activity, covers, receipts, appointments, and bookings already taken, then corrected and written by the manager. Constraints written once: hard, qualifications required on a slot, maximum hours per week, minimum rest between two shifts, rest days, unavailability entered by each person; soft, preferences and pairs. A proposal of assignments computed under the hard constraints, weighing the soft ones, explaining every choice, hours this week, rest, qualification, preference, and flagging the slots it could not cover; the manager corrects and decides. One published version on phones, confirmed by each person, locked at D-2. Swaps and absences requested from the phone, checked against both people's rules before reaching the approver, with replacements proposed. Clock-in compared with the roster shift by shift, gaps noted, and counted hours exported to payroll.
This guide is for the restaurant, the pharmacy, the clinic, the retail chain, the call centre, the security company, the gym of the gym guide, and the founder based in France who wants to know on Tuesday that Saturday night is covered. It does not repeat how machines and production orders are scheduled, described in the production scheduling guide, nor how technicians are dispatched to jobs, described in the field service guide; here it is about people, slots and rules. Payroll, overtime, premiums and working-time law are for the accountant and counsel: the application counts planned and clocked hours and applies the thresholds the manager writes, it does not say which to write.
Scheduling a week, in six beats
The proposal is the accented beat: the application assigns, explains and flags the gaps; the manager decides.
Compute the needs: for each slot and position, kitchen, floor, till, counter, the need comes from the activity of the same slots over the last weeks, covers, receipts, appointments from the online booking guide, plus bookings already taken and events entered; the manager corrects and writes, and the figure is kept with its source. Write the constraints: hard ones, which a valid roster must respect, qualifications required on a slot, maximum hours per week, minimum rest between two shifts, rest days, unavailability that each person enters on their phone; soft ones, which one tries to satisfy without obligation, day preferences, pairs. Propose: the application searches for an assignment that respects all hard constraints and satisfies the most soft ones, explains every choice and flags the slots it could not cover; the manager moves, replaces, accepts.
Publish: one version, on phones as in the notifications guide, confirmed by each person with one tap, locked at D-2; after the lock, a change goes through a swap or an absence, never through a silent edit. Swap and replace: a swap request between two people is checked against both people's rules, hours, rest, qualification, before reaching the approver; an absence declared from the phone triggers a list of proposed replacements, by qualification, hours and distance to the post, and the first to accept is assigned. Clock in and count: on-site clock-in, as in the phone sign-in guide, is compared with the roster shift by shift; gaps are noted, never retyped; counted hours go to payroll as in the integration guide.
One week’s roster: needs per slot, assigned, one gap
The figure is a restaurant's grid: three slots, seven days, and in each cell the assigned over the need.
The need: morning, lunch, evening, for fourteen employees; the figures come from the last eight weeks' covers on the same slots, plus bookings already taken, 84 covers on Saturday evening; the manager corrected them once, for a birthday on Thursday, and the correction is kept with its reason. The assigned: each cell counts the people assigned, qualified for the position, under their maximum hours, with their rest respected; a green cell is not a full cell, it is a cell that respects the rules. The gap: Saturday evening, five of six; it appears on Tuesday at proposal, not on Saturday at 6 pm.
The proposal: Karim, 34 hours this week of 40, 13 hours' rest before, qualified for the floor, and his Saturday preference respected; a second option, Nadia, with her own figures; nine other people were filtered out by hard constraints, hours, rest or qualification, and the manager can see why for each. The manager chooses; the application does not decide. The totals: planned hours per day show where the week is heavy, and the month board shows who is nearing their maximum. Needs, assignments and names are a constructed example.
«The need per slot is computed from activity, then written; the roster is compared with the need, not with habit, and Saturday's gap is seen on Tuesday.»
Amina’s week: planned, clocked, swapped, replaced
The figure follows one employee for seven days: what was planned, what was clocked, and what changed in between.
The planned: five shifts over the week, two rest days, and the written rules visible at the top: 40 hours at most, 11 hours' rest between two shifts, two rest days; these are this manager's rules, not this guide's. The clocked: under each shift, the clock-in bar; Monday and Friday stick to the roster; on Tuesday, a twelve-minute delay is noted with its duration, without anyone retyping anything, and without it disappearing. The swap: on Thursday, Amina asked to swap her lunch with Yacine; the application checked both people's hours and rest, then the manager approved; both people's hours were recomputed.
The replacement: on Saturday, Amina declares an absence at 6:40 from her phone; the application proposes three qualified replacements under their maximum, in order, and Sofiane accepts at 7:05; the manager made no call. The count: 29 hours planned at the start of the week, 17 hours clocked after the swap and the replacement, and the 12 hours passed to Yacine and Sofiane counted against them; everyone's hours go to payroll, whose rules are not in the application. Times and names are a constructed example.
«A swap or a replacement is checked against both people's rules before reaching the approver; what violates a hard constraint never arrives.»
Six real situations, and what the application does
Each row is a sentence heard in a team that works in slots, and the answer is a written rule, not a whiteboard.
Saturday night is always one short: the need is computed per slot, and the gap is flagged at proposal, on Tuesday; the manager has four days, not four minutes. Two employees swapped without telling: the swap is requested in the application, both people's rules are checked, the manager approves or refuses, and clock-in knows who was supposed to be there. The qualified person is not there at 2 pm: qualification is a hard constraint on the slot; a slot that requires it does not validate without it, neither at proposal nor at swap.
One employee works 58 hours, another 22: week hours are shown at every assignment, the written maximum blocks, and balance between people is measured monthly. The morning absentee is found at 8:05: the absence is declared from the phone, replacements are proposed in order, and the first to accept is assigned in minutes. The roster changes three times a day: one published version, locked at D-2; afterwards, every change is a swap or an absence, traced as in the roles guide and notified to the people concerned.
Shift scheduling, in five layers
Constraints are the accented layer: written by the manager, hard ones are not bypassed and soft ones are weighed.
Needs. Per slot and position, computed from past activity, bookings and events, corrected by hand and written with their source; a need is a number, not a habit, and it is recomputed every week by a background job as in the background jobs guide. Constraints. Hard ones are those a valid roster must respect: a person does not hold two shifts at once, a slot that requires a qualification gets it, maximum hours per week, minimum rest between two shifts, rest days, unavailability; soft ones are those one tries to satisfy without obligation, preferences, pairs. This distinction is that of the common description of the problem of assigning staff to shifts, known to be hard to solve exactly as constraints pile up; that is why the application proposes and explains, it does not impose. Proposal. A search for assignments under the hard constraints, weighing the soft ones, explaining every choice, and flagging the gaps; the manager corrects and decides, and their decision is logged.
Publication and swaps. One version published on phones, confirmed, locked at D-2; after the lock, swaps and absences are checked against the rules of the people concerned before reaching the approver, with replacements proposed; every change recomputes everyone's hours and notifies those concerned; everything works offline as in the offline guide, clock-in included. Clock-in and measurement. Clock-in is compared with the roster shift by shift; gaps, delay, early leave, unclocked shift, are noted with their duration; counted hours go to payroll, whose rules are not in the application; and the manager reads in their dashboard slot coverage, hour balance, swaps, absences, replacement time, with definitions beside them. The founder in France sees the same thing as in the remote management guide.
Scheduling teams in 2027, in weeks
Seven weeks, the first without code, and two for needs and constraints, because the proposal is only a search under those two layers.
- What the manager sees: on Tuesday, next week with its gaps; every day, who is in and who clocked in; swaps to approve with rules already checked; the month, hours per person.
- What teams no longer do: photograph the whiteboard, ask the group who works tomorrow, swap without telling, discover an absentee at opening.
- What is measured: slot coverage, hour balance between people, swaps and absences, replacement time, clock-in gaps, slots validated without the required qualification, which must stay at zero.
Week 1, rules: positions and slots, qualifications per position, maximum hours, minimum rest, rest days, admitted preferences, who approves a swap, the lock delay; with the manager, without code. Weeks 2 and 3, needs and constraints: needs per slot computed from history and bookings, hard and soft constraints written, unavailability entered by each person from their phone. Week 4, proposal: assignments under constraints, explanations, gaps flagged, correction by the manager, publication with confirmation.
Week 5, swaps and absences: requests from the phone, rules checked, approval, replacements proposed, notifications, hours recomputed. Week 6, clock-in: on-site clock-in, shift-by-shift comparison, gaps noted, counted hours, export to payroll. Week 7, measurement: slot coverage, hour balance, swaps, absences, replacement time, Monday review with team leads.
- Where does the need per slot come from?
- From the activity of the same slots over the last weeks, covers, receipts, appointments, plus bookings already taken and events the manager enters; the application computes a figure and the manager corrects and writes it, with its source. A hand-corrected need is kept as such, and the next month shows whether the correction was right.
- Does the application decide the roster?
- No: it proposes an assignment that respects all hard constraints, satisfies as many soft constraints as possible, explains every choice and flags the slots it could not cover; the manager moves, replaces and decides. Assigning people to shifts under constraints is a problem known to be hard to solve exactly; an explained proposal the manager corrects is worth more than an optimum nobody understands.
- Who writes the hour and rest thresholds?
- The manager, in the rules, per position or contract: maximum hours per week, minimum rest between two shifts, rest days. The application applies them at every assignment, swap and replacement; it does not say which to write. Working-time law, payroll, overtime and premiums are for the accountant and counsel.
- How does a shift swap work?
- A person offers their shift to another from their phone; the application checks both people's hours, rest and qualification before the request reaches the approver; they approve or refuse; both people's hours are recomputed and both are notified. A swap that violates a hard constraint never reaches the approver.
- And a same-morning absence?
- It is declared from the phone, with a reason; the application proposes qualified replacements, under their maximum and with their rest, in the order the manager wrote, for instance fewest hours first; the first to accept is assigned, the others are told. The time between declaration and replacement is measured.
- Does clock-in replace payroll?
- No: it compares presence with the roster shift by shift, notes gaps with their duration, and counts hours, which are exported to payroll as in the integration guide. What those hours are worth, premiums, overtime, paid or unpaid absences, is a payroll and rules question, outside the application.
- How long to set this up?
- Seven weeks in the typical calendar, the first without code and two for needs and constraints. A business with one team and three slots takes less; a chain with several sites, qualifications per position and people rotating between sites takes more, the time to write each site's rules.