← ccPlanning Academy · Advanced track

Optimisation & the solver mindset

Free visual lesson · about 5 minutes · short quiz at the end

ccPlanning academy · advanced

Optimisation & the solver mindset

Behind every “auto-schedule” button is a maths problem worth understanding.

The big idea

Scheduling is a constrained optimisation problem.

“Cover the requirement at lowest cost, without breaking any rules” is the textbook shape of an optimisation problem: an objective to minimise, subject to constraints. WFM auto-schedulers are solvers doing exactly this — and understanding the framing makes you their master, not their servant.

The three ingredients

Objective, variables, constraints.

Objective
what to minimise (e.g. cost, under-cover)
Variables
what you can choose (shifts, starts)
Constraints
rules that must hold (contracts, rest)

Every solver, simple or fancy, is juggling these three.

What solvers are brilliant at

Searching a vast space fast.

There are billions of ways to arrange a month of shifts. A solver explores that space far faster and more thoroughly than any human, finding low-cost rosters that satisfy every hard rule. For big, constraint-heavy problems, this is genuinely beyond manual scheduling.

What solvers can’t fix

A wrong objective, optimised perfectly.

A solver answers exactly the question you pose. Tell it to minimise cost and it’ll happily produce a brutal, unliveable roster that’s technically optimal — and drives attrition. Garbage objective, optimal garbage. The hard part isn’t the algorithm; it’s defining what “good” means.

Hard vs soft constraints

Must-haves and would-likes.

Hard constraints can never break (legal rest, max hours). Soft constraints are preferences you’d pay to honour (shift preferences, fairness, weekends off). Good optimisation weights the soft ones thoughtfully — over-tighten and there’s no feasible roster; ignore them and you get an efficient, hated schedule.

The planner’s real job

Frame the problem; sanity-check the answer.

The solver does the search; you set the objective, encode the constraints honestly, and judge whether the output is humane and sensible. An optimiser is a power tool — it amplifies a good problem definition and a bad one equally. Never ship a solver’s roster without a human read.

Optimal ≠ good

“Minimise cost” — be careful what you ask

Tell the solver one thing — minimise cost — and it obeys perfectly: split shifts every day, lunch at 3pm, weekends for the newest staff, nobody’s preferences honoured. Technically optimal. Also unliveable, and it drives the attrition that blows the plan apart within a quarter.

The algorithm did its job; the objective was wrong. The craft was never the maths — it’s defining what “good” means before you press solve.

The takeaway

The maths is easy; the framing is the craft.

Scheduling is objective + variables + constraints, and solvers search that space superbly. But they optimise exactly what you ask — so the value is in defining “good” well, balancing hard and soft constraints, and sanity-checking the result. Master the framing and the solver works for you.

Now test yourself ↓

1 / 8

Slides done? Here’s the same idea in a bit more depth — the part worth keeping.

In depth: the maths behind the auto-schedule button

“Cover the requirement at lowest cost, without breaking any rules” is the textbook shape of a constrained optimisation problem: an objective to minimise, subject to constraints. WFM auto-schedulers are solvers doing exactly this, and understanding the framing is what makes you their master rather than their servant. Every solver, simple or fancy, is juggling three ingredients — an objective (what to minimise, like cost or under-cover), variables (what you can choose, like shifts and start times), and constraints (rules that must hold, like contracts and rest).

What solvers do brilliantly — and can’t fix

There are billions of ways to arrange a month of shifts, and a solver explores that space far faster and more thoroughly than any human, finding low-cost rosters that satisfy every hard rule — for big, constraint-heavy problems this is genuinely beyond manual scheduling. But a solver answers exactly the question you pose: tell it to minimise cost and it’ll happily produce a brutal, unliveable roster that’s technically optimal and drives attrition. Garbage objective, optimal garbage. The hard part isn’t the algorithm; it’s defining what “good” means.

Hard vs soft constraints, and the planner’s real job

Hard constraints can never break (legal rest, maximum hours); soft constraints are preferences you’d pay to honour (shift preferences, fairness, weekends off). Good optimisation weights the soft ones thoughtfully — over-tighten and there’s no feasible roster, ignore them and you get an efficient, hated schedule. So the planner’s real job isn’t the search, which the solver does: it’s setting the objective, encoding the constraints honestly, and judging whether the output is humane and sensible. An optimiser is a power tool that amplifies a good problem definition and a bad one equally — never ship a solver’s roster without a human read.

The principle to remember: the maths is easy; the framing is the craft. Scheduling is objective + variables + constraints, and solvers search that space superbly — but they optimise exactly what you ask, so the value is in defining “good” well, balancing hard and soft constraints, and sanity-checking the result.

Quick quiz

Five questions. Pick an answer to each, then check your score.

1. How is scheduling framed as an optimisation problem?

Cover the requirement at lowest cost without breaking rules — objective + constraints.

2. What are the three ingredients of an optimisation problem?

What to minimise, what you can choose, and the rules that must hold.

3. What are solvers brilliant at?

They explore billions of arrangements far faster and more thoroughly than a human.

4. What can a solver NOT fix?

It answers exactly the question you pose — garbage objective, optimal garbage.

5. What’s the difference between hard and soft constraints?

Over-tighten soft constraints and there’s no feasible roster; ignore them and you get a hated one.

Related: the rotating rosters and shift design lessons cover the constraints in practice.

Next lesson: Planning for automation & AI deflection →