Skip to content
Who's In

Everything  /  Basics

Start With a Spreadsheet

For a team under about fifteen, a well-built sheet beats a subscription. What it needs to contain, and the point at which it stops being enough.

Basics

Software vendors will tell you a spreadsheet is inadequate. For a small team it is usually fine, and building it teaches you what you actually need before you pay for anything.

What the sheet needs

One row per person, one column per day, for the year.

A code in each cell: present, holiday, sick, unpaid, training, other.

Entitlement, taken and remaining calculated per person.

A tab for the reasons, so codes stay consistent.

A note column for anything that needs context.

Nothing else. Sheets that try to do more become sheets nobody maintains.

The rules that make it work

One person owns it. Two people editing a shared sheet produces two versions and an argument.

Update it the same day, which is the whole difference between a record and a reconstruction.

Lock the past. Protect completed months so a correction is deliberate rather than accidental.

Keep the version history on, which cloud spreadsheets do automatically and which is your audit trail.

Share a read-only view with the team, so people can check their own balance without asking. This removes most of the questions and catches errors early.

What it will not do

Stop double-booking. Nothing prevents two people taking the same week unless someone looks.

Calculate sick pay to a statutory formula.

Handle part-time entitlement in hours rather than days without getting fiddly.

Notify anyone.

Survive its owner leaving, unless someone else has been shown how it works.

The point it stops being enough

Around fifteen people, roughly, and it is more about complexity than headcount.

Several approvers.

Part-time and variable hours, where entitlement is calculated in hours and pro-rated.

Shift work with coverage requirements.

More than one site.

Any statutory calculation you are getting wrong.

Before you buy anything

Run the sheet for six months. You will learn which reasons you actually use, how much absence you actually have, and which questions you keep needing to answer.

That list is your requirements document, and it will be shorter and more accurate than anything you would have written up front.

And if the sheet is still working at the end of six months, you have saved a subscription — which is a legitimate outcome that no vendor will suggest.

What to code the days as

Six codes, and no more.

P present. H holiday. S sickness. U unpaid. T training or other work-related absence. O other, with a note.

Six is enough to answer every ordinary question and few enough that everyone uses them consistently.

Do not add codes for reasons — no separate code for dental appointments — because the list grows and the consistency goes.

Put the list on the sheet itself, so nobody has to remember it.

Turn the principle into a test

For an example that can make this requirement testable, consult view this scope example. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, exceptions and permissions.