RevOps/No. 05/5 min read

Your intent data is dying in the CRM. Here’s the object model that fixes it.

Buying intent data doesn’t build pipeline. Acting on it in hours does. Here’s the object model most CRMs are missing, and how to build a signal layer that actually routes.

SM

Sage M.

LSR Marketing · July 1, 2026

Open your CRM and try to answer one question: which accounts showed buying intent in the last 48 hours, and did anyone follow up? If you can’t pull that in a single view, your intent data isn’t a growth lever. It’s a monthly invoice.

This is the quiet failure behind most “signal-based GTM” programs in 2026. Teams buy 6sense or Bombora, light up an intent dashboard, and assume the pipeline will follow. It doesn’t. The signal shows up in a vendor’s UI, maybe syncs a score into a hidden field, and then nothing routes, nothing decays, nobody gets a task. The data is fine. The place you’re putting it is broken.

Buying signals is not the same as acting on them

Intent data is an event. “This account researched your category on Tuesday.” Events are perishable. The value of that signal is highest the day it fires and close to zero three weeks later, after the buyer has already talked to two of your competitors.

Now look at how a CRM models the world. Contacts, companies, deals. Static records that describe what something is, not what just happened. There’s no native object for “a thing that occurred at a moment and gets stale.” So the signal gets crammed into a property on the account, intent_score = 82, and sits there. No timestamp anyone routes on. No decay. No trigger. A number that was urgent on Tuesday looks identical on the following Monday, and by then it’s fiction.

That’s the mechanism. It’s the same root cause we write about constantly: most CRM problems are data problems. You can’t route a signal you haven’t modeled as a signal.

Why the score-in-a-field approach quietly fails

Three things break when intent lives as a single overwritten property:

The score has no memory. When intent_score updates from 82 to 40, you’ve lost the fact that it was 82. You can’t see the spike, only the current state. Spikes are the entire point of intent data. A flat 60 for a quarter means nothing. A jump from 20 to 85 in four days is a sales conversation.

There’s no freshness anyone can act on. Even if the vendor stamps a “last updated” date, it usually isn’t a property your routing workflows can read, and it isn’t surfaced to the rep who has to decide whether to call today or ignore it. Freshness is the difference between a warm account and a cold list.

Routing is disconnected from the signal. Most teams still route on static fit: company size, industry, territory. Fit tells you who’s worth talking to. It says nothing about when. When routing ignores timing, your best signals land in a queue behind a hundred stale ones, and the rep works top-to-bottom instead of hottest-first.

The fix: model intent as its own layer, then route on it

You don’t need a new platform. You need three moves inside the stack you already run.

1. Give signals an object, not a field

Model intent as records that accumulate, not a number that overwrites. In HubSpot that’s a custom object (or a dedicated activity timeline for accounts); in Salesforce it’s a related “Intent Signal” object hung off Account. Each row is one event: source, topic, strength, and the timestamp it fired. Now a spike is visible as a cluster of recent rows, and history survives. You can answer “what changed this week” because the week is actually recorded.

If a full custom object is more than the account justifies, the minimum viable version is a set of properties that preserve motion instead of erasing it: intent_score_current, intent_score_7d_ago, intent_signal_last_date, intent_topic_top. Ugly, but it keeps the delta, and the delta is what you route on.

2. Make freshness a first-class, routable property

Stamp every signal with the date it arrived and compute days-since. intent_signal_last_date and a derived intent_days_stale. This one property changes everything downstream, because now a workflow can say: fit is strong AND a signal fired in the last 5 days, so create a task now. After 14 days with no new signal, the account cools automatically and drops out of the “act now” view. The decay is built in, not left to a rep’s memory.

3. Route on fit times timing, and prove the handoff

Build the routing workflow to fire on the combination: qualified fit plus a fresh, rising signal. That’s your 6QA-style trigger, an account worth a human, right now. Route it to a named owner with the signal context attached (which topics, how recent, the score delta) so the rep opens the record and already knows why they’re calling. Then instrument it. Log the routed date, the first-touch date, and the gap between them. If signals are routing but time-to-touch is still four days, you’ve found the leak, and you can only find it because you’re now recording every step.

What you get when the signal layer actually holds

Accurate answers to the only questions that matter: which accounts are hot right now, who owns them, and how fast we responded. Reps working hottest-first instead of alphabetically. An intent subscription that finally shows up in sourced pipeline instead of a renewal you can’t justify. This is the same discipline that produced a +28% MQL-to-SQL lift on a rebuild we ran: the gains didn’t come from a smarter score, they came from modeling the data so the automation on top of it could hold.

The reverse is the status quo. You keep paying for signals you can’t act on, reps keep guessing, and every quarter someone asks whether the intent tool is worth it. It isn’t, until the object model underneath it can carry the signal to a person before it goes stale.

Where to start

You don’t have to rebuild everything at once. Start by auditing what happens to a single signal today: trace one account from “intent fired” to “rep followed up” and mark every place the trail goes cold. That map is usually all the proof you need that the problem is structural, not effort. Fixing the object model underneath is the work we do in nearly every Marketing Operations & CRM engagement, because you can’t route a signal the data model can’t hold.