Buying signals, intent signals, and the one you already own

The short answer

What buying signals are

A buying signal is something a prospect does, or something that happens to them, that makes a purchase more likely. Asking about pricing is one. Starting a trial is one. So is hiring a new head of the department you sell to, although that one is weaker.

The definitions agree on the core. Clearbit calls them a potential customer's actions or behaviors that suggest an interest in buying, and rates fifteen examples by strength: a trial signup is high, a funding round is low. ZoomInfo widens it to behavioral, firmographic and technographic events that suggest an account is in a buying motion right now. The strength rating is the useful part. Not every signal deserves a phone call.

Intent

Intent signals and who owns the data

Intent signals are the subset of buying signals that come from research behavior: reading about a topic, comparing products, visiting pricing pages. Bombora, which sells this data, describes it as telling you when buyers are actively researching a solution online.

The part that matters is who collected it. TechTarget's guide to intent data gives the clearest three-way split:

• First-party intent is data you own: your site visits, your product usage, your CRM.
• Second-party intent is data owned by another company and shared with you. G2 describes its buyer intent this way: activity on G2.com, sold to the vendors being researched.
• Third-party intent is gathered by an aggregator from sites it doesn't own, then sold to many buyers.

Not everyone uses three tiers. Cognism splits it into two: from your site, or from anywhere else. And HubSpot's buyer intent mixes its own visitor tracking with third-party research intent in one product. When a vendor says "intent," ask which party collected it.

Trigger events

Trigger events

A trigger event is a change at a company that opens a window for a sale. UserGems keeps a list of 23 of them, from new executives and funding to acquisitions, layoffs and new regulation. Leadfeeder's version adds job ads, expansions and register filings. The difference from intent is timing: a trigger event says something changed, not that anyone is researching yet.

If you landed here from a Salesforce question: in Apex, a trigger event is the database operation (insert, update, delete) that fires a trigger. Different thing entirely, and Salesforce's Apex guide is where you want to be.

Method

Signal-based selling

Signal-based selling is prospecting driven by these signals instead of by a static list. Salesloft describes it as tracking, analyzing and prioritizing buying signals so reps spend time on the buyers most ready to buy. In practice it is a set of workflows, each one turning one kind of signal into one kind of action. The people who build them are usually GTM engineers, and five of the workflows are written out in GTM workflows.

At a glance

The usual signal types

Here is what the sources above list, with who collects the data. I marked company events like funding and job changes as public, since they are announcements anyone can watch, even though vendors sell them packaged.

Notice what is missing. When UserGems lists "new product announcement" as a trigger, it means the prospect's launch. None of the trigger lists I read include the seller's own launches. That gap is the rest of this page.

The catch

The problem with bought intent

Third-party intent is the signal most teams buy first, and the one with the most complaints. Demandbase, which sells intent data, published a post titled Intent Data (On Its Own) Is Just Wishful Thinking. Its argument: one keyword search doesn't mean an account is buying, and when topics get broad enough, most of your market looks "in-market" and sales stops believing any of it. Forrester's look at intent data expectations found most users got some benefit, but more expected benefits than got them, with the biggest gaps in sales use.

None of that makes third-party intent useless. It makes it a probability. You are buying a guess about another company, and so are your competitors, from the same vendors, on the same morning.

First-party

Product signals, both kinds

"Product signals" gets used for two different things, and both are first-party.

Usage signals are what customers and trial users do inside your product. A free account inviting five teammates, a trial hitting a plan limit, a customer whose usage dropped by half. Salesloft's signal guide files these under "your own signals," and product-led companies build whole sales motions on them.

Release signals are what your product team ships. A new feature, an integration, a fixed bug, a performance change. They are about your company, not the buyer's, which is why they never show up on a trigger event list. They matter anyway, because a lot of buyers already told you which release they were waiting for.

The argument

The case for release signals

A release signal has three properties no bought signal has. It is true: the code merged, there is no probability attached. It arrives first: you know before any customer does. And it is yours alone: no vendor sells your roadmap to your competitors.

One caveat on "true": merged and live are not always the same day. Teams that ship behind feature flags or on a release train can merge a feature weeks before a customer can use it. If that is your team, treat the merge as the heads-up and the deploy as the signal, and check the feature is on before anyone writes to a buyer.

What makes it a buying signal is the join. On its own, "we shipped SAML" is an announcement. Joined to every deal, churned account and open opportunity that asked for SAML, it is a list of people with a specific reason to hear from you today. Clay says it does exactly this with its own pipeline, in a post on how it handles closed-lost deals. The closed-lost reactivation play builds the same thing step by step.

The reason most teams don't do it is boring: the signal is stuck in GitHub. Sales hears about releases from a changelog written weeks later, if anyone writes one. That was my problem too, from the other side. I shipped things and told nobody, so I built Merge & Tell to read each merged pull request, decide whether a customer would notice it, and write the post and changelog entry for the ones that matter. The same result is available to a workflow through an API, an MCP server and a public feed, which the GTM tools map puts in its own layer.

You don't need my tool for this. GitHub's webhooks and release feeds carry the raw signal for free. What you add on top is the filter, because most merges are not news, and the sentence a salesperson can actually say out loud. The same release still needs announcing to everyone else, and the product updates guide covers that side.

Honesty

Where release signals fall short

They only help with buyers who already told you what they need. They won't find new accounts, which is what most intent data is bought for. They depend on someone recording the request in a field, not just in a call note. And they only work if the product team's work is visible somewhere a machine can read it, which for Merge & Tell means GitHub.

Merge & Tell itself has no CRM integration and sends no sales email. It tells you what shipped. Matching that to the people who asked is still your workflow, in your tools.