Trigger events for outbound: funding, leadership and launches

A trigger event is a dated change at a company that gives a seller a reason to get in touch now and something specific to say. This guide covers the 13 event types Fokals classifies in company announcements and regulatory disclosures, what each can open for a seller, how a leadership change is read by role, and a method for ranking the triggers that arrive each week.

What makes an event a trigger

Three tests separate a trigger from news. The event must be dated, so you know its age. It must create a decision your product can serve, such as a budget, a new team, a new market or a vendor review. And it must still be actionable when you see it.

Announcements pass the first test well, because each carries a date, normally the one the company published. They pass the second for the event types that create a need, which is why the types matter. A company announces what it has done, so for earlier warning pair announcements with the signals described in timing outreach with hiring signals.

Where the events come from

Fokals collects announcements from company newsrooms and feeds, and regulatory disclosures from listed companies, and classifies each item into one of 13 event types from a fixed list, under frozen label versions. A disclosure is classified by the items it is filed under, which say what was filed: a material agreement maps to partnership, a completed acquisition to acquisition made, a restructuring to layoffs and restructuring, an unregistered equity sale to funding round, a change of control to acquired or merged, an officer or director change to leadership change and a security incident to incident.

Everything lands in Company News (company_news) in the announcements dataset, one row per announcement, with at, title, url, event_types, the disclosure items where there are any, and an excerpt of the company's own text. A newsroom item carries one event type, and an item that is not about the company itself carries none. A disclosure filed under several items can carry several types.

The 13 event types as triggers

The right-hand column is what the event can open for a seller. It is a prompt to test and not a rule.

Funding has a second trace in a second dataset. Company Funding (company_funding) holds private capital raises reported in regulatory filings, with the amount offered, the amount sold and the date of first sale, filed within 15 days of a first sale, and it belongs to the intent dataset. The notice and a funding round announcement can describe the same round, so join them on company and a window of dates and count the round once. Where only one exists you still have a trigger, and the guide to following private capital raises covers how to read the notice.

Leadership changes by role

For a leadership change, the company's own text is read once more under a frozen version to give the role concerned. In a query, roles holds the role and role_labels the full reading, with the direction (appointed, departed or succession) and a flag when more than one role changes. The record is built around the seat, so the trigger tells you which seat changed, and the owner of your account research adds who sits in it. The roles, and what a seller might read into each:

• ceo: strategy and vendor reviews at the top; relevant to offers that span the company.
• cfo: finance systems, spend management, audit and treasury.
• coo: operations, supply chain and process tooling.
• cro_cso: the revenue, sales or commercial leader, so sales and revenue tools, data and enablement.
• cmo: marketing platforms, agencies, analytics and advertising.
• cto_cio_cpo: engineering, IT and product tooling, infrastructure and security.
• chro: HR, recruiting and workforce tools.
• general_counsel: legal, compliance and contract tools.
• board: rarely a trigger for a sale, and useful context for strategy.
• other_executive and none: read the text.

Read the direction before the role. An appointment is the usual trigger, since a new leader often reviews tools and vendors. A departure leaves a vacancy, during which a purchase can stall. A succession announces a change that has not happened yet. Match the role to the buyer you sell to and ignore the rest.

Ranking the triggers

Fit decides whether a company is on your list. Relevance and age decide where a trigger ranks on it.

1. Fit first. Restrict to the accounts that match your target list. A trigger at any other company is noise.
2. Relevance. Give each trigger a weight from the need it creates for your product, from 0 for none to 3 for a direct need. Weight a leadership change by role: a cro_cso appointment may be 3 for a sales tool and 0 for a security product.
3. Freshness. Fade the weight by half every 30 days, the half-life Fokals uses for its own intent signals: score = weight × 0.5 ^ (age in days / 30).
4. Corroboration. Where two traces describe one event, such as a newsroom item and a regulatory disclosure, count it once and keep the earlier date.
5. Sum per account and sort.

The query below does steps one, two, three and five. target_accounts is your own list of company_id values, and trigger_weights is your own table of a trigger_key and a weight. A key is an event type, or leadership_change: and a role, such as leadership_change:cro_cso. A trigger with no row scores nothing. It assumes JSON cells are loaded as jsonb and empty cells as null.

with triggers as (
  select n.company_id, n.at, e.value as trigger_key
  from company_news n
  cross join lateral jsonb_array_elements_text(n.event_types) as e(value)
  where n.at >= now() - interval '60 days'
    and e.value <> 'leadership_change'
  union all
  select n.company_id, n.at, 'leadership_change:' || r.value
  from company_news n
  cross join lateral jsonb_array_elements_text(n.roles) as r(value)
  where n.at >= now() - interval '60 days'
)
select
  t.company_id,
  round(sum(w.weight * power(0.5, extract(epoch from now() - t.at) / 86400 / 30))::numeric, 2) as score,
  array_agg(distinct t.trigger_key)                                                             as triggers,
  max(t.at)                                                                                     as latest
from triggers t
join trigger_weights w on w.trigger_key = t.trigger_key
join target_accounts a on a.company_id = t.company_id
group by t.company_id
order by score desc
limit 50;

The example is illustrative: Acme Robotics is an invented account, and the weights are invented for a seller of sales tools. Each row is one trigger inside the 60-day window, scored as the query scores it.

Acme ranks first with 4.50 because two triggers of different kinds agree, and the freshest trigger of all, a launch two days old, ranks last because it matters least to this seller. That is the purpose of weights and of summing, and the weights are yours to change as results come in.

How to read a trigger

• Dates. The announcement date is the date the company published the item. When a source gives none, the date is the day the item was first seen, so a newsroom page without dates can make an old item look new. Check the link and the excerpt before you act on a trigger that seems too good.
• Duplicates. One event can appear in a newsroom, in a feed and in a disclosure. Deduplicate by company, event type and a window of days.
• Labels. Event types are produced under frozen versions, and a column says which version read a row. A disclosure type is as specific as the items it is filed under, so read the excerpt for the detail.
• Negative triggers. Layoffs, incidents and the sale of the company are triggers for some products and reasons to stay quiet for others. Decide per product, in the weights.

What announcements give a seller

Announcements are what a company chose to say, when it chose to say it, in its own words and with its own date. That makes them a clean, citable reason to write: a trigger carries a link to the original and an excerpt a rep can quote. They tend to arrive at or after the event, so pair them with the earlier signs in hiring and website changes. A trigger names a role, so the rep takes the role to the CRM and finds the person there.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.