A target account closes its Series B on a Tuesday. Your funding feed picks it up Wednesday and writes Recently_Funded__c = true on the Account. The nightly sync to the warehouse runs Wednesday night, the list-building job that feeds outbound runs on Mondays, and the sequencer imports new list members in a weekly batch. The SDR's first email ("congratulations on the round") goes out nineteen days after the announcement. By then the new VP of Sales the round paid for has already booked two demos, one of them with your closest competitor. Three months later the checkbox is still true, and a second sequence congratulates the same account on the same round.
Nothing in that chain failed. What failed is an architecture that treats a signal as a fact to be stored rather than an event with a clock on it. The signal was worth the most on day one and less every day after, and nothing in the stack knew that.
The window in which a signal can change an outcome is short. 6sense's 2025 Buyer Experience Report (more than 4,000 B2B buyers, November 2025) found 94% of buying groups had ranked preferred vendors before first contact, that they bought from that preliminary favorite 77% of the time, and that first contact with sellers now happens around 61% of the way through a buying cycle of roughly ten months. A signal that a company has started to look is the chance to be in the frame before that ranking forms.
Speed has been measured for a long time on the inbound side. In The Short Life of Online Sales Leads (Harvard Business Review, 2011), Oldroyd, McElheran and Elkington reported an audit of 2,241 US companies: 37% responded to an online lead within an hour, 24% took more than 24 hours and 23% never responded. A separate study in the same article examined 1.25 million leads received by 29 B2C and 13 B2B companies. Firms that attempted contact within an hour were nearly seven times as likely to qualify the lead as those that waited even an hour longer, and more than 60 times as likely as those that waited 24 hours or more. Qualification meant a meaningful conversation with a key decision-maker, not a closed sale. Yesware quotes both findings. These are inbound findings, not measured half-lives for outbound signals; outbound windows must be calibrated on your own outcomes.
The underlying events keep coming. Gartner's B2B buying research states that 99% of B2B purchases are driven by organizational changes. The US Bureau of Labor Statistics JOLTS release for August 2026 (published September 29, 2026) counted 5.1 million total separations, a rate of 3.2% in nonfarm employment. This includes quits, layoffs and discharges, and other separations; it is not a job-change rate for B2B contacts. Forrester's State of Business Buying 2024 (December 2024) found 13 people involved in the average purchase decision and 86% of purchases stalling at some point.
This is a systems problem, not a rep-discipline or vendor problem. A faster SDR cannot fix a weekly batch job, and a better provider cannot fix a checkbox that never expires. The fix is to give every signal a timestamp, a type-specific half-life and a routing window, and make orchestration act inside that window.
Where it breaks
Signal decay never shows up as an error. It shows up as falling reply rates and reps saying "intent data doesn't work". Five patterns cause most of it.
Signals stored as state, not events
The most common schema is a boolean or picklist on the Account: Intent_Surge__c, Recently_Funded__c, Hiring_SDRs__c. There is no observed_at, no source and no expiry, and a new signal overwrites the old one instead of adding to a history. The flow that reads the field cannot tell a surge from this morning from one last quarter.
Latency set by the slowest batch job
Signals arrive in real time from webhooks and in batches from provider exports, then pass through a nightly warehouse sync, a scheduled list refresh and a sequencer import. An event-driven RevOps architecture can remove scheduled waiting from the fast path. End-to-end latency is the sum of every hop, and it is usually set by the one weekly job nobody remembers scheduling. Few teams can say how many days pass between a funding announcement and the first touch, because no single system sees both timestamps.
Detection lag mistaken for signal age
Every signal has three clocks: when the event happened (event_at), when your provider observed it (observed_at) and when your stack received it (received_at). Job changes surface only when someone updates a profile, hiring signals when a posting is indexed, tech installs when a crawler next visits the site. If the stack starts the clock at received_at, it believes a two-week-old job change is fresh and routes it with an urgency the moment no longer deserves.
One queue for every signal type
All signals land in a single "signals" view or a single outbound list, first in, first out. A pricing-page visit from a known contact two hours ago waits behind a funding alert from last month, and both get the same generic sequence. A live hand-raise needs a person today; a tech install can wait for a thoughtful sequence next week. A single queue spends its fastest capacity on its slowest signals.
No expiry and no suppression
Nothing turns a signal off. Stale signals keep accounts in "hot" lists, inflate intent-based scores for months and trigger copy that references old news. Meanwhile an account with a dozen fresh signals from different sources is treated like one with a single stale one, because nobody combines them.
Reference architecture
The design treats signals as timestamped events, decays them by type and routes them by the window in which action still changes the outcome. Tools are examples of categories, not endorsements, and every half-life and window below is an illustrative starting assumption to calibrate on your own history, not an empirical benchmark.
Components: first-party signals (form fills, pricing page visits, product sign-ups and usage milestones) and third-party signals (topic intent, funding news, job postings, champion job changes, technographic installs and removals).
Contract to the event layer: every signal arrives as an event, by webhook where the source supports it, never as a direct write to a CRM field. It carries the event_at the source knows, the observed_at the provider recorded and the raw payload.
Components: a signal event table (in the warehouse, a queue, or a custom CRM object for smaller teams) with one row per signal: signal_type, account_key, person_key, event_at, observed_at, received_at, source, strength and payload. Identity resolution attaches each event to a canonical account and person first.
Contract to decay and scoring: append-only events, never overwritten, each tied to a known record. Detection lag (observed_at minus event_at) and ingestion lag (received_at minus observed_at) are computed per row.
Components: a per-type configuration holding a half-life, an action window and an expiry; a freshness function that discounts each signal by its age; and an account-level signal score that sums fresh signals across types and people, with extra weight when independent sources agree. Usually a scheduled warehouse model (dbt, for example) plus a real-time path for the fastest types.
Contract to orchestration: for each account and person, the current signal score, the freshest signal and its type, the remaining action window and the reason in plain language ("pricing page, 3 visits from 2 people, last 4 hours").
Components: routing rules keyed to action window rather than to signal source: a live-response lane for signals measured in minutes and hours, an assigned-owner lane for signals measured in days, and an automated nurture lane for signals measured in weeks. SLAs per lane, owner lookup and suppression of accounts in open opportunities. Built in a workflow tool such as n8n or Workato, a platform such as Clay, or middleware code.
Contract to the system of record: one routing decision per signal event, with lane, owner, due_at and the decay state at decision time.
Components: a Signal object related to Account and Contact (or a signal history in the warehouse synced back by reverse ETL), tasks and alerts for reps, sequence enrollments, and agents that draft outreach from the reason text.
Contract: no activation reads a signal without its age. Every task, enrollment and agent draft shows when the underlying event happened, and anything past expiry is suppressed from copy automatically.
The decay model fits on one screen. These half-lives, action windows and expiry periods are illustrative assumptions, not empirical benchmarks. Replace them with your own conversion-by-age data:
freshness(signal) = strength * 0.5 ^ (age_hours / half_life_hours) age is measured from event_at when known, otherwise observed_at signal_type half_life action_window expiry lane inbound_hand_raise 4h 1h 3d live pricing_page_repeat 2d 24h 14d live intent_topic_surge 7d 5d 30d owner champion_job_change 21d 30d 120d owner hiring_relevant_role 21d 21d 60d owner funding_round 30d 21d 90d owner tech_install_change 45d 30d 120d nurture route if account_signal_score >= threshold and not in_open_opportunity suppress copy references when age > expiry
Build sequence
Six steps, in order, each ending in a test.
Inventory every signal and its clocks
List every signal source, where it lands, which fields and flows read it and which of the three timestamps you actually keep. The diagnose-before-you-build playbook covers how to do this read-only. Test: for each signal type you know where it is stored, who acts on it and whether its age is known.
Move signals from fields to events
Create the signal event table or object, route every source into it with event_at, observed_at and received_at, and resolve each event to a canonical account and person. Test: a new signal of each type appears as an event row within the expected ingestion lag, tied to the right account.
Measure end-to-end latency on the last 90 days
For every signal that led to a touch, compute time from event to first action, broken down by hop: detection, ingestion, list refresh, sequencer import, rep pickup. Test: you can name the single slowest hop for each signal type, in hours or days, from data rather than memory.
Calibrate half-lives on your own outcomes
Start from the suggested values above, then bucket historical signals by age at first touch and compare meeting and opportunity rates across buckets. Test: each signal type has a half-life and action window supported by your own conversion data or explicitly marked as an assumption to revisit.
Wire the lanes, SLAs and expiry
Build the live, owner and nurture lanes, replace batch hops on fast-decaying types with event-driven triggers, add suppression for open opportunities, and expire signals past their window. Test: in a sandbox, a pricing-page signal reaches an owner inside its action window, and a 100-day-old funding signal produces no task and no copy reference.
Replay real cases before go-live
Run around twenty recent signals through the new layer and compare its lane, owner and timing with what an experienced operator says should have happened. We hold every system to the same bar: 85 percent agreement on the client's own past cases, or it does not ship. Test: agreement clears the bar, and every disagreement has a named cause in the config.
Build vs. buy: trade-offs
Where the logic runs matters less than whether signals are stored as timestamped events.
| Approach | Fit | Cost of ownership | Failure risk |
|---|---|---|---|
| Native CRM (signal fields or a custom Signal object, record-triggered flows, CRM scoring) | A handful of signal types, one or two providers, a lean RevOps team, signals mostly inbound | Lowest. Admin skills you already have and no new licences | Tends to collapse events into checkboxes; decay math in formula fields gets brittle; batch imports set the latency |
| Workflow or signal platform (for example Clay for enrichment and signal tables, n8n or Workato for event-driven routing) | Several third-party sources, a technical RevOps owner, a need to test new signal types quickly | Moderate. Platform licensing, provider credits and an owner for every table and workflow | Easy to rebuild the same batch schedule in a new tool; decay and expiry must be designed on purpose |
| Custom event pipeline (webhooks into a queue, event table and decay model in the warehouse, reverse ETL and real-time triggers to the CRM) | High signal volume, product-led motions, an existing data team, agents acting on signals | Highest. Engineering time, monitoring, on-call and provider contract management | Most control over latency and history; the risk is sophisticated plumbing with nobody owning the half-life calibration |
A reasonable default between Series A and Series C: keep the event table and decay configuration somewhere you own, use a workflow tool for event-driven routing of the fast lanes, and let the CRM hold the Signal object and the tasks.
Running it in production
Track, per signal type: volume, detection and ingestion lag, time from event to first action, share of signals actioned inside their window, conversion by age bucket and the share that expired untouched. A rising expired-untouched rate means capacity, not data, is the constraint.
When a source stops sending events, alert on the silence rather than assuming no signals. When the live lane breaches its SLA, reassign to a backup owner. Expire rather than escalate: a signal past its window goes to nurture or is suppressed.
Leadership needs three statements: we know how many days pass between a buying signal and our first touch, by signal type; we act on the fastest-decaying signals inside the window where they still change outcomes; and every opportunity shows which signal started it and how old it was when we moved.
Where this fits in the system
Signal freshness sits between the signal and orchestration layers of the GTM data stack: identity resolution decides which account and person an event belongs to, enrichment adds context, and the decay model decides how urgently orchestration should act. The Signal-Based Outbound Engine is where this design runs end to end, from a buying-intent trigger to a routed, timed and personalized touch: see Signal-Based Outbound in action. Speed-to-Lead covers the fastest-decaying signal of all, the inbound hand-raise, where the window is measured in minutes. The Handoff Orchestrator keeps the signal and its age attached when an account moves from SDR to AE, so context does not decay at the handoff either. The full map is on the systems page.
Build the clock before you buy another signal source. A forward-deployed engineering approach measures how long your current signals actually wait, calibrates half-lives on your own history and proves the routing on your past cases.
Sources: 6sense, The B2B Buyer Experience Report 2025 (November 2025); CustomerThink's summary (61% first-contact timing). Oldroyd, McElheran and Elkington, The Short Life of Online Sales Leads, Harvard Business Review (March 2011); Yesware's quotations. Gartner, B2B buying journey research. US Bureau of Labor Statistics, JOLTS, August 2026 (released September 29, 2026). Forrester, The State of Business Buying, 2024 (December 2024).
