What desk reviewers actually kick back — and how to preempt it

A kickback isn't a reviewer being difficult. It's a reviewer telling you the file doesn't yet support the decision you're asking them to make. They weren't on the roof — they can only approve what the documentation proves. So a bounced file almost never means you did bad work. It means the proof of the work didn't make it back with you.

Almost every kickback lands in one of five buckets. Here's what actually gets files sent back, from the desk's side of the transaction — and how to give the reviewer nothing to return.

1. The slope that isn't there

The single most common trigger: a roof where three slopes are documented and the fourth isn't mentioned at all. The reviewer doesn't read that as "the fourth slope was fine." They read it as "the fourth slope wasn't inspected" — and they have to, because approving an undocumented slope is their exposure, not yours.

Same with missing test squares. "Hail damage to the roof" with no chalked square per slope gives the reviewer no way to tell eleven hits from two. There's nothing to approve, so they ask.

Preempt it: a test square on every slope, including the clean ones, plus all four elevations. A documented clean slope isn't wasted effort — it's the evidence that closes the file. (The on-roof routine for this is in the 10-minute capture routine.)

2. Numbers a reviewer can't stand behind

"Some hail impacts." "A few dented shingles." "Significant granule loss." A reviewer can't put their name behind an adjective. When the measurement is vague, they either kick it back for specifics or cut the scope to what's provable — and neither outcome is the one you wanted.

The failure mode here is subtle: it's not that the number is wrong, it's that it's unverifiable. A range reads as a guess. A hedge reads as doubt. An exact count with a photo behind it reads as a finding.

Preempt it: counts per slope, measurements with a tape or gauge in the frame, and exact values (roof age, squares, pitch) typed into the file rather than narrated loosely. If a number genuinely isn't known, say so explicitly rather than approximating — a flagged gap survives review; a soft guess doesn't.

3. Damage with no cause attached

You can document damage flawlessly and still get bounced if nothing ties that damage to the reported loss. The reviewer's job is coverage, and coverage turns on causation: is this the peril on the claim, from the date of loss — or is it wear, age, or a prior event?

Files get returned when the photos show damage but the narrative never connects it to the storm. No directional evidence (which is what those clean slopes were for). No mention of roof age when age is the obvious counter-argument. No comment on why this is sudden-and-accidental rather than long-term deterioration.

Preempt it: state the cause out loud and back it. Directional damage consistent with the storm track. Age noted and addressed. One clear sentence linking the loss to the peril and the date. Give the reviewer the coverage argument already made, not a pile of photos to argue it from.

4. A narrative that argues with its own estimate

This one bounces files quietly. The narrative describes replacing the north and east slopes; the estimate scopes the whole roof. The report says the gutters are functional; the line items replace them. A close-up shows a soft-metal dent; the scope calls it a puncture.

A reviewer reads the narrative and the estimate as one document. When they disagree, the reviewer can't tell which one is right — so the safe move is to send it back and make you reconcile it.

Preempt it: the narrative and the scope have to tell the same story. Every line item should trace to something documented. Repair versus replace should be stated and justified in the narrative, so the estimate reads as the conclusion of the report rather than a separate opinion.

5. The small stuff that still bounces a file

None of these are about the loss, and all of them get files returned:

• Dates that don't line up — date of loss after the inspection date, an inspection date that predates the assignment.
• Identity errors — wrong claim number, misspelled policyholder, the previous claim's address left in a copied template.
• Carrier format — the carrier expects specific sections or a specific structure and the report doesn't follow it. Reviewers working a State Farm queue all day spot a non-conforming file instantly.
• Internal contradictions — a measurement in the narrative that disagrees with the same measurement in the field data.

Preempt it: a 60-second consistency pass before you submit. Dates in order, identifiers correct, the carrier's structure followed, no number contradicting another. It's the cheapest kickback to prevent and one of the most common.

What an approve-on-sight file has

Turn the five buckets around and you have the reviewer's mental checklist — the file that clears on the first pass:

• Every slope documented, including the clean ones
• Counts and measurements a reviewer can verify
• Damage explicitly tied to the peril and the date of loss
• A narrative and an estimate that tell the same story
• Dates, names, and carrier format that hold up to a glance

A reviewer approves the file that leaves them nothing to decide on your behalf. Build that file on the property, and the desk becomes a formality instead of a round trip.

---

The five buckets above are all decided on site — which is why the 10-minute capture routine is the other half of this. If you want to see what a file with nothing to kick back looks like written up, read a full sample report, or grab the field guide for the shot list and memo script. LossNarrative writes the narrative from your photos and memo — but the reviewer approves it because of what you captured, not what wrote it up.