Program · 2026-05-09 → ongoing

Account Enhancement

Umbrella program for Practice-Account data improvements requested by sales. Each child plan addresses a specific data gap; together they make the practice list usable for the 90-day call cadence.

Active — 2 children Owner: Kyle Requestor: Tyler (Sales)

§1Why this program exists

Sales operates off Practice-level Account records. The signal quality on those records is uneven — rollup-from-Prescriber-Contacts data has never been surfaced cleanly, secondary office locations are missing for many providers, and most practices have additional NPs / MDs / PAs we don't have in our CRM at all. Each gap costs sales touches. This program closes them.

§2Child plans

Two children today. Each has its own README + visualization. Click into either for the full plan.

Build-ready
elite-prescriber-rollup/
Elite-Prescriber Rollup
DLRS Realtime count rollup of Contact.Prescriber_Tier__c = '⭐ ENT Elite ⭐' Prescriber Contacts up to parent Practice Account. Adds two Account fields. ~1,245 Practices flip to TRUE on day 1.
Effort: <1 hour
Cost: $0
Awaiting: Tyler confirm + Sarah review
Draft
practice-data-enrichment/
Practice Data Enrichment
One-time scrape of the 1,245 Elite-flagged practice websites for missing prescribers and secondary office locations. Playwright + Claude Haiku Batch API extracts; Python validator splits rows into auto-import vs human-review so most rows skip per-row review.
Effort: ~2 days
Cost: ~$50
Awaiting: Rollup ship + Sarah review

§3How the children relate

The rollup produces the set of practices in scope. The enrichment finds the gaps in our CRM data about that set — missing prescribers, missing secondary locations. The enrichment plan is downstream — can't run before the rollup defines who's in the list.

Child 1
Elite-Prescriber Rollup
~1,245 Practices flagged
Has_ENT_Elite_Prescriber__c = TRUE
→
Child 2
Practice Data Enrichment
Extract + Python validator →
auto_import.csv + human_review.csv

§4Cross-cutting principles

Apply to every child in this program. New children added later inherit unless they explicitly override and document why.

Declarative-first
No Apex unless the declarative path is genuinely insufficient. The rollup uses DLRS; enrichment runs outside Salesforce entirely.
Validator-as-reviewer
A Python validation layer is the first reviewer — confidence thresholds, NPI Luhn checks, fuzzy matching against existing Salesforce records, credential allowlists. Most rows clear the validator and skip per-row human review.
No direct API writes in v1
Validator output is a CSV, not a Composite-API push. Admin runs Data Loader manually. Direct API integration is straightforward but not worth the engineering until recurrence is in scope.
One-off bias
Sales' immediate ask is point-in-time improvement. Do not build quarterly/automated infrastructure until v1 proves the data is worth refreshing.
Tyler owns scope
When a question is "do we want the broader version or the simpler version," Tyler (sales) decides. Kyle (tech) builds.
Sarah owns prod-deploy
When a change is ready to ship to production Salesforce, Sarah's team owns the promotion. Kyle builds in Full Sandbox; Sarah promotes.
PDFs preserved as receipts
Deep-research artifacts that informed any child plan are committed under that child's research/ folder. The plan summarizes; the PDF preserves the reasoning chain.

§5Deferred future direction

Real possibilities that should not be built now. Documented so they're not forgotten when sales decides quarterly recurrence is worth it.