Custom CRM With Lead Scoring: Real Cost, Real Risk

What lead scoring actually is once real leads hit it

Lead scoring looks like a formula. Fifteen points for a demo request, ten for pricing page views, minus twenty for a free email domain, sort descending, hand the top of the list to sales. You can build that in a weekend. It survives about six weeks in production.

The failure looks like this, and it looks like this every time. A rep opens the CRM on a Tuesday and sees Acme Corp at score 92, marked hot, assigned to him. He calls. The person who filled out the form left the company in March. The actual buyer is a different contact record, created eleven days ago from a webinar list upload, spelled "ACME Corporation Inc." with a different domain, sitting at score 14 because none of the website activity got attributed to her. Two records, one company, and the score is attached to the wrong human. The rep now trusts the score less than his own gut, and once a rep stops trusting the number, you have paid for a feature nobody uses.

That is an identity resolution failure, not a scoring failure, and it sets the pattern for the whole build: the model is easy and everything the model depends on is hard. The score is a function over a graph of people, companies and events, and the expensive work is making that graph correct.

Identity resolution: the part that eats the budget

Before you can score a lead you have to know what a lead is. In practice you get the same buyer arriving as a form fill with a personal Gmail, an anonymous cookie from three weeks of research browsing, a LinkedIn ad click, a calendar invite from a colleague, and a row in a conference list your marketing lead uploaded as CSV with the columns in the wrong order.

A competent build separates three layers explicitly: Person (an individual human), Account (a company), and Identity (an observed identifier such as an email hash, a cookie id, a device id, a phone number). Identities attach to Persons through match rules with confidence weights. Persons attach to Accounts through domain matching plus a hierarchy for subsidiaries, because Acme UK and Acme US are one commercial relationship and two buying centers.

The specific decisions you have to make:

• Deterministic or probabilistic matching. Deterministic (exact email, exact phone in E.164 format) is safe and misses a lot. Probabilistic (fuzzy company name, IP to company reverse lookup, name plus domain similarity) catches more and creates false merges. Real answer: deterministic auto-merges, probabilistic above a threshold goes to a human review queue. Budget for that queue UI, it is a real screen with real workflow.
• Merges must be reversible. The single most painful bug in this category is an irreversible bad merge. Two customers become one record, someone deletes the "duplicate," and you have destroyed pipeline history. Model merges as a link table with a surviving record pointer, never as a destructive update. Unmerge is a required feature, not a nice to have.
• Anonymous to known stitching. Someone reads your pricing page for two weeks anonymously, then fills a form. Those two weeks of intent are worth more than the form. Stitching them means keeping an anonymous identity graph and backfilling events on identification, which means your event store has to be replayable, which means it cannot be a fire and forget analytics pipe.

In Digital Heroes delivery, identity resolution is consistently 30 to 40 percent of the total build effort on scoring projects, and it is the line item nobody else quotes.

The event pipeline, ordering, and why scores drift

Scores are computed from events, and events lie about time. A mobile SDK buffers offline and delivers a page view four hours late. A webhook from your marketing automation tool retries and delivers the same event twice. Your CRM ingests both and the lead now has two demo requests and 30 points instead of 15.

What a competent build does:

• Idempotency keys on every ingest path. Every event carries a client-generated id, and ingestion is an upsert on that id, not an insert. Without this, any webhook source with at-least-once delivery semantics (which is all of them, including Stripe, Segment, HubSpot and Salesforce Platform Events) will inflate your scores. The vendor is not doing anything wrong; at-least-once is the contract.
• Event time versus ingest time as separate columns. Scoring windows ("visits in the last 14 days") must use event time or the late-arriving batch pushes a cold lead hot on the day it syncs.
• Decay is a scheduled job, not a formula. Everyone wants recency weighting. The naive version computes score on read with a decay function, which is fine until you want to alert on "score crossed 80," at which point nothing ever crosses anything because nothing recomputes. You need a materialized score, a recompute trigger on new events, and a periodic sweep for time-based decay. That sweep over 500,000 contacts is a real batch job with a real cost.
• Backfill on rule change. When marketing changes a rule weight, do existing scores change? If yes, you need a full recompute path over history. If no, you have two leads with identical behaviour and different scores, and someone will notice. Pick one, write it down, tell the client. We recommend versioned rule sets with an explicit "recompute now" action and a visible model version on every score.

Explainability, or the feature that decides whether reps use it

A score of 87 tells a rep nothing. A score of 87 with "+30 requested demo (2 days ago), +25 3 visits to /pricing, +20 company size 200 to 500, +12 job title contains VP" tells a rep what to say on the call.

This is an architectural requirement disguised as a UI nicety. Every score must be stored with its contributing factors, not just the total. That is a score_factors table, one row per contribution, written on every recompute, for every contact. At 200,000 contacts recomputed nightly with an average of eight factors, that is 1.6 million rows a day. You partition it, you retain the current version plus a rolling history window, and you decide the retention policy up front. Teams that skip this ship a black box, the reps route around it, and the client concludes custom software does not work.

The same requirement kills the "just use machine learning" reflex early. A gradient boosted model will beat your hand-tuned rules on AUC and lose the argument with the sales director who wants to know why his best account scored 40. If you go ML, you carry SHAP values or equivalent per prediction, and you carry them into the UI. That is not free. It is also why the honest first version of scoring is almost always rules based, with a scoring engine designed so a model can be swapped in behind the same interface later.

And there is a cold start problem nobody mentions: a supervised model needs labelled outcomes. If the client closes 40 deals a year, there is no training set. Under roughly 300 to 500 closed-won and closed-lost records with clean timestamps, rules win, full stop.

Permissions, GDPR, and the two-way sync you will regret

Three things that reliably surface in week nine and were not in the quote.

Row level visibility. Reps see their accounts, managers see their team, admins see everything, and the scoring list view has to respect that. If scoring runs as a background job with admin rights and the list view filters after the fact, your pagination breaks and your counts lie. Visibility has to be a predicate inside the query, and territory rules ("west coast, above $50k ARR, excluding named accounts") are a rules engine of their own.

GDPR and the erasure request. Under GDPR Article 17, a person can demand deletion. Your scoring system has their behaviour spread across an event store, a score history table, a factors table, and probably a warehouse copy. Erasure has to cascade to all of them, and you need to prove it did. Also relevant: profiling for decisions has consent implications under Article 22, and if the client sells into the EU their DPO will ask. Design the event store with a person id foreign key that supports hard delete, or accept a crypto-shredding approach where you drop the per-person encryption key. Decide in week one, not week thirty.

Two-way sync with Salesforce or HubSpot. Clients almost always want the score written back to the system of record. This is where it gets ugly. Salesforce enforces API request limits per 24 hours based on edition and licence count, and a nightly bulk score push over 200,000 records will burn through them; you use the Bulk API and batch, not per-record REST calls. HubSpot enforces per-second and daily caps by tier. Both fire webhooks back at you when records change, which triggers a recompute, which writes back, which fires a webhook. That loop has taken down more than one integration. You break it with an origin marker on writes and a suppression window, and you build it assuming their webhook delivery is at-least-once and out of order, because it is.

What this costs and what drives the number

These bands are Digital Heroes delivery experience across 2,000-plus projects, not market averages.

• Scoring added to an existing CRM or product: $15,000 to $60,000, typically 4 to 8 weeks. You already have contacts, accounts and auth. The work is the event pipeline, the scoring engine, the factors model, the admin UI for rules, and the write-back. The $15,000 end is a single source of events, deterministic matching only, and rules configured by us rather than by the client. The $60,000 end has multi-source ingestion, a merge review queue, and a rule builder the marketing team drives themselves.
• Custom CRM with scoring as a first release: $50,000 to $130,000, 10 to 16 weeks. Now you are also paying for the object model, pipelines, activity timeline, permissions, import, and the mobile-responsive list views reps actually live in.
• Full platform: $150,000 to $350,000, 6 to 12 months. Multi-source enrichment, ML scoring with explainability, routing and assignment rules, forecasting, multi-tenant, SSO with SCIM provisioning, audit trails.

What specifically moves this capability up the band:

1. Number of distinct event sources. One is easy. Website plus product usage plus email plus calls plus an enrichment vendor is five different schemas, five failure modes, five sets of rate limits. Each additional source after the second adds roughly $6,000 to $12,000.
2. Who edits the rules. "We configure the weights" versus "marketing builds rules in a UI with AND/OR nesting, preview against historical data, and version rollback" is a $20,000 swing. The preview feature alone is a query engine over your event store.
3. Two-way sync with an existing CRM. Add $10,000 to $25,000 and expect the loop-prevention and rate-limit work to take longer than the happy path.
4. ML instead of rules. Add $25,000 to $50,000 and only if the closed-deal volume justifies it. Most of that cost is retraining pipeline, drift monitoring, and explainability, not the model.
5. Existing data quality. If the client hands you 80,000 contacts from three spreadsheets and a legacy CRM, deduplication and migration is a project, not a task. We have seen migration exceed the scoring build itself.

Ongoing cost, since nobody mentions it: enrichment vendors bill per record. Clearbit, ZoomInfo and Apollo all price per contact or per credit, and a nightly refresh over your whole database is a bill you will not enjoy. Refresh on activity, not on schedule.

When you should not build this

Direct position: if you are a company selling one product to one segment with under about 2,000 new leads a month, and you already pay for HubSpot or Salesforce, do not build custom lead scoring. Use HubSpot's predictive scoring on Marketing Hub Enterprise or Salesforce Einstein Lead Scoring. They are built, they work at that scale, and $60,000 of engineering buys a lot of licence years.

Build custom when at least one of these is true, and be strict about it:

• Your signal is product usage inside your own app. Off-the-shelf scoring cannot see that a trial account ran 40 reports and invited five teammates. That is the highest-value signal you have and it lives in your database. This is the single best reason to build.
• Your buying unit is not a person. If you sell to committees, franchises, dealer networks or households, the vendor object model fights you every day. Scoring an account made of eleven people with different roles is genuinely custom.
• Your scoring inputs are regulated or proprietary. Underwriting data, clinical eligibility, credit signals. You cannot push those into a third-party scoring engine, and you need the decision auditable.
• You have real volume and the vendor economics have inverted. At hundreds of thousands of contacts, per-contact pricing on the enterprise tiers stops being cheaper than owning it.

There is a middle path more clients should take: keep HubSpot or Salesforce as the system of record, and build only the scoring service that reads your product events, computes the score with your logic, and writes one number and a factors summary back to a custom field. That is the $15,000 to $30,000 version, it ships in five weeks, and it captures most of the value. If a vendor jumps straight to a full custom CRM without asking whether this is enough, that tells you something.

How to brief and vet whoever builds it

Give them, before any estimate: your current contact count and monthly new lead volume, every system that will send events, whether write-back to an existing CRM is required, your closed-won and closed-lost count for the last 24 months, and who is supposed to edit the rules. An estimate given without those five facts is a guess.

Then ask these. They are chosen because someone who has shipped this answers instantly and someone who has not will generalise.

1. "Two records for the same company arrive from different sources. Walk me through your merge, and show me the unmerge." If unmerge is an afterthought, they have not been through a bad merge in production.
2. "The same webhook is delivered twice. What stops the score from doubling?" The word you are listening for is idempotency, and the answer should mention a key on the event, not a duplicate-check query.
3. "A rep asks why this lead is an 82. What does the screen show him?" If the answer is the number, walk.
4. "Marketing changes a weight on Monday. What happens to the 40,000 existing scores?" There are two acceptable answers, recompute or freeze with a version stamp. There is one unacceptable answer, which is "I would have to think about that."
5. "We have 60 closed deals. Rules or a model?" Anyone who says ML at 60 deals is selling, not engineering.
6. "How do you keep the write-back to Salesforce from triggering a webhook that triggers another write-back?" Loop prevention and API limits should come up unprompted.
7. "A contact requests erasure under GDPR. What tables does that touch and how do we prove it?" The answer should name the event store, not just the contact record.
8. "What is the batch job that runs at 3am and what pages you when it fails?" If there is no scheduled recompute in their design, their scores go stale silently, which is the worst failure mode because nobody notices for a month.

Ask for one thing more: a lead they scored in a previous build where the score was wrong, and what they changed. Everyone who has shipped this has that story.