This case study is the proof point behind the pillar article on Custom CRM vs Salesforce vs HubSpot. It's a real engagement: a California health-insurance company that came to us in late 2022 with a CRM bill they couldn't justify and ops workflows they couldn't fix from inside Salesforce. We delivered a custom CRM layer in 6 months. Year 2 came in roughly 30% cheaper than Year 0. Year 3 is on track for ~50%.
The numbers below are anonymized at the request of the client. The methodology is exact.
The starting point — fragmented ops, growing CRM bill
Company profile
Mid-size US health-insurance company. California-based. Roughly 150 total employees: 65 licensed insurance agents, 28 internal sales/ops staff, 12 management, 45 broker users. Two main product lines: individual Medicare supplement plans and small-group employer plans. Annual CRM-related spend approaching $720K when we engaged.
The stack before
Before our engagement, the operational stack looked like this:
- Sales Cloud Enterprise for the entire 150-user population
- Service Cloud Professional add-on for agents handling client servicing
- A Shield add-on for HIPAA audit trail
- Two AppExchange apps — a quote generator and a document e-signature integration
- An external Salesforce partner on a $9K/month customization retainer
- 1.7 FTE internal Salesforce admin/developer time
Per-seat costs: $165/user/month on Sales Cloud Enterprise. Service Cloud add-on: $50/agent/month for 65 agents. Shield: $30K/year. Implementation legacy debt: still amortizing $180K spent in 2020.
What the CFO was actually worried about
The CFO laid out the brief in the first call. It wasn't "I want to leave Salesforce." It was three concerns:
- The Salesforce bill had grown 22% over two years while revenue grew 11%
- The internal Salesforce admin had left; the replacement took 7 months to hire and is still ramping
- The board had asked specifically how much of the Salesforce spend translated to revenue impact, and nobody could answer
The brief: figure out where the money is going, what it's worth, and what the alternatives look like.
What we found in the audit
We ran a 2-week audit. Three things came out of it.
License utilization (% of seats actively used)
Of 150 paid seats, 87 were active in any given 30-day window. 58% utilization. The dormant 63 seats cost $125K/year in licenses alone. Many were users from a 2021 acquisition who'd been provisioned and never deprovisioned. Some were agents who'd quit and whose seats were still active because the admin process to deactivate involved a ServiceNow ticket and approval chain.
Feature utilization (which modules sat dormant)
We pulled Salesforce feature usage reports across the prior 90 days. The breakdown:
- Accounts, Contacts, Activities, Tasks — heavy use (90%+ of users in last 30 days)
- Opportunities — moderate use (40% of users); most policies don't move through Opportunities cleanly
- Cases (Service Cloud) — heavy use by agents (85%)
- Knowledge — 8%; no one builds or uses the knowledge base
- Marketing Cloud — 0%; paid for but disconnected
- Pardot — 0%; paid for but disconnected
- Reporting features — ~15%; the rest used Excel exports
Two full Clouds paid for and untouched.
The hidden cost: ops hours spent on workarounds
The audit interview surfaced workarounds:
- A senior ops manager spent 4 hours/week maintaining the agent commission spreadsheet — exporting from Salesforce, applying commission rules in Excel, emailing payouts to finance
- Renewal tracking: a calendar reminder per agent for "check Q1 renewals due" — manual, missed deadlines
- Loss-run reports: rebuilt monthly in Excel from Salesforce CSV exports because the Salesforce reports didn't match how underwriting needed the data
- Broker portal: a separate system entirely; broker payouts reconciled by hand against Salesforce
We estimated ~22 person-hours/week across the ops team spent on workarounds. At fully loaded rates, that's roughly $115K/year in operational labor that Salesforce was supposed to eliminate.
The three workflows that mattered
Out of dozens of workflows, three drove ~80% of the operational pain:
- Policy lifecycle (quote → bind → renew → cancel) — didn't map to Salesforce Opportunities cleanly
- Agent management (productivity tracking, commission, license verification) — entirely in Excel
- Client servicing (renewal reminders, plan changes, claim escalations) — partially in Cases, partially in inbox
These three were the entire reason ops felt the platform didn't fit. Fix these three and most of the workarounds disappear.
The decision — why "custom layer" beat "replace platform"
Migration risk vs build risk
Replacing Salesforce entirely was on the table. We didn't recommend it. Two reasons:
First, migration risk. Three years of customer history, audit trails, and integration touch-points lived in Salesforce. Migrating all of that to a new platform is a 12–18 month project with a real risk of data loss and operational disruption.
Second, the parts of Salesforce that worked, worked. Accounts/Contacts/Activities, Cases, Shield audit trail — these were genuinely useful and the ops team trusted them. The right call: keep the parts of Salesforce that worked. Build a custom layer for the three workflows that didn't fit. Deprecate the Clouds and seats that weren't being used.
Timeline to value
A pure-replacement project would have delivered nothing for 12+ months. The custom-layer approach delivered value in 6 months: by month 3 the policy lifecycle was running on the new layer; by month 6 the agent management and client servicing flows had migrated.
What we kept, what we replaced, what we wrapped
- Kept — Sales Cloud for Accounts, Contacts, Activities. Shield for audit trail. Service Cloud Cases for support tickets.
- Replaced — Marketing Cloud (deprecated, replaced with Mailchimp at 1/20th the cost). Pardot (deprecated). The customization retainer (in-housed via the custom layer).
- Wrapped — Opportunities (we built our own Policy object with proper lifecycle states, sitting alongside SF's Opportunities). Cases (we built agent-facing workflows that surfaced Cases without requiring agents to learn Service Cloud UI).
What we built
Centralized data model for client, policy, agent
A Postgres database with three first-class objects: Client (insured person or company), Policy (with lifecycle state machine: quote → bound → active → renewing → cancelled), and Agent (with license verification, geographic territory, commission rules). This data model sat alongside Salesforce, not in front of it. Salesforce remained the system of record for Accounts and Contacts. The custom layer became the system of record for Policies and Agents.
Automated lifecycle workflows (renewals, onboarding, commission)
Concrete workflows we automated:
- Policy renewal — 90-day, 60-day, 30-day reminders to agents with one-click renewal flow
- Onboarding — new client → agent assignment → license verification → underwriting question packet → policy bind
- Commission — monthly calculation from policy data, with rule engine for tiered commission structures
- Broker payouts — monthly reconciliation against bound policies, with audit trail
All of these had been manual or partially-manual in Salesforce. After 6 months, they ran themselves.
Integrations with existing claims/billing/portal systems
The custom layer integrated with three external systems: the claims platform (read-only sync of claim status), the billing engine (write claim adjustments, read payment status), and the broker portal (bidirectional sync of broker activity and payouts). Integration patterns: REST for claims, SOAP for billing (vendor legacy), event-driven webhook for the broker portal. We built a small middleware layer to normalize the three.
What we deliberately did NOT build
Worth naming what we didn't build, because that's where SaaS bundling math fails:
- A full marketing automation tool — Mailchimp covers it
- A separate analytics warehouse — existing data warehouse picked up the data
- A document management system — kept the existing one
- A general-purpose ticketing system — Salesforce Cases remained the system of record
Each of these would have added $50–150K/year in license cost or build cost. None were needed.
The numbers
Year 1 — investment phase
Year 1 was a net spend year — partly amortizing the previous Salesforce contract while standing up the new layer:
- Salesforce reduced footprint — $310K (vs $497K prior year, after Marketing Cloud and unused seats deprecated)
- Custom build (one-time) — $185K (6-month engagement, fixed-price)
- Custom layer hosting + ongoing — $35K
- Internal admin time — 0.8 FTE = $110K (down from 1.7 FTE)
- Year 1 total — ~$640K (vs prior baseline of ~$720K; already 11% lower in Year 1)
Year 2 — ~30% CRM cost reduction (breakdown by category)
- Salesforce footprint — $245K (further seat reduction + renegotiated at renewal)
- Custom layer maintenance — $55K
- Internal admin — 0.5 FTE = $70K
- Year 2 total — ~$370K, a 48% reduction vs prior baseline ($720K), or roughly 30% reduction year-over-year after Y1 amortization smoothing
The 30% figure in the article title is the apples-to-apples Year 2 number after smoothing for Year 1's one-time build cost. The raw Year 2 vs Year 0 number is closer to 48%.
Year 3 projection — ~50% reduction
Year 3 (running now) is on track for $360K total — driven primarily by further Salesforce seat reduction as more workflows migrate to the custom layer. Projected total reduction vs Year 0: 50%.
Year 4 — break-even on total program cost
Year 4 is the break-even year on the cumulative program cost, including the one-time Year 1 build investment. After Year 4, the program is net cost-positive every year forward.
Soft wins (agent NPS, time-to-quote, fewer support tickets)
Beyond the dollar numbers, three operational wins:
- Agent NPS on internal tooling went from 4.1 to 7.8 (10-point scale, biannual survey)
- Time-to-quote dropped from 47 minutes (median) to 11 minutes
- Internal support tickets to the Salesforce admin dropped 64% — mostly because the workflows the admin had to fix monthly were now automated
The CFO's question from the first call ("how much of our CRM spend translates to revenue impact?") now has an answerable form. Each Y2 dollar in the layer maps to a workflow with a measurable ops outcome.
Lessons that transfer to other insurers
Audit before you architect
We didn't propose the architecture for 2 weeks. The first 2 weeks were the audit — and the audit, not the architecture, was what made the CFO comfortable with the path. If we'd opened with "let's build a custom CRM," the project wouldn't have happened. We opened with "let's see where the money is going." That's how you get permission to move.
Don't replace what works — wrap it
The fastest way to lose a custom-CRM project is to migrate too much. We deliberately kept Accounts/Contacts in Salesforce. The data model wraps Salesforce's data, doesn't replace it. Trust the parts of the platform that work.
Adoption beats features
We shipped fewer features than the original Salesforce setup. Adoption was higher. The custom layer covers exactly what the team uses, and nothing else. When agents log in, every screen is a workflow they actually use. That's the difference between 58% license utilization and 91%.
Want the same audit for your CRM stack? Book a free 2-week CRM Cost & Fit Audit, or read the underlying case study for the full delivery breakdown.