A founder liked a post. A company raised a round. Someone changed jobs, according to a headline that updated last night. A lead's score just crossed 80. Each of these arrives in an outbound tool as a "signal", and in most tools a signal means one thing: send.
That is the mistake. An event is a fact about the world. Intent is a claim about a person. The distance between the two is where most bad outreach comes from, and it is a distance you can measure. This article is the decision model we enforce in our own system, written as a rubric you can apply by hand to any list, in any tool, before a message goes out.
Two clocks
Every event has two times, and confusing them is the most common error in the category.
Event time is when the thing happened. The job started in March. The post was published on the 4th. The funding round closed in Q2.
Detection time is when your tool noticed. The profile was re-scraped last night. The post surfaced in a feed today. A news article ran this morning about a round that closed nine weeks ago.
Every tool has detection time, because that is when the row appeared. Far fewer carry event time, because it has to be read from somewhere: the start date in the experience entry rather than the diff between two scrapes, the publication timestamp encoded in a post's id rather than the day the scraper saw it, the dated announcement rather than the day the news aggregator picked it up.
Age is measured from event time, always. "Changed jobs in the last 90 days" is a question about the world, not about your scraper's schedule. A tool that measures from detection time will present a year-old job change as this week's, because it only just found out, and the opener will say "congrats on the new role" to someone who has been there since last spring. That is the single most recognisable tell of automated outreach, and it comes from reading the wrong clock.
Our rule: if an event's time is unknown, treat it as the detection time and mark it as such, but never present it as fresh. If the event time is known and already past the window, do not store it at all. A signal that is born expired only costs reads and confuses whoever looks at the record.
Expiry
Every event type has a shelf life, after which it stops being a reason for anything. The windows we use, measured from event time:
| Event | Window |
|---|---|
| Reaction, comment or repost on a post | 30 days |
| Connection accepted | 30 days |
| Headline change | 60 days |
| Job change, title change, seniority change, location change | 90 days |
| Joined a watched group, attended an event, joined a watched company | 90 days |
| Company funding round, leadership change | 90 days |
| Company hiring surge, department expansion | 45 days |
| Company headcount growth or decline, layoff | 60 days |
| A message of yours ignored | 90 days |
| A connection request ignored or declined | never expires |
Two things to notice. Engagement decays fastest, because it is the weakest evidence and the most tied to a moment. And the last row does not decay at all, because it is not a reason to reach out. It is a reason not to. A declined connection request is the person telling you something, and it stays true.
You can argue with any number in the table, and you should set your own. What you cannot do is leave them unset, because an unset window means "forever", and forever is how a like from February ends up in an opener in September.
Source reliability
Not every source that reports an event is equally likely to be right about it.
- The platform itself, read directly. A profile's experience section. A post's reactions list. A company's announcement page. High reliability, with one caveat: fields lag. A headline updates when the person remembers to update it.
- A diff between two of your own observations. You scraped the title in May and again in August, and it differs. Reliable about the fact of the change, unreliable about when: the change happened somewhere in the gap, and if the gap is three months, "recent" is a guess.
- A third-party data vendor. Reliable in proportion to how recently they refreshed the record, which they rarely tell you. A vendor's "new in role" flag with no date behind it is a detection-time signal wearing an event-time label.
- A model reading unstructured text. A classifier that decided a news article describes a funding round. Useful, and wrong often enough that we require a second confirming fact before it counts: the company name matching a known entity, an amount, a date. A name match alone is not corroboration.
The rubric asks one question here: could this source be wrong about whether the event happened, and could it be wrong about when? Each "yes" pushes the event down a tier.
Evidence strength
Now the harder question: assume the event is real and recent. What does it actually say about the person?
This is where the category is weakest, because it flattens everything into "intent". Here is a more honest ladder, from weakest to strongest.
- Passive attention. A reaction on a post. The person saw a topic and pressed a button. It says "this topic is in my feed and I did not scroll past it". It does not say they have the problem.
- Expressed opinion. A comment. Now you know what they think, and you can quote it. Still says nothing about budget or timing.
- A change in their situation. New job, new title, new seniority. The person's world moved. Whether it moved toward you depends entirely on what the new situation is.
- A change in their company's situation. Funding, headcount growth, a leadership change. A reason the company might buy, with the person as a proxy.
- Direct contact with you. Accepted your connection request, replied to a message, attended your event. The only tier where the person did something involving you.
- An explicit ask. They asked a question you can answer, commented "how do you handle X", requested the resource. Rare, and the only tier that resembles what the word "intent" claims.
Most signal-based outreach runs on tiers 1 and 2 and writes openers that assume tier 6. The fix is not to ignore tiers 1 and 2. It is to write to their level: a reaction earns a message about the topic, not a message about the person's supposed evaluation of your product.
ICP fit, separately
An event happens to a person. Whether that person is worth reaching depends on who they are, and that is a different question with a different answer.
Keep them apart. Score the person against your ICP on the facts that do not change day to day: company size, industry, role, seniority, geography. Then let the event add to that score, weighted by its tier and decayed by its age. In our system the arithmetic is literally one number added to another, and the event's contribution is capped so that a perfect event on a wrong-fit person never outranks a quiet person who fits.
The practical consequence: a founder at a two-person company who wrote a long, thoughtful comment on your post is a great conversation and a poor lead, and the rubric should say so. The comment is tier 2 with high strength. The fit is low. The right action is to reply to the comment, in public, and not to add them to a sequence.
Prior relationship
The last input, and the one that overrides the others.
- They opted out, bounced, or asked to be deleted. No event on any tier changes this. A high score and a fresh signal on a suppressed person is a bug in the pipeline, not an opportunity.
- They are a client, a competitor, or a colleague. Same. These are exclusion rules, and they are re-checked at the moment of sending, because a person becomes a client after the list was built.
- You wrote to them recently. An event on someone already in a thread with you is a reason to continue that thread, not to open a new one. Two openers from one sender is the fastest way to become the vendor everyone screenshots.
- They ignored or declined you before. The never-expiring row in the table. Not a hard block, but the bar for a second approach is a tier 5 or 6 event, not a like.
The rubric
Put together, for any event on any person, in order:
- Is the event real, and when did it happen? Source tier and event time. Unknown time is detection time, and it is not fresh.
- Is it inside its window? From the table, measured from event time. Outside, discard.
- What tier of evidence is it? One to six. Write the tier down, because it decides what the message may claim.
- Does the person fit? ICP score on the stable facts, event added on top, capped.
- What do you already know? Suppression, exclusions, recent contact, prior refusals. Any hit here stops the process regardless of the answers above.
- Research, or send? Tiers 1 to 3 on a fitting person are a reason to research: enrich, verify the company, read what they said, decide. Tiers 4 to 6 on a fitting person, with nothing in step 5, are a reason to send, at the level the tier supports.
Five counterexamples, run through it:
- A year-old job change discovered today. Step 1: event time is a year ago. Step 2: outside 90 days. Discard, and never say "congrats on the new role".
- A founder liking a post. Steps 1 and 2 pass. Step 3: tier 1. Step 4: depends entirely on the company. Step 6: research, not send, and if it becomes a send, the opener may mention the topic and nothing else.
- A company funding announcement. Step 1: which date, the close or the article? Use the close. Step 3: tier 4, about the company. Step 4: which people at that company fit. Step 6: send to the ones who fit, with the round as the reason for timing, not as evidence they want you.
- A relevant comment from a vendor. Steps 1 to 3 look great: fresh, tier 2, quotable. Step 4: they sell what you sell. Fit is zero. Reply in public if you like; do not sequence.
- A high-scoring lead who already opted out. Steps 1 to 4 all pass. Step 5 stops it. This is the case the rubric exists for, and the one most tools get wrong, because the score is computed in one place and the opt-out lives in another.
What this looks like when it runs by itself
Everything above works in a spreadsheet, one list at a time. The difficulty is that step 1 has to be re-read from the source, step 2 has to be re-run every day because windows close, step 4 has to be re-run whenever the ICP changes, and step 5 has to be re-run at the moment of sending, because a person can opt out between the list being built and the message going out.
That is what CampaignStack does continuously rather than once: each signal stores its event time separately from its detection time and expires on the event clock, born-expired signals are refused at write time, the score is the ICP number plus a capped, decayed signal number that is recomputed when either side changes, and exclusions and prior contact are checked again at dispatch for every workflow, not only at import. The post-engagement playbook is the manual version of this rubric applied to one post; this article is the general rule.
But the rubric comes first. A tool that turns every detected event into a message has automated the mistake. The point of writing the model down is that you can hold any tool, ours included, to it.