Getting Off the People Spreadsheet Without Losing What Made It Good

Every company under fifty people has the sheet. Ours was called Team and by the end it had twenty-three columns, because each one had been perfectly reasonable at the moment somebody added it. Start date. Manager. Emergency contact. T-shirt size, from the hoodie order. Laptop serial, from the insurance form. Notice period, from the one time we needed it. There was a second tab called Team (old) that nobody was willing to delete.

It works. That is the honest starting point, and most posts on this topic skip it. A spreadsheet is instant, it costs nothing, and when you need to track something new you add a column in four seconds and get on with your day. Every HR tool that has ever failed to displace one failed on that last point.

So the question is not how to escape the sheet. It is which parts of it were load-bearing.

The three ways it goes wrong

They arrive in a predictable order.

Access is all or nothing. The t-shirt column and the home address column are in the same file, so sharing is one decision covering both. The usual resolution is that only the founder has the file, which makes the founder a lookup service. Every question about anybody routes through one person, forever, including while that person is on holiday.

There is no history, only the present. When did Marta's title change? The cell says Senior Engineer. It has always said Senior Engineer, as far as the cell is concerned. Sheets keeps version history, and I have never once met anyone who successfully answered a question like that with it. So you add a "last changed" column, which is accurate right up until the first time somebody forgets, after which it is worse than nothing because it looks accurate.

It is always a little bit wrong. Not through carelessness. Updating the sheet is nobody's job at the exact moment the fact changes — it is a second, separate act of remembering, performed after the real work of changing the thing. The gap between the change and the update is where the errors live, and it grows with headcount.

The fourth one arrives later and hurts more: someone exercises their GDPR access rights and you have to grep four tabs, a shared drive and your own inbox to answer a question the sheet could have answered in a second if it had been built for it.

Not every fact is the same kind of fact

This is the bit that makes the migration tractable, and it is the bit spreadsheets can't express, because a sheet has exactly one shape for everything.

Some facts are structured, and the software computes with them. A work schedule, a manager, a team, a country, a holiday calendar. These cannot be free text, because leave day-counting depends on them: a four-day-week employee and a five-day-week employee who book the same calendar week are charged different amounts, and the only way to know that is for the schedule to be typed data rather than a note.

Some facts are yours alone. T-shirt size, badge number, desk, which of the two coffee machines they have opinions about. Nobody can predict these, which is precisely why the tool has to let you add one without a schema change and without filing a ticket. This is the spreadsheet's real advantage and it is the one thing a replacement must match.

And some facts are history, which should never be a field. "When did this change" is a question about the past, and the only reliable answer is one the system wrote down as a byproduct of the change itself. If a human has to remember to record the history, you do not have history. You have another column that goes stale.

What to move, in what order

Move the structured facts first: names, emails, start dates, managers, teams, countries, work schedules. That is the set the product actually needs to do arithmetic with, and it is usually about eight of your twenty-three columns.

Then define your own fields for the ones that are genuinely yours, and be ruthless: a column that has been empty for nine people out of thirty is not a field, it is a note from 2024.

Then stop. Do not backfill history. You cannot reconstruct it honestly anyway, and a timeline that starts today and is true beats one that goes back three years and is half-invented. Keep the old sheet read-only somewhere for a year; you will look at it twice.

Where SquadBear keeps this

Every person has one profile with six tabs, plus a seventh for admins. Overview holds contact details, teams, manager, holiday calendar, work schedule, emergency contacts, and your own custom-field values. Teams & projects, Leave, Documents, Processes, and Schedule sit beside it. Data & privacy is admin-only and is where an export or an erasure runs, so the GDPR request above is a screen rather than a weekend.

Custom fields are defined under Workspace settings → Workspace → Employee fields. Text, number, date, select or boolean, grouped into Personal, Job or Other, up to fifty of them, and any field can be marked admin-only so the sensitive ones aren't visible to managers browsing a profile. They behave like built-in fields everywhere afterwards, including for a connected AI assistant. One rule worth knowing before you start: a field's key can't be renamed once set, only relabelled, so spend a moment on the key and none at all on the label.

Two things are deliberately not custom fields. Emergency contacts are structured — name, relation, phone, optional email, capped at three per person — because a "next of kin" text field is where phone numbers go to be formatted eleven different ways. And employment history isn't a table you fill in at all: it's a read-only timeline assembled from the audit log, so hires, accepted invitations, profile edits, schedule changes and country changes appear because they happened, not because somebody logged them.

An honest limit: SquadBear has no compensation field, on purpose. The salary column does not move here. Whatever you use for payroll keeps owning that number, and what the EU pay transparency directive expects you to be able to produce is a question for that system, not this one.

Setting up the fields is itself a thing you can hand off:

"Add a custom field called 'T-shirt size' with options S, M, L and XL in the Other section, then list every field already defined and how many people have a value for each."

The people model guide walks through profiles, fields, teams and the org chart; invite your team covers getting everyone in.

Start free — up to five people costs nothing, which is enough to move the eight columns that matter and see whether the rest were ever real.