Roofing Lead Scoring Model: Roof Age, Storm Exposure, And Ownership Signals

A roofing lead scoring model should rank which properties deserve review first. It should not decide that a roof is damaged, prove a roof is old, predict insurance coverage, or decide whether a homeowner may be contacted. The useful version is a scorecard template: weights, caps, reason codes, contact checks, sample records, and audit rules a manager can explain.

Model In One Page

Use this as the first-pass template before adding local weights:

Example output:

That is the lane for this page. A broad source-stack comparison belongs in the property-data source guide. A detailed permit-record workflow belongs in the permit-history page. This model page owns the scorecard mechanics.

Use roof age, storm exposure, and ownership or relationship signals as scoring modules. Then add caps and hold gates. A high score can move a property to manager review, route planning, or follow-up assignment. It cannot turn a preliminary storm report into a damage finding. It cannot turn a public property record into permission to call or text. It cannot turn a missing permit into proof that a roof was never replaced.

The sources need visible limits. The NOAA Storm Events Database can support historical storm context. SPC storm reports are useful for current and recent severe weather, but SPC labels current reports preliminary. NOAA's NSSL hail basics explains why hail size and hail swaths matter, but it does not diagnose one roof. The Census Building Permits Survey supports aggregate construction permit context, not parcel-level roof history. Local building-data tools, such as NYC DOB building data, can be more specific, but they still require local interpretation.

The practical goal is a score that a manager can explain in one minute: why this property is in the route, which sources were used, what is still uncertain, which outreach channels are released, and which reviewer owns the next step.

This guide is an operating model for roofing teams. It is not legal advice, privacy advice, insurance advice, or approval to use a data source for outreach. A company should have qualified compliance review before it launches a scored campaign, especially if the workflow uses purchased data, consumer-report-derived fields, calls, texts, email, door-to-door canvassing, or storm-event language.

Use the model alongside deeper workflow resources, not as a stand-alone sales script. The scoring side pairs naturally with property data source limits, permit-history scoring limits, storm documentation boundaries, inspection-report review, and estimate review workflows. Those pages answer different parts of the same operating question: what can the team know, what can it say, and what should happen next?

Roofing Lead Scoring Architecture

Build the scoring model in layers, not as one blended number. A single blended score hides the most important question: is the property actually ready for action, or did it only look promising in a data table?

Use this architecture:

This structure prevents a common mistake: giving a property a high score and immediately pushing it into a campaign. Property interest is not contact permission. A property can be a strong review candidate and still be blocked from call, text, email, or door-to-door outreach. Another property may have a lower data score but deserve faster action because the owner requested help.

The model should also record the reason code behind the score. "Roof age source: local permit record" is stronger than "roof old." "Storm exposure source: SPC preliminary report" is different from "storm exposure source: NOAA historical event record." "Relationship source: inbound form request" is different from "ownership signal: public mailing address mismatch." The score is useful only when the reason is visible.

Avoid black-box scoring for field teams. Reps need a plain explanation of what they can say. Managers need to know which records should be suppressed. Compliance reviewers need to know which fields drove routing. A simple score with clear reason codes is usually safer than a complicated score that nobody can defend.

Signal Reliability Ladder

Every signal needs a trust tier. The same fact can deserve different weight depending on where it came from.

The CFPB FCRA advisory opinion is a clear warning for consumer-report data: users need a permissible purpose, and disclaimers do not repair the absence of one. The FTC's Big Data report is also a useful reminder that data-driven decisions can create consumer-protection, privacy, credit reporting, data security, and exclusion risks. A roofing scorecard should not quietly import sensitive fields just because a vendor offers them.

The ladder should be visible in the model. Do not let a vendor-inferred field outrank a direct customer request. Do not let a preliminary storm report outrank a completed inspection note. Do not let missing permit data outrank a documented recent replacement. If two fields conflict, the model should send the property to review instead of averaging the conflict into a confident score.

100-Point Example Scorecard

The model below is an illustrative starting point, not a validated universal formula. Adjust weights only after roofing operations, privacy, marketing, and legal review. Keep the structure: modules, caps, gates, and reason codes.

Example: A prior customer with a 17-year-old documented roof in the company CRM, recent NOAA storm context, and an inbound request may score 86 and move toward an appointment workflow only through a cleared contact channel. A property with no recent permit found, a vendor-inferred roof age, and an SPC preliminary report might score 62 but stay in manager review. A property with a high score but unclear phone consent should stay out of call and text workflows. A property that includes a credit-derived field should be held even if every other signal looks useful.

Use score bands:

The score band should never rewrite the evidence. A 90 from weak sources is not stronger than a 72 from direct sources. That is why the source quality label should sit beside the score in every list.

Field Dictionary: Use, Cap, Hold, Or Exclude

The fastest way to keep the score honest is to decide how every field is allowed to behave before it enters the model. Do not wait until a route list is ready to ask whether a field was appropriate.

A field can be useful and still be held. For example, a vendor append might help clean addresses, but if the same file includes consumer-report-derived fields, the record should stop until the restricted data is removed or reviewed. A storm report might help route a field team, but it still cannot become a damage claim. A mailing-address mismatch might route an account to a property-manager workflow, but it should not become a pressure signal.

Hard Caps And Hold Gates

Caps keep weak signals from creating false confidence. Hold gates keep risky records from entering the field before review. Use both.

A cap is different from a hold. A cap says, "This record can stay in the model, but weak evidence limits its priority." A hold says, "This record cannot move to the next workflow until a person resolves the issue." Do not turn every concern into a cap. Some concerns are hard stops.

The model should also use conflict rules. If one source says the roof was replaced two years ago and another says the roof age is unknown, the model should not split the difference. It should keep the recent replacement signal, flag the conflict, and route the record to manager review or suppression. If a modeled hail swath overlaps a property but the homeowner recently requested service for a non-storm leak, the workflow should separate storm outreach from service follow-up.

Use caps to control the top of the route list. The highest tier should require at least one strong property signal plus either relationship context or strong source confidence. A property should not reach the top tier from a storm report alone, a missing permit alone, or a vendor append alone. That rule makes the model less noisy and easier to explain.

Score Calibration Board Before Scaling

A scorecard should not move from spreadsheet to daily route until the team calibrates it against real operating examples. Calibration is the step that asks whether the model behaves the way a responsible roofing manager would behave. It is where overconfident weights, hidden weak sources, and field-team confusion show up before they become customer conversations.

Build a calibration board with at least five buckets:

Start with fifty records, not thousands. Score them manually, then score them through the model. For each record, write the expected band before looking at the model output. If a manager expects a record to be weak and the model scores it high, the weight is too aggressive or a cap is missing. If a manager expects a prior customer with direct context to rank high and the model buries it, the relationship weight may be too low.

Do not calibrate only against appointments. Appointment rate matters, but it can reward aggressive channel use and weak scripts if it is the only metric. A better calibration board includes appointment rate, correction rate, opt-out rate, complaint rate, invalid-address rate, field-note quality, and manager override rate. A source that creates many appointments and many corrections may need tighter language or better filtering. A source that creates fewer appointments but cleaner records may deserve more weight for high-trust campaigns.

Use a written calibration decision:

Keep calibration changes versioned. A manager should be able to see that version 1.2 lowered preliminary storm-only caps, version 1.3 separated property-manager workflow from priority score, and version 1.4 added a stricter missing-permit cap. Without version notes, the team cannot tell whether improvement came from better scoring or from a lucky week.

Worked Examples

Examples expose whether the model is behaving like a real operating tool.

Example 1: prior customer with direct roof history and recent storm context. The company replaced a roof 16 years ago, the customer is still in the CRM, and NOAA historical storm context shows a recent severe weather event in the service area. The property is inside the current route, and the customer has not opted out. This lead can receive a high property score because the roof age source is direct and the relationship is known. The next action may be a service check-in or appointment offer, depending on contact-channel release. The script should not say the storm damaged the roof. It can say the company is checking on prior customers after severe weather.

Example 2: preliminary storm report with no relationship. SPC shows preliminary hail reports near a neighborhood. No company history exists, roof age is unknown, and the only ownership signal is a public record. This lead can enter storm triage, but it should be capped. It may be useful for manager review, but door hangers, door knocks, email, ads, calls, texts, and mail all stay held until channel, suppression, script, and local solicitation gates clear. The reason code should say preliminary storm context, not damage.

Example 3: missing permit in one local source. A local data feed has no recent roof permit for a property. The property is in a target service area, but there is no owner request, no company history, and no storm context. This record deserves low to moderate priority only. The external message should not mention the missing permit. A safe internal reason code is no recent documented roof permit in checked source. If the model gives this record a top score, the missing-permit weight is too high.

Example 4: ownership routing without sensitive targeting. A property appears to be owned by an entity with a mailing address different from the site address. That can matter operationally because the team may need a property-manager workflow or mail channel rather than door knocking. It should not become a personal vulnerability score. The model can route it to portfolio review while holding call/text release until the contact source and permission are clear.

Example 5: high data score with a compliance hold. A lead has an older roof-age signal, storm context, and route density. The vendor file also includes credit-derived or consumer-report-derived fields. The property score may look strong, but the compliance gate should block it. Quarantine the risky fields outside the scoring workflow and do not route from them unless counsel documents a separate lawful process and a specific FCRA permissible purpose before any outreach.

These examples are the fastest way to test the model with managers. If the next action is obvious, the model is useful. If the team argues about what a score means, add reason codes, caps, or holds until the workflow is readable.

Roof Age Module

Roof age is one of the most useful signals for roofing lead scoring, but it is also easy to overstate. A roof can be old and still serviceable. A roof can be newer and still have storm damage or installation issues. A permit can describe work that is not a full replacement. A missing permit can mean the record was not checked, the work was not required to be permitted, the jurisdiction stored it elsewhere, the work was miscoded, or the roof was replaced before the searchable period.

Use roof age as a review signal, not a conclusion.

Model-level roof age inputs:

• company job history: replacement year, repair year, inspection date, estimate date, warranty record;
• owner-supplied records: invoice, listing packet, disclosure, inspection report, warranty registration;
• local permit/AHJ records: roof permit, re-roof permit, tear-off, overlay, repair, finaled status, expired status;
• building-data tools: permit/job/filing status, complaints, violations, related exterior work;
• aggregate context: Census BPS for market construction activity, not address-level history;
• vendor field: roof age estimate, property age, remodel year, material guess, confidence level.

Model-level roof age reason codes:

Do not make the model reward ignorance. Unknown roof age is not the same as old roof age. Missing permit history is not the same as old roof history. If a property has unknown roof age and no other strong signal, it should receive a small review value, not a top score.

For markets with strong local permit systems, the roof age module can carry more weight. For markets with incomplete or hard-to-interpret permit records, lower the weight and use company history, owner-supplied records, and inspection opportunities instead.

Keep permit detail out of this page. If the scoring dispute turns on permit scope, status, missing records, or how to talk about a public record, move the record to the permit-history workflow instead of adding more permit logic to the scorecard.

Storm Exposure Module

Storm exposure is a strong routing signal because timing matters. After hail or wind events, roofers need to decide where to send field teams, which existing customers to check on, and which neighborhoods deserve service capacity. But storm exposure is not damage proof.

Use three storm source levels:

A practical storm score can include recency, event type, proximity, source strength, and relationship context. For example:

• 0-8 points for event recency;
• 0-8 points for event severity context;
• 0-5 points for proximity or route overlap;
• 0-4 points for source quality and date label.

Apply caps. A lead based only on an SPC preliminary report should not score as high as a lead with a prior customer relationship and a documented inspection request. A lead based only on a vendor storm path should not outrank a lead with owner-supplied photos and an appointment request. If the source says hail was reported nearby, the reason code should say "storm context near property," not "hail damage."

Use safe storm language:

The storm module should be the most carefully worded part of the model because it is tempting to turn weather context into a sales conclusion. Do not do that. The score can say where to look first. The roof, customer, inspection, and documentation decide what is real.

Ownership And Relationship Module

Ownership signals can help assign the right workflow. They should not become a way to target people by sensitive characteristics. Keep the module focused on operational relationship, account handling, and routing.

Useful ownership or relationship signals:

• prior customer;
• inbound request;
• open estimate;
• warranty or service account;
• property manager or portfolio owner;
• builder, HOA, multifamily, commercial owner, or entity owner workflow;
• mailing address different from site address, used only to route owner-contact workflow;
• known opt-out or do-not-contact state;
• appointment preference or channel preference supplied by the customer.

Risky or rejected ownership signals:

• homeowner age;
• household composition;
• income;
• credit attributes;
• health or disability;
• language or ethnicity;
• protected-class proxies;
• purchase of consumer reports without permissible purpose;
• data bought from vendors with unclear acquisition or use terms;
• inferred distress, vulnerability, or financial pressure.

The ownership module should answer operational questions:

• Is this a customer we already serve?
• Is there an inbound request?
• Is this property managed by a portfolio owner or HOA?
• Is the owner mailing/contact record different from the site record, requiring a different mailing or scheduling workflow?
• Has the property opted out?
• Is the record held because ownership data is uncertain?

It should not answer personal questions about the homeowner. Do not infer occupancy, vacancy, absence, distress, vulnerability, ability to pay, likelihood to buy, or pressure susceptibility from ownership or mailing data. Those fields create privacy, fairness, consumer-protection, and brand risk.

Give the ownership module modest weight. Prior customer and inbound request can carry real operational value. Mailing-address mismatch, entity ownership, or property-manager workflow should route the lead differently, not necessarily make it hotter. If the signal mainly changes who to contact or how to schedule, it belongs in workflow routing rather than the priority score.

Contact And Compliance Gates

The model should have gates that cannot be bypassed by a high score.

The FTC advertising FAQ supports truth and substantiation controls for marketing claims. The FTC CAN-SPAM guide supports a separate email release review. The FTC Telemarketing Sales Rule guide and the FCC unwanted robocalls and texts guide support stronger call and text caution. The FTC Cooling-Off Rule page is a useful boundary when door-to-door contact can lead to covered in-home sales, contracts, deposits, or cancellation notices. These sources do not replace legal review, but they make one thing clear: a high property score is not a channel release.

Before any scored record leaves manager review, create a release packet. It does not need to be complicated, but it needs to be explicit.

Safe script language should track the source:

Export Packet And Field-Minimization Rules

The scoring table should contain more information than a route export. The route export should contain only what the next owner needs to do the approved task. This matters because raw scoring records often include source notes, rejected fields, internal confidence labels, and private documents that should not travel into every tool.

Create one export packet for each approved channel:

The export packet should include a message_version and expires_at value. A route list without those fields is too easy to reuse after the original review is stale. If the source changes, a storm window closes, local rules change, or a suppression update arrives, the export should expire.

Field minimization also improves writing quality. The rep does not need a database argument at the door. The rep needs a useful reason for the conversation and a respectful way to offer help. The manager does not need twenty vendor columns if three source labels explain the priority. A smaller export makes it less likely that a cautious internal reason becomes a hard customer-facing claim.

RoofPredict should preserve the full audit record in the controlled workflow while allowing narrow task packets for each owner. That lets the company keep evidence without turning every field into sales copy.

RoofPredict Implementation

RoofPredict can be used as the workflow layer around this model. The product value is not that it makes legal or weather decisions. The value is that teams can organize ranked lists, route work, customer context, CRM follow-up, reports, notes, and review status in one operational system. If a team wants custom fields such as source labels, reason codes, or hold categories, those fields should be configured and reviewed before the workflow is used in production.

Example RoofPredict workflow fields:

The record should show why a score changed. If a property moves from 54 to 82, the manager should see the new source: inbound request, verified permit, NOAA event, inspection photo, prior customer record, or corrected address. If a property moves from 82 to 20, the manager should see the reason: recent replacement, opt-out, invalid address, outside service area, unsafe route, or bad source.

Add review queues:

• weather_review: storm source unclear, preliminary only, or date/geography mismatch;
• permit_review: ambiguous scope, no local source, old feed, unmatched parcel;
• privacy_review: sensitive field, consumer-report issue, vendor acquisition unclear;
• marketing_review: script says damage, coverage, urgency, free roof, or permit conclusion;
• operations_review: outside service area, route capacity issue, special account;
• suppress: opt-out, do-not-contact, bad address, recent completed roof, duplicate.

The model should also have an audit view. Managers should be able to sort by high scores with low source confidence, released records with no channel evidence, storm-only high scores, permit-only high scores, and ownership signals that created a hold. Those are the records that create risk.

In RoofPredict, the most useful view is a ranked list with visible brakes. A manager should be able to filter:

• high score plus low source confidence;
• high score plus no released channel;
• storm-only records above the cap;
• missing-permit records above the cap;
• vendor-inferred records without vendor/date/confidence fields;
• records released to sales without a script lane;
• records with opt-out, suppression, or recent-work conflicts;
• records that changed score after a manual override.

Those filters make the score auditable. They also make the model easier to improve. If the same field keeps creating holds, complaints, or bad appointments, the field needs lower weight, stricter caps, better source labels, or removal.

Manager Override Ledger

Manager overrides are useful when they explain local context. They become dangerous when they silently defeat caps, holds, or suppressions. Treat every override as a ledger entry, not a casual note.

Two rules keep overrides sane. First, an override can change priority, but it should not clear restricted-data, contact-channel, privacy, solicitation, or script holds by itself. Second, an override should not erase the original source reason. If a manager raises a score because a neighborhood route is efficient, the record should still show whether the roof-age source was direct, inferred, missing, or unclear.

Audit overrides separately. High override rates usually mean the model is misweighted, the route goal is pressuring managers, or the source map is not detailed enough. If many managers raise storm-only leads above the cap, the storm module needs review. If managers repeatedly suppress leads after field visits, the scoring model is probably overvaluing a weak source. If overrides clear holds without evidence, the process needs a stricter product control.

Use override notes to improve content and operations. If managers keep writing the same explanation, turn it into a reason code. If reps keep asking the same question, add it to the review packet. If homeowners keep correcting the same source, lower that source weight or add a manual review rule.

Suppression Rules And Audit Sampling

Suppression is part of the model, not an afterthought. A lead score that only creates positive priority will drift toward over-contacting the wrong records. The system needs clear reasons to remove, pause, or reroute a property before a campaign begins.

Use suppression rules for:

Audit sampling should be boring and repeatable. Each month, pull a small set from each important bucket: top scores, mid scores, suppressed records, held records, manual overrides, storm-only leads, permit-only leads, vendor-inferred leads, and prior-customer leads. For each sample, answer the same questions:

• Is the source visible and current?
• Is the reason code understandable to a manager?
• Did a cap apply when it should have applied?
• Did the record move to a channel before release evidence existed?
• Did the script match the source family?
• Did the field result justify the score?
• Did a complaint, opt-out, bad appointment, or wasted route trace back to a specific field?

Do not let the audit become a search for success stories. The best audit finds weak records before customers do. If a model regularly produces high scores that a manager cannot explain, lower the weights and improve the reason codes. If a suppression rule removes too many good records, tighten the rule rather than bypassing it. If a vendor field creates repeated confusion, either verify it with a stronger source or remove it from scoring.

QA And Drift Review

Lead scoring decays when nobody checks outcomes. A score that worked in one hail season may be wrong in another market or after a data vendor changes fields. Treat the model as an operating system that needs review.

Track these outcomes:

• appointment rate by score band;
• inspection finding rate by score band;
• false positive rate for storm-only leads;
• false positive rate for permit-only leads;
• customer complaint rate by source;
• opt-out rate by channel;
• invalid address rate;
• recent-roof suppression rate;
• records held by compliance category;
• manual corrections by manager.

Run a monthly review during normal seasons and a weekly review during storm response. Pull ten high-scoring leads from each source family. Ask:

• Can a manager explain the score from visible sources?
• Did the score rely on unsupported roof age, storm, or ownership inference?
• Did any contact happen before the channel was released?
• Did any script overstate damage, permit history, coverage, or urgency?
• Were opt-outs and suppressions honored?
• Did field outcomes support the weight assigned to each module?
• Which fields created complaints, bad appointments, or wasted routes?

Then adjust weights. If permit-only leads rarely produce useful appointments, lower the missing-permit factor or raise the source-quality cap. If prior customers with recent storm context produce strong service calls, increase the relationship weight. If preliminary storm reports create too many false positives, lower the storm cap until final or better source context is available. If ownership signals trigger privacy review too often, remove the field or narrow its use to workflow routing.

30-Day Model Improvement Loop

A good scoring model should create a short learning loop. Do not wait a year to discover that the score is rewarding the wrong records. Use a thirty-day cycle that combines field outcomes, source quality, suppression data, and manager review.

The loop should produce a one-page model change memo:

This makes the model feel less like a magic score and more like an operating decision. It also gives future writers and product builders something real to reference: not "we use advanced data," but "we label source strength, cap weak evidence, review corrections, and change the model when outcomes show a problem."

Source-To-Script Release Board

A lead score is not ready for the field until the script matches the source. The release board is the bridge between model output and what a salesperson, appointment setter, mail piece, or customer-support person may say.

Use one board for every campaign:

The board should show status, not only source. A script can be released for mail but held for calls. A prior-customer check-in can be released while a storm-damage sentence stays blocked. A route can be approved for manager review and still held from sales export. Each release should have a reviewer, date, message version, channel, and expiration.

The best operating rule is simple: if the script says more than the source supports, the script is wrong. If the source is broad, the script must be broad. If the source is preliminary, the script must say context or review, not conclusion. If the source is a relationship record, the script should explain the relationship instead of hiding behind a score.

RoofPredict can make the board visible beside the ranked list. A rep should not need to remember which source family allowed which phrase. The approved phrase, blocked phrase, review owner, channel state, and reason code should travel with the lead.

Route Review Meeting Agenda

Before a scored list becomes a route, hold a short route review meeting. The meeting should be operational, not theatrical. The goal is to decide which records move, which records stay held, which records are suppressed, and which rules need repair.

Use this agenda:

The meeting should produce a short route decision:

This meeting prevents the model from being treated as a vending machine for leads. A score is a recommendation for review. A route is an operating decision with service capacity, customer trust, contact rules, and script accountability attached.

Model Versioning And Evidence Pack

Every scoring model needs version history. If the company cannot tell which weights, caps, sources, and scripts created a route, it cannot audit the result later.

Save a versioned evidence pack:

The evidence pack should be small enough to review and complete enough to reconstruct the decision. A route exported on June 10 should point back to the exact model version used on June 10, not a model that was changed later. If a homeowner corrects a record, the team should know whether that source came from company history, local permit review, vendor inference, or manual override.

Versioning is also useful for content quality. It turns broad product language into real operating proof. Instead of saying the system "uses signals," the product can say it stores source labels, caps weak evidence, records holds, version-controls scripts, and preserves change memos. That claim is narrower and more defensible.

Bad Record Examples

The model should be tested against records that should fail. Good examples show how the score works. Bad examples show whether the system has brakes.

These examples should be used in training and QA. If a bad record reaches export, the model is not ready. Fix the cap, hold, field dictionary, script board, or reviewer workflow before adding more records.

Source Limits

Lead Scoring Review Checklist

Use this checklist before a score is released to sales.

FAQ

Does a high roofing lead score prove damage?

No. A high score means the property deserves review sooner. Damage requires safe observation, documentation, qualified inspection, and customer context. Insurance coverage and claim questions belong outside the score.

How should weights change by market?

Change weights based on source quality and operating reality. If a market has strong permit records, roof age can carry more weight. If permit records are weak, lower that module. If storm response is the business priority, storm context can carry more weight, but preliminary or modeled signals still need caps.

Should ownership signals be used?

Use relationship and workflow signals carefully: prior customer, inbound request, property manager workflow, account type, opt-out, or channel preference. Do not use homeowner age, household makeup, health, language, ethnicity, income, credit, or sensitive proxies for ordinary roofing sales scoring.

Can the model feed ads, email, calls, texts, or door knocking?

Only after contact checks. The property score can select records for review. Channel rules, consent, opt-out, DNC, state/local rules, platform rules, and script review decide where the record can go next.

How often should the model be audited?

Review monthly in normal operations and weekly during active storm response. Audit high scores, held records, suppressions, complaints, opt-outs, false positives, and field outcomes. The weights should change when the evidence changes.

What should be in a roofing lead score output?

A useful output should show score, score band, reason codes, source labels, source dates, confidence, caps applied, holds, suppression state, contact-channel state, next owner, and next action. If a manager cannot explain the score from visible fields, the output is not ready for sales use.

Can a manager override the score?

Yes, but the override should be logged with reason, evidence, old score, new score, reviewer, date, expiration, and remaining holds. A manager override can adjust priority or routing, but it should not silently clear privacy, restricted-data, script, or contact-channel holds.

What is the difference between a cap and a hold?

A cap limits how high weak evidence can score. A hold stops the record from moving forward until a reviewer resolves a risk or data-quality problem. Missing permit history might be capped. Credit-derived data, unclear consent, or an unapproved call channel should trigger a hold.

Should storm exposure and roof age be combined?

They can be combined for prioritization when each source is labeled and capped correctly. The combined score still cannot prove damage, replacement need, insurance coverage, or permission to contact the homeowner.

What should be removed before exporting a route?

Remove fields that the next owner does not need: rejected vendor columns, restricted data, private owner documents, raw source notes unrelated to the approved task, and unapproved claims. Export only the fields needed for the approved channel and message version.

How do you know the model is getting better?

Track appointment quality, correction rate, opt-out rate, complaint rate, invalid-address rate, recent-roof suppression rate, field outcomes by source, and manager override rate. Improvement means cleaner source explanations and better outcomes without higher complaint or correction risk.

How should RoofPredict be described in this workflow?

RoofPredict should be described as the workflow system for ranked lists, source labels, holds, routes, notes, follow-up states, and review history. It should not be described as proving roof damage, verifying permits, clearing legal compliance, or approving a contact channel.

What is a source-to-script release board?

It maps each source family to the wording a team may use, the wording that must be blocked, the approved channel, the reviewer, and the expiration date. It keeps a score from becoming an unsupported sales claim.

What should happen before exporting a scored route?

Managers should review top scores, caps, holds, suppressions, channel release, script version, service capacity, and feedback plan. A route should not leave review just because the properties have high scores.

Why does model versioning matter?

Versioning shows which weights, caps, source maps, field rules, scripts, suppressions, and reviewers created a route. Without version history, the team cannot audit corrections, complaints, overrides, or field outcomes later.

Should bad records be part of model testing?

Yes. Test opt-outs, missing source URLs, vendor fields without dates, broad storm context, recent replacements, restricted-data contamination, and scripts that overclaim. A model is not ready if bad records pass into export.

Final Note

A useful roofing lead scoring model is not the one with the most data. It is the one that points the team toward better work while staying honest about what the sources prove. Score the property, label the source, cap the weak signals, hold the risky fields, and release outreach only when the channel is actually ready.