When the spreadsheet stops being the system

A spreadsheet is the best tool ever made for a problem nobody has defined yet. That is also how it ends up carrying a yearly publication, a waiting list or an order book long after it stopped being able to. This article is about recognising that moment, and about what the replacement tends to look like when it goes well.

The symptoms

The symptoms are organisational before they are technical. People rarely say "our spreadsheet has become a system". They say things like these.

• Requests arrive by phone or e-mail and someone types them into the sheet. Every request is incomplete in a different way, and the typing is a job in itself.
• One person holds the sheet. They know which column is really used, which colour means what and which rows are dead. When they are away, the sheet waits.
• The same data lives in three places: the sheet, the e-mails that fed it and the document that was built from it. They disagree, and nobody knows which one is right.
• A yearly edition, report or catalogue is assembled from the sheet and a season of e-mail,.

Several of these together mean the sheet has become the system of recordThe one place where a fact is considered true. When two sources disagree, the system of record wins. A spreadsheet rarely holds that role well, because anyone can edit any cell..

Why patching stops working

The first response is always to patch: a macro here, a protected range there, a second tab with instructions. A spreadsheet has no notion of who owns a record, so nobody can confirm their own entry. It has no validation beyond what one person remembers to check. It has no history, so a wrong edit cannot be traced. And it has no exit except retyping, so everything built from it is built by hand. A system of record needs exactly those things, and no amount of patching adds them to a grid of cells.

The pattern, from work you can look at

Several public cases on our site started here. Where there are results, they are in the client's own words.

Hospindex and Carehomesindex, the annual reference works for Belgian hospitals and residential care, used to be assembled from spreadsheets, e-mail and a lot of chasing. The platform gave every organisation its own login to check and correct its entry, a validation step so the editors see, per record, what has been confirmed, and one structured export that goes straight into the printed edition. The export turns a year of scattered corrections into a book that ships on time.

Wit-Gele Kruis East Flanders used to receive home-nursing requests from doctors, health funds and hospitals by phone. A secured care-request website replaced that, built in a weekly working group with their care team. It went live three months after the first working group, and requests now arrive complete. Peter Rasschaert, Director of Care, said: "Everyone is helped faster through the website, and that is real added value for us."

Medisch Labo Bruyland moved its results server to newer, friendlier technology built around how the lab works, and a lot of manual data entry went with it. Karen Bruyland of the lab: "Thanks to the renewed results server we notice that more doctors are requesting electronically, which results in faster turnaround times in the lab."

Vivalyte, still in development, applies the same pattern to a product catalogue: specifications, variants and documents sync from the product information system the company already runs, so nobody retypes any of it.

What transfers between cases

• A sharp problem. Each case started from one painful moment: the edition closing, the phone ringing, the retyping. We scope to that moment, and the rest waits.
• A weekly rhythm. The client sets out the requirements, we fill in the rest, and a short weekly working group keeps both sides close to the work.
• A small first scope. The first live version does one job completely: take a request, confirm an entry, export an edition.
• Your own system as the source of truth. Where a system already exists, the new one syncs from it. Where none does, the new one becomes the one place and the sheet is retired, because two systems of record are worse than a spreadsheet.
• A handover that holds. You end with a working system and a setup your team can run without us. We have written about what that includes.

One more thing transfers: the replacement is rarely a large build. The problem a spreadsheet carried is narrow, and narrow problems make small, durable systems. That is also why buying something standard deserves a look before anyone builds; only the part of the sheet that is specific to how you work is worth building.

What to bring to a first call

• The sheet itself, with the colours and the dead rows.
• The name of the person who holds it, and an hour of their time.
• The moment that hurts most: the yearly close, the Monday phone calls, the retyping. That becomes the first scope.
• The other places the same data lives, and which one people trust when they disagree.
• The systems you already run that the new one should talk to.

You tell us the goal and the constraints, and we come back with a clear approach and a scope you can sign off. For something new, that scope is a range with its assumptions written down, and we have explained why. If the call ends with "keep the spreadsheet, add a form", that is a result too.