The week the spreadsheet quietly became your system of record

Every mid-term operator has a spreadsheet. That is not the problem, and anybody who tells you a spreadsheet is unprofessional has not run an operation. A blank grid models a situation nobody anticipated better than any software ever will, which is exactly why it gets used for the situations software did not anticipate.

The problem is a transition that happens without anybody deciding it. The sheet stops being a record you keep and becomes the record: the thing that is true, that other people act on, and that nothing can check.

How it happens

It starts because the PMS cannot represent something. Usually the cleaning rota, because a system built around bookings has no opinion about who is holding which key on Thursday. So the rota goes in a sheet. Reasonable.

Then the deposit tracker joins it, because the PMS holds a number but not the argument about whether the sofa was already like that. Then a tab for which tenancies are up for renewal, then one for the units under renovation, then one somebody made for a specific month and never deleted.

At no point does anyone say "we are moving operations into a spreadsheet". Each individual tab is the sensible response to a real gap, and the aggregate is a parallel system of record with no validation, no history and no owner.

Three signs it has already happened

Somebody asks you a question and you open the sheet, not the software. This is the clearest one. If the answer to "is Thursday covered?" lives in a spreadsheet, then the spreadsheet is your operations system and the PMS is a booking archive you also pay for.

Two people have it open at once and you have stopped noticing. Concurrent editing is fine for a shopping list. For the document that determines whether a cleaner turns up to a flat, it means the state of your operation depends on save order.

A booking changed and the sheet did not. This is the expensive one, and it is usually invisible until a tenant arrives at a flat nobody cleaned. The reason it is inevitable rather than careless is that the sheet has no way to know a booking moved. It is a copy, and every copy drifts.

The distinction that actually matters

Not "spreadsheet versus software". The useful distinction is between derived and maintained.

A maintained record is one somebody has to update when reality changes. Every maintained record is a promise that a human will remember, and humans are reliably about ninety-five per cent good at that, which sounds fine until you count how many times a week the promise is made.

A derived record is computed from something else each time you look at it. It cannot be stale, because there is no copy to go stale. If today's cleaning list is computed from the tenancies, then a tenancy that moves takes its cleaning with it, and nobody has to be told.

This is why "put the spreadsheet into software" is usually the wrong fix. Rebuilding the sheet as a database table gives you a maintained record with worse ergonomics. The fix is to work out which columns are derivable, and most of them are, then keep only the genuinely new information: who is doing it, when, and the note about the key.

What to keep

Some of that sheet should survive any migration. The parts capturing decisions and judgement (this tenant pays late, this owner wants a call before any work, this flat's boiler is temperamental) are not derivable from anything, and they are the most valuable content in the file.

In The Quarters that is the split we drew: the board derives what happens today from the reservations, and stores only what a person decided. If you take one thing from this and never speak to us, take that split. It is worth more than the software.