THE QUIET DEATH OF EXCEL IN ROOFING

Every roofer above $5M revenue runs at least one piece of their operation in Excel. Usually the job-tracker. Sometimes the commission calculator. Often the AR aging report. Always the budget vs actual the owner glances at on Saturday morning.

Excel doesn't get killed by a vendor. It gets killed by the day the spreadsheet finally breaks something visible.

What's actually wrong with the spreadsheet

Most arguments against operational Excel are aesthetic or theoretical. They aren't the real problem. The real problem is structural: a spreadsheet is one human's mental model in a grid, and the company has now passed three people through that grid.

Three patterns we see in every roofer we audit:

**The phantom formula.** Someone three years ago wrote `=IF(B7>0, B7*1.07, B7*1.04)` to capture an upcharge on a specific job type. Nobody now remembers what 7% versus 4% means. Every job since has run that formula. Bonus: row 213 was overwritten by hand to fix a one-off, breaking the column.

**The merged-cell trap.** Someone merged cells to make the section header look nicer. Three updates later, the conditional formatting points at the wrong cells, the sort silently corrupts data, and only the row count makes the owner realize half the jobs are missing.

**The truth-fork.** Two sales reps are editing the same job tracker. Their versions diverge for a week before someone manually reconciles. Median jobs lost per quarter on $10M revenue companies: 1.4. Median dollars at risk: $48K.

We pulled the last one from a 12-operator audit. The dollar figure was conservative — it only counted jobs the owner could later trace, not the ones that just disappeared.

Why companies don't quit

The reasons are obvious and they aren't wrong:

1. The spreadsheet is fast. You can change a column in 4 seconds.

1. Everyone already knows it.

1. The migration to anything else feels like a 90-day project nobody has time for.

1. The vendor alternatives (we'll be generous and not name them) often cost more than the headcount they're supposed to replace and don't fit any actual roofing workflow.

All four are real. The migration plan we recommend addresses each.

The migration that doesn't break the company

Three phases. Total elapsed time: 30 days if you stay disciplined. Each phase has a clean exit.

Phase 1 (week 1): Mirror, don't migrate

Pick one spreadsheet — usually the job tracker. Set up the agentic OS in parallel. The Quoting Agent and the Scheduling Agent read from both the spreadsheet and the system, but only write back to the system. Your team keeps using the spreadsheet.

End of week 1 you have two sources of truth and you can diff them. Every cell that diverges is a data quality issue you would have eventually found the hard way.

Phase 2 (weeks 2–3): Cut over the writes

Now the team writes only to the system. The spreadsheet becomes a read-only mirror generated nightly from the system. This is the moment that breaks bad habits. The team has 14 days to stop using the spreadsheet as a writeable workspace.

Friction during this phase is high. Plan for it. Your Ops Lead spends most of their day answering "how do I do X in the new system" questions. By day 10 most of them have stopped.

Phase 3 (week 4): Retire the spreadsheet

The nightly mirror stops generating. The spreadsheet is archived (do not delete — auditors and tax season will want it later). Everyone is on the system.

Common pushback at this stage: "the owner still wants the Saturday-morning dashboard." Easy answer — give them the same exact dashboard rendered out of the system. The agent generates it on Friday night. No one cares whether the rows came from cells or rows.

What the data hygiene exercise will surface

Migrations are always also audits. Every operator going through this will discover at least one of the following inside the first two weeks:

• **Ghost jobs.** Jobs marked "in progress" three quarters ago that nobody is working. Often these are real revenue still owed; sometimes they are jobs that were silently abandoned.

• **Commission errors.** Reps who were paid on jobs that later canceled and never recouped; reps who weren't paid on jobs they actually closed.

• **Material variance.** Material costs that don't match what was actually delivered to the yard, because the spreadsheet was tracking the bid and the receipts were never reconciled.

Surfacing these is uncomfortable. It is also why the migration pays for itself before you finish it.

The companies that don't migrate

We are not interested in evangelism. There are plenty of profitable roofers running on spreadsheets. They tend to share three characteristics: a single dominant operator who personally tracks every job; a relatively small geographic footprint; and a low-growth posture.

If any of those is changing — the owner wants to step back, the territory is expanding, growth targets are doubling — the spreadsheet is the wall the company will hit first.

What replaces it

Not another spreadsheet. Not a fragmented CRM-plus-accounting-plus-scheduling tool stack held together by Zapier glue. The operating system itself — agents that act on the data, dashboards that read from it, and a clean migration path that doesn't punish you for trying.

Return to the autonomous roofing playbook for how this fits the broader system, or read about the anatomy of a modern roofing CRM workflow.