Staff Scheduling Optimisation With Machine Learning

Rotas go wrong in the same two ways

Somebody builds next month's rota from last month's rota. Tuesdays get the same three people they always have, Saturdays get whoever did not say no fast enough, and the manager fills holes by text message the night before.

The result is predictable. Quiet periods are overstaffed, which is wage cost with nothing to show for it. Peaks are understaffed, which is queues, missed service levels and your best people quietly updating their CVs. Neither problem shows up clearly on the payroll report.

Two separate problems, two different tools

Most vendors bundle all three and call the lot AI scheduling. It helps to separate them because each fails differently. A bad forecast puts staff in the wrong hours. A bad solver produces legal but miserable rotas. A missing requirement model means nobody knows how many people a given volume actually needs.

What the forecasting model learns

The forecast predicts workload by hour or half hour: orders to pick, patients to see, covers to serve, tickets to answer. A useful model takes in more than last year's calendar.

• Day of week and hour, with separate patterns for school holidays and bank holidays
• Marketing sends and promotions, which shift demand in ways the calendar cannot predict
• Weather, for hospitality, garden centres and anything with footfall
• Known bookings or orders already on the books for the coming days
• Local events, where they genuinely matter and can be recorded consistently

Take a care agency or a busy clinic: much of the next fortnight is already booked, so the model is forecasting the unbooked remainder plus cancellations. A warehouse is the opposite, where most of tomorrow's orders do not exist yet. The right model depends on which of those you are.

The solver, and the rules it has to respect

Once you know how many people you need each hour, a solver assigns shifts. This is where the real-world rules live, and there are always more than anyone writes down at the start.

• Working Time Regulations, minimum rest between shifts and maximum weekly hours
• Contracted hours, part-time patterns and zero-hours availability
• Skills and certifications, such as a forklift licence or a clinical grade
• Fairness rules: weekends, late shifts and bank holidays spread evenly
• Personal preferences and fixed commitments like school runs

The first draft rota the solver produces will be technically valid and rejected by the team within minutes, because an unwritten rule was missed. That is normal. Capturing those rules is most of the project.

When machine learning scheduling is not worth it

If you have twelve staff, stable demand and a manager who knows everyone's circumstances, a decent rota app is the right answer. Custom forecasting adds little when the busy hours are the same every week.

It becomes worthwhile when demand is volatile, when you have enough staff that the rota takes a manager a day each week, when labour is the largest controllable cost, or when you run several sites that borrow people from each other. A contact centre, a multi-site retailer or a 200-person warehouse is squarely in that zone. Our older post on rota automation covers the simpler, rules-based end of the problem.

Staff acceptance is a design requirement

A mathematically optimal rota that people hate is not optimal. It produces sickness, swaps and resignations, and those costs do not appear in the solver's objective.

The rota is the most personal piece of software most employees will ever touch. Treat its fairness rules as seriously as its cost targets.

We build three things in from the start: a way for staff to state preferences and unavailability, a visible fairness score so people can see weekends are shared, and a manager override that is logged so recurring overrides become rules.

How we would run the project

SpiderHunts would usually start by lining up twelve months of workload against staffed hours to show where the mismatch sits. That picture tends to settle arguments about whether there is a problem.

1. Build the workload forecast and test it against the last few months
2. Agree staffing requirements per unit of work with the operations lead
3. Write down every scheduling rule, including the unwritten ones
4. Run the solver alongside the manager's rota for a month and compare
5. Go live with manager approval of every rota before publishing

Forecasts and solvers integrate with most workforce management and HR systems through their APIs. If yours has none, a CSV export and import is fine to start. We cover the build side under machine learning services.

How to tell whether the new rota is working

Wage cost alone is a poor measure, because a cheaper rota that loses two good people has not saved anything. Track a small set of numbers before and after, and give it at least two full rota cycles before drawing conclusions.

• Hours where staffing fell short of forecast workload, and by how much
• Hours where staffing exceeded workload by more than one person
• Overtime and agency spend
• Last-minute shift changes and swaps per week
• Sickness absence and voluntary leavers over the following quarter
• Service measures the business already cares about: queue times, orders dispatched on time, patient wait

If the shortfall hours fall and swaps stay flat or drop, the rota is doing its job. If swaps climb sharply, the rules are wrong somewhere, and the team is telling you so.

Frequently asked questions