The direct answer
A public event is an observation, not proof that a company intends to buy. Use it to prioritize a narrow research question only when you can retain the exact source, date, permitted interpretation, expiry rule, and an action that is safe if the hypothesis is wrong.
A job posting, product launch, expansion announcement, regulatory filing, or executive change may be relevant to your offer. None automatically proves budget, timing, ownership, urgency, or permission to contact. The discipline is to record what the source says, what it reasonably allows you to investigate next, and what it does not establish.
1. Build a trigger-evidence ledger
The ledger makes the important distinction visible: evidence is what occurred; priority is your internal decision; intent is not assumed.
2. Use source classes deliberately
Prefer a company-controlled or authoritative source for the observation. A third-party source may be corroborating context when the field contract records why, but it is not sufficient by default for a material claim. If you begin with a third-party signal, find primary evidence before creating a strong claim. A page can disappear or change; a checked date matters as much as a URL.
3. Add stale, conflicting, and no-result states
Do not collapse every field into yes/no. A current, direct observation may be supported; an expired page is stale; credible sources that disagree are conflicting; no acceptable source is no result. Each state needs a different action. No result means no priority based on that trigger—not “the account has no activity.”
Use the trigger-evidence ledger
Download the trigger-evidence ledger. For each observation, record the source and date, the narrow statement it supports, the tempting but unsupported inference, a safe next action, and an abstain condition. Assign every row one controlled sample_group: signal, no_signal_control, ambiguous, or known_false_positive. Record the named next action before and after review, then set next_action_changed to yes only when those two values differ. A job post can support “this role was publicly listed on this date”; it cannot on its own support “the company is buying software.” The ledger makes that distinction auditable across a 20-account pilot.
4. Test whether a trigger is useful
Run a 20-account, time-boxed pilot. Include accounts with the signal, without the signal, ambiguous evidence, and known false positives; record these as the controlled sample_group values in the ledger. For each, independently review account fit, role relevance, and the next allowed action. Twenty accounts is an operational, directional workflow pilot—not a statistically powered estimate of demand, revenue, or causal uplift. Then compare:
- source-supported observation rate;
- reviewer agreement on the permitted statement;
- accounts whose priority changed after full account review;
- false-priority rate; and
- review time per account whose next action genuinely changed.
Do not declare a trigger “high intent” from a handful of positive anecdotes. Your pilot can show that a specific observation is a useful research priority in one segment and time window. Repeat when source availability, ICP, market, or offer changes.
5. Keep the message separate from the observation
This workflow ends at a reviewed priority decision. If a campaign is later permitted, message review has its own evidence, policy, and approval requirements. Do not turn a job post into a personalized claim the source does not support. The next safe action may be more account research, a generic approved message, or no action at all.
6. Start with a decision question, not a list of signals
A useful trigger workflow begins with a narrow decision that a team can change. For example: "Which already-ICP-qualified accounts deserve a company review this week because a current first-party observation could make the service-operations problem more relevant?" That question has boundaries. It requires an account to fit the ICP first, names the source standard, and ends in review rather than a claim that the company is buying.
By contrast, "find intent signals" is not a research question. It invites a mixed list of job posts, funding articles, social posts, and generic news, each with a different meaning and expiration. The result can look precise because it has a score, while the evidence and action remain undefined.
Write the trigger contract before collecting accounts:
If a sentence cannot fit into one of these rows, it probably belongs to a different process: ICP qualification, contact research, campaign review, or customer intelligence. Do not add it to the trigger score merely because it is interesting.
7. Work two examples all the way through
Example A: a job posting is an observation, not an implementation plan
A company-controlled careers page displays a role titled "Field Service Systems Manager" in a target country. On the observation date, the ledger can safely say: "The company publicly listed this title on its careers page." It can also record that the posting is relevant enough to ask an account reviewer whether the account fits a service-operations segment.
It cannot safely say that the company is buying field-service software, has an approved project, has budget, or that the job holder is the buyer. The job may be a replacement, a speculative role, a third-party hiring page error, or only one small part of a much larger organisation. A removal from the page does not prove the initiative ended. Those are reasons to label the event as a time-bound research input rather than a purchase prediction.
A review outcome might be: account already meets the ICP; source is current; role family is plausible but unverified; next allowed action is to research the company's operating context. It might also be: account does not meet ICP; do not prioritise. Both outcomes validate the discipline because the event did not override the account rule.
Example B: an expansion announcement does not establish a local problem
An official announcement says a company opened an office in a new country. The ledger may state the opening, source date, and location exactly as published. A team can use it to check whether the entity, market, and offer are relevant. It must not convert an office opening into a claim about headcount, deployment needs, procurement schedule, or an approved contact action.
If the announcement is from a parent company, first resolve whether the named entity is the account in the Sheet. If it is a subsidiary, branch, or unrelated company with a similar name, record the identity uncertainty and abstain until that is resolved. This is why trigger research cannot replace the separate market-map or entity-resolution workflow.
These examples are deliberately bounded. They demonstrate how to retain an observation and a permissible internal priority decision; they do not prescribe what to say to a person or assert facts about real accounts.
8. Collect evidence in a repeatable order
For each selected account, follow the same sequence so a reviewer can find the weak point:
- Confirm the account identifier and ICP state before opening the trigger source. A signal is not a substitute for the right entity.
- Capture the original source URL, page or publication title, source class, and observation date. Do not rely on a search result preview or an unlinked summary.
- Write a narrow observation in words that the source itself supports. Quote only what is necessary for the internal record; link to the source for the full context.
- Write the tempting inference in a separate column. Seeing it written down makes it easier for a reviewer to reject unsupported personalisation.
- Choose one safe next action and one abstain condition. An action such as "review account fit" is safer and more testable than "contact immediately."
- Set a review or expiry date. Do not keep an old signal indefinitely merely because it once produced a useful account.
The ledger supports this sequence. A Leadbase research output can be a useful starting point for a defined field, but the team still needs to inspect whether the returned source and summary satisfy its contract. Confidence is not a substitute for source relevance, identity resolution, or an approved decision.
9. Design a fair pilot before naming a signal useful
Choose one segment, one observation type, one source standard, and a limited time window. Then take a small, deliberately mixed sample: accounts with a current qualifying observation; accounts without it; ambiguous sources; and known false positives such as the wrong entity or an expired page. Do not let the reviewer know only the attractive positive examples.
For every sampled account, ask an independent reviewer to record the permitted statement, source sufficiency, account-fit result, and safe next action. Compare the trigger-led priority with the decision after normal account review. Your pilot ledger can calculate, for example:
- Source-sufficiency rate: accounts whose retained source met the contract ÷ accounts reviewed.
- Priority-change rate: accounts whose review priority changed for the defined reason ÷ accounts reviewed.
- False-priority rate: trigger-prioritised accounts later rejected because the evidence, entity, or ICP basis failed ÷ trigger-prioritised accounts.
- Reviewer disagreement rate: records where reviewers disagree on the permitted statement ÷ doubly reviewed records.
None of these metrics measures purchase intent or revenue. A low source-sufficiency rate means the observation definition or source rule needs work. A high disagreement rate means the permitted statement is too loose. A useful result can be "do not use this trigger in this segment"; that protects the team from a persuasive but untested score.
Keep each metric's denominator in the ledger
Use controlled values, not reconstructed notes. For the four headline measures, calculate source_sufficient = yes divided by rows with reviewed_at; a priority change where priority_after_review differs from priority_before_review, divided by reviewed rows; later rejections with later_rejection_reason among rows initially marked prioritised, divided by initially prioritised rows; and reviewer_agreement = no divided by rows with a named second_reviewer. Calculate review time per genuinely changed next action as the sum of review_minutes where next_action_changed = yes, divided by the count of those same rows; require next_action_before_review and next_action_after_review to differ before setting that flag. Do not use a priority change as a proxy for an action change. Empty, abstained, or unreviewed rows must remain in the ledger, but not silently enter a denominator that their status does not meet. The downloaded template names these fields so another reviewer can reproduce the rates.
Audit a trigger-evidence pilot
Turn a trigger-evidence pilot into auditable rates with explicit denominators for sources, reviewer agreement, changed actions, and later rejection.
A changed priority is not a changed action. Count an action change only when the named before and after actions differ.
Among 20 reviewed rows, 12 have sufficient sources and 4 change the named next action. Reviewer agreement is 80%; later rejection is 25% of initially prioritised rows.
| Pilot rate | Result |
|---|---|
| Source-sufficient rate | 60% |
| Second-reviewer agreement rate | 80% |
| Named-action change rate | 20% |
| Later-rejection rate | 25% |
| Review minutes per changed action | 60 |
Compare evidence and decision-quality rates without relabelling them as purchase intent or revenue impact.
Source sufficiency and action change divide by all reviewed rows. Reviewer agreement divides by second-reviewed rows. Later rejection divides by initially prioritised rows. Review time per changed action divides total review minutes by genuine named action changes.
These measures test whether an observation changed a controlled research decision. They do not measure purchase intent, causality, conversion, pipeline, or revenue.
10. Decide when to abstain or retire a trigger
Put stop rules beside inclusion rules. Abstain when the source is not available to the reviewer, the entity cannot be resolved, the source is outside the defined window, or the statement needed for the next action goes beyond the source. Hold the account when the observation is interesting but the controlling policy or account-fit review is unresolved. Retire or redesign a trigger when the pilot repeatedly produces ambiguous evidence, false priorities, or actions that recipients cannot distinguish from unsupported outreach instructions.
This creates a more credible queue than treating every observed event as a lead score. The absence of a trigger is not negative evidence about a company; it only means this particular workflow has no current, contract-compliant reason to prioritise further research.
11. Keep trigger research separate from adjacent work
Trigger research answers whether a dated observation warrants a bounded review. It does not build a market map, establish a buying-committee hypothesis, verify a person, or determine a message's compliance. Send a trigger-prioritised account through those relevant processes only after the evidence and allowed next action are clear. That separation preserves the useful part of a public observation without inflating it into a claim Leadbase cannot make: a real-time intent feed or an autonomous buying prediction.
12. Review the language that leaves the ledger
The most careful evidence record can still fail when its wording is compressed for a queue, brief, or message. Before sharing a trigger-derived note, compare it with the permitted statement. Replace "is expanding rapidly" with the exact published observation; replace "needs a solution" with "may warrant account review"; remove a claim about a named person unless a separate person-research record supports it. If a concise version cannot preserve the boundary, keep the source link and do not use the shorthand as a claim.
Use a second reviewer for high-impact or ambiguous events. They need not agree that the account is attractive; they need to agree that the record says no more than the source supports and that the proposed next action is safe if wrong. Disagreement is useful evidence that the trigger definition needs a narrower statement or clearer abstain rule.
Run a final source check at the moment of use
For a time-sensitive trigger, check the retained source again immediately before using the record in a priority review. Record whether the page is still available and whether its material statement is unchanged. This is not a claim of real-time monitoring; it is a deliberate reviewer action for the small set of accounts whose next step depends on recency. If the source has disappeared, changed materially, or cannot be checked, apply the contract's stale or abstain rule. Do not replace that uncertainty with a stronger summary merely because a previous run found the page.
13. Do not compare different events under one number
A job posting, a register entry, and an expansion announcement can all lead to a priority queue. They should not, however, be blindly added under one "intent score." They come from different source classes, expire under different rules, and support different statements. A higher score might otherwise mean only that an account has more public mentions, not that a specific purchase-relevant hypothesis is better supported.
When your team tests several event types, give each one its own contract, source standard, expiry, and pilot assessment. Do not compare alleged demand; compare practical properties instead: How often was the source sufficient? How often did the observation actually change priority after account review? How many records were unusable because of entity, expiry, or evidence failure? Only after those questions are answered can a team decide whether two event types may trigger the same bounded review action.
14. Treat time as a property of the statement
For triggers, an observation date is not decoration. "The company listed a role on 8 August" and "the company is seeking this role" are different statements. The first is tied to a source and date; the second implies a present condition that may no longer be supported after the expiry window. Word the ledger statement so its timing remains visible, and define when it no longer qualifies as a reason to prioritise research.
This does not mean every source needs the same short expiry. An official register entry may be relevant for a different question and for longer than a careers page. The key is that the expiry follows the permitted action. An observation used only to enrich a later market map may follow a different rule from one used for review this week. Do not adopt a universal number of days without that connection.
15. Prevent feedback loops that retrospectively confirm the trigger
A dangerous assessment looks like this: an account with a trigger receives more attention, gets a better research note, and is then counted as proof that the trigger worked. That confuses extra effort with signal value. Use a comparison group without the trigger and document the same depth of account review for all groups. If only the trigger group receives intensive review, a higher number of found relationships says nothing about whether the original event was a useful priority.
Also record when a reviewer reinterprets the original observation later. Moving from "a role was listed" to "the team is modernising its processes" is a new hypothesis that needs its own evidence. It must not retrospectively make the initial trigger look stronger. A clean pilot retains the first permitted statement and separates later discoveries from it.
16. Maintain a small trigger library with decisions
After a pilot, you do not need a large catalogue of signal names. Maintain a concise library that records, for each tested trigger, its population, permitted observation, source class, expiry, safe action, stop rule, and pilot decision. For example: "Careers page with a defined operations role; only for already qualified accounts; prioritise account review; make no purchase or buyer claim; recheck before the next use."
Include rejected triggers too. An event type whose sources were often unavailable or whose reviewers strongly disagreed protects the team from repeating the same apparently new idea later. The library is not a proprietary intent feed or a global market claim. It is the traceable memory of your own tests and decisions.
Make your own signal operational
Predefined intent products classify events within the provider's taxonomy and scoring model. Leadbase supports a different job: take the specific public change your team believes matters, turn it into one focused research field, and keep the observation, source, date, confidence signal, reviewer decision, and next action together.
Your signal does not need to exist in somebody else’s taxonomy. It needs a precise observation rule and a safe action when the hypothesis is wrong.
That is what makes the custom signal usable. A hiring page, expansion announcement, or other public event does not become “intent” because a model found it. It becomes a testable input because the team can inspect the source, separate the observation from the inference, leave conflict or no-result visible, and measure whether the review actually changed priority or action.
Leadbase is not proprietary intent data, real-time event monitoring, or an automatic account-scoring engine. It does something more controllable for custom questions: it gives your own source-linked hypothesis a structured place to run on selected accounts and be challenged by a reviewer. Create one trigger-evidence pilot and make the first decision whether the signal deserves to exist at all.
Trigger-release checklist
- The source supports the narrow observation verbatim or in faithful summary.
- Permitted statement and unsupported inference are written separately.
- Freshness and abstain rules are set before review.
- The action is safe if the hypothesis is wrong.
- A control sample tests false priorities.
- Campaign eligibility is not inferred from the event.
