Short answer: The carrier does not see your work. They see a row in a queue, a list of file names, and whatever previous handlers typed into the notes. A claim submission that answers every predictable question in one pass gets decided in one pass — and in most states the decision clock only starts once the carrier has everything it asked you for.
I build CRM For Claims, and the thing that surprises people most about a claim submission is how little of it is about the work. You spent four hours on the roof. You photographed every slope. You wrote a scope you could defend line by line. Then you send it, and it lands on a screen belonging to somebody who was not there, has a queue of other files open this week, and will decide from what is in front of them in the next few minutes.
That gap — between what you did and what actually arrives — is where a large share of the delay in this business lives. It is not in the roof, and usually not even in the price. It is in the packet.
What does the carrier actually see when you submit a claim?
A file list, not a job. Their screen shows the claim number, the loss date, the policy, notes left by whoever touched it before, and your attachments as file names in the order they arrived. Nobody sees the four hours. They see whether the answer to their next question is already in the file.
Three things follow from that.
First, the person opening your packet is often not the person who inspected. Claims move between a field adjuster, a desk adjuster, a reinspection vendor and a supervisor, and each handoff is somebody reading cold. The file has to survive being opened by a stranger, because eventually it will be.
Second, your file names are the index. A folder of camera-numbered files is not sixty photographs to a reviewer — it is one unopened folder. I wrote a whole post on naming and filing conventions that survive a second person because it is the cheapest fix in the workflow and almost nobody does it.
Third, there is exactly one place where you get to speak in your own voice, and it is the cover note or narrative field. Most submissions leave it blank or fill it with a sentence that repeats the claim number. That is a wasted paragraph in the only spot where you can tell a stranger what they are looking at.
| What you think you sent | What lands on their side | What it costs |
|---|---|---|
| A full photo walkthrough of the loss | A folder of camera-default file names in upload order | The one photo that proves the line item is never found |
| The revised estimate after the supplement | A third PDF called Estimate, beside two older ones | The reviewer guesses which is current, or asks |
| Everything we agreed on the phone last Tuesday | Nothing at all, unless somebody wrote it in the file | Your version of the call does not exist |
| The emergency mitigation invoice | A dollar amount with no signed authorization behind it | The line gets held while they go looking for one |
| A scope built from real measurements | Line items with no diagram or photo attached to them | Each unsupported line becomes an assertion to argue |
Why do complete claim submissions come back faster?
Because the clocks that put pressure on a carrier start when they have everything, not when you first made contact. Send most of a packet and the deadline you are quietly counting on has not begun to run. This is not a theory about carrier culture — it is written into how the deadlines are worded.
The Texas Department of Insurance states it in one sentence: “Your company has 15 business days after getting what it needs from you to decide if it will pay. The company can extend this deadline by 45 days if they tell you why they need more time.” Read the first clause again. The countdown is anchored to after getting what it needs from you. Every item you leave out moves that anchor.
Illinois — where we are — builds the same idea into its improper-claims rules from the other direction. Under 50 Ill. Adm. Code 919.80(b)(7), a fire and extended coverage claim that “remains unresolved for more than 75 calendar days from the date it is reported, or 25 calendar days after receipt of proof of loss, whichever is less” obliges the company to send the insured a written explanation of the delay. Read the “whichever is less” carefully: the earlier of those two dates governs, so paperwork that lands early can pull the carrier’s explanation deadline forward from day 75 to day 25.
One honest clarification, because the distinction gets blurred constantly: a sworn proof of loss is the policyholder’s document, not your estimate packet. Your submission does not become the proof of loss. But the structure of the rule is the point: regulators tie the carrier’s obligations to the moment paperwork lands, because that is the only moment anyone can measure.
| Rule | What starts the clock | What the carrier then owes |
|---|---|---|
| Texas, per the state insurance department | Getting what it needs from you | Accept or reject within 15 business days; a 45-day extension needs a stated reason |
| Illinois 919.80(b)(7)(B) | 75 days from report, or 25 days after proof of loss, whichever is less | A reasonable written explanation of the delay to the insured |
| Illinois 919.80(b)(7)(A) | The company’s own aggregate performance | A median payment period over 40 calendar days counts as unreasonable delay |
The Illinois regulator does not measure a carrier one claim at a time; it measures a median payment period. Your file is a data point in somebody’s distribution, and files that can be closed today are what pull a median down. Deadlines and day counts differ by state and by line of business, so check the ones that govern your work — but the shape does not differ. Completeness starts clocks.
What belongs in a clean claim submission?
Everything a stranger needs to say yes without contacting you. That is the entire test. Not everything you have — a hundred-megabyte dump is its own kind of incomplete — but every item that answers a question the reviewer is guaranteed to ask, arranged so they can find it without a second email.
- A one-page cover summary — what happened, when, what you are asking for, and a numbered list of what is attached.
- The estimate in the format they read — if the carrier works in a specific estimating platform, sending a PDF of something they cannot open natively adds a step to every review.
- Photos captioned by location and by line item — not by camera number. The point of photo documentation on a claim is retrieval, and retrieval happens through the caption.
- Measurements or a diagram — whatever the quantities in your scope were derived from, so the numbers are checkable rather than assertable.
- The signed authorization or work agreement — the document that makes your invoice a contract instead of a favour.
- The emergency record, if there was one — timestamps, pre-work photos, the equipment log. On mitigation work that record is the whole basis of the bill, because the condition you were paid to respond to no longer exists.
- One named contact on your side — with a direct number. Files stall for days because the reviewer’s question went to a general inbox.
Notice what is not on that list: explanation. If the packet needs a paragraph arguing why a line item is fair, that argument belongs beside the line item as a photo and a measurement, not as prose at the end.
Why does one missing item cost more than one day?
Because a question is not a message, it is a re-entry. When a reviewer cannot decide from what is in front of them, your file leaves the pile of things being closed today and joins the pile of things waiting on someone else. It comes back when it comes back — behind whatever arrived in the meantime.
I cannot see inside a carrier’s workload system and I am not going to invent a number about it. What is documented is enough: the decision deadline is anchored to having what they need, and regulators grade carriers on aggregate speed. Both reward a file that closes in one touch, and neither cares how good the work behind it was.
Every row in the table at the top of this post is a round-trip trigger, and every one of them is free to prevent. Version confusion is the most common of them by a distance — two estimates in a folder with nothing saying which one is current, on a file where the reviewer has no way to tell them apart and no reason to guess.
Does what you said on the phone count?
Only if somebody wrote it down. Illinois puts this directly in the regulation: a company may not deny a claim on information from a phone conversation or interview unless that conversation is documented in the claim file. The file is the claim. Anything that happened only in a phone call is, for practical purposes, something that did not happen.
The exact wording of 50 Ill. Adm. Code 919.50(b) is: “No company shall deny a claim upon information obtained in a telephone conversation or personal interview with any source unless such telephone conversation or personal interview is documented in the claim file.”
That rule exists to protect the policyholder, but it also tells you where decisions come from on the other side of the phone: the written record. Your habits should mirror theirs. After every adjuster call, two things go in the file — a dated note of what was said, and a short confirming email to the adjuster: confirming our call at 10:15 this morning, you asked for the attic photos and the moisture log, I will send both by Thursday. That is not lawyering. It is making sure the record that gets read later matches the conversation you actually had.
This is the part a shared inbox will never solve, and it is one of the reasons we built the product the way we did: the adjuster is a contact on the claim, the call note lands on the claim, and the document that was sent is logged against the claim with a timestamp. I have written before about keeping adjuster conversations on the claim rather than in someone’s inbox, and everything here is downstream of that habit. The document side is on the features page, and if you are evaluating tools, our comparison of a claims CRM against a generic one is built around this kind of question.
When is a slow answer not your fault?
Often. A clean submission removes the delays you control, and that is all it does. It does not win a coverage dispute, it does not speed up a hailstorm queue, and it does not turn a weak claim into a strong one — though it will get you a clear answer on the weak one faster, which has its own value.
- Coverage is genuinely contested. If the argument is about whether the policy responds at all, the packet is not the bottleneck. That is a different fight, and sometimes not yours.
- Catastrophe volume. After a regional storm every file in that territory queues behind every other one. This is the one time a perfect packet still waits.
- Reinspection or engineer referral. Once a third party is scheduled, the calendar belongs to them.
- Reading their document, not yours. Plenty of delay starts on the carrier’s side of the page — which is why reading an insurance scope properly is a separate skill from writing a submission.
And the honest carve-out on the software question: if you run two or three claims a month with one carrier that dictates its own portal format, you do not need a system for this. You need a checklist taped to the wall and the discipline to use it. The point where a tool starts earning its keep is when more than one person submits, because that is when “the way we send things” stops being one person’s memory. If you get there, our pricing page puts a number on it — $59 or $99 a month plus $39 for each additional user — and that is the figure to weigh against the delay you are absorbing now.
The one test worth running this week
Take the last submission you sent. Open it the way a stranger would — file list first, no context, no memory of the job. Then ask the only question that matters: could someone who has never spoken to you decide this today, or would they have to ask you something first?
If they would have to ask, write down what they would ask about. Do that for three files and you will have your own list — and it will be shorter and more specific than any generic checklist, including this one. Fixing those items acts on every future claim at once, which is more than any other change to your process can say. If you want to see how this looks when the submission assembles itself from the claim record instead of from someone’s memory, book a live walkthrough and bring a real file with you.
