The spreadsheet-as-CMMS tax: what it actually costs

Every solar O&M operation we’ve inherited from a previous provider has had a shared Excel file at the heart of it. Sometimes it’s a Google Sheet. Once or twice it’s been a SharePoint workbook with macros that nobody dared touch. The shape is always the same: a single source-of-truth file, owned by one person, modified by several, accurate on Tuesdays and divergent by Friday.

We’ve run on that pattern ourselves. There’s a reason it exists — it’s easy to set up, free to run, and everyone in the operation already knows how to use it. The trouble is that the cost shows up sideways. Not on the line where it’s easy to spot, but in the time the operation loses every week, the things it can’t do, and the risks that nobody priced in when the spreadsheet started.

This post is about that hidden tax.

What the spreadsheet usually contains

A typical small-fleet O&M spreadsheet has somewhere between three and six tabs:

• Sites — one row per site: address, owner, inverter brand, installed capacity, commissioning date
• Inspections — when each site was last inspected, when it’s due next, who signed it
• Cases / faults — open faults, dates, status, assigned engineer
• Maintenance schedule — planned visits across the calendar
• Contacts — owner reps, gate codes, site access notes
• Reports — sometimes a tab that tries to summarise monthly performance

Some operations also have a parallel folder of PDFs (inspection reports, photos, signed documents) referenced loosely by filename from the spreadsheet. The link between the spreadsheet row and the PDF is “look in the folder for the matching site name and date”.

This works. It works in the same way that a six-year-old’s bedroom works as a filing system: the kid can find things in there, and nobody else can.

The tax, in five parts

1. Time tax: synchronisation and reconciliation

The spreadsheet is one file. The operation has multiple people. Concurrent editing of an Excel workbook in OneDrive or SharePoint nominally works; in practice it doesn’t, because someone always has a local copy open offline, the version on the server diverges from the version on someone’s laptop, and the recovery is by hand.

For a typical small operation, an engineer or PM spends somewhere between two and five hours a week reconciling the spreadsheet. That’s 100-260 hours a year. At a fully-loaded cost of around £30 per hour, that’s £3,000-£7,800 per year. For a single small operation. We’ve measured this in our own shop and the figure was at the higher end of that range before we replaced it.

That number alone is larger than the annual cost of most O&M software at the size of fleet a single spreadsheet is being used to run.

2. Audit trail: not a feature

The most expensive failure mode of the spreadsheet isn’t the time tax. It’s that an Excel cell has no history.

If someone changes the status of a case from “open” to “closed”, there’s no automatic record of who did it, when, and why. Track Changes in Excel exists but is rarely turned on; if it is, it captures the change but not the engineer’s reasoning. If a row gets deleted by accident, it’s gone. Version history in OneDrive helps a little but isn’t designed to be queried for “what was the state of this case at 14:00 on the 17th of March”.

This becomes a real problem in three specific situations:

• A site has a serious fault and the owner asks what was known and when. If the spreadsheet was the system of record, the answer is “let me find an old version” — which is a hard conversation to have professionally.
• An engineer leaves, taking institutional knowledge with them. The spreadsheet shows what they did but not why. The next engineer is reading tea leaves.
• An insurance claim requires evidence of the operation’s actions. Insurers will accept a spreadsheet, in our experience, but the level of forensic scrutiny is higher because the document is harder to authenticate.

We’ve not yet had a contract dispute go to lawyers on a spreadsheet trail. We’re aware of operations that have, and the outcome was not encouraging for the spreadsheet’s owner.

3. GDPR and data protection

The spreadsheet usually contains personal data: site contacts, gate codes, sometimes engineer notes that include observations about people. UK GDPR applies. The duties are real:

• Access controls — who can see what. A single shared file gives everyone the same view.
• Retention — old data should be deleted after a defined period. Nobody ever deletes rows from the maintenance spreadsheet.
• Right to erasure — if a contact requests deletion, where exactly is their data? In the current spreadsheet, in seventeen old versions, in three engineers’ OneDrive local caches.
• Breach notification — if the spreadsheet is exposed (an emailed copy gone astray, a shared link found in a search), it’s a notifiable breach.

The probability of any single small operation being inspected on this is low. The cost if it happens is high, and the obligation is real whether anyone’s inspecting or not.

4. The data you don’t have

A spreadsheet captures what someone typed into it. It doesn’t capture anything else.

Things a spreadsheet-based operation typically doesn’t have, because nobody was going to enter them by hand:

• Every alert ever raised — the silent ones that resolved themselves, the noisy ones that turned out to be nothing, the trend you’d see if you could look at all of them in aggregate
• Time-on-case from open to acknowledgement to closure — without per-row timestamps that update automatically, you can’t answer SLA questions retrospectively
• The actual telemetry trace under a fault — what the inverters were reporting in the hour before and after a problem
• Photos linked to specific test values on an inspection sheet
• Engineer location and travel time for SLA reporting

You can run an operation without these. You just can’t improve it from one year to the next, because you don’t have the data to know what improved.

5. The cap on growth

The spreadsheet imposes a ceiling. Somewhere around 20-40 sites for most operations. Past that point, the time tax becomes overwhelming, the audit trail becomes unmanageable, and the operation either hires more people to maintain the spreadsheet (which is mad) or it makes a tooling change under duress.

The tooling change under duress is the most expensive version of the change, because it happens during a period when the operation is already stretched. The site you’re trying to onboard is the one that breaks the spreadsheet, and you’re now trying to learn a new platform while also keeping the existing operation running.

The objection we hear most

“We’ve got a spreadsheet that works for us. Switching to software adds another tool we have to maintain.”

That objection is partly fair. New tools have onboarding costs. Engineers don’t want to learn another interface. The spreadsheet is, at least, familiar.

The honest counter: a well-designed O&M platform isn’t an additional tool — it’s a replacement for the spreadsheet, the photo folder, the version-history search, the monthly reporting macro, and the weekly reconciliation meeting. The substitution math is favourable if the platform actually does all those things. If it only does some of them, the spreadsheet doesn’t go away and you’ve added cost, not removed it.

This is why we built SolarFleet the way we did. It has to be the spreadsheet’s full replacement, not a supplement.

What good replacement looks like

We’ve migrated operations off spreadsheets several times. The pattern that works:

1. Import the sites first. Get the static data (addresses, owners, inverter brands, capacities) into the platform. The platform should be able to take a CSV — most spreadsheets export cleanly enough.
2. Connect the inverters. APIs from SolarEdge, Solis, whichever brands the fleet runs on. The platform should be able to fan out from a single account-level key.
3. Backfill the case history manually. Take the open cases from the spreadsheet and create them in the platform. Don’t try to bring across closed cases — start fresh on the audit trail. Past closed cases stay searchable in the archived spreadsheet.
4. Move inspections forward. As each site comes up for its next periodic inspection, do it in the platform rather than on paper. Don’t try to retrofit inspection history.
5. Decommission the spreadsheet on a fixed date. Pick a Friday. Save the file. Don’t open it again. The platform is the system of record from that Monday.

We’d estimate 6-10 hours of operator time for a fleet of 20-40 sites, spread over a couple of weeks. Less than a single quarter’s spreadsheet reconciliation time.

The deeper point

Tools shape practice. Operations run on a spreadsheet end up making decisions that fit a spreadsheet’s grain — they batch work into manageable chunks, they avoid generating more data than someone wants to type, they postpone analysis because the analysis is hard.

Operations run on a well-designed platform end up making decisions that fit the platform’s grain — they generate data as a side-effect of doing the work, they look at trends weekly because the trends are visible, they raise concerns early because the data is right there. The platform doesn’t make the operation better on its own; it removes the constraints that were forcing the operation to be worse than it wanted to be.

That’s the tax the spreadsheet was charging. Not just hours. Not just risk. The ceiling on how good the operation could become.

---

SolarFleet replaces the spreadsheet, the photo folder, the inspection PDFs and the monthly reporting macro with one system of record. Start free with 2 sites — we’ll import your fleet on the call.