Over the past two years, “AI” has found its way into nearly every planning software brochure, ours included. The trouble is that the word covers very different things: a genuine optimisation engine, a rule-based sort given a new name, or nothing at all. Let us sort through it.
What automation genuinely does well today
Four uses are mature, in the sense that they rest on proven techniques and produce verifiable results.
Constrained allocation. This is the heart of it. Assigning people to tasks while simultaneously respecting required skills, availability, rest periods and hour caps is a combinatorial optimisation problem that machines handle better than we do. With a team of ten, an experienced planner does fine. With sixty, four overlapping qualifications and rest constraints, nobody explores that solution space in their head.
The orders of magnitude explain why. Assigning thirty people to thirty slots already means more than 1032 possible combinations. Nobody enumerates those, human or machine: the whole point is to traverse a vanishingly small fraction of that space intelligently. That is exactly what constraint solvers do, a technology that long predates the current AI wave and still powers most optimisation claims.
Workload forecasting. Activity history makes it possible to anticipate peaks. Some tools go as far as cross-referencing external signals, seasonality or weather. Useful, on one condition: enough clean history, which in practice rules out your first months of use.
Anomaly detection. Spotting that someone has been overloaded three weeks running, that a project is burning twice its planned effort, or that a slot is consistently left empty: these alerts are simple to produce and surprisingly effective, because nobody has time to go looking for them by hand.
Self-scheduling. Rather than imposing slots, people state their preferences and the system looks for an arrangement satisfying the most constraints. The practice is spreading, especially where shift work makes schedules painful to negotiate.
What AI will not do for you
Arbitrate fairness. An algorithm optimises what you ask it to optimise. Ask it to minimise cost and it will hand the unpopular slots to the same people every time, because that is optimal. Fairness is not an emergent property: it is a constraint you have to write down, and what it means in your team is your call.
Negotiate. A schedule is not only a calculation, it is a social agreement. The moment someone agrees to shift their leave because a colleague has a family emergency does not model well, and should not be modelled.
Carry the liability. Maximum durations and rest periods remain your obligation. If the tool proposes a schedule that breaches a daily rest, you are the one who will answer for it, not the vendor. A good system refuses to produce a non-compliant solution rather than displaying it with a discreet warning.
The real prerequisite, rarely mentioned: your data
This is what decides everything, and it is what sales demonstrations say least about.
An allocation engine cannot account for a skill that was never recorded. It cannot avoid a clash with an absence nobody declared. It cannot smooth workload if tasks carry no estimated duration. Output quality is bounded by input quality, and input is daily human work.
The practical advice follows: before buying optimisation, make sure your schedule is filled in properly for a few months. If your teams do not declare absences, no model will compensate. Frustrating, but that is the order of operations.
In practice, four inputs govern everything else:
- each person’s skills, kept current as they change;
- absences declared in advance, not recorded after the fact;
- an estimated duration on every task, however rough;
- the rest constraints specific to your activity, written down once.
About the numbers you will be shown
A methodological warning. While preparing this article we came across several widely repeated figures: productivity gains, project success rates, adoption forecasts. Tracing them back, most turn out to be either unsourced or lifted from studies whose scope has nothing to do with team scheduling.
Always ask where the number comes from. A serious vendor will tell you the sample, the period, and the baseline. A vendor who cannot answer is reciting a brochure.
Five questions to ask before signing
- Which constraints does the engine optimise for, and can I weight them myself?
- What happens when no compliant solution exists: an explicit refusal, or a non-compliant proposal?
- Can I see why a given person was assigned to a given slot, or is it a black box?
- How much history is needed before forecasting becomes reliable?
- Are decisions fully automated, or does a manager always validate? This also carries regulatory weight once assignment has significant effects on people.
What it changes for whoever builds the schedule
The concrete change is not that the planner disappears, it is that the work moves. Building the baseline schedule becomes fast. What remains, and what ends up filling most of the time, is handling exceptions: Monday morning’s sick leave, the site that slips three days, the person who needs easing off after a heavy stretch.
Good news for anyone who enjoys the job, because the mechanical part was the least interesting. Bad news for anyone hoping to cut the role: exceptions do not go away, they simply become the whole of the work.
Where we stand
We build AI in where it delivers a measurable gain: resource allocation under constraints, fill-rate calculation, identifying real availability. We do not claim it replaces a team manager’s judgement, because it does not, and because the customers who believed otherwise came back disappointed.
If the topic interests you, the page on AI in SOPlanning sets out what is actually implemented, and the feature list covers the rest, module by module. The most telling test is still to try the online demo with a case resembling your own.
The simplest test is on your own data. SOPlanning is free for 30 days, no commitment and no credit card.


Français
Italiano
Español
