How to Add or Remove Employees From a Parking Rota Fairly

A staff parking rota is easy to reason about when the same group of people stays in it. Add a new name or take one away, though, and a rota that felt perfectly fair yesterday can start producing results nobody quite agreed to.

Editing a spreadsheet row is trivial. What's actually hard is changing the rota without accidentally moving existing employees backwards, handing someone an extra turn, or disrupting parking that people were already expecting to receive.

A simple way to avoid that is to stop thinking of the rota as a series of separate weeks, and start treating it as one continuous queue.

Why changing a parking rota can create fairness problems

Imagine a workplace with three parking spaces and seven employees. A simple rota might look like this:

At first glance that looks like four separate weekly allocations. But underneath, it's really one continuous sequence, wrapping back to the start once it runs out of names:

A → B → C → D → E → F → G → A → B → C …

Every available space just goes to the next person in line. That framing matters the moment the employee list changes.

What happens when a new employee joins the parking rota?

Suppose an eighth employee, H, joins the company. The obvious move is to add H to the roster and let the spreadsheet recalculate future weeks. That sounds harmless, but "recalculate" can go wrong in two different ways, and they aren't equally bad.

By the point H joins, nine turns have already been handed out: A, B, C in week 1; D, E, F in week 2; G, A, B in week 3.

Mistake one: restarting everyone's turn mid-cycle. If the spreadsheet just swaps the cycle length from seven to eight and recalculates from the running turn count - which is exactly what a formula like MOD(turn - 1, COUNTA(roster)) does the instant you add a row to the roster - it's quietly pretending H had been in the rotation since turn one. A cycle of eight lines up differently than a cycle of seven, so the next turn now lands on B again, instead of C. But B already had a turn in week 3. B hasn't earned another one yet - whoever had a turn this cycle can get resurfaced and sent to the front again, ahead of people who are still waiting for their turn on that of that cycle.

Mistake two: inserting H without restarting the count. This is less damaging - nobody who's already had a turn gets repeated - but it isn't free either. Splice H into the remaining queue right now and everyone still waiting their turn this pass gets pushed one place later than they were expecting. Nobody's turn repeats, but people who were told "you're up in two weeks" are suddenly up in three.

Both mistakes come from touching the pass that's already in progress. Whichever way it's done, the actual complaint is the same: someone's plans got changed close to their date, not that the arithmetic was hard.

The long-term allocation does need to change - if seven people are sharing three spaces and an eighth joins, everyone's eventual share of parking shifts slightly, and that's unavoidable. What's avoidable is touching the part of the rota that's already in progress.

Treat the parking rota as a continuous queue

A fairer approach is to let the current rotation run until it reaches a defined boundary, and only apply membership changes there.

Say the current rota is:

[marker] A → B → C → D → E → F → G

The marker tag shows where this version of the rota began. If H joins while this cycle is still running, don't rebuild the sequence immediately - let it finish. When the rota returns to the marker, start a new version that includes H:

[marker] A → B → C → D → E → F → G → H

The underlying principle:

A change in membership shouldn't make someone lose a normal parking turn they were already due to receive.

That's what lets the rota adapt to new starters without disrupting allocations already in flight.

Why a rota marker helps

Without some kind of marker, it's hard to know where the old rota ends and the new one begins. Recording where the current rotation started - and letting the queue run until it reaches that point again - solves that cleanly. At that boundary, you update membership and begin the next rotation.

The marker doesn't need to line up with the start of a calendar week. With three spaces and seven employees, one full pass doesn't divide evenly into weeks - looking back at the table above, the seventh person, G, takes the first space of week 3, and the rotation wraps straight back to A for the remaining two. The boundary can land on any space in any week, not just a tidy Monday-morning reset. What actually matters isn't the exact order people get their turn in - it's that everyone gets one before the next pass starts. You can even reshuffle who's grouped with whom each time a new pass begins; it's the same trick our guide to spare parking days recommends to stop the same people repeatedly landing in the same week together. The one thing that can't bend is that a pass has to finish - everyone gets their go - before the next one begins.

What about employees who leave the parking rota?

Departures raise two separate questions, and it's worth keeping them apart: what happens to the specific day they were about to use, and what happens to the roster going forward.

The immediate day. If E is leaving this week and was due a space on Thursday, the simplest fix is to treat it exactly like any other no-show: release that day and hand it out under your normal rules for spare parking days. Restructuring the whole upcoming rotation just to fill one gap - shifting everyone else's weeks earlier to compensate - is more disruptive than the gap itself, and it's really mistake one from the section above wearing a different hat: it moves dates that were already close.

The roster. Taking E out of the rotation for good is a separate decision, and like adding someone, it should wait for the next boundary rather than being applied mid-pass. When it is applied, the mechanics are the same simple list operation as before, just in reverse: delete E and shift everyone after them forward by one position. Nobody's completed turn gets touched, and nobody skips ahead of where they'd naturally be.

Old rotation: A → B → C → D → E → F → G

New rotation: A → B → C → D → F → G

What to avoid is the removal-side version of mistake one: recalculating the whole sequence from scratch against a shorter cycle length, as if E had never been in the rotation at all. That has the same failure mode as before - it can resurface people who've already had a turn this pass, just because the arithmetic now divides differently.

Avoid rebuilding the entire rota after every change

One of the easiest spreadsheet mistakes is treating every membership change as a reason to regenerate the whole rota from scratch. It produces a technically correct new schedule, and it's still unfair, because fairness here isn't only about everyone's eventual share of parking - it's about preserving the sequence people have already progressed through.

If someone is sixth in line and about to reach the front of the queue, adding a new employee shouldn't suddenly send them back a place or two.

Can you manage a changing parking rota in a spreadsheet?

Yes - for a small workplace, a spreadsheet handles this reasonably well. At minimum you need to track:

• the employees currently in the rota;
• their order in the rotation;
• the current position in the queue;
• the marker showing where the current version began; and
• any pending starters or leavers to apply at the next boundary.

When the queue reaches the marker, you update membership and begin the next version. The rule itself isn't complicated. The difficulty is remembering when to apply the change, and making sure the spreadsheet doesn't quietly rewrite allocations that should stay untouched.

In practice, adding or removing someone comes down to the same short sequence every time:

1. Record the new starter or leaver as pending - don't touch the live rotation yet.
2. Let the current rotation keep running until it reaches its marker.
3. At the marker, update the employee list and note the new marker position.
4. Start the next rotation from there, with the change now applied.

What if several employees join or leave at once?

The same principle still holds. If two people join and one leaves during the same rotation, you don't need to rebuild the schedule after each individual change - just record the pending changes and apply them together at the next boundary. The updated employee list then becomes the basis for the next complete cycle.

This also makes the whole thing easier to audit: there's a clean line between the old rota and the new one, instead of a trail of partial recalculations every time someone's contract changes.

The catch: someone has to manage it by hand

Like a lot of spreadsheet solutions, the logic here is genuinely simple. Maintaining it is the harder part. Someone has to know where the current rotation began, track pending starters and leavers, notice when the boundary is reached, and update the list at exactly the right point.

For a small, stable team, that's perfectly manageable. But as headcount grows, or people join and leave more often, keeping the rota fair starts demanding real attention - and the spreadsheet doesn't care who's on leave the week the marker hits, or that the one person who understands the formula is off sick. You will.

When parking allocation software becomes useful

A fair parking rota should adapt when the workforce changes without disrupting allocations already underway. For a small team, a continuous queue and a simple marker can get you there in a spreadsheet - but somebody still has to maintain the sequence by hand.

ParkRound handles this without requiring anyone to rebuild the schedule manually. Employees can be added to or removed from the parking pool, future allocations adjust to the new membership automatically, and the system keeps the allocation history rather than relying on someone to remember the correct position in a spreadsheet.

For some workplaces, a spreadsheet will remain enough. But once managing new starters, departures and shifting parking demand turns into an ongoing task, automating the rotation removes most of that work.