ZoomInfo Scoops: Which Trigger Events Earn a Message, and When to Send It

Picture a Series B announcement going out first thing on a Tuesday. By lunchtime the VP of Operations named in it has a stack of congratulatory emails, several of them opening with more or less the same sentence. Every one of those senders had a trigger-event feed working exactly as designed. The feed was never the problem.

Scoops is ZoomInfo's name for that feed. This page covers two things: what Scoops actually is according to ZoomInfo's own documentation, and the harder question underneath the search, which is which of those events deserve a message at all and what you do in the hour after one fires.

What Scoops is, in ZoomInfo's own words

ZoomInfo's Search Scoops API reference defines them directly: "Scoops are real-time business intelligence signals that provide timely insights into significant events and changes occurring at companies. These actionable data points help sales and marketing teams identify opportunities and engage prospects at the right moment."

Scoops sits inside a wider structure that ZoomInfo documents on its Signals and Insights page. That page states ZoomInfo captures 50+ signal types, and it draws a distinction worth carrying into your own vocabulary.

Signals are the raw buying and business activities you can search. An employment change signal, in ZoomInfo's own example, records that a contact has joined, left, or changed roles at a company.

Insights are curated: ZoomInfo describes them as generated by enriching one or more signals with account context, buying groups, ownership, CRM data and recency. Its example is a buying group change, where a contact belonging to your buying group joins a named account, which surfaces a potential opportunity against your existing customer or opportunity data.

The signal categories ZoomInfo enumerates on that page cover corporate and financial events (funding, IPO, M&A, hiring plans, product launches, partnerships, earnings call summaries, projects, pain points), person moves (employment changes, layoffs, person news, podcasts), intent, and website or technology changes such as technology added or dropped.

Sources are named as three: ZoomInfo's own proprietary intelligence, your first-party data from CRM, email, calendar and meeting summaries, and partner signals, described as trusted third-party data from partners such as G2 and TrustRadius.

Two constraints from the same page matter before you build anything on this. ZoomInfo states that the availability of Signals and Insights varies by ZoomInfo package. And Insights, as distinct from Signals, are documented as available only for configured target accounts in the Copilot package.

SignalsSearchable across the database

• Raw buying and business activities you can search and analyse.
• Reached through the Search Scoops, Search News and Search Intent APIs.
• Available across all companies and contacts in ZoomInfo's data.
• Example given by ZoomInfo: an employment change, where a contact has joined, left or changed roles.

InsightsCurated against your accounts

• Signals enriched with account context, buying groups, ownership, CRM data and recency.
• Reached through the Get Insights by Type API.
• Documented as available only for target accounts configured in the Copilot package.
• Example given by ZoomInfo: a buying group change, where a contact in your buying group joins an account.

Getting at Scoops without a seat in the UI

Two endpoints do the work, and the split is the useful part. ZoomInfo documents POST /data/v1/scoops/search for finding Scoops across all ZoomInfo companies, and POST /data/v1/scoops/enrich for retrieving Scoops on a specific company you already care about. That maps cleanly onto the two real jobs: discovery across a market, and monitoring of a named account list.

Access is gated by its own OAuth scope, api:data:scoops, listed among the scopes ZoomInfo publishes in its developer documentation. So a licence that reaches contact data does not automatically reach Scoops, which is worth checking before scoping a build rather than after.

The commercially interesting detail is on the search endpoint. ZoomInfo's reference states that Search Scoops does not consume any credits. Each Scoop returned counts toward the account's Record Limit, and a successful response counts toward the Request Limit, with the documentation's own worked example: a response returning 10 Scoops counts as 10 Records and 1 Request. Signal discovery is therefore metered differently from contact enrichment, which is a genuinely useful asymmetry when you are deciding how wide to cast the net.

ZoomInfo also documents webhooks as an alternative to polling. Its webhooks page says they notify your application when long-running jobs complete, records change, credit thresholds are reached, or new GTM signals become available, and notes that those signal notifications come via its Agents API. That is the difference between a feed reaching you when something happens and a job finding out on its next scheduled run, and on a play where the timing window is the whole point, it is the build decision.

For completeness: Scoop search existed on the legacy Enterprise API as POST /search/scoop, and that legacy API documentation states it is in the process of being deprecated, with new development directed to the current documentation. If you inherit an integration pointing at the old path, that is your migration.

Which triggers earn a message

Here is where the vendor documentation stops and judgment starts. Signal-timed outreach is what we run, so this half is ours.

A trigger is worth acting on when the event changes something about the buyer's situation that your offer speaks to. That is a narrower bar than it sounds, and most of the volume in any signal feed fails it.

Ask three questions of any fired signal, in this order.

Did it move a budget, a mandate, or an owner? A funding round moves budget. A new VP of Sales moves mandate and owner at once, because a new executive is hired to change something and has roughly a quarter to say what. A layoff moves budget in the other direction and often moves the mandate toward cost. A product launch moves the mandate for whoever owns the launch. A podcast appearance moves nothing.

Is the person you can reach the person the event happened to? A funding round belongs to the CEO and CFO. The consequences land on whoever now has to hire, build or buy. Getting this wrong is the most common failure in trigger outreach: the event is real, the timing is right, and the message is sitting in the inbox of somebody with no stake in it.

Would the prospect find it normal that you know? Public funding, a public hire, a public launch, an earnings call: all of these are things a well-briefed person in your market would obviously have seen. A technology-stack change detected on their website is a different feeling to receive, and an intent signal is the wrong thing to mention out loud at all. Use the quiet signals to decide who to contact and what to say. Do not use them as your opening line.

Does this trigger earn a message?

• ✓Yes: Funding round, where your offer is something the raise pays for
• ✓Yes: New executive in the function you sell to, inside their first quarter
• ✓Yes: Announced hiring plan for the team that would use what you sell
• ✓Yes: Product or market launch that creates the problem you solve
• ~Depends: M&A, where the work you do is part of integrating two companies
• ~Depends: Layoffs, which are real but need care and a genuinely cost-shaped offer
• ~Depends: Technology added or dropped, better for prioritising than for opening
• ✕No: Intent research signals, useful for targeting and wrong to mention out loud
• ✕No: Podcast appearances and generic press mentions with no consequence attached
• ✕No: Any signal where the person you can reach has no stake in the event

The window matters more than the novelty

The instinct with a trigger feed is to send fastest. The better instinct is to send inside the window where the consequence is actually being handled, which is rarely the same hour as the announcement.

A funding announcement is loudest on day one, when the inbox is congratulations and the executive team is doing press. The hiring, tooling and vendor decisions that follow it happen over the following weeks, and a message that lands in that stretch competes with far less noise while being just as well timed. A new executive is worth reaching early in their first quarter, because that is when they are still deciding what to change. A hiring plan is live from the moment it is announced until the roles are filled.

Two practical rules follow.

Define the window per signal type, in writing, before you launch. The window is a property of the event rather than of your calendar, and writing it down stops the play from degrading into "send whenever the feed updates".

Freshness has a floor. A signal fires with a date attached, and acting on a stale one is worse than not acting, because it tells the prospect your timing is automated and your research is not. If a signal is older than the window you defined for its type, it goes into targeting rather than into an opening line.

What the trigger changes in the message, and what it does not

A trigger changes the opening line. It does not change the offer, the proof, or the ask.

The failure pattern is easy to spot once you know it: an email that spends three sentences on the prospect's funding round, one on what the sender does, and none on why the two are connected. The event earns you the first sentence. Everything after it has to be the same clear, specific pitch you would have sent anyway, with the relevance made explicit rather than implied.

So the shape is: one sentence naming the event and why it makes this relevant now, then the offer, then a single ask. The trigger is the reason for the timing, and the message still has to stand up on its own merits.

How we run this, and the parts we refuse to do

Our house rules on trigger outreach are strict, and they exist because the alternative degrades quickly.

One message per campaign. A trigger fires, you send one message built around it. We do not send thread replies and we do not add bump steps to a sequence. If the message does not land, the answer is a new campaign with a genuinely fresh angle later, never a follow-up sitting under the first one.

No no-reply retargets on LinkedIn. A second LinkedIn message arrives in the same thread, directly beneath the message they already chose not to answer. Whatever the campaign structure says, it reads as a bump to the person receiving it, so we do not do it.

Email and LinkedIn. Those are the two channels we run. We do not do cold calling, so nothing on this page is advice to dial a prospect because a signal fired.

Verify before you send. A signal tells you the moment is right. It says nothing about whether the address you hold still works, and a trigger-timed campaign into a stale list produces bounces at exactly the moment you wanted to look sharp. Every address is verified immediately before the send, whatever source it came from. Email verification tools covers that step properly.

1. Step 1Signal fires

   Search Scoops or a webhook surfaces the event with a date attached. Record the date; it decides the window.

2. Step 2Test it against the bar

   Did it move a budget, a mandate or an owner, and is the person you can reach the one it happened to?

3. Step 3Pick the right person

   The consequence-owner rather than the person named in the announcement, when those differ.

4. Step 4Write one opening line

   One sentence on the event and why it makes this relevant now. The offer and the ask stay as they were.

5. Step 5Verify, then send once

   Verify the address immediately before sending. One message. No bump, no thread reply, no second LinkedIn message under the first.

If you do not hold a ZoomInfo licence

Scoops is a paid feature inside a paid platform, gated further by package and scope, so it is not a starting point for a team without a contract. The judgment half of this page transfers to any signal source: funding databases, job-posting feeds, executive-move alerts, or your own CRM. What changes is the coverage and the latency of the feed, not the question of which events deserve a message.

If you are shopping, best ZoomInfo alternatives covers the platform landscape, and ZoomInfo vs Clay is the right comparison when you want to orchestrate several signal sources rather than buy one. Whichever you pick, test the data on your own market before committing: Apollo vs ZoomInfo data accuracy sets out a testing method you can run on a sample. If you are folding signals into an account-prioritisation model rather than a campaign, the lead scoring glossary entry is the vocabulary for it.

Signal timing rewards the team that sends one good message at the right moment more than the team that sends four. If you would rather see that run on your market than build it, we do exactly this end to end: start with a free campaign.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.