LeadOps Autopilot: Sourcing and Scoring US Clinic Leads from Public Data

Most lead lists are bought, stale, and sprayed. Ours is none of the three — and the interesting part is not the scraping. It is everything the pipeline refuses to do.

LeadOps Autopilot is the outbound system we built at Botslave to find US clinics that plausibly need lead-intake and follow-up automation — dental practices, med spas, physical therapy, mental health, urgent care — and to prepare outreach that a human approves before anything is sent. This note documents how it actually works: where the data comes from, how a lead earns its score, and why the pipeline deliberately stops one step short of sending.

The problem with clinic lead data

Clinics are a hard segment to source well. Directory data is fragmented across official registries, map platforms and review sites, and it decays fast: practices move, rebrand, change booking systems. A purchased list tells you a clinic exists. It tells you nothing about whether that clinic has the operational shape your offer fits — a working website, an online booking path, signs of inbound volume, a contact channel a human actually reads.

So instead of buying conclusions, the pipeline collects raw public evidence and scores it. The score is a hypothesis with receipts: every lead carries up to eight recorded reasons, so a reviewer can see why the machine thinks this clinic fits before approving any contact.

Stage 1: Collect from sources that are allowed to be boring

Two collectors feed the pipeline, chosen for provenance rather than volume:

• CMS/NPPES. The US National Plan and Provider Enumeration System is the official registry of healthcare providers. collect_nppes.py pulls clinic organizations by state, city and taxonomy — slow, structured, and authoritative about existence.
• OpenStreetMap via the Overpass API. collect_osm_overpass.py discovers clinics geographically at zero data cost. Map data is uneven — excellent in some metros, thin in others — which is exactly why it is a discovery layer, not a source of truth.

An enrichment pass (enrich_websites_google_places.py) then resolves or confirms each clinic's website, because the website is where the scoring evidence lives. A clinic without a findable website is out of scope for this offer by definition — the README's avoid-list also excludes hospitals and large health systems, whose procurement cycles make them a poor fit, and anything that would require collecting patient health information. That last line is architectural, not decorative: the pipeline handles business contact data only.

Stage 2: Read the homepage, not the listing

The scorer (leadops.py) fetches each clinic's homepage and scores what it finds there. The model is intentionally simple enough to argue with:

• Every lead starts from a base score of 35 — existence is worth something, not much.
• Fit signals found on the site add points: evidence that the clinic takes its inbound flow seriously (or visibly struggles with it) moves the score up.
• Negative signals subtract (a flat −8 penalty in the current rules), and a homepage that cannot be fetched at all costs the lead 35 points — if we cannot see your front door, we do not get to pitch you a better one.
• Scores are clamped to 0–100 and mapped to fit tiers at 75, 58 and 45, so review batches sort themselves: work the top tier, sample the middle, ignore the rest.

Alongside the score, the pipeline generates a pain hypothesis from the recorded reasons — a one-line theory of what this clinic's intake problem probably is — and drafts outreach copy from it. The hypothesis is labeled as a hypothesis everywhere it appears. That discipline matters more than the model: a scorer that shows its reasons can be corrected; a black-box score just gets believed.

Segmentation runs in parallel (segments.py): dental, physical therapy and the other verticals each carry their own keyword rules, so batches, scoring context and copy stay separated by vertical instead of dissolving into one generic blast list.

Stage 3: The gate — where the pipeline stops on purpose

Here is the design decision people question most: the MVP stops before sending. Its output is a reviewed CSV — leads, scores, reasons, segments, draft messages — and a human approves the high-fit rows before any contact happens. Later stages exist in the codebase (CRM preparation, a sender pool, reply processing), but they sit behind that approval, not instead of it.

This is the same principle as how we work on client systems: automate the routine aggressively, and spend human judgment exactly where it changes the outcome. In outbound, the judgment step is "should this business hear from us at all?" Getting that wrong at scale is how domains get burned and studios get a reputation. The 60-second promise LeadOps makes to clinics — every inbound inquiry becomes a qualified record, an assigned owner and a follow-up task within 60 seconds — only works as a pitch if our own outbound shows the same discipline we are selling.

What this architecture buys you

• Provenance per lead. Source, score, reasons and segment travel with the record into the CRM, so six months later you can still answer "why did we contact them?"
• Cheap iteration. Scoring rules are plain keyword-and-signal logic in one file. When a vertical underperforms, you read the reasons on the rejected leads and adjust the rule — no model retraining, no vendor ticket.
• Compliance by construction. Public business data only, no patient information anywhere in the pipeline, human approval before contact. The constraints were chosen at design time, when they are cheap.
• Failure is visible. An unscored or unreachable lead is a row with a low score and a reason, not a silent gap in a purchased spreadsheet.

Where it goes next

The honest limits: OpenStreetMap coverage varies by city, homepage signals are a proxy for operational pain (a beautiful site can hide a chaotic front desk), and a human gate caps throughput by design. We accept all three. The next build-notes entries in this series go deeper on the scoring model itself and on what the approval gate has caught that automation would have sent.

If you run a clinic group — or any business whose inbound inquiries leak between the website and the follow-up — this is the class of system we build. See what we build, or read the companion piece on validating email addresses without sending mail, which covers the verification layer that contact data passes through before it is trusted.

Frequently asked questions

Why not just buy a clinic list?
Because the list answers the wrong question. Existence is cheap; fit is the scarce signal, and fit lives on the clinic's own website, not in the directory row.

Is OpenStreetMap data reliable enough for this?
As a discovery layer, yes — with an authoritative registry (NPPES) alongside it and a scoring stage that penalizes what it cannot verify. No single source is trusted alone.

Does the system send the outreach itself?
The pipeline prepares scored leads and draft messages; a human approves before contact. Sending mechanics exist behind that gate, by design.

What data does it collect?
Public business information: practice names, websites, published contact points, and the evidence used for scoring. No patient health information is collected or processed.

References

• NPPES (National Plan and Provider Enumeration System): https://nppes.cms.hhs.gov
• OpenStreetMap Overpass API: https://overpass-api.de
• Google Places API: https://developers.google.com/maps/documentation/places/web-service
• Botslave — How we work: https://botslave.com/how-we-work
• Botslave — Services: https://botslave.com/services

Originally published on botslave.com. Botslave is an automation studio — see what we build and how we work.