Building an ICP Score That Updates in Real Time

The Static Snapshot Problem

Most ICP scoring models are built on a snapshot. Someone on the RevOps team configures the scoring criteria, selects a data provider — Clearbit, ZoomInfo, Apollo, or one of the several newer enrichment APIs — and maps the enrichment fields to score dimensions. The model runs at the time of lead creation and writes a fit tier to the record. From that point forward, unless someone explicitly re-enriches the record, the ICP score reflects the state of the company at the moment they filled out your form.

This is fine for companies that are static. The problem is that the most interesting inbound leads are rarely static. A company that just closed a funding round is in motion. A company that just hit 100 employees crossed a headcount threshold that often triggers new tooling decisions. A company that recently replaced their CRM is in an active evaluation cycle. These are exactly the signals that make a lead high-priority — and all of them change after the snapshot.

The deeper issue: static scoring models built on Clearbit snapshots specifically suffer from Clearbit's data refresh cadence. Clearbit's company data refreshes on a schedule that varies by company size and signal activity — fast-growing companies with high web footprint get fresher data, smaller or less active companies can have data that's months old. When your ICP score is computed from a months-old snapshot of a company's headcount and tech stack, the score may be wrong not because your model is wrong, but because your input data is stale.

What "Real-Time" Means for a Scoring Model

Real-time ICP scoring doesn't mean the model recalculates every second. It means the model recalculates when something changes — and that "something changed" event is triggered by enrichment signals arriving fresh, not by a scheduled batch job.

The architecture has three components. First, a trigger mechanism: whenever a significant enrichment signal updates (new headcount reading, funding event detected, tech stack change observed), a scoring recomputation is queued for the affected record. Second, a weighted scoring model that runs against the current enrichment state — not against a cached snapshot. Third, a write-back mechanism that updates the fit tier field in the CRM and optionally triggers downstream actions (assignment rule re-evaluation, Outreach sequence re-enrollment, Slack notification).

This is meaningfully different from periodic re-enrichment jobs, which run on a schedule regardless of whether anything changed. Schedule-based re-enrichment is better than one-time snapshot scoring, but it still creates windows where a high-priority signal change doesn't affect the record's score until the next scheduled run. A headcount spike detected on a Tuesday doesn't move the record's fit tier until the Friday batch runs — if Friday is when the batch runs. Event-triggered rescoring closes that window.

The Signal Stack: What Belongs in a Real-Time ICP Model

Signals That Should Trigger Immediate Rescoring

Not all signal changes warrant immediate rescoring. Some signals are noisy and high-frequency (minor job posting fluctuations, small headcount adjustments). Others are low-frequency but high-conviction (funding announcements, leadership hires at VP level or above, confirmed technology additions or removals). A well-designed real-time scoring model distinguishes between these categories.

High-conviction triggers that should drive immediate rescoring:

• Funding event detected — any confirmed round signals budget availability and board-driven growth pressure. This should immediately recalculate the funding recency dimension of the score.
• Headcount delta exceeds threshold — a 15%+ headcount change over 90 days is a meaningful inflection signal. Below-threshold deltas can wait for scheduled refresh.
• Technology addition or removal in primary category — specifically, tools in the same category as your product. A company that adds a competing tool is a churn risk; a company that removes one is an active evaluation signal.
• VP-level or above hire in a relevant function — a new VP of Sales or Head of Revenue Operations at a company that hasn't engaged yet is a meaningful intent signal. New executives often re-evaluate the tool stack within 90 days of starting.

Signals That Can Wait for Scheduled Refresh

Signals like geographic expansion (a company opening a new office), minor job posting volume changes (going from 5 to 8 open roles), and peripheral technology additions (adding a new analytics tool that doesn't affect your product category) are useful for enrichment context but don't warrant immediate scoring recomputation. Processing them on a daily or weekly refresh cadence is appropriate and avoids over-triggering the scoring pipeline on low-conviction events.

Configuring a Weighted Scoring Model That Handles Signal Freshness

The scoring formula itself needs to account for signal age, not just signal presence. A standard weighted scoring model looks like this:

// Simplified ICP score calculation
// Each signal_value is 0–100, weight is 0–1, weights sum to 1.0

const score = (
  (headcount_fit * 0.25) +
  (industry_fit  * 0.20) +
  (funding_recency_score * 0.20) +
  (tech_stack_match * 0.20) +
  (headcount_velocity * 0.15)
);

// funding_recency_score decays over time:
// 100 if funding_days_ago <= 90
// 80  if funding_days_ago <= 180
// 60  if funding_days_ago <= 365
// 30  if funding_days_ago > 365
// 0   if no funding data

// headcount_velocity: 90-day growth rate normalized to 0–100
// tech_stack_match: binary or partial match against ICP tech criteria

The critical detail is the funding_recency_score decay function. A funding event that happened 91 days ago should not score identically to one that happened yesterday. The urgency signal degrades over time. The same decay logic applies to technographic signals: a tech stack change observed 10 days ago is more predictive of active evaluation behavior than one observed 6 months ago.

A real-time ICP model is only as useful as its downstream routing rules. If the model recalculates correctly but the result sits in a CRM field that no assignment rule or sequence trigger references, the recomputation produced accurate data that nobody acted on. Build the trigger logic before you build the model refinement logic.

The Practical Limit: Not Every Signal Is Available in Real Time

We want to be direct about a constraint that's real for any enrichment-based scoring system, including Salmon's. The signals that matter most for ICP scoring — funding events, leadership hires, tech stack changes — are not uniformly available in real time for all companies. Large, well-documented companies with active LinkedIn presences, press coverage, and public job boards have high signal density. Smaller companies, especially those without significant online footprint, have lower signal density regardless of which enrichment provider you use.

For a B2B SaaS RevOps team we worked with — one processing around 800 inbound leads per month — real-time enrichment resulted in strong signal coverage for approximately 72% of inbound leads (those coming from companies with 50+ employees and active web presence). For the remaining 28%, coverage was partial: firmographic signals were generally available, but technographic and velocity signals were thin. This isn't a failure of the real-time architecture — it reflects the underlying availability of signals in the market. The correct response is to route low-coverage records to a different scoring pathway, not to score them down as if thin coverage equals low fit.

Wiring It Into Salesforce: The Field That Triggers Everything

The practical implementation in a Salesforce environment centers on the Salmon__ICPFitTier__c field — a picklist with values Strong / Moderate / Weak / Insufficient Data. This field is the output that routing rules, automation rules, and sequence enrollment triggers reference. Routing should be configured to act on this field, not on the raw score number, because the tier abstraction makes rule logic readable and maintainable.

When Salmon's scoring model recomputes and upgrades a record from Moderate to Strong — triggered by, say, a new funding event detected for the company — the field update fires a Salesforce Flow that can escalate the record, notify the assigned rep, or trigger a re-enrollment in a higher-priority Outreach sequence. The signal change propagates into SDR behavior automatically, without anyone checking a CRM report.

The scoring product page covers signal weight configuration and how to set fit tier thresholds that map to your specific ICP definition.