Why roofing software still needs manual data entry (and what it costs)

It's 4:15. The job is sold. The photos went up this morning, the measurement came back before lunch, the estimate is out. And somebody in your office is opening a second system to type in a customer who already exists in two others.

You paid for all of it, and every one of those tools is good at the job it was built for. Nobody sold you a bad product.

What nobody sold you is the part in between. That part is a person at a desk, every afternoon, retyping — and it is the only part of your operation that never appears on an invoice.

Why the gap exists at all

Your CRM was built by one company. Your photo app by another. Your measurement provider by a third, your accounting package by a fourth, and none of them were in the room together.

Each connection between them carries the fields those two companies agreed to carry, on a schedule they decided, in one direction or both depending on what got built. That list is usually reasonable. It just was never going to include the parts specific to one particular business — the way a job gets named, the product codes actually in use, how work is split across two branches, the exception made for insurance jobs.

Everything outside that list falls to a person.

This isn't anyone behaving badly, and it isn't a technical wall — the data can move perfectly well. It's that no vendor's roadmap has a line item for how your company in particular runs. You are one of thousands of customers on a shared product, and the product has to be the average of all of you.

So the work falls to the only part of the system that can adapt to anything: a human being.

The most expensive person in your office is the integration

Here is the part that makes it hard to see. Nobody sends a bill for it.

If a tool charged $900 a month to move data between two systems, you would evaluate it. You would compare it against alternatives, ask what it does, and probably negotiate. But when the same work is absorbed into an existing salary, it becomes invisible. It just looks like "what Karen does in the afternoons."

Some industry context worth sitting with. In the US roofing industry, federal wage data from May 2023 counts about 26,700 office and administrative support staff — roughly one in nine people in the trade — at an annual mean wage of $47,190. The striking number is the split underneath it: only 620 people in the entire industry are classified as Customer Service Representatives, against 10,520 general Office Clerks.

The person answering the phone at a roofing company is almost never a dedicated phone person. They're a generalist doing six things, and one of those six is being the connection between systems. Every hour spent on that is an hour not spent on the one thing that actually wins work — calling back the homeowner who enquired this morning.

The version where this problem never existed

Step back for a second, because the retyping is a symptom rather than the disease.

The reason data has to be carried between six systems is that six different companies each modelled a roofing job slightly differently. One thinks a job belongs to a customer. Another thinks it belongs to a property. A third has no concept of a job at all, only a project with a number. Your office staff spend their afternoons translating between those definitions, which is genuinely skilled work, and it produces nothing.

A system built around how one roofing company actually operates doesn't have that problem — not because it integrates better, but because there is nothing to integrate. There is one definition of a job, and it's yours. The address gets entered once because there is only one place it belongs. The insurance exception isn't an exception, it's just how the system works, because it was built by someone who asked what happens with insurance jobs.

That is the real difference between software that understands your business and software you have to understand. In the first case the data ends up in the right places because the system knows what the work is. In the second, a person supplies that understanding manually, forever, at 4:15 every afternoon.

If that argument is interesting, it's made properly in own your software instead of renting it forever — including why the economics usually work out better than people expect.

If replacing everything isn't realistic — and it usually isn't

Most roofing companies reading this are already deep into a stack. Staff are trained on it, years of history live in it, and it's the middle of a season. "Replace all six tools" is not a sentence anybody wants to hear in July, and it would be a strange thing to recommend.

So the practical answer is the smaller one: connect what you already have.

If the tools stay but the connections between them get built properly — built around how the work actually moves through your office, rather than around what two vendors agreed to expose — the manual labour goes away regardless. You keep every tool your team knows. You just stop paying a person to be the bridge between them.

That's a genuinely good outcome, and for a lot of companies it's the right first move. It doesn't fix the underlying mismatch — you're still running six models of what a job is — but it stops that mismatch costing an hour a day.

What a well-built connection actually does

Worth knowing what to expect, whether the work gets done in-house, by a contractor, or by whoever built your existing tools.

It handles your exceptions, not just the happy path. Generic connectors move the fields two vendors agreed on. The retyping that survives is almost always the awkward stuff — the odd product code, the split branch, the insurance job that gets handled differently. If a connection doesn't carry those, the person doing them by hand still does them by hand.

It fails quietly rather than confidently. When something breaks it should stop and tell somebody, not guess. A flow that does nothing is noticed the same day. A flow that pushes wrong numbers into accounting is discovered by a customer.

It's one flow, finished. Not a platform, not six connections at once. One path from end to end, running on real jobs, before anyone considers the next.

It survives holidays. Right now the retype is a habit living in one person's head. Anything that replaces it should not also live in one person's head.

When it isn't worth automating

Some retyping should stay manual, and it's worth being honest about which.

Anything that happens a few times a year. If a job crosses between two systems twice a season, a person doing it deliberately is cheaper and safer than a system nobody remembers exists.

Anything where the exception is the work. Some steps look like data entry but are really judgement — deciding how a difficult claim gets coded, or which bucket an unusual job belongs in. Automating the typing there just moves the thinking somewhere less visible.

Anything about to change anyway. If you're already planning to move off a tool next year, wiring into it now buys a few months and then has to be redone.

The test is simple. How often does it happen, how many people touch it, and what breaks when the person who normally does it is away? If the answers are "often," "several" and "quite a lot," it's worth fixing. If not, leave it alone.

What to do this week

One thing, and it costs nothing but a notepad.

1. Count it for one week.Ask whoever runs the office to make a mark every time they enter the same job into a second system. Not how long it took — just a mark.
2. Look at the count, not the clock.Owners consistently guess the time per entry about right and the number of entries badly wrong. The count is what changes minds.
3. Ask what breaks in July.For whatever tops that list, ask what happens when that person takes two weeks off. The answer names your load-bearing flow.

Most owners already know which one it is. It's the thing they stopped mentioning years ago, because they assumed it was simply the cost of running software from four different companies.

It was. It isn't any more.