Water Damage vs Wind and Hail: Two Different Workflows

Short answer: They diverge in the first hour. A water loss is still happening, so mitigation starts before anyone has approved anything and the proof has to be recorded daily before the building dries out. A wind or hail loss finished the night it happened, so the argument is whether the damage exists, and the pressure is queue volume.

I build CRM For Claims, and the question I get most from companies running both sides of the business is some version of water damage vs wind and hail: is this one process with two labels on it, or two genuinely different jobs? It is two different jobs. They share a homeowner, a carrier and an invoice, and almost nothing else about how the week actually runs.

Most companies find this out the expensive way — by building a process around whichever work they did first, then bolting the other one on as a permanent special case. The special case is usually the water side, because it is the one that refuses to wait for your process to catch up.

What actually separates a water damage claim from a wind and hail claim?

The state of the loss. Water damage is an event still in progress — the building keeps getting worse until somebody stops it, so work begins before coverage is confirmed. Wind and hail damage is finished and static. Nothing about that roof changes while you wait, so every deadline on it is commercial rather than physical.

That one difference cascades through everything else. On a water loss the clock is the enemy and the calendar is close to irrelevant: dispatch is measured in hours, frequently at night, and nobody involved cares what day of the week it is. On a hail loss the calendar is the enemy: the storm creates a queue, other companies are knocking on the same street, and the homeowner signs with whoever showed up and sounded competent first.

There is a quieter difference underneath that one. A hail-damaged roof is one building among several hundred nearly identical ones, which is why that side of the business can be run in batches — inspection days, adjuster meeting days, production runs. No two water losses look alike. The category of water, which materials are affected, whether anyone is still living in the house and whether contents have to come out are all decided per address, and none of it batches.

Why does water mitigation start before anyone has approved it?

Because waiting produces a bigger claim. Emergency mitigation runs on a work authorization signed by the homeowner, not on a carrier approval — you are being paid to stop further damage, and the mitigation invoice gets reviewed afterwards, line by line. That reversal of the normal order is the single largest workflow difference between the two claim types.

It is worth being precise about what you are actually holding when the truck rolls, because both sides of the business sign something at the door and the two documents do very different things. A work authorization gives you permission to perform emergency services on the property. A contingency agreement on the roofing side gives you permission to pursue a claim on the homeowner's behalf. Neither one is an approved scope, and neither one is a promise that the carrier will pay what you are about to spend. The difference is what happens next: on the roof you sign and then wait; on a water loss you sign and then start.

Which means you can be two days into drying a basement that the policy was never going to cover. Flood is the obvious case — the Insurance Information Institute puts it plainly that homeowners policies do not cover flooding, and flood coverage is a separate policy through the NFIP or a private carrier. Water backing up from a sewer or drain is commonly a separate endorsement rather than something a standard policy includes. Neither of those facts is visible from the driveway at eleven at night.

So the design question for a water intake is not "how do we capture the details" — it is how few fields it takes to create a real record. A name, an address and a phone number at 11pm, from a phone, in under two minutes. Everything else gets added when somebody is at a desk. And the authorization has to be a hard gate ahead of dispatch rather than a piece of paper found later, because the one document that decides whether the mitigation invoice is collectible is the one signed before the work, not after it.

What evidence does each claim type actually run on?

Water runs on perishable evidence: moisture readings, daily drying logs, equipment counts and photographs taken before the air movers go in. Once the building is dry, nothing on site proves how wet it was. Wind and hail run on durable evidence — the damage is still on the roof and can be re-inspected weeks later by anyone who climbs up.

That asymmetry decides how much documentation discipline each job needs. On a hail claim, a missed photo is an inconvenience: somebody goes back up the ladder. On a water claim, a missing set of chamber readings from day two means day two no longer exists in any form a reviewer can examine. "We take a lot of photos" is a complete answer on one side of the business and about half an answer on the other.

The reviewer question on a water file is usually the same one: why was this material removed instead of dried, and why did the equipment stay this long. Those decisions are made against a professional standard — the ANSI/IICRC S500 standard for water damage restoration is the reference most restorers work to, and it is what a category call gets measured against later. The person asking was not at the property and will never see it. They are reading what you wrote down.

Wind and hail have their own weakness inside durable evidence, and it is not the damage — it is the date. The roof will still be there in three weeks, but so will twenty years of prior weather, and a claim can turn on whether the marks came from the storm that is on the file. A dated set from the first inspection is doing different work here than on a water job: it is not preserving something that will disappear, it is fixing a point in time. The habits that make a photo set usable months later are the same for both; what changes is the deadline for taking it.

How many approvals are you really chasing?

A water job usually has two, in sequence: the mitigation invoice, reviewed after the work is done, and then a repair or reconstruction scope approved before that work starts. A wind or hail job usually has one scope agreed up front, plus supplements as things are discovered. Two approvals means two separate waiting states.

This is where a single stage called "waiting on carrier" quietly destroys your visibility. On a water file, the mitigation invoice can be sitting in review while the reconstruction scope is still being written, and those two waits belong to different people, sometimes to different reviewers entirely — mitigation invoices are frequently examined by someone other than the adjuster who handles the rebuild, occasionally by an outside review service. Collapsing them into one stage tells you a claim is waiting. It does not tell you which half is stuck, and the stuck half is usually the one nobody has called about.

On the roofing side the second approval arrives later and from a different direction: the crew opens the roof and finds something that changes the number. That is a supplement with its own submission, review and decision states, and the mistake there is treating the original approval as final while the actual scope has moved past it.

The payment shape matters more than it looks. A mitigation invoice is frequently the one bill on a water file that gets paid on its own schedule, while the reconstruction goes through the usual sequence of an actual cash value release, the deductible and depreciation recovered at completion. If your invoicing is tied to what was actually approved, that split is visible. If it is not, a half-paid water file reads as a paid one.

Do the two need separate pipelines, or one?

Two stage sets, one of everything else. The stages genuinely differ — a water job has drying days and a dry-standard check that no roof job has, and a roof job has an adjuster meeting on site that a water job rarely schedules the same way. Contacts, documents, messages and invoicing should stay shared across both.

Duplicating the shared half is the mistake I see most, usually as two tools or two accounts. The homeowner, the carrier, the adjuster, the signed paperwork and the money behave identically on both claim types, so splitting them means splitting the contact record. A corrected phone number, a new adjuster name or a signed document then exists in one system and not the other, and nobody finds out which copy is current until it matters.

Forcing both into one stage set is the mistake in the other direction, and it is subtler because it looks tidy. What actually happens is that half the stages do not apply to half the claims, so people stop using them and everything lives in a catch-all "in progress" bucket. That kills the one number that tells you a claim has gone quiet — days since the claim last moved is worthless if nothing ever moves it between stages.

The test for whether a stage deserves to exist is short: at that point, does the job get handed from one person to another, or is somebody waiting on somebody outside the company? If neither is true, it is a task, not a stage. Drying passes the test. "Equipment delivered" does not.

None of this needs two subscriptions. Both stage sets live in the same account, sharing one contact list and one document store — that is the practical reason a claims-shaped pipeline with its own stages and automation is different from a general sales tool, and most of what separates a claims CRM from a generic contractor CRM shows up exactly here, at the point where you need two workflows without two databases. The plan you are on decides seats, not how many workflows you can run, which is set out on the pricing page.

Where does each claim type quietly lose money?

Water files lose money on undocumented equipment days, missing pre-mitigation photographs, and a reconstruction nobody ever scoped. Wind and hail files lose it on supplements told to the wrong person, depreciation never recovered after completion, and storm leads called back two weeks late. None of these shows up as a lost job.

• Equipment days nobody wrote down — water. If the on-site and off-site dates were not recorded as they happened, the last two or three unit-days become an argument you will lose politely.
• No pre-mitigation photographs — water. The category call and the removal scope both get read down when the only images are of a room that is already torn out.
• The reconstruction that never got scoped — water. The mitigation invoice was paid, the file felt finished, and the rebuild quietly went to somebody else. This is the biggest one, and it is entirely a process failure.
• The supplement told to the wrong person — wind and hail. A crew lead mentions extra decking to whoever answered the phone, and it never becomes a written submission.
• Depreciation never recovered — wind and hail. The work is complete, the money is earned, and the completion documents were never sent because the job was mentally closed.
• The week-three callback — wind and hail. Leads that arrived in the first 48 hours after a storm and got a call once the queue cleared. By then somebody else was on the roof.

What if you only run one of them?

Then build the one you run and ignore the rest of this. A company doing only roofing does not need drying stages, and a mitigation-only company does not need a storm queue. Adding structure for work you do not do is how a CRM turns into homework nobody finishes.

The harder case is the lopsided one — mostly roofing with a handful of water losses a year, or the reverse. My honest advice there is not to build a full second stage set for the minority type. Run those few as plain jobs and accept that they get handled by hand. The threshold for building the second workflow is not a claim count; it is the first time somebody other than you has to run one of the minority claims without asking you how it works.

Both stage sets in CRM For Claims are configured in your own wording during onboarding, because the stage names that matter are the ones your team already says out loud. If you run both types and want to see what that looks like on your actual claims rather than a demo file, book a live walkthrough and bring the messiest open water job you have.