Shift scheduling software: the rota published on Friday, and by Monday morning it no longer exists

The coordinator of a care home near Brescia, in northern Italy, one hundred and twenty beds and ninety six employees, publishes the monthly rota on Friday afternoon. By Monday morning that rota no longer exists: two care assistants have asked to swap, one has called in sick, another has a mandatory training course nobody had looked at, and Saturday night is uncovered. At nine on Monday the coordinator is on the phone, and the phone will stay her planning tool for the rest of the month. If you are looking for shift scheduling software, this article gives you a way to know whether you really need it, and how much it will give back, with a number instead of a feeling.

You will find the real cost of shifts run today on a spreadsheet and a phone, the single number that says whether shift scheduling software pays you back or just gives you a prettier rota, the rules a shift plan must actually respect across law, collective agreement and accreditation, why shift planning is a genuinely hard problem and what a solver does that a spreadsheet never will, fairness as the constraint that appears in no law and makes people leave, the real price ranges between your payroll system's module, a dedicated product and a custom system, and the threshold beyond which the arithmetic flips.

I have been writing software since 1999, and my relationship with shift planning is an old one: I wrote my first scheduling engine for a private security company at the start of the 2000s, when availability arrived by fax. Since then I have seen the same scene in care homes, supermarkets, continuous process food plants, cleaning and emergency services. The vocabulary changes, the problem does not: someone builds a grid with great effort, the grid survives two days, and from then on the rota is rewritten by chance, one phone call at a time.

What I have learned, and what explains why so many companies buy a beautiful digital rota and a year later are still paying overtime they did not need, is this: the number that decides is not how many people you have on rota, it is how much of the hours you planned gets rewritten after the shift plan has been published. A rota that holds is a rota you can defend: people know when they work, who covers an absence is decided by a rule and not by whoever answers the phone, and you pay extra hours when they are genuinely needed. A rota that gets rewritten is a daily negotiation, and every negotiation costs a premium rate, a phone call and a little trust.

What shift scheduling software is, and what it is not

Shift scheduling software is the system that decides who works when, before the work happens. It holds three things that today live in three different places: the staffing need, meaning how many people with which skills are required in each time band of each day; the constraints, meaning what law, collective agreement and accreditation forbid you to ask of a person; and availability, meaning holidays, leave, training, part time arrangements, approved unavailability and preferences. From those three it builds a proposed rota, publishes it, and from then on tracks every gap between what you planned and what happened.

If one of the three is missing you do not have shift scheduling software, you have a coloured grid. And that is why so many projects stall halfway: the tool that draws the grid gets bought, and the three pieces of information needed to fill it stay where they were, which is in the coordinator's head.

Scheduling, attendance and payroll: three different systems everyone calls the same thing

Here the confusion costs real money, because you end up buying the tool for a different problem. Shift scheduling looks forward: it decides who will work tomorrow and in three weeks. Time and attendance looks backward: it records who clocked in and when, and turns clockings into payable hours. Payroll takes those hours and turns them into a payslip. Three systems, three purposes, often three vendors, and their boundary is where the money is lost.

If your problem is that you do not know how many hours someone actually worked, or that clockings arrive on a sheet at month end, you do not need scheduling software: I have written about that at length in time and attendance software, and it is a different project with a different return. If instead you know exactly how many hours were worked and the problem is that they were worked by the wrong people, at the wrong moments and at the wrong premium rates, then the problem is planning, and that is what the rest of this article is about.

The question I use to tell which side a company is on is a single one: when month end arrives, are the surprises in the total hours or in how they are distributed? If the total adds up but overtime is concentrated on seven people out of seventy, the problem is the rota. If the total does not even add up, the problem comes earlier and has to be solved first.

The rota, the checks and the engine: what separates the products

On the market, under the same label, you find three generations of tools. The digital rota is a spreadsheet with colours, sharing and a phone app: it shows the plan, lets you change it, notifies people. It is a huge step up from a printed sheet on a noticeboard, and for many small companies it is enough. The rota with checks adds the rules: when you assign someone to a night after a late shift it tells you that you are breaking the eleven hours of rest, and it counts weekly hours as you type. The planning engine does something different: you give it the staffing need and the constraints, and it proposes the rota to you, telling you which preferences it had to sacrifice to make it stand up.

The price gap between the first and the third generation is, surprisingly, not huge. The gap in results is, and it depends on one thing: who does the hard work. With a rota tool, the coordinator still does it and the software only tells her when she got it wrong. With an engine, the software does it and the coordinator decides which proposal convinces her most. In a business with seventy people on rota that is the difference between a day and a half a week and two hours.

The real cost: what shifts run on a spreadsheet cost you today

I will take the reference business, the one with the coordinator who spends Monday on the phone, and keep it for the whole article so the numbers stay comparable. One hundred and twenty beds, ninety six employees of whom seventy eight are on rota: fifty two care assistants, thirteen nurses, five physiotherapists and activity staff, eight in the kitchen and laundry. Revenue of around four million nine hundred thousand euros a year between fees and the regional health contribution, labour cost of three million three hundred and fifty thousand, sixty eight per cent, operating profit around two hundred and twenty thousand euros. One hundred and twenty five thousand planned hours a year, a spreadsheet, a chat group and the memory of two people.

With the director and the coordinator we measured five costs, one by one, over the last twelve months, cross referencing the published rota, the clockings and labour cost. I will give them in order of weight, with how we measured each one, because the value of the exercise is in the method more than in the total: your numbers will be different, the method will not.

The premium on agency staff called at the last minute

The home had used six thousand four hundred hours of agency work in the year, almost all of it care assistants. The agency's hourly cost averaged twenty six euros eighty against nineteen forty for its own staff at the same grade: seven euros forty of difference for every hour, which is forty seven thousand euros a year of premium.

Part of that reliance on agencies is normal and worth defending: with a tight establishment, agency staff are the insurance that lets you open the rota even when three people are ill at once. But when we looked at what those hours covered, three thousand nine hundred out of six thousand four hundred, sixty one per cent, covered absences known at least three days in advance: holidays approved weeks earlier, mandatory courses scheduled at the start of the year, planned occupational health appointments, leave notified in good time. They were not emergencies: they were gaps the rota had never absorbed, because when the rota was written that information sat in a different folder.

The overtime that comes out of a predictable gap

In the same year, permanent staff had worked nine thousand two hundred hours of overtime. Here too we separated the causes: how much came from something sudden, and how much from an absence that was known. Four thousand one hundred hours, forty five per cent, were the second kind.

The cost of those hours is not entirely wasted, because the work had to be done anyway. What is wasted is the difference: an hour of overtime, with the contractual premium and with the fact that it almost always falls at night or on a public holiday because those are the uncovered bands, cost on average five euros sixty more than the same hour worked at normal time by someone with room left in their own hours. Four thousand one hundred hours at five euros sixty is twenty three thousand euros a year. On top of that there is an effect we did not count because it is hard to measure honestly, but it is real: last minute overtime concentrates on whoever answers the phone, and whoever answers the phone eventually stops answering.

The coordination hours spent building and rebuilding the rota

The coordinator spent about a day and a half a week on the rota: building the month, the changes after publication, the calls for cover, counting hours and rest periods by hand. The senior nurse helped for another half day, and the director stepped into the difficult cases. Added up, that was around zero point five five full time equivalents on coordination roles: twenty four thousand euros a year.

It is the cost management always underestimates, for an understandable reason: those people are already there and already paid. But coordination time is the one resource a care business cannot easily buy, and spending it on jigsaw puzzles is the worst possible choice, because it is exactly the time missing for the staff, the families and the quality of the service.

The turnover that comes out of the rota

Over the year, fourteen people had left out of seventy eight on rota, eighteen per cent. In exit interviews, five gave as their main or secondary reason the way shifts were distributed: the same people always on weekends, changes announced a day ahead, leave requests granted to whoever asked first instead of whoever had given most.

We costed a replacement conservatively: advertising and selection, the hiring paperwork and above all the three weeks of shadowing during which the new person works paired with an experienced one. About five thousand two hundred euros per replacement. Five departures attributable to the rota is twenty six thousand euros a year, and that is without counting that in a care home turnover is also paid in quality of care, which is the reason families choose you over the home ten kilometres away.

The errors that reach the payslip and the rest periods that vanish

The last cost is the least visible and the most irritating. Every month the step from the worked rota to payroll produced corrections: night premiums allocated wrongly, swaps agreed verbally and never recorded, training hours counted as service. Around two hundred and forty hours a year across coordination, HR administration and the payroll consultant, plus corrections on the following month's payslip, which is the thing that destroys trust faster than anything else.

In the same review we found sixty one cases over the year where less than eleven hours had passed between the end of one shift and the start of the next. Nobody had wanted them: they were the result of swaps agreed between colleagues directly in a chat group, with nobody counting the hours. The direct cost of those cases is zero until an inspection or a dispute arrives; the expected cost is not, and in the total we put it together with the correction time for nineteen thousand euros.

The measured total is one hundred and thirty nine thousand euros a year. Against an operating profit of two hundred and twenty thousand, that is sixty three per cent. And the thing to notice is not the figure, it is the structure: four costs out of five come from the same fact, namely that the published rota and the worked rota are two different things. That is why the number that decides is the one in the next section, and not the number of people on your payroll.

The share of hours rewritten after publication: the number that decides

The definition is simple. Take the rota as you published it, with the name, date and time band of every shift. Take the rota as it was actually worked, which comes from clockings. Compare line by line: a shift has changed if a different person does it, if the time band changes, if it disappears or if one appears that was not there. The share of rewritten hours is the total hours involved in a change divided by the total planned hours over the same period.

It is measured on hours and not on the number of changes for a practical reason: a swap between two colleagues on the same shift is half an hour of admin, an uncovered night filled by a call is eight hours costing twice as much. In the reference home the share was fourteen per cent: seventeen thousand five hundred hours a year decided after the rota was published, which means decided on the phone.

I use four thresholds. Under five per cent the planning holds: new software will give you convenience, visibility and continuity when the person who builds the rota goes on holiday, not much margin. Between five and twelve the problem is the process: availability arrives late, the rule for deciding who covers is not written down, the staffing need is never stated explicitly, and a few organisational decisions are worth as much as software. Over twelve the rota is rewritten by chance, and every rewritten hour costs more than a planned one. And then there is the most common case, never measured, which almost always sits in the third band and almost always surprises management.

How to measure it in two weeks, buying nothing

The measurement uses what you already have. Two things are needed: the rota as it was published, and the hours as they were worked. You certainly have the second, because it is what you send to payroll. The first is what almost nobody keeps, and this is the first real step of the project: saving a copy of the rota at the moment of publication, frozen, never touched again. In a spreadsheet that is a duplicate tab with the date in its name. It is a thirty second gesture each month that lets you measure everything else.

If you already have two or three months of published rotas archived somewhere, the measurement is a query. This is the one I use when the data sits in a table, and it works the same whether you put it in a database or in an imported sheet.

-- Share of hours rewritten after publication, by department and by cause.
-- Published = the rota frozen at the moment of publication, never touched again.
-- Worked = what comes from the clockings, already matched to the shift.
WITH Comparison AS (
    SELECT
        p.Department,
        p.Day,
        p.Hours                                 AS PlannedHours,
        CASE
            WHEN w.ShiftId IS NULL              THEN 'shift cancelled'
            WHEN w.PersonId <> p.PersonId    THEN 'different person'
            WHEN w.Band     <> p.Band        THEN 'different band'
            WHEN ABS(w.Hours - p.Hours) > 0.25  THEN 'different length'
            ELSE 'unchanged'
        END                                     AS Outcome
    FROM PublishedRota AS p
    LEFT JOIN WorkedRota AS w
           ON w.ShiftId = p.ShiftId
    WHERE p.Day >= @From AND p.Day < @To
)
SELECT
    Department,
    SUM(PlannedHours)                                                    AS PlannedHours,
    SUM(CASE WHEN Outcome <> 'unchanged' THEN PlannedHours ELSE 0 END) AS RewrittenHours,
    CAST(100.0 * SUM(CASE WHEN Outcome <> 'unchanged' THEN PlannedHours ELSE 0 END)
              / NULLIF(SUM(PlannedHours), 0) AS decimal(5,1))            AS RewrittenShare
FROM Comparison
GROUP BY Department
ORDER BY RewrittenShare DESC;

Two warnings about the result, worth more than the query. First: look at the figure by department and by time band before looking at the total, because the average fourteen per cent almost always hides one unit at twenty three and one at three, and the project happens where the twenty three is. In the reference home the unit with the most dependent residents was at twenty three per cent, the kitchen at three. Second: separate wanted changes from imposed ones. A swap between two colleagues who have found an arrangement is almost always a good thing and should be made easy, not blocked; what you need to reduce is cover decided by the coordination team under pressure.

The second number, the one that says where to act

Alongside the share of rewritten hours I use another one, cheap to compute and very informative: the share of hours rewritten because of an absence known more than seventy two hours in advance. That is the part of the problem that has nothing to do with emergencies, and the part software gives back almost in full, because all it takes is letting information the company already had reach the rota. In the reference home it was sixty one per cent of agency hours and forty five per cent of overtime hours: two thirds of the problem was memory, not surprise.

When I bring these two numbers to a management team, the most frequent reaction is a defensive and legitimate question: if we had known in time, what would we have done differently? The answer is almost always concrete. With three weeks of notice you have three roads you do not have with three hours: move a shift by an hour and cover the gap with people already there, ask the person who owes hours instead of the most accommodating one, or call the agency a week ahead, which costs less and sends you someone who has already worked with you.

The rules a shift plan must respect: law, agreement and accreditation

This is why the rota is not a calendar problem but a constraint problem. The rules come from three different sources, they add up, and none of the three is written down where the rota is built.

What working time law says

In Italy the reference text is Legislative Decree 66 of 2003, and the rules that touch planning are few and precise. Daily rest: at least eleven consecutive hours in every twenty four. That is the one that breaks first when a swap happens in a chat group, because a late shift ending at nine at night and a morning starting at seven leave ten hours. Weekly rest: at least twenty four consecutive hours every seven days, as a rule coinciding with Sunday, to be added to the eleven hours of daily rest, and calculated as an average over a period no longer than fourteen days. Average weekly working time: no more than forty eight hours on average, overtime included, over a four month reference period that collective agreements may extend. Breaks: at least ten minutes when the working day exceeds six hours.

Night work rules are even more specific, and in businesses running around the clock they matter a great deal. Night time is a period of at least seven consecutive hours including the hours between midnight and five in the morning. A night worker is someone who works at least three hours in that window on a non occasional basis, or who performs night work for at least eighty days a year, unless the collective agreement says otherwise. For anyone in that definition, working time may not exceed eight hours on average in twenty four, and periodic health surveillance is mandatory. And there are personal exclusions: a pregnant worker may not be assigned to night work, and among others the parent of a child under three and anyone caring for a disabled dependant cannot be obliged to do it.

Breaches of these rules carry administrative penalties, computed per worker and per reference period and rising in bands with the number of people involved. The point, though, is not the penalty, which is rare: it is that these rules are the constraints of the problem. A rota that breaks them is not an aggressive rota, it is a wrong one, and sooner or later you pay for it in another currency.

What the collective agreement adds

The agreement adds the layer that changes from sector to sector, and it is the one no product knows when you install it. Multi period distribution of working time and the limits of shift cycles. The notice with which the rota must be communicated, expressed in days in several agreements and in weeks in some. Premium rates for night, public holiday and Sunday work and how they stack, which is the part that shows up in the payslip. The treatment of shift changes requested by the employer at short notice.

And for part time workers, elastic and flexible clauses: changing when the work is performed requires a written agreement, a minimum notice of two working days and a specific premium. It is the rule most often broken in care businesses without anyone noticing, because calling a part time colleague feels like asking a favour, when it is in fact a change to the agreed working pattern.

What accreditation requires, and why it outranks everything else

In health and social care there is a third source, and in practice it is the one in charge: the care standard required by regional accreditation. In Lombardy, for residential care homes, the reference standard is expressed in weekly minutes of care per resident, nine hundred and one, with a share that must be provided by nursing staff. Standards vary from region to region and must be read against your own rules, but the mechanism is the same everywhere: the rota must not only respect the rights of the people working, it must also prove that in every time band there were the number and type of staff you committed to provide.

This changes the nature of the problem, and I say so because it is the point management grasps immediately and vendors often do not: the rota is not only an organisational document, it is the evidence of a commitment. If on one night there was one nurse for two units when one per unit was required, that is not a planning slip, it is an unmet requirement. Software that cannot compute care minutes per resident from the rota is not helping you where you need it most, and that is the first question to ask anyone giving you a demonstration, before the price.

Why shift planning is genuinely hard, and what a solver does

There is a widespread and damaging belief that shift planning is boring but simple, left to manual work only because nobody ever bothered to automate it. That is not so: it is a genuinely hard problem, studied for decades under the name of staff rostering, and it belongs to the family of problems for which no method finds the best solution in reasonable time as size grows. With seventy eight people, thirty days and four shift types, the number of possible combinations is a number with hundreds of digits. Nobody explores them all, neither a person nor a computer.

The practical consequence is that whoever builds rotas by hand is not doing something stupid: they are applying a reasonable heuristic, starting from last month's grid, adapting it and fixing what breaks. The problem is not their intelligence, it is that every adaptation propagates effects no head can hold together. Move one person off Thursday night and you have just broken the weekly rest two weeks later.

Hard and soft constraints: the distinction that makes it all work

The structure of the problem is always the same and is easy to explain to a management team. There are hard constraints, which may never be violated: the eleven hours of rest, weekly rest, the hours cap, approved unavailability, the mandatory skills for a given shift, the minimum cover of every band. A solution that violates even one of them is not a worse solution: it is not a solution at all. Then there are soft constraints, which can be violated at a price: the preference of someone who does not want Thursday nights, the balance of weekends, continuity of the same care assistant on the same unit, regular rotation between mornings, afternoons and nights, not switching band twice in three days.

A solver does exactly this: it looks for a solution that respects every hard constraint and minimises the sum of the weights of the soft ones it breaks. And the most valuable thing it gives you is not the rota: it is the sentence that comes with it, namely which preference it had to sacrifice and why. That is the difference between a coordinator who has to defend a personal choice and one who can say that this weekend fell to you because over the last two months you had done one fewer than the unit average.

The code: hard constraints get checked before anyone argues

Before building the rota you need a function that says whether a rota is valid, because you need that function at three moments: when the engine proposes, when the coordinator edits by hand and when two colleagues swap a shift on their phones. This is the core I use, reduced to the three constraints that break most often.

// The three constraints that break first when a rota is edited by hand:
// eleven hours of daily rest, weekly rest over 14 days, 48 hour average.
var breaches = Constraints.Check(shifts, from: new DateOnly(2026, 10, 1), days: 31);

public record Shift(int PersonId, DateTime Start, DateTime End)
{
    public double Hours => (End - Start).TotalHours;
}

public record Breach(int PersonId, DateOnly Day, string Rule, string Detail);

public static class Constraints
{
    public static IReadOnlyList<Breach> Check(
        IEnumerable<Shift> shifts, DateOnly from, int days)
    {
        var result = new List<Breach>();

        foreach (var person in shifts.GroupBy(s => s.PersonId))
        {
            var ordered = person.OrderBy(s => s.Start).ToList();

            // 1. Daily rest: at least 11 hours between the end of a shift and the start of the next.
            for (var i = 1; i < ordered.Count; i++)
            {
                var gap = (ordered[i].Start - ordered[i - 1].End).TotalHours;
                if (gap < 11)
                    result.Add(new Breach(person.Key,
                        DateOnly.FromDateTime(ordered[i].Start), "daily rest",
                        $"{gap:0.0} hours between one shift and the next"));
            }

            // 2. Weekly rest: 24 consecutive hours plus the 11 of daily rest,
            //    averaged over 14 days: every window needs two long rests.
            for (var d = 0; d + 14 <= days; d++)
            {
                var start = from.AddDays(d).ToDateTime(TimeOnly.MinValue);
                var end = start.AddDays(14);
                var inside = ordered.Where(s => s.Start >= start && s.Start < end).ToList();

                var longRests = 0;
                for (var i = 1; i < inside.Count; i++)
                    if ((inside[i].Start - inside[i - 1].End).TotalHours >= 35)
                        longRests++;

                if (inside.Count > 0 && longRests < 2)
                    result.Add(new Breach(person.Key, DateOnly.FromDateTime(start),
                        "weekly rest",
                        $"{longRests} rests of at least 35 hours in 14 days, 2 are required"));
            }

            // 3. Average weekly working time, overtime included, over the reference period.
            var weeks = days / 7.0;
            var average = ordered.Sum(s => s.Hours) / weeks;
            if (average > 48)
                result.Add(new Breach(person.Key, from, "average weekly hours",
                    $"{average:0.0} hours a week on average over the period"));
        }

        return result;
    }
}

Three warnings about this code that matter more than the lines themselves. First: weekly rest must be checked across the month boundary, so the window has to reach into the last days of the previous month, otherwise every first of the month is a blind spot. Second: the reference period for the forty eight hour average is set by the collective agreement, so it belongs in configuration and not in the code. Third, and most important: this function must run before a change is accepted, not in the month end review. A check that tells you afterwards that you broke a rest period is worth nothing, because that rest is already gone and the person has already worked.

The engine: what it really takes to make it work

Building the rota, not just checking it, is the next step, and the good news is that the tools for it are free and mature. A constraint solver of the kind available in open libraries handles a month of seventy people in a few minutes on an ordinary computer. The model is simpler than it sounds: one true or false variable for each combination of person, day and shift type, the hard constraints as equations and the soft ones as penalties to minimise.

// Constraint model with a free solver: who works, when and on which shift.
// x[p, d, t] = true if person p works shift type t on day d.
var model = new CpModel();
var x = new BoolVar[people.Count, days, types.Count];

for (var p = 0; p < people.Count; p++)
    for (var d = 0; d < days; d++)
        for (var t = 0; t < types.Count; t++)
            x[p, d, t] = model.NewBoolVar($"x_{p}_{d}_{t}");

// Hard constraint 1: each day a person works at most one shift.
for (var p = 0; p < people.Count; p++)
    for (var d = 0; d < days; d++)
        model.AddAtMostOne(Enumerable.Range(0, types.Count).Select(t => x[p, d, t]));

// Hard constraint 2: the minimum cover of every band must be met.
for (var d = 0; d < days; d++)
    for (var t = 0; t < types.Count; t++)
        model.Add(LinearExpr.Sum(Enumerable.Range(0, people.Count)
            .Select(p => x[p, d, t])) >= cover[d, t]);

// Hard constraint 3: after a night, no work the following day (the 11 hours of rest).
for (var p = 0; p < people.Count; p++)
    for (var d = 0; d < days - 1; d++)
        for (var t = 0; t < types.Count; t++)
            model.AddImplication(x[p, d, night], x[p, d + 1, t].Not());

// Soft constraint: every weekend above the unit average carries a cost.
var penalties = new List<IntVar>();
for (var p = 0; p < people.Count; p++)
{
    var excess = model.NewIntVar(0, days, $"excess_{p}");
    model.Add(excess >= LinearExpr.Sum(weekends.SelectMany(d =>
        Enumerable.Range(0, types.Count).Select(t => x[p, d, t]))) - averageWeekends);
    penalties.Add(excess);
}

model.Minimize(LinearExpr.Sum(penalties));

var solver = new CpSolver { StringParameters = "max_time_in_seconds:120" };
var status = solver.Solve(model);

The point I want to land is not the code, it is what the code makes possible: the engine should not produce the rota, it should produce three rotas. One favouring weekend fairness, one favouring continuity on the same unit, one minimising cost. The coordinator looks at the three, sees what each one costs in sacrificed preferences, and chooses. That is how these systems get accepted instead of worked around, because the decision stays with the person responsible for the unit and only the way of reaching it changes.

The real work, and the real cost of a project like this, is not the solver. It is the three things the solver demands and that almost no company has written down: the skills matrix, meaning who can actually do what and not on paper; the declared staffing need per band, which often has never been put in writing and comes out differently depending on who describes it; and unavailability collected early and in one place. When a project is asked to go faster, that is always what gets cut, and that is always where the project then stalls.

Fairness: the constraint in no law that makes people leave

If I had to name the single thing that separates an accepted planning project from a rejected one, it would not be any rule of law. It would be this: the system must be able to answer the question "why me?". And to answer it, it has to count.

In the reference home we counted, over the previous twelve months, how many weekends and how many nights each of the fifty two care assistants had worked. The average was twenty one weekends a year. The distribution ran from thirteen to thirty two: same job, same contract, and nineteen more public holidays and weekends worked in a year between the most protected person and the most exposed one. Nobody had decided that. It was the result of a year of phone calls in which you call the person you know will say yes.

That figure, shown to management, did more than the cost analysis, because it explained three apparently separate things at once: why five people had left, why leave requests had become a tug of war, and why some people were always off sick at weekends. When fairness is not measured, the system self regulates in a predictable way: those who have learned to say no get called less, and those who say yes pay for everyone until they leave.

How to measure fairness without starting a war

Fairness is not giving everyone the same number of nights, because contracts differ, part time arrangements differ and some people ask for nights. It is keeping a balance per person, pro rated to contracted hours, over four quantities only: weekends worked, nights, public holidays required and changes accepted with less than forty eight hours of notice. That balance is shown to everyone, resets at the start of each year, and becomes the criterion by which the system decides who to ask first when someone is missing.

The fourth quantity is the one nobody usually counts and the most important one: whoever saved a shift by answering the phone on a Sunday evening did the company a favour, and that favour must be worth something concrete, namely priority on future requests. The moment this becomes a visible number instead of generic gratitude, willingness to be called goes up and reliance on agencies goes down. In the reference home it happened in the first four months, before the planning engine was even running: it was enough for the criterion to exist and be public.

Publication and notice: the part worth more than the engine

There is one more thing that counts as much as fairness and costs even less: publishing earlier. People organise their lives around the rota, and the value of knowing it four weeks ahead instead of one is enormous even with the same shifts assigned. It is one of the few things a company can improve without spending anything, and it has an immediate effect on morale.

The rule I recommend fits in one line of policy: the rota is published at least four weeks ahead and is not touched after publication, except for sudden absences; sudden absences are covered by a known rule and not by a discretionary phone call. Everything known before publication, meaning holidays, courses, appointments and leave, enters the rota before the rota exists, which means holiday requests must close earlier. It is the most unpopular organisational change in the whole project and the one that gives back the most, because it hits exactly that sixty one per cent of agency hours which in the reference home covered absences that were already known.

What shift scheduling software costs: module, dedicated product or custom

There are three roads, plus a fourth which in this case is the one I recommend almost always. Here are the price ranges I see on the Italian market today, for a business the size of the reference one.

The first is the scheduling module of the time and attendance or payroll system you already have. Many attendance systems have a planning function, sometimes included in the fee, more often between one and four thousand euros a year. It does one thing well: the rota connects to clockings and payroll with no bridge to build, and that is worth more than it sounds. It usually knows no constraints beyond the most basic, proposes nothing, and knows nothing about fairness or care standards. If you are on a spreadsheet today, it is the first thing to try, and sometimes you have already paid for it.

The second is a dedicated product for workforce scheduling, on subscription. Pricing is almost always per person: between two and a half and six euros a month per employee, meaning three to seven thousand euros a year for a business with ninety six employees, plus a setup between five and fifteen thousand euros that is mostly configuring rules and loading records. The good products handle availability, swaps, rest checks and a phone app well. The typical limit is twofold: the rules of your collective agreement and your accreditation only go in as far as the product anticipates them, and the link to attendance and payroll is often a periodic export rather than shared data.

The third is a custom system. It starts at forty thousand euros for the constraint engine, availability collection, publication with a frozen history and fairness accounting, and reaches ninety five thousand with two way integration to attendance and payroll, the calculation of care minutes per resident and a staff app. On top of that comes fifteen to twenty per cent a year of maintenance.

The threshold: around three hundred and fifty people on rota

Here the arithmetic leads to a conclusion that does not suit anyone selling custom software, and I write it anyway because it is what the numbers say. The product costs in proportion to people, custom software hardly does. On cumulative five year cost, with a nine thousand euro setup for the product and a sixty thousand euro build plus maintenance for custom, the two lines cross at around three hundred and fifty people on rota. With the seventy eight of the reference home, the product costs about thirty thousand euros over five years against one hundred and five thousand for custom: there is no contest, and anyone proposing to build a rostering engine from scratch for seventy people is doing you a disservice.

Above three hundred and fifty people the arithmetic flips, and above a thousand custom costs half. But even there the headcount alone does not decide. The threshold drops a lot when the constraints that matter are not the standard ones: minimum staffing ratios per resident or per shift set by regional accreditation, certified skills that expire and invalidate eligibility for a duty, shift cycles defined by a company agreement with rules no product has ever seen, teams moving between several sites with travel times to respect. If the valuable part of your problem sits outside the product, you end up paying a subscription for the rota and keeping the hard part in a spreadsheet, which is the most expensive way of not solving a problem.

The fourth road, the one I recommend almost always

The road I recommend in the vast majority of cases below three hundred people is mixed: the product for the rota, the swaps and the app, a custom piece for the rules the product does not know. In practice you keep publication, availability and staff communication in the product, and build separately the part that computes: the specific constraints, care minutes per band, the fairness balance, the comparison between published and worked rota. It costs between twelve and thirty thousand euros, connects to the product through its interfaces, and leaves to the market the part the market already does well.

In the reference home it went like this: a dedicated product at four thousand eight hundred euros a year plus seven thousand of setup, and a custom piece of eighteen thousand euros for the constraint engine, the care standard calculation and the bridge to attendance. Twenty nine thousand euros in the first year against one hundred and thirty nine thousand of measured cost. In the first year the share of rewritten hours fell from fourteen to seven per cent, and the two costs that moved first were the predictable ones: agency staff called in a hurry and overtime born of a known absence.

The five questions to ask before signing

Whichever road you take, five questions separate shift scheduling software from a coloured rota. First: does it check constraints while I assign, blocking the save, or does it run a check afterwards? Second: does it keep the published rota in a frozen copy, so I can measure how much it changes? Third: can it compute cover per band the way my accreditation asks for it, and not just a headcount? Fourth: does it keep a fairness balance per person, pro rated to contracted hours, and show it to the people working too? Fifth, worth more than the other four: will it load my worst month from last year, with the real absences and the real constraints, and try to rebuild it before I sign? If it proposes a valid rota in two hours you have the right product; if it tells you that case is handled manually, you have a coloured grid.

Where to start: the first release in ninety days

The first release does not have to be complete, it has to be useful to somebody within three months. This is the order I use, and note that the first two steps need no software at all and already deliver a substantial part of the return.

Weeks one and two: freeze and measure. From now on, every time the rota is published a copy is saved that nobody touches again. Then take the last three months of rotas and clockings and compute the share of rewritten hours by department, together with the share rewritten because of absences known more than seventy two hours ahead. By the end of the two weeks you must have two numbers and the department to work on. In the reference home, at this stage it already emerged that one unit out of four absorbed half the problem.

Weeks three to six: the three tables that are always missing. The skills matrix, meaning who can do what, with certifications and their expiry dates. The declared staffing need per time band and per typical day, discussed and approved by management, which is a difficult conversation and has to happen now. Unavailability collected in one place, with a clear deadline. At the same moment one rule gets written, worth more than all the software: no planned absence and no shift swap exists unless it goes through the system.

Weeks seven to ten: the checks and publication. Hard constraints verified at the moment of assignment and at the moment two people swap a shift, with a block and not a warning. Publication four weeks ahead, with each person notified of their own shifts. The fairness balance visible. This is where staff start to see a benefit, and staff consent decides whether the project survives month three.

Weeks eleven to thirteen: the automatic proposal. Only now the engine that builds the rota, with three proposals to compare. It comes last on purpose: if it comes first it works on wrong skills, imaginary staffing needs and incomplete availability, proposes absurd rotas, and the coordinator stops trusting it within two days. And that, in my experience, is the number one reason automatic scheduling projects fail: not the solver, the data you feed it.

One last piece of advice on what not to do first. The dashboard with charts of hours by department is the part shown in every demonstration and the least useful at the start. A weekly list of ten lines saying which shifts in the next three weeks are uncovered and who has the lowest fairness balance is worth more than any chart, because somebody reads it and does something.

If the number says this is not your problem

It happens, and it is worth saying because almost nobody does. If your share of rewritten hours is under five per cent, if the rota is published a month ahead and cover is rarely needed, shift scheduling software will not give you much margin: it will give you convenience, the ability to build the rota even when the person who knows how is on holiday, and tidier communication with staff. Those things are worth having, and in a shift based business continuity is worth more than it seems, because there is almost always a single person who really knows how it all fits together. But they are worth the price of a subscription, not of a custom project.

In that case the bottleneck is almost always elsewhere, and it is one of these three. The hours data: the rota holds but you do not know precisely what was worked, and then the subject is the one described in time and attendance software, which comes before any planning. The margin per job or per service: you know who works when, but not which activities make you money, and then the subject is job costing software or, if the question is at company level, management control software. Or field work: your people are not in one place but on the move, and the problem is not who works when but how jobs are organised, which is what I write about in field service management software.

And there is a case where software is not the answer even when the numbers are bad: when the establishment is simply too small. If the declared staffing need requires eighty people and you have seventy, no solver will find a solution, because the solution does not exist: the system will tell you precisely what is missing and where, which is valuable information to take to a board or an accrediting body, but it will not cover the rota. I have seen organisations buy planning software hoping it would solve a headcount problem and be disappointed for a mathematical reason. Which, incidentally, is already a good reason to measure, because an uncovered staffing need that becomes a number is a discussion you can finally have with data instead of impressions.

If you have read this far, you probably have in mind the last month when the rota fell apart. Before looking at any demonstration, freeze the next publication and compare it with what actually happens: thirty seconds a month and two weeks of analysis, costing nothing, and it tells you whether you are buying margin or just tidiness. From there the decisions get much simpler, and you make them instead of leaving them to a Sunday evening phone call.