Workforce scheduling & shift planning

Planners in hospitals, shops, restaurants, logistics hubs and contact centres build rosters in spreadsheets, balancing demand, skills, labour law and personal wishes. A forecast-plus-solver pipeline produces a compliant, fairer roster in minutes, lets staff swap shifts in an app and re-plans when someone calls in sick. The solver does the optimisation; ML supplies demand; LLMs are only the interface. Because the output steers people's work, works-council and AI Act rules matter.

Problem & value

• Today: a team lead or HR planner assembles the roster by hand or in Excel, often weekly or monthly. Constraints are numerous: minimum rest times, maximum hours, qualification mix, weekend fairness, collective agreements (e.g. TVöD, TV-L, retail agreements), part-time contracts. Short-notice absences trigger phone-round re-planning.
• AI/optimisation value: coverage matched to forecast demand (less over- and under-staffing), fewer rule violations, transparent fairness (weekend and night distribution), less planner time, more predictable schedules and higher staff satisfaction through preference-aware rostering and self-service swaps.
• Evidence: vendors publish case studies on planner time and overtime reductions, but figures vary widely by sector and baseline and are rarely independently audited; measure your own baseline first. Academic nurse-rostering research has benchmarked solvers for decades [1][2].

Variants

• Retail & hospitality: demand-driven rosters from footfall/sales forecasts, short shifts, high fluctuation.
• Healthcare & care: qualification mix, night/weekend fairness, strict rest rules; see HLTH-008.
• Contact centres & service desks: interval-level (15-30 min) staffing from call-volume forecasts (PRED-011), with skill-based routing (OPT-035).
• Logistics, warehouses, airports: multi-skill shift templates, agency/temp staff, peak-season ramp-up.
• Public sector: civil services such as fire brigades, hospitals, municipal utilities with collective agreements and works/staff councils.
• Private use: family chore/care rotas or club volunteer rosters via simple apps; no regulatory weight.

How it works

1. demand forecast (PRED-011) + staff data + rules
2. rule compilation (law, collective agreement, works agreement
3. constraints)
4. optimisation model (CP-SAT / MIP; hard constraints + weighted soft goals)
5. roster candidate(s) + explanation of violations and fairness
6. planner review & approval (human-in-the-loop)
7. publication to staff app, swap/open-shift marketplace
8. daily re-planning on absence (re-optimisation with minimal changes)
9. actuals from time & attendance
10. forecast and rule feedback

• Demand forecasting: gradient boosting or time-series models (hierarchical, with calendar, weather, promotions) per interval and skill.
• Optimisation core: the decision is made by a solver, not by a language model. Hard constraints (rest time, legal maxima, qualifications) must hold; soft constraints (preferences, fairness, cost) are weighted in the objective. Constraint programming (CP-SAT) is the de-facto open standard for rostering; commercial MIP solvers are an alternative.
• LLM layer (optional): turn plain-language rules from collective agreements into candidate constraints for a human to verify, explain why a shift was assigned, and answer staff questions in the app. Never let an LLM edit the roster unchecked; always re-validate with the rule engine.
• Human-in-the-loop: planner approves; staff may decline or swap within rule limits; works council co-determines rules and objectives.

Data preparation

Rostering needs employee master data (contracts, hours, skills, qualifications), availability, absences, demand forecasts and the applicable rules (working-time law, collective agreements, house rules). Sources are HR/payroll systems, time-recording, Excel rosters, WhatsApp requests and paper lists.

Typical gaps are outdated qualifications, unrecorded preferences and informal agreements, rules known only to the shift lead, no demand history and conflicting time-recording data.

Preparation steps: - Export HR and time data (PREP-005) and clean contracts and skills with HR as data owner (PREP-004). - Formalise rules from collective agreement and house practice as explicit, testable rule lists (PREP-016). - Build a demand history (orders, footfall, patients) from existing systems and structure Excel rosters (PREP-011). - Pseudonymise data for tests (PREP-022) and check purpose and legal basis (PREP-025).

Rough share of effort: about 30-40 percent. Because HR data is personal, access rights matter as much as quality. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A. Mature, EU-hosted shift-planning SaaS with rule engines for working-time law is available at per-employee prices.
• Enterprise: Path C. Employee data is sensitive and rosters are core to operations, so an open-source solver such as Timefold on own infrastructure integrated with HR/time systems avoids seat costs and keeps data in-house.
• Developer: Path C. Timefold or OR-Tools run on HW1.
• Public sector: Path C. Self-hosted solvers on sovereign infrastructure keep staff data under own control (hospitals, municipal services) and ease procurement.

Path A — Buy (recommended for most)

• Workforce-management suites: UKG (Kronos), Quinyx (SE), Planday (DK), Shiftbase (NL), Papershift (DE), Staffomatic (DE), Personio shift plans (DE, SMB basics), Dienstplan tools such as Atoss Staff Efficiency Suite (DE, strong in retail/industry/health), Dienstplan specialists, Orbis/ P&I and SAP SuccessFactors / Workforce Scheduling for large enterprises. Healthcare: Deputy, generic hospital-information-system modules.
• Check: EU data hosting, support for German Arbeitszeitgesetz and local collective agreements, time-tracking integration (mandatory working-time recording), payroll export (DATEV), works-council documentation, explainability of why a shift was assigned.
• Choose A when: standard shift models, 10-5,000 employees, a payroll/time-tracking system exists.

Path B — Build on cloud APIs

• Solver services: Google Cloud Optimization AI / OR-Tools on your own VM, Gurobi Cloud, Timefold Platform (BE, EU-based; Employee Scheduling model), nextmv decision platform.
• Forecasting: managed time-series (Amazon Forecast successors, Vertex AI, Azure ML) or open libraries run in your tenant.
• LLM layer: EU-region frontier APIs (Claude, Gemini, GPT, Mistral) with structured outputs to translate rules and explain results; do not send identifiable staff data unless needed.
• Choose B when: you have unusual rules or embed rostering in your own product.

Path C — Self-host (open source)

• Solvers: Google OR-Tools CP-SAT (Apache-2.0; documented employee-scheduling and nurse examples), Timefold Solver (Apache-2.0, Java/Python; employee-scheduling quickstart), OptaPlanner lineage, HiGHS, Pyomo/PuLP, MiniZinc.
• Forecasting: LightGBM, Prophet, StatsForecast, open time-series foundation models such as Chronos or TimesFM as a baseline.
• LLM (optional): a small self-hosted open-weight model (e.g. Qwen, Llama, Mistral families, ~8B) via Ollama or vLLM for rule drafting and explanations.
• Hardware: HW1 suffices - rostering is CPU-bound; GPUs are only needed for an optional LLM. Ops effort: modest, but rule modelling needs an operations-research or strong developer skill.

Path D — Custom training

Rarely needed for the roster itself. Worth it for custom demand models (many sites, rich history), learned shift-preference or no-show prediction, or reinforcement-learning/learned heuristics for very large or real-time re-planning. Needs one to two years of demand and attendance history per site.

State of the art (2026)

• Hybrid "predict, then optimise": ML forecasts feed exact solvers; CP-SAT-class solvers solve realistic nurse-rostering instances well and are the practical default. Pure end-to-end neural rostering is still research-grade [2].
• LLM-to-model translation: LLMs help write constraint models from text (see OPT-018) but produce subtle rule errors; verify against test rosters and keep the rule engine authoritative.
• Employee-centric planning: preference bidding, self-rostering, fair-schedule objectives and shift-swap marketplaces are standard in modern suites.
• Re-optimisation: stability-preserving re-planning on absence, with minimal changes to already published shifts.
• Limits: poor data (wrong availability, missing qualifications), under-specified informal rules, forecast error at interval level, and fairness objectives that conflict with preferences. Optimising purely for cost can produce unhealthy, unpredictable schedules.

Shared resources & combinations

• Same stack (optimization-solver + time-series): OPT-002 production scheduling, OPT-013 timetabling, OPT-019 field service dispatch, OPT-035 contact-centre routing; one CP-SAT/Timefold skill base serves all of them.
• Upstream: PRED-011 workload and staffing demand forecasting; HLTH-008 hospital capacity.
• Interface: AGENT-012 scheduling agents can handle swap requests via chat; workflow engine shared with AGENT-002 back-office automation.

Effort, cost & KPIs

• Path A: weeks to 3 months incl. rule configuration, payroll/time integration and works-council agreement; per-employee-per-month SaaS pricing is typical.
• Path B/C: 3-6 months for a production model with integration; cost is mostly engineering and rule modelling.
• KPIs: coverage vs. demand per interval, labour cost ratio, overtime hours, rule violations (target zero hard), planner hours per roster, share of preferences honoured, fairness spread (nights/weekends), short-notice changes, sick-call fill time, staff turnover/satisfaction.

People & change

Involve management, HR, shift or department leads, employees as users and the works council from the first concept, plus IT and the DPO.

Works council: yes in companies with one. Rosters touch working time (§87(1) no. 2 and 3 BetrVG), and a system processing preferences, absences and fairness data is objectively suited to monitor behaviour (§87(1) no. 6). §90(1) no. 3 requires early information, §80(3) allows an AI expert at the company's cost, and where the tool affects selection or deployment decisions §95(2a) applies. Conclude a works agreement (GUIDE-004). Public sector: staff council.

Data protection: employee data requires a legal basis (§26 BDSG), an AVV with the vendor and likely a DPIA when preferences or absences are evaluated systematically (GUIDE-005). Depending on use it may touch high-risk rules (Annex III, employment), see GUIDE-014.

AI literacy: train planners and employees on fairness rules and how swaps work, supporting AI literacy under Art. 4 AI Act (GUIDE-006).

Pilot with one willing team, publish the fairness rules and keep manual override with the shift lead. Typical concerns are opaque fairness, preferences ignored and surveillance; address them with transparency and a veto right. See GUIDE-008.

Risks, regulation & compliance

• EU AI Act: depends. Pure rule-based or solver rostering from availability is generally not high-risk. Annex III point 4(b) lists AI systems used to allocate tasks based on individual behaviour or personal traits or characteristics, or to monitor and evaluate performance and behaviour in work relationships; a roster that ranks employees by predicted reliability or performance, or assigns tasks on behavioural profiles, can fall in the high-risk class (provider and deployer duties: risk management, logging, human oversight, informing workers). Emotion recognition at work is prohibited (Art. 5(1)(f)); never infer moods or emotions to schedule. AI literacy (Art. 4) applies [3].
• GDPR: staff data (health-related absence, availability, union membership via preferences) is personal data and partly special category; employment context (Art. 88 GDPR, §26 BDSG in Germany), data minimisation, no use of sick-leave reasons, DPIA where profiling is used, Art. 22 limits on solely automated decisions with significant effects [4].
• Labour law: German Arbeitszeitgesetz (rest 11 h, max daily hours), Jugendarbeitsschutzgesetz, Mutterschutzgesetz, the EU Working Time Directive 2003/88/EC, collective agreements; ECJ ruling on systematic working-time recording. Works council co-determination on working time and technical monitoring (BetrVG §87(1) Nr. 2, 6); advance-notice rules for schedule changes. The Platform Work Directive (EU) 2024/2831 adds algorithmic-management rules for platform workers [5].
• Risks and mitigations: unfair patterns and indirect discrimination (audit fairness metrics by group), schedule unpredictability (publish early, limit changes), hidden surveillance (separate rostering from performance scoring), model errors (hard-constraint checker independent of the solver), over-reliance (planner approval, override log).

Getting started

1. Document your rules (law, agreements, informal practice) and measure the baseline: planner hours, overtime, violations.
2. Involve the works council early; agree on objectives, data used and prohibited uses.
3. Pilot one team with a Path A tool or an OR-Tools/Timefold prototype on past rosters and compare.
4. Add a demand forecast (start with a simple seasonal baseline) and test against actuals.
5. Roll out with swap/open-shift features and review fairness and KPIs monthly.

Sources

1. Google OR-Tools — Employee scheduling (CP-SAT) — https://developers.google.com/optimization/scheduling/employee_scheduling
2. Ernst et al. 2004, "Staff scheduling and rostering: A review of applications, methods and models", European Journal of Operational Research — https://doi.org/10.1016/S0377-2217(03)00095-X
3. Regulation (EU) 2024/1689 (AI Act), Art. 4, Art. 5, Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. Regulation (EU) 2016/679 (GDPR), Art. 22 and Art. 88 — https://eur-lex.europa.eu/eli/reg/2016/679/oj
5. Directive (EU) 2024/2831 on improving working conditions in platform work — https://eur-lex.europa.eu/eli/dir/2024/2831/oj
6. Timefold — Employee scheduling documentation — https://docs.timefold.ai/employee-scheduling/latest/introduction
7. Directive 2003/88/EC (Working Time Directive) — https://eur-lex.europa.eu/eli/dir/2003/88/oj