The Roofing Supplement Department Software Stack: How to Build the Tooling Layer by Layer

A supplement department lives or dies on two things: the quality of the documentation it produces, and how fast a file moves from "job sold" to "final payment received." Most roofers I talk to think they have a supplementing problem when what they actually have is a tooling problem. They've got a sharp estimator who knows code and knows Xactimate, but that person is buried under PDFs, screenshotting carrier estimates into a shared drive, retyping line items into a spreadsheet, and chasing adjusters by leaving voicemails they never log. The skill is there. The system isn't.

The job here is to lay out the actual software stack a roofing supplement department runs on — not as a feature checklist, but as a workflow with layers. Each layer does a specific job, hands off to the next, and breaks in a specific way when it's wired wrong. I'll name real tool categories and real products that fill each one, give you a lean version and a scaled version of every layer, and call out the integration mistakes that quietly bleed margin. At the end there's a one-page starter-stack table you can build against.

One framing note before we start, because it changes which tools you should even look at. A roofing contractor documents its own inspection, its own estimate, its own scope, and its own evidence. It compares its own estimate to the carrier's estimate internally, requests documents it's missing, and tracks the paperwork it has submitted. The homeowner files the claim. The insurer decides the claim. The contractor does not represent the homeowner, interpret their policy, tell them what they're entitled to recover, or negotiate the claim on their behalf — that's public adjusting, and in most states it requires a license. Software that nudges you toward representing the insured, or that's built around deductible-waiver and "free roof" messaging, is software that will eventually get a principal in front of a state department of insurance. The stack below is built for the documentation-and-internal-comparison job, which is the job a contractor is actually allowed to do.

The workflow the stack has to support

Before you pick a single tool, get the workflow straight, because every tool either serves a stage of it or it's clutter. A supplement file moves through roughly these stages:

1. Intake — a sold job (or a claim job) enters the supplement queue with the carrier estimate, the policy declarations page if you have it, the homeowner's contact info, and the property.
2. Inspection and capture — measurements, photos, and field notes that establish what the roof and the property actually need.
3. Document handling — the carrier estimate, prior estimates, ESX/PDF files, and correspondence get parsed, named, and filed so nothing is lost.
4. Estimate build and comparison — your scope goes into Xactimate (or a Symbility/estimate platform), and your line items get compared against the carrier's estimate to surface what's missing, mispriced, or out of code.
5. Packet assembly — the documented scope, photos, measurements, code citations, and cover narrative get packaged into a submission.
6. Submission and follow-up cadence — the packet goes to the carrier, and the file enters an aging cadence until you get a response.
7. Reconciliation and depreciation release — you track approved vs. requested, recoverable depreciation, and the deductible, and you confirm the supplement actually got paid.
8. Analytics — you measure cycle time, approval rate, dollars recovered per file, and which estimators and which carriers move the needle.

Every layer of the stack maps to one or more of those stages. Where the stack breaks is almost always at the handoffs — intake to estimate, estimate to packet, packet to follow-up, follow-up to payment. Keep that in mind; the integration mistakes I flag are mostly handoff failures.

Layer 1: The estimating engine (Xactimate and its world)

This is the non-negotiable core, and it's the layer people get most confused about, because they think the estimating platform is the supplement stack. It isn't. It's the pricing and line-item engine. Everything else exists to feed it good inputs and to do something useful with its outputs.

What the layer does: It produces a properly structured, line-item estimate at the carrier's accepted price list, in the format adjusters and carriers expect. For most of the U.S. property-claims world, that means Xactimate, which runs on Verisk's regional price lists. The reason this matters for supplementing specifically: when you write your scope in the same system and against the same price list the carrier used, your supplement is an apples-to-apples comparison the desk adjuster can validate quickly. Write it in a different format and you've added friction to your own approval.

Real tools that fill it:

• Xactimate (Verisk) — the dominant property estimating platform. Xactimate X1 runs in the cloud and on desktop and mobile. If your carriers settle in Xactimate, you need to write in Xactimate. There's a real learning curve, and price lists update monthly, so you're never "done" learning it.
• Symbility (now part of CoreLogic) — the other major estimating platform. Some carriers and TPAs settle in Symbility. If you work those carriers, you may need both.
• Verisk's price-list documentation and Xactimate training — not optional reading. The line items, modifiers, and operation codes you cite are only as defensible as your understanding of how the price list is built.

How it connects: Xactimate ingests an ESX file (the carrier's estimate, when you can get it) and your measurement data; it exports the estimate as a PDF and ESX that flow into your packet. The handoff you care about is measurements in and comparison out — getting accurate roof and elevation geometry into Xactimate without retyping, and getting your finished estimate into a side-by-side against the carrier's.

Lean vs. scaled:

• Lean: One Xactimate seat shared by your estimator/supplementer. Manual ESX import. This is fine for a shop doing a handful of supplement files a week.
• Scaled: Multiple seats, a defined price-list-update routine, and a documented internal standard for how line items get written (so two estimators produce consistent files). At volume, consistency is worth more than raw speed.

Common mistakes: Writing supplements outside the carrier's platform and price list because it's faster for you — it slows down approval and invites pushback. Letting price-list updates lapse so your numbers are stale. And the big one: treating Xactimate as a database. It's an estimating tool, not a CRM or a document vault. Don't try to run your whole department inside it.

A word on the price list, because it's where a lot of disputes start. Xactimate's prices come from Verisk's regional price lists, which update monthly and vary by metro. When you and the carrier are on different price-list versions, you'll get line-item deltas that look like disputes but are really just timing. The professional move is to write against the same price list the carrier settled on, note the version, and only push on a price when it's genuinely off the current list — not because your copy is a month newer. Estimators who understand how operations, modifiers, and minimum charges are built into the price list write supplements that hold up; estimators who treat the line item as a magic number that the software spits out write supplements that get kicked back. The depth of your Xactimate knowledge is, bluntly, the ceiling on the quality of everything downstream.

Layer 2: Measurement and field capture

What the layer does: It turns the physical roof and property into the numbers and images your estimate and packet need — area, pitch, facets, lineal footage of ridge/hip/valley/rake/eave, and dated photographs of damage and existing conditions. Bad inputs here cause more rejected supplements than weak narratives do. If your squares are wrong or your photos don't show what you claim, the rest of the stack is polishing a flawed file.

Real tools that fill it:

• Aerial/measurement reports: EagleView, Hover, Roofr (which bundles measurements with proposals), GAF QuickMeasure, and similar. These give you roof geometry without a tape measure on a steep cut-up roof, and many export data that drops into Xactimate. Worth being clear-eyed: a measurement report tells you the size and shape of the roof; it doesn't tell you condition, age, or what's damaged. That's a separate judgment you make.
• Photo documentation: CompanyCam is the category leader here — time- and geo-stamped photos, organized by project, shared across the crew. The geo/time stamp is the part that matters for documentation; an undated photo in a folder is weak evidence.
• Drones (with a licensed remote pilot under FAA Part 107) for roofs you shouldn't or can't walk. Pair with the photo platform so images land in the project automatically rather than on someone's phone.

How it connects: Measurement data feeds Layer 1 (the estimate). Photos feed Layer 5 (packet assembly) as evidence. The handoff to get right: photos and measurements should attach to the project record in your CRM/project system, not live in a personal camera roll or a one-off email. If a photo isn't attached to the file, for documentation purposes it functionally doesn't exist.

Lean vs. scaled:

• Lean: CompanyCam plus one aerial measurement vendor, ordered per job.
• Scaled: A standardized photo checklist enforced in the field app (so every inspector captures the same shots in the same order), measurement reports auto-ordered at intake, and drone capture for the hard roofs.

Common mistakes: Inconsistent photo capture — every inspector shooting whatever they feel like — so half your files are missing the eave shot or the slope overview the desk adjuster wants. Treating measurements as exact truth when reports can disagree on cut-up roofs; verify when the number drives a big dollar line. And relying on undated phone photos.

Layer 3: Document intake, OCR, and the carrier-estimate problem

This is the layer most departments under-build, and it's where the most labor hides. Every supplement file is a pile of documents: the carrier estimate (PDF or ESX), the scope sheet, prior estimates, the dec page if you have it, correspondence, invoices. Someone has to receive all of it, read it, name it, file it, and pull the key numbers out — the carrier's line items, the RCV/ACV split, the deductible, the recoverable and non-recoverable depreciation, the claim number, the date of loss.

What the layer does: It ingests documents, extracts and classifies the data inside them, and makes that data searchable and structured instead of locked in a PDF. The goal is that no one is retyping a carrier estimate into a spreadsheet by hand.

Real tools and approaches that fill it:

• The estimating platform itself, when you can get an ESX: If the carrier shares the ESX, Xactimate ingests it directly and you've got structured line items for free. Always ask for the ESX. The trouble is you frequently get a flat PDF instead.
• Document/OCR tooling: For flat-PDF carrier estimates, you need optical character recognition to pull text and tables out. General tools (Adobe Acrobat Pro's OCR/export, cloud OCR services) get you text; the harder part is classifying what you've extracted — knowing which number is the deductible vs. the depreciation vs. the net claim.
• Roofing-specific claim/document tools: A growing set of products read a carrier estimate and map its line items against a known scope, then flag gaps. RoofPredict's RoofClaim/RCM module does this — claim intake, document OCR and classification, and opportunity detection that maps estimate lines to a knowledge base and flags missing scope, code items, and likely-missed supplements with evidence and pricing, on locked, license-gated, contractor-documentation-only templates. Its honest limits matter: it documents your own scope and compares to the carrier estimate internally — it doesn't file, handle, or negotiate the claim, and it doesn't tell the homeowner what they're entitled to. Treat any tool in this category as a strong first-pass reviewer that an experienced estimator still checks, not as an auto-pilot you ship unread.
• A disciplined file-naming and folder convention in cloud storage (Google Drive, SharePoint/OneDrive, Dropbox). Unglamorous, but a consistent naming standard — claim number, document type, date — is the cheapest reliability upgrade in the whole stack.

How it connects: Extracted carrier-estimate data feeds Layer 4 (comparison) directly — that's the whole point. Deductible and depreciation figures feed Layer 7 (reconciliation). Classified documents feed Layer 5 (packet). The handoff to protect: the structured carrier data has to land somewhere it can be compared to your estimate, rather than only filed as a read-only PDF.

Lean vs. scaled:

• Lean: Always request the ESX; for PDFs, a person reads and enters the key figures into your CRM/job record, with a strict naming convention on a shared drive.
• Scaled: OCR-and-classify tooling that pre-extracts the carrier estimate and pre-flags gaps, with a human reviewing the output. The labor you save here is real and recurring.

Common mistakes: Never asking for the ESX (and retyping by hand as a result). Letting documents pile up in inboxes and personal drives so files are perpetually "almost complete." And over-trusting OCR output — OCR on a noisy PDF makes mistakes, and a misread depreciation figure can wreck your reconciliation. Always reconcile extracted numbers against the source before you rely on them.

Layer 4: Estimate comparison and opportunity detection

This is the analytical heart of supplementing: comparing what the carrier scoped and priced against what the roof and the property actually need under the manufacturer's instructions and the applicable building code, and surfacing the gaps. Done as documentation of your own scope, this is squarely within what a contractor can do.

What the layer does: It puts your estimate and the carrier's estimate side by side and answers: what line items are missing entirely (e.g., a code-required item the jurisdiction enforces), what's under-quantified (squares, lineal footage, accessories), and what's mispriced against the current price list. Then it ties each flagged item to evidence — a photo, a measurement, a code citation, a manufacturer instruction.

Real tools and inputs that fill it:

• Side-by-side inside the estimating platform: Xactimate lets you work both estimates; disciplined estimators build the comparison there.
• A scope/knowledge base of common gaps and the evidence each requires: This can be a tool feature (RoofPredict's RoofClaim maps lines to a KB and flags missed items with evidence and pricing) or your own internal checklist built from experience. The strongest departments have a documented library of "items we routinely have to support, and what proves each one."
• Code references: The International Residential Code (IRC) and your locally adopted/amended code govern things like ice-barrier requirements, drip edge, and re-roofing/tear-off rules. Cite the adopted code in your jurisdiction, not the generic model — local amendments are real and adjusters know them. Manufacturer installation instructions (which carry their own requirements) are the other authority.

How it connects: This layer consumes Layer 3's structured carrier data and Layer 1's estimate, and it produces the list of supplemented items with justification that becomes the spine of Layer 5's packet. The cleaner the comparison, the shorter and stronger the packet.

Lean vs. scaled:

• Lean: An experienced estimator working both estimates with a written gap checklist.
• Scaled: Software-assisted gap detection that pre-flags missing/mispriced items with attached evidence and a price, reviewed by your estimator — so the human spends time on judgment calls, not on hunting line by line.

Common mistakes: Citing code you can't actually source to the adopted local code. "Supplementing" items you can't tie to evidence — every flagged item needs a photo, a measurement, or a citation behind it, or it's noise that weakens the whole file. And the boundary mistake: framing the comparison as what the homeowner is owed or entitled to rather than what your scope documents and what the carrier's estimate omitted. Document your scope; let the carrier reconcile the coverage.

Layer 5: Packet assembly and narrative

What the layer does: It assembles the submission — your estimate, the supplemented line items with evidence, the photo report, the measurements, the code/manufacturer citations, and a cover narrative that walks the adjuster through what's documented and why. A strong packet makes the desk adjuster's job easy; a weak one makes them work, which means delay or denial.

Real tools that fill it:

• Document generation / PDF assembly: Many roofing CRMs and project tools generate branded PDF packets. CompanyCam can produce photo reports. Some shops build templated packets in their estimating or document tools.
• Per-home report tooling: Products that generate a clean, evidence-organized report per property help here. RoofPredict produces per-home microsites, PDF reports, and QR-linked reports — useful as a presentation/evidence-index layer, with the same boundary: it's your documentation, not advocacy for the homeowner's coverage.
• A narrative template library: Your own bank of cover-letter language for recurring items (with placeholders for the specific evidence) keeps quality consistent and speeds assembly. Keep it factual and scope-focused.

How it connects: Packet assembly pulls evidence from Layer 2 (photos/measurements), the flagged items from Layer 4, and the documents from Layer 3, and it produces the artifact Layer 6 submits. The handoff failure here is evidence that's scattered — if photos and measurements aren't already attached to the project record, assembling the packet becomes an archaeology project.

Lean vs. scaled:

• Lean: A template packet in your document tool, photos pulled from CompanyCam, assembled by hand.
• Scaled: Packet completeness scoring — a checklist or tool that won't let a file go out missing a required photo, measurement, or citation — so submissions are consistent regardless of who built them.

Common mistakes: Sending walls of text instead of organized evidence. Inconsistent packets between estimators. Submitting incomplete files because nothing flags the missing piece before it goes out. And tone — a packet that reads as adversarial advocacy rather than professional documentation invites a defensive response.

Layer 6: Submission, follow-up cadence, and aging

This is where supplements go to die in most shops. The packet goes out, and then... nothing tracked. No one knows which files are waiting on a response, how long they've been waiting, or whose turn it is to follow up. Dollars that were earned in Layer 4 evaporate because nobody chased them.

What the layer does: It tracks every submitted file as an aging item, assigns follow-up tasks on a cadence, and logs every contact with the carrier (date, person, what was said, next step). The supplement isn't done when you submit it; it's done when it's paid.

Real tools that fill it:

• Your CRM / pipeline as the system of record: This is the right home for follow-up. Roofing CRMs — AccuLynx, JobNimbus, Roofr, Jobber, plus general CRMs like HubSpot, and field/ops platforms like ServiceTitan and SalesRabbit — all support stages, tasks, and reminders. A supplement file should live as a stage in your pipeline with automated follow-up tasks and an aging view.
• Supplement-cadence tooling: Tools that specifically track supplement aging and follow-up cadence (RoofPredict's RoofClaim includes supplement aging and cadence plus packet-completeness scoring) reduce the "who's following up on what" chaos. Whatever you use, the requirement is the same: every open supplement is visible, aged, and assigned.
• Communication logging: Email and call logging tied to the file. If a contact isn't logged on the record, it didn't happen as far as the next person to touch the file is concerned.

How it connects: This layer holds the file open between Layer 5 (submission) and Layer 7 (payment). It feeds Layer 8 (analytics) the cycle-time data. The integration that matters: the cadence has to live where the rest of the job lives (the CRM/project record), not in a separate spreadsheet someone forgets to open.

Lean vs. scaled:

• Lean: A pipeline stage in your CRM with manual follow-up tasks and a logged-contact discipline.
• Scaled: Automated cadences (task auto-generated at N days with no response), an aging dashboard the manager reviews, and supplement-specific tracking.

Common mistakes: No system of record for open supplements — the single most expensive gap in most departments. Following up by memory. Not logging contacts, so follow-up restarts from zero every time. And letting files age past the point where the carrier considers them stale.

A practical note on cadence design, because "follow up" is too vague to run a department on. Decide your intervals up front and let the CRM generate the task — for example, a first follow-up at a week to ten days if there's no acknowledgment, then a tighter rhythm once the file is acknowledged but unresolved, with a defined escalation when a desk adjuster goes quiet (a supervisor, a re-submission with clarified evidence, whatever your process is). Write down what "escalate" means so a coordinator can do it without an estimator's judgment. The discipline that separates departments that collect from departments that don't isn't a fancier tool — it's that every open file is visible on an aging board, every contact is logged with a next step and a date, and no file is allowed to sit with no next action assigned. When you review the aging board weekly, the files that have aged out without contact are the ones telling you exactly where your cadence is leaking.

Layer 7: Reconciliation, depreciation, and deductible tracking

What the layer does: It closes the financial loop. For each file it tracks: requested vs. approved (line item and total), the deductible, the recoverable depreciation and whether it's been released, and whether the supplement actually got paid. Recoverable depreciation in particular is real money that's withheld until work is completed and documented — and it routinely goes uncollected because nobody tracked the release. This is internal financial tracking of your paperwork, which is firmly in-bounds for a contractor.

Real tools that fill it:

• CRM/job financials or accounting integration: Track approved-vs-requested and the deductible on the job record, and tie it to your accounting system (QuickBooks via your CRM's integration, or ServiceTitan's financials).
• Recoverable-depreciation tracking: A field/automation on the file that flags when work is complete and the depreciation-release documentation is due — RoofClaim describes a recoverable-depreciation "autopilot" and deductible tracking for exactly this. Manually, it's a column and a task; the point is that something owns the release.
• A reconciliation step before close: Confirm the supplement paid, the depreciation released, and the deductible is accounted for before you mark the file complete.

How it connects: Consumes the deductible/depreciation figures extracted in Layer 3 and the approved amounts logged in Layer 6; feeds Layer 8 the dollars-recovered numbers. The handoff failure: marking a file "done" at production completion instead of at financial reconciliation, so recoverable depreciation quietly never gets collected.

Lean vs. scaled:

• Lean: A reconciliation checklist and a tracked depreciation-release task per file.
• Scaled: Automated depreciation-release triggers, deductible tracking on every file, and an accounting integration so the numbers reconcile without re-entry.

Common mistakes: Never collecting recoverable depreciation because the release wasn't tracked. Closing files at production, not at payment. And on the boundary: never structure your fee as a percentage of claim proceeds, and never use deductible-waiver/"free roof" messaging — both are bright-line problems. Bill for your work.

Layer 8: Analytics and the feedback loop

What the layer does: It tells you whether the department is actually working and where to push. The metrics that matter: average cycle time (sold/intake to payment), supplement approval rate, average dollars recovered per file, recoverable depreciation collected vs. left on the table, and breakdowns by estimator and by carrier. Without this layer you're guessing.

Real tools that fill it:

• CRM reporting / dashboards: Most roofing CRMs report on pipeline stages and cycle time. A results funnel that shows actual-vs-estimate and cost-per-win is the mature version — RoofPredict's results funnel does actual-vs-estimate and cost-per-win, which is the same instinct applied to the front of the business.
• A BI layer at scale: Export to a spreadsheet or a BI tool (Looker Studio, Power BI) for cohort and carrier-level analysis once your CRM reporting hits its limits.
• A monthly review ritual: The tool is worthless without the meeting. Review aging, approval rates by carrier, and depreciation collected, and feed what you learn back into the Layer 4 gap checklist and the Layer 5 narrative library.

How it connects: It closes the loop back to Layer 4 and Layer 5 — the carriers that push back on a given item tell you where to strengthen evidence; the items that get approved cleanly tell you your strongest plays. Analytics with no feedback into the documentation standard is just a report nobody reads.

Common mistakes: Measuring volume but not cycle time or dollars-per-file. Not breaking out by carrier (carriers behave very differently). And collecting metrics no one acts on.

How the layers connect: the handoffs that actually matter

If you take one thing from all of this, make it the handoffs. The layers are mostly available off the shelf; the value and the failures live in the seams between them. The four seams that decide whether your stack works:

• Intake → estimate (Layers 3→4): Carrier-estimate data has to arrive as structured, comparable data, not a read-only PDF. Get the ESX when you can; OCR-and-classify when you can't; never retype by hand at volume.
• Estimate → packet (Layers 4→5): Every flagged item has to carry its evidence with it. If your photos and measurements aren't already attached to the project record, packet assembly stalls.
• Packet → follow-up (Layers 5→6): The moment you submit, the file becomes an aging item with an owner and a cadence — in the CRM, not a side spreadsheet.
• Follow-up → payment (Layers 6→7): A file isn't closed at production; it's closed at reconciliation, with recoverable depreciation released and the deductible accounted for.

Get those four seams tight and a mediocre tool in each layer will outperform a best-in-class tool in each layer that doesn't talk to its neighbors.

The layer nobody lists: people, roles, and SOPs

Software doesn't run a supplement department; people running software do. The most over-tooled shops I've seen still bleed files because no human owns the seams. Before you spend another dollar on tools, decide who owns each stage and write the standard operating procedure that the tools enforce. The tools are the rails; the SOP is the train schedule.

At small volume, one person wears most of the hats: the estimator is also the supplementer is also the follow-up chaser. That works until it doesn't — usually around the point where follow-up starts slipping because the same person is heads-down writing the next estimate and never gets back to the carrier on the last one. The first role you split out is almost always follow-up, because it's the cheapest to delegate (it's cadence and logging, not estimating judgment) and it's the stage that quietly loses the most money. A coordinator who lives in the CRM, works the aging dashboard, logs every carrier contact, and escalates stuck files to the estimator will pay for themselves fast.

As you scale, the roles separate into roughly: intake coordinator (gets the carrier estimate, dec page if available, and claim details onto the record, orders measurements), estimator/supplementer (writes the scope, runs the comparison, makes the judgment calls), packet builder (assembles evidence to the completeness standard — sometimes the same person, sometimes not), and follow-up coordinator (cadence, logging, escalation through to payment and depreciation release). Whether those are four people or two people wearing two hats each, the point is that every stage has a named owner and a written standard. A file should never be in a state where no one knows whose move it is.

The SOP is what makes the software worth buying. Photo-completeness scoring only works if there's a documented shot list it scores against. A follow-up cadence only works if there's a written rule for when and how you escalate. Gap detection only helps if there's a checklist of which items you support and what evidence each one needs. Buy the tools to enforce standards you've actually written down — buying tools to substitute for standards you haven't written is how shops end up with expensive software and inconsistent files.

One more practical note on training: every layer here has a learning curve, and Xactimate is the steepest. Budget real ramp time for a new supplementer — months, not days, to write defensible files consistently — and lean on the gap checklist and narrative library to shorten it. The library of "items we support and the evidence each needs" is the single best training asset you can build, and it lives in the same place whether your team is one person or six.

How to actually evaluate and migrate tools

When you're choosing a tool for any layer, run it through the same short test instead of getting sold on a feature demo:

1. Which stage does it own, and does it duplicate something I already have? A tool that wants to be a second system of record is a liability unless it's replacing the first one. Be honest about overlap.
2. How does data get in and out? Ask specifically: does it import an ESX, does it export to my estimating platform, does it two-way-sync to my CRM, and what happens to my data if I leave? A tool with no clean export is a roach motel for your records.
3. What's the handoff to the next layer? Trace a real file through it on the demo. If the salesperson can't show you the handoff — measurements into the estimate, flagged items into the packet, submission into the cadence — assume the handoff is manual.
4. Does it keep me on the right side of the public-adjusting line? Look at the templates and the default messaging. If the product or its marketing pushes deductible-waiver language, "free roof" framing, or representing the homeowner's coverage, walk away regardless of how good the rest is.
5. What does it cost me in labor on top of the license? A cheap tool that needs heavy manual babysitting can cost more than a pricier one that automates a real handoff. Price the whole loaded cost.

On migration: the dangerous moment is the cutover, when you've got open files in the old system and new files in the new one. Don't migrate mid-cadence. Let in-flight supplements finish in the old system, start new intake in the new one, and run both in parallel until the old queue drains. And before you trust a new system of record, export your data out of it once on day one — confirm you actually can, and confirm the export is complete, before you've staked the business on it.

Build vs. buy, and the one-platform-vs-best-of-breed question

You'll face a recurring choice: lean on one platform that does many layers adequately, or stitch best-of-breed tools per layer. Honest answer: it depends on volume and on whether your CRM is already your system of record.

If you're running a CRM you trust (AccuLynx, JobNimbus, Roofr, ServiceTitan), let it own intake, follow-up cadence, reconciliation, and analytics (Layers 3-partial, 6, 7, 8), and bolt on specialists for estimating (Xactimate), capture (CompanyCam + a measurement vendor), and document/gap detection. The CRM is your spine; everything two-way-syncs to it. This is why CRM integration breadth matters when you pick adjacent tools — a capture or claim tool that two-way-syncs to your CRM keeps the project record whole; one that doesn't creates a second source of truth you'll have to reconcile by hand.

If you're low-volume, don't over-buy. A single Xactimate seat, CompanyCam, an aerial vendor, a disciplined shared drive, and pipeline stages in whatever CRM you already run will carry you a long way. Add OCR/gap-detection and depreciation automation when the manual labor of those layers starts costing more than the software.

The trap at both ends: at the low end, running the whole department out of spreadsheets and inboxes (no system of record, files age and die). At the high end, buying overlapping platforms that each want to be the source of truth, so your data forks and nobody trusts any single screen. Pick one system of record and make everything else feed it.

A worked example: one file through the stack

Make it concrete. A storm job sells. Here's the file moving through a well-wired stack — note these dollar figures are illustrative, not a benchmark:

1. Intake. Job enters the supplement pipeline stage in the CRM. The carrier's PDF estimate is attached; the homeowner's claim number, date of loss, and deductible are entered on the record.
2. Capture. The inspector shoots the standardized photo set in CompanyCam (slope overviews, eaves, accessories, damage detail), all time-stamped and attached to the project. An aerial measurement report is ordered and comes back at, say, 28 squares.
3. Document handling. No ESX was provided, so the carrier PDF is run through OCR and the line items, the RCV/ACV split, the deductible, and the recoverable depreciation are extracted and reconciled against the PDF by a human.
4. Comparison. The carrier scoped 26 squares and omitted drip edge that the locally adopted code requires; the estimator confirms the 28-square measurement, documents the drip-edge requirement against the adopted code, and flags both with photo and measurement evidence.
5. Packet. The supplemented items (2 squares, drip edge, the associated accessories) are assembled with the photos, the measurement report, the code citation, and a factual cover narrative. A completeness check confirms nothing required is missing.
6. Submission and cadence. Packet submitted; the file is now an aging item with a follow-up task at 10 days if there's no response. Every adjuster contact is logged on the record.
7. Reconciliation. The supplement is approved and paid; once production completes, the depreciation-release documentation goes out and the recoverable depreciation is collected — instead of being left on the table. The deductible is accounted for. Only now is the file marked complete.
8. Analytics. Cycle time, the approved-vs-requested delta, and dollars recovered land in the dashboard, broken out by this carrier and this estimator, and the drip-edge play (clean approval) gets noted in the gap checklist as a strong, well-evidenced item.

Every stage handed clean data to the next. No retyping, no lost photos, no orphaned file, no uncollected depreciation. That's the whole game.

What pros get wrong (the short list)

• No system of record for open supplements. The single most common and most expensive failure. Files submit and vanish.
• Retyping carrier estimates by hand. Ask for the ESX; OCR the PDFs. Hand-keying is slow and error-prone.
• Evidence not attached to the project record. Undated phone photos and personal drives turn every packet into a scavenger hunt.
• Flagging items with no evidence. Every supplemented line needs a photo, a measurement, or a citation. Unsupported items weaken the whole file.
• Closing files at production, not payment. Recoverable depreciation left uncollected is money you earned and walked away from.
• Citing model code instead of the adopted local code. Adjusters know the difference.
• Crossing the public-adjusting line. Documenting your own scope is in-bounds. Representing or advising the homeowner on their coverage, negotiating the claim for them, charging on claim proceeds, or running deductible-waiver/"free roof" messaging is not. Keep the software and the messaging on the documentation side of that line.
• Buying overlapping platforms. Two systems that both want to be the source of truth give you zero reliable sources of truth.

The starter stack (one page)

Start with your system of record — the CRM — and the estimating engine. Get capture and document handling clean so good data flows in. Then tighten the four handoffs. The fanciest gap-detection tool in the world won't save a department whose submitted files age out unnoticed and whose recoverable depreciation never gets collected. Build the boring layers first; they're the ones that actually pay you.

FAQ

What software does a roofing supplement department actually need at minimum?

At minimum: an estimating engine (Xactimate, or Symbility for carriers that use it), a photo-documentation app with time- and geo-stamps (CompanyCam), an aerial measurement source (EagleView, Hover, Roofr, or GAF QuickMeasure), and a CRM or project system to act as the system of record for intake, follow-up cadence, and reconciliation (AccuLynx, JobNimbus, Roofr, ServiceTitan, or similar). Everything else — OCR/gap-detection, depreciation automation, completeness scoring — is an upgrade you add as volume makes the manual version more expensive than the software.

Do I have to use Xactimate for supplementing?

Practically, if your carriers settle in Xactimate, yes — writing your supplement in the same platform and against the same regional price list the carrier used makes it an apples-to-apples comparison the desk adjuster can validate quickly, which speeds approval. Some carriers and third-party administrators settle in Symbility (CoreLogic) instead, so if you work those, you may need both. Writing supplements in a different format adds friction to your own approval.

What's the difference between supplementing software and a public-adjusting tool?

Supplementing software helps a contractor document its own inspection, estimate, scope, and evidence, and compare its own estimate to the carrier's estimate internally — all things a contractor is allowed to do. A public adjuster represents the insured: interpreting policy rights, advising on what the homeowner is entitled to recover, and negotiating the claim, which in most states requires a license. Avoid tools or messaging built around representing the homeowner, deductible waivers, or 'free roof' offers, and never charge a fee based on claim proceeds.

How do I get a carrier's estimate into Xactimate without retyping it?

Always request the ESX file from the carrier first — Xactimate ingests it directly and you get structured line items with no retyping. When you only receive a flat PDF, run it through OCR to extract the text and tables, then have a person reconcile the extracted figures (deductible, depreciation, RCV/ACV split, line items) against the source before relying on them. Roofing-specific claim tools can OCR, classify, and pre-flag gaps, but a human should still review the output because OCR makes mistakes on noisy PDFs.

Where should I track open supplements so they don't get lost?

In your CRM or project system as a dedicated pipeline stage, with each submitted file treated as an aging item that has an owner, a follow-up cadence, and a logged record of every carrier contact. The most expensive failure in most departments is having no system of record for open supplements, so files submit and then vanish. A side spreadsheet doesn't count — it lives outside the job record and people forget to open it.

What is recoverable depreciation and why do tools emphasize tracking it?

Recoverable depreciation is the portion of the claim amount the carrier withholds until the work is completed and documented; it's released to the policyholder afterward. It routinely goes uncollected because no one tracks the release once production finishes. Tools emphasize it because it's real money you earned and can lose simply by closing the file at production instead of at financial reconciliation. The fix is to assign ownership of the depreciation-release documentation on every file.

Should I buy one all-in-one platform or stitch together best-of-breed tools?

It depends on volume and on whether your CRM is already a trusted system of record. If it is, let the CRM own intake, follow-up, reconciliation, and analytics, and bolt on specialists for estimating, capture, and document handling that two-way-sync back to it. If you're low-volume, don't over-buy. The trap at the high end is buying overlapping platforms that each want to be the source of truth, so your data forks and no single screen is trustworthy. Pick one system of record and make everything feed it.

How does RoofPredict fit into a supplement stack, and what are its limits?

RoofPredict fits in two layers, not as the whole stack: its RoofClaim/RCM module does claim intake, document OCR and classification, opportunity detection that maps estimate lines to a knowledge base and flags missing scope, code items, and likely-missed supplements with evidence and pricing, plus recoverable-depreciation and deductible tracking and supplement aging/cadence; and its per-home reports help with packet presentation. Its honest limits: it documents your own scope and compares to the carrier estimate internally on locked, license-gated, documentation-only templates — it does not file, handle, or negotiate the claim, and it doesn't tell the homeowner what they're entitled to. Treat its gap detection as a first-pass an experienced estimator still reviews.

What metrics tell me whether my supplement department is working?

Track average cycle time from intake to payment, supplement approval rate, average dollars recovered per file, recoverable depreciation collected versus left on the table, and break all of those out by estimator and by carrier. Measuring only volume hides the real problems. Carriers behave very differently, so the per-carrier view tells you where to strengthen evidence, and feeding what you learn back into your gap checklist and narrative library is what actually improves results.

What's the most common integration mistake when building this stack?

Handoff failures — the data doesn't flow cleanly between layers. The four seams that matter most: carrier-estimate data arriving as a read-only PDF instead of structured, comparable data; flagged items losing their evidence because photos and measurements weren't attached to the project record; submitted files not becoming tracked aging items; and files closing at production instead of at financial reconciliation. Tight handoffs with mediocre tools beat best-in-class tools that don't talk to each other.