US behavioral health provider
Lead intake and patient financial estimates on Health Cloud
Cut inbound lead noise ~50%, and automated the up-front cost estimate patients receive at admission.
- Period
- November 2024 – present
- Role
- Salesforce developer — requirements, solution design, build
~50%
reduction in inbound lead noise
~74
benefit fields in the verification matrix
24 h
default infill turnaround, configurable
Context
A US behavioral health provider running on Health Cloud. I have owned requirement gathering, solution design and delivery through direct client conversation since November 2024. Two pieces are worth writing up.
Problem
First, inbound leads. Calls arrived through a call-tracking platform, and what landed in Salesforce was noisy — repeat callers, wrong numbers and non-leads mixed in with genuine enquiries. Reps also found out about a new lead whenever they next refreshed a list view, which is not when the lead is worth calling back.
Second, and harder: patients are given an estimate of what treatment will cost them before admission. Producing that number by hand is slow, inconsistent between staff, and easy to get wrong, because it depends on the patient's live insurance benefits and on a fee schedule that varies by payer and level of care.
What I built — lead intake
Lead generation is part of the business's core flow, and there was no packaged connector that fit, so this was a complete system rather than a field mapping: a custom integration built to be secure, idempotent, observable, and extendable by the business without a developer.
Custom webhook integration
An Apex REST endpoint receives call-tracking events and creates the Lead and follow-up Task in Salesforce, with every request checked against a signature before anything is written.
Spam filtering
Filtering logic that separates genuine enquiries from repeat callers, wrong numbers and non-leads before they ever reach a rep. Noise dropped roughly 50%.
Idempotency
Repeated or retried events for the same call resolve to the same record, so a retry from the provider never produces a duplicate lead.
Monitoring
Every inbound event is logged with its outcome, so failures are visible and reproducible instead of silently dropped.
Scales to new business units without code
Per-business-unit configuration — tracking numbers, credentials and lead routing — lives in custom metadata. Onboarding another unit is a configuration change, not a release.
Real-time notification
Platform Events feed a subscribed Lightning component and email alerts, so a rep knows a qualified lead exists immediately rather than at the next list refresh.
Deployment and rollback plan
Shipped with a validated deployment manifest, a written go-live runbook and a rollback plan — the release was rehearsed, not improvised.
What I built — the estimate system
Insurance verification intake
Benefit data arrives from a clearinghouse by API. A configurable matrix of roughly 74 fields records which values are reliably available from the API and which are not.
Infill queue
Any field marked required but missing routes the record to a manual infill queue assigned to named users, with a configurable turnaround — 24 hours by default.
Estimate engine
Total charges are computed across levels of care from a fee schedule keyed by payer and revenue code. Patient responsibility applies the remaining deductible, then coinsurance on the balance, capped at the remaining out-of-pocket maximum with any overage credited back, plus copay. An approved hardship discount is deducted and the result splits into monthly instalments.
Ranges, not false precision
The estimate is expressed as a range driven by expected length of stay, plus or minus a configurable number of days.
Approval and audit
Hardship and financial-assistance discounts route to approvers by email. The audit trail captures amount, original amount, approver, result and timestamp, and edit rights are separated from override rights by role.
Versioned distribution
Estimates are versioned — a re-issued estimate explicitly supersedes the earlier one — and delivery status is tracked, so there is never ambiguity about which number a patient was actually given.
Configuration over code
Fee schedules, expected length of stay per level of care, the day range and the required-field flags are all admin-editable. The business changes numbers without a developer.
Constraints and trade-offs
The clearinghouse API does not cover everything. Out-of-network benefits and carve-out limits in particular are frequently absent or unreliable.
The system could have inferred those values and produced a clean, fully automated number. It does not. Anything required and missing goes to a human with a deadline attached, because a confidently wrong cost estimate given to a patient at admission is a far worse failure than a slower one. Routing beats guessing — the infill queue exists precisely because the automation knows what it does not know.
The same instinct drove configuration over code: the numbers in this domain change on the business's schedule, not on a release schedule.
Outcome
Lead noise down roughly 50% with reps notified in real time, and the admission-time estimate produced consistently from live benefit data with an explicit audit trail behind every discount.
Alongside these, I build the wider behavioral health workflows with Apex, Flow and async processing (Queueable and Batch) for the calculation-heavy paths.
Stack
Salesforce Health CloudApex (Queueable, Batch)FlowLightning Web ComponentsREST API integrationCustom metadata & settingsApproval routing
Want the parts I can't put on a public page?
Happy to walk through the data model, the trade-offs, and what I would do differently. Open to Salesforce roles, 30-day notice.