--- title: Account Enhancement (program) last_verified: 2026-05-11 verification_type: eyeball verification_ttl_days: 30 status: active --- # Account Enhancement — program overview > **What this is:** an umbrella program for making Practice-RT Account records more useful to sales. Started 2026-05-09 from a single ask (flag practices with Elite prescribers) and expanded as Kyle + Tyler scoped a follow-on website-scrape pass that fills the prescriber + secondary-location gaps Tyler raised in the same thread. > > **Owner:** Kyle. **Requestor for v1:** Tyler Adcock (Sales). ## Why this program exists Sales operates off Practice-level Account records. Two specific signal-quality gaps are worth closing this quarter: - **No practice-level Elite flag.** Sales currently can't filter their call list to "practices that anchor at least one ENT Elite prescriber" without manually checking every Contact. The rollup plan adds that flag. - **Some prescribers are missing from CRM.** We already have many NPs / MDs / PAs at Elite-flagged practices — but not all. Some are recent additions to the practice; some are longstanding gaps. Sales has no way to discover what's missing short of manually browsing practice websites. The enrichment plan automates that gap-finding. This program closes both gaps with the smallest reasonable build for each. ## Child plans | Plan | Status | Owner | Summary | | -------------------------------------------------------- | ------------------------------------------ | ----- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`elite-prescriber-rollup/`](elite-prescriber-rollup/) | build-ready (pending Sarah review) | Kyle | DLRS Realtime count rollup of `Contact.Prescriber_Tier__c='⭐ ENT Elite ⭐'` Prescriber Contacts up to parent Practice Account. Adds `Account.ENT_Elite_Prescriber_Count__c` (Number) + `Has_ENT_Elite_Prescriber__c` (Formula Checkbox). Day-1 production: ~1,245 Practices flip to TRUE from ~2,073 Elite Prescribers. Declarative metadata only. | | [`practice-data-enrichment/`](practice-data-enrichment/) | draft (pending rollup ship + Sarah review) | Kyle | One-time website scrape of the 1,245 Elite-flagged practices to find missing prescribers and secondary office locations. Playwright + Claude Haiku Batch API extracts; **Python validator splits rows into auto-import vs human-review** so the bulk of the data goes straight to Data Loader without per-row human eyes. ~$50, ~2 days build. | ## How the children relate `elite-prescriber-rollup` produces the **set** of practices in scope. `practice-data-enrichment` finds the **gaps** in our CRM data about that set. The enrichment plan is downstream — it can't run before the rollup defines who's in the list. ``` elite-prescriber-rollup → 1,245 Practices flagged │ ▼ practice-data-enrichment → extract + validate │ ├─→ auto_import.csv → admin runs Data Loader (no review) └─→ human_review.csv → reviewer eyeballs ambiguous rows ``` ## Cross-cutting principles These apply to every child plan in this program. New children added later inherit unless they explicitly override and document why. 1. **Declarative-first.** No Apex unless the declarative path is genuinely insufficient. The Elite rollup uses DLRS; the enrichment pipeline runs outside Salesforce entirely. 2. **Validator-as-reviewer.** A Python validation layer is the first reviewer. It handles confidence thresholds, NPI Luhn checks, fuzzy matching against existing Salesforce records, and credential allowlists. Most rows clear the validator and route to a Data Loader–ready CSV — **no per-row human review for clean cases.** Humans only eyeball the ambiguous tail. 3. **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 adds engineering surface that isn't worth it until recurrence is in scope. 4. **One-off bias.** Sales' immediate ask is point-in-time data improvement. Do not build quarterly reconciliation infrastructure until v1 proves the data is worth refreshing. 5. **Tyler is the scope owner.** When a question is "do we want the broader version or the simpler version," Tyler (sales) decides. Kyle (tech) builds. 6. **Sarah is the prod-deploy path.** When a change is ready to ship to production Salesforce, Sarah's team owns the promotion. Kyle builds in Full Sandbox; Sarah promotes. ## Deferred / future direction (not v1) These are real possibilities that should NOT be built now. Documented so they're not forgotten when sales decides quarterly recurrence is worth it. - **Quarterly reconciliation pipeline** with autonomous Salesforce write-back. Comprehensive design in [`practice-data-enrichment/research/quarterly-reconciliation-architecture.pdf`](practice-data-enrichment/research/quarterly-reconciliation-architecture.pdf). Splink fuzzy matching, NPPES cross-validation, custom Salesforce review objects, Composite-API write-back with idempotency. Heavy engineering. Defer until v1 proves recurring value. - **Tier 2 enrichment** — EHR system detection, sub-specialty taxonomy, languages spoken, office-manager extraction, accreditations. Not requested. Don't build. - **AccountContactRelation completion** for multi-practice prescribers. The enrichment scrape will surface gaps in the locations output. Whether to backfill ACR records (vs. just flagging in the human-review CSV) is a separate scope question. - **Parent-practice (network) flag bubble-up.** 155 parent network Accounts anchor Elite-bearing children but have no direct Elite prescribers. Deferred per Tyler 2026-05-09 (Option A on Q4.1 of the rollup plan). ## How to add a new child plan 1. Create `docs/plans/account-enhancement//` (kebab-case). 2. Inside, create `plan.md` (canonical) and optionally `visualization.html` (visual companion — see the existing children for the convention). 3. Add a row to the **Child plans** table above. 4. The top-level [`docs/plans/README.md`](../README.md) inventory points at the program directory, not individual children — children inherit visibility from the program row. 5. Cross-link the child's `plan.md` back here. ## Cross-references - Top-level inventory: [`docs/plans/README.md`](../README.md). - Operating rules for planning docs: `CLAUDE.md` → "Planning & project docs." - Tyler Adcock email thread, 2026-05-08 / 2026-05-11 (program origin).