What Are Buying Signals? All 27 Types, With the Public Record Behind Each One

almost nobody I talk to has a targeting problem, because they already have a list and it is usually a good one, filtered down by industry and headcount and funding stage. every name on that list is a company which could plausibly buy what they sell.

what none of it gives them is a reason to call any particular one of those companies this morning, and that is a different problem with a different fix. the two get confused constantly, because a list and a reason look identical when you are looking at a dashboard.

so, plainly: a buying signal is a change at a named company, on a known date, that you can go and check for yourself. all three parts have to be there, and a fair amount of what gets sold as intent data is missing at least one of them, which is my read from what I have looked at rather than a figure I can source.

what a company is tells you whether it fits, a signal tells you what has just changed there, and several signals at once tell you why that change matters this week instead of next quarter. everything below sits on one of those three ideas.

so here is what this piece covers:

• the two questions worth asking about any signal, which are where you saw it and what actually changed
• what is not a signal, which is the section I would read first if I were only reading one
• all 27 of them, grouped into nine sets, each with the public record you can look it up in
• five of them worked through in full, and I have picked the ones people ignore instead of the ones everybody already runs
• how to check it, meaning the public record you can open yourself to see that a change really happened, and when
• buying windows, where single signals stop being trivia and start being a reason to pick up the phone

for anyone new here, this newsletter is me building a GTM engine in public and publishing what I find every couple of weeks. an engine has three layers, which are observe, plan and act, and this whole piece sits in the first one. none of what follows is worth anything on its own, but all of it decides what the rest of the engine ever gets to work with.

there is one thing worth saying before the first number arrives, which is that most published statistics about buying intent come from companies that sell buying intent, so I am going to name the vendor every time I use one of their figures.

the clearest illustration of why that matters comes from 6sense's buyer experience research. their 2024 report said buyers were 69% of the way through choosing before they first spoke to any seller, that figure got quoted everywhere for a year, and their own 2025 report then moved it to 61%. the direction those numbers point in is real and worth acting on, the precision is not, and 6sense sell the product that the number justifies.

---

1. the two questions that organise everything

this section is the framework, and it should take about thirty seconds to read. there are only two questions worth asking about any signal, and most of the lists you will find online collapse because they try to answer both of them at once.

1.1 where did you see it ?

the first question is simply where the observation came from, and there are four honest answers.

• your own systems, meaning everything you already hold on a company: product events, support tickets, the CRM, email replies, and who came back to your pricing page on Tuesday. the industry calls this first-party data.
• from a partner, meaning anything another company shares with you on purpose, whether that is an integration partner, a reseller or somebody you run campaigns with.
• out in the open, meaning public records and data you can buy, which covers filings, permits, tenders, job posts, patents and news.
• two or more, joined up, meaning several of the above pointing at the same company or the same person, which is where the interesting work lives and where all of the difficulty lives too.

your own systems are the cheapest source you have and the one most teams under-use, and the reason for that is boring rather than strategic. it already sits in four systems that do not talk to each other, and usually nobody owns the job of joining them up.

public and bought-in data has the opposite problem, since it is easy to buy and easy to over-buy, and you can end up subscribed to six feeds and still not know which account to call. combining sources is the genuinely hard one, because a company is not a clean identifier and people change employers. most of the engineering work in a system like this goes on proving that a filing, a job post and a website visit all belong to the same organisation.

1.2 what changed ?

the second question is what actually changed, and there are 27 answers in the tables in section 2. each one is a type of change in the world, described in terms of what happened, never in terms of who it happened to.

the grid matters more than either of its two sides does on its own, because the same change read off a different source is a completely different quality of signal. a hiring change you find in a public job post is nowhere near as reliable as the same hiring change mentioned by your champion on a call.

1.3 what is not a signal

this is the most useful part of the page, so it gets its own section instead of sitting in a footnote, and it comes down to four ideas.

company context is not a signal, because industry, headcount, revenue band, geography and ownership structure all describe the shape of a company rather than something that happened to it. all of them are stable by design, which is exactly what makes them good for filtering and useless for timing.

the most common mistake of the lot is a team holding company facts, calling it intent, wiring it into a sequence and then wondering why reply rates did not move.

news is not a signal, the event is, because an article is a report of a change that gets published on whatever day an editor got round to it. the date on the article is therefore the date of the coverage, and not the date of the thing itself.

the acquisition, the appointment, the launch and the facility opening are the signals, and the article is just where you happened to find out. media activity counts as its own separate signal, since a sudden run of coverage or a founder appearing on four podcasts in a month tells you something real about what a company is pushing, and that gets its own row in the tables below.

an industry is not a signal, because healthcare, financial services, energy and real estate are markets rather than changes, whereas a reimbursement decision, a planning permission, a rate change and a licence suspension are changes that happen across several markets at once. group by industry in a dashboard wherever that helps somebody find their way around, but keep it out of the list itself. the moment industries become signals you end up with twelve copies of every row, and no way to reason about any of them.

anything without a date on it is not a signal, and that includes topic-surge scores with no named account attached, aggregate website traffic and engagement on your own posts. these are all real measurements of something, but none of them survive the only question that matters when you are deciding what to do this morning, which is when did this happen and is it still true. if you cannot date something you cannot age it, and a signal you cannot age will sit in a queue looking permanently urgent.

---

2. all 27 signals, in nine groups

this is the reference part of the piece, and it is deliberately built as tables instead of paragraphs, because twenty-seven of anything written out as prose is unreadable and anybody looking for the one they care about is scanning rather than reading.

every row says the same three things, which are the signal itself, the changes you can actually see, and where you can go and check one of them really happened. the nine groups exist purely to help you find your way around, and they deliberately do not sneak industries back in.

under each table there is a note on how long that set of signals stays worth acting on. those are my own estimates and not measurements, because we have not published real numbers on this yet, and I would rather say so than dress a guess up as data.

2.1 people and leadership

these are the signals that come from somebody being hired, arriving or leaving, and they are the group most teams already watch.

how long it stays useful: an executive is easiest to reach in their first 90 days and hardest after their first year. a job post is the awkward one, because it stops being true the moment the role is filled and usually stays up regardless.

2.2 money and ownership

money decides what a company can afford and what it is under pressure to fix, and this group splits cleanly into the good news everybody chases and the bad news almost nobody watches.

how long it stays useful: funding stays warm for a quarter and sometimes two, and it is easily the most contested signal on this list. distress moves faster and in the opposite direction, because a charge registered against a company changes the conversation within weeks.

2.3 technology and product

this group tells you what a company builds with and what it has just shipped, and most of it you can go and see for yourself without waiting for anyone to announce anything.

how long it stays useful: a tag that appeared last week is a signal and the same tag six months later is simply their stack. patents and trials age in years instead of weeks and are the slowest things on this page.

2.4 demand and attention

this group is about somebody actively looking, and it goes stale faster than anything else here.

how long it stays useful: days, and in the case of an identified visit, hours. this is the group where a slow handover between marketing and sales destroys the entire value of the observation.

2.5 engagement with you

everything in this group is already sitting inside systems you own, which makes it the cheapest data you have and the most commonly ignored.

how long it stays useful: a proposal opened three times ages within hours, whereas a renewal date does not age at all, because it is a fixed date you should have known about for eleven months.

2.6 reputation and relationships

these tell you who a company trusts and who it has just started working with, and they tend to open a door rather than create any urgency.

how long it stays useful: months, since a partnership announced in March is still a perfectly good route in July, which makes this the most patient group on the page.

2.7 buying and contracting

here the company is telling you directly what it is buying and on what terms, which is as close to a stated intention as this list gets.

how long it stays useful: exactly as long as the document says, because these arrive with their own dates already printed on them, which is true of very little else on this page beyond a renewal date and a layoff notice.

2.8 risk and obligation

these are the signals that come with a deadline attached to them, which is what makes them the strongest ones on the page.

how long it stays useful: the deadline is the answer, so read the date the company has to have fixed something by, not the date it had to admit something.

2.9 physical and operational

this group is about things happening in the physical world, and it carries the longest lead time of anything on the page.

how long it stays useful: quarters, because a permission granted this month is a building that starts somewhere between six and eighteen months from now, and everything you sell into that project has its own right moment inside that window.

---

3. five of them, in full

the tables above cover everything, so these five are here to be read rather than scanned, and I have chosen the ones people ignore over the ones everybody already runs. each one covers the same ground, which is what it tells you, where you find it, how long it lasts and what to do with it, and each ends with the place where it breaks.

3.1 security-incident and technology-exposure

a breach on its own is news, but a breach with a legal deadline attached to it is a decision somebody has been forced into.

what makes this one useful is the clock that starts once the incident becomes official, and in the US that clock is written into the rules. under item 1.05 of Form 8-K, a public company has four business days to disclose a material cybersecurity incident, and those four days start from the day the company's lawyers decide it is serious, not the day it found out.

by the time that filing is public there is an audit committee asking somebody for a remediation plan, so a company you were emailing in March about a roadmap conversation has become a company with a board-level deadline.

the wider version of the same idea is the state breach registers, and this is a place to be careful, because notifying a state attorney general is close to universal and publishing a public list is not. the World Privacy Forum counts roughly fifteen states that actually publish one, with Texas writing the duty to publish into the statute itself and California and Washington running searchable directories. where a register does exist it is worth working, since it covers private companies as well as public ones and every entry carries a date. there is a third thing to watch here, because a known vulnerability plus evidence that the affected version is running describes a company that has not had an incident yet, and that turns out to be a shorter and considerably easier conversation.

these windows stay open for a matter of weeks, and inside them I would stop leading with the breach itself, since everybody in that building already knows about it, and lead instead with whichever part of the remediation plan nobody has been hired to do.

where it breaks: that four-day clock runs from a legal determination and not from the attack, so a filing date tells you when a company had to speak and close to nothing about when it was actually breached. the rule does require that determination to be made without unreasonable delay after discovery, so the gap is not unbounded, but it is real and nobody publishes it.

3.2 procurement, tender, contract and vendor-lifecycle

this is the one place where a certain kind of buyer publishes their own timetable for you.

everywhere else on this page you are working something out from a change, whereas here the buyer writes the intention down, puts a date on it and publishes it, because somebody legislated that they have to. in the US, FAR part 5 puts most federal purchases expected to exceed $25,000 on one public website at least fifteen days before the solicitation itself is issued, which is why SAM.gov carries early notices as well as finished deals. FAR 5.202 lists fourteen exceptions to that, covering national security and genuine urgency among others, so read it as the normal case and not as a guarantee.

across the EU the same job is done by TED, where a contract award notice has to be sent for publication within 30 days of the contract being concluded, under article 50 of Directive 2014/24/EU.

the finished deals deserve far more attention than the open tenders do, and this is the part most teams skip, because it names who won, says how long they won it for, and therefore tells you roughly when that contract goes back out to market. a three-year-old award notice is a dated pipeline for next year.

here the timing comes printed on the document, since a tender dies on its closing date and a five-year contract with two option years hands you a date to count backwards from. six to nine months before the re-tender is where I would aim rather than the week the notice first appears, though that one is a rule of thumb of mine and not a measured figure.

so run the whole thing in reverse, which means pulling the contracts won in your market three years ago, working out which ones are coming up, and building the account plan for the incumbent's customer while there is still nothing to respond to.

where it breaks: this only covers buyers who are obliged to publish, meaning the public sector, regulated utilities and the handful of large enterprises that keep open vendor registers. for a private mid-market company no equivalent document exists at all, and assuming otherwise will send you hunting for records that were never written.

3.3 location, expansion, construction and physical-activity

the signal very few people in software watch, and the one with the longest lead time of anything here.

a distribution centre that has just been granted planning permission is going to need racking, power, connectivity, security, staffing, payroll, insurance and a long list of software, and not one of those purchases has been made yet. a permit is a public, dated commitment of capital that drags a long chain of buying along behind it. the people who will actually make those purchases get hired somewhere later in that build, and I have not found a published figure for how much later, so I would not put a number on it.

it stays underused because the data is local rather than national, since planning portals, building permits, land registry transfers, lease filings and utility connection applications are all public, and almost none of it arrives packaged. the work here is putting it together rather than getting hold of it.

the sequence inside the window is the actual product here, because permission granted is the signal for finance and design suppliers, ground broken is the signal for equipment, and the fit-out contract is when everything that goes inside the building finally gets chosen. so pick the single stage that sits about two quarters ahead of your own sale and monitor only that one, since a team that tries to watch the whole construction lifecycle ends up with a feed nobody opens.

where it breaks: permits move slowly and plenty of them never become buildings, so slow is not the same thing as stale. but a permission granted in 2023 with no construction started since is a project that stalled, and treating it as live will cost you a quarter.

3.4 financial-health, credit and distress

the mirror image of funding, and far less crowded.

everybody emails on the raise, and my own view is that this is why the raise converts badly, though I have not found a public number that settles it, because a funding announcement drops every rival you have into the same inbox in the same week and the company receiving them has money and no new problem.

a registered charge attracts nobody at all, and it describes a company whose constraints have just changed. a UCC-1 financing statement is the US record of a lender taking a claim over a company's assets if it cannot repay, and it sits publicly with the secretary of state. it stays effective for five years unless a continuation is filed in the six months before it expires, so the register also tells you when somebody actively chose to keep that security in place. the UK equivalent is a charge registered at Companies House within 21 days of being created.

layoffs leave their own paper trail, because a WARN notice reaches the state 60 calendar days before a mass layoff at any US employer of 100 or more, which is usually well before anybody announces anything publicly. the act carries exceptions for unforeseeable business circumstances, a faltering company and natural disasters, so shorter notice is lawful and does happen.

these windows are short and they close unevenly, so a lien stays interesting for a quarter, a layoff notice for a few weeks, and once the restructuring is finished the whole thing shuts.

the move is to change the offer instead of changing the account, because it is the same company and the same fit as before, just with a different problem, and what they need this quarter is almost never what sits on your standard first slide.

where it breaks: money trouble is the easiest thing on this page to misread, and the failure mode is sending something that reads as circling. a UCC-1 can be routine equipment finance on a perfectly healthy balance sheet, and a layoff at one site can sit inside a company that is growing everywhere else, so read the filing itself rather than the mood around it.

3.5 hiring and workforce

they are telling you what they are about to spend money on, in public, in advance.

I have put the most familiar one last deliberately, because it lands better as confirmation after four unfamiliar ones than it would as an opener.

a job post is a budget decision that has already been approved and then described in enough detail for you to work backwards from it. a first data engineer means there is no data platform yet, four SDR roles opened at once means somebody has signed off on a pipeline number, and a spec naming a certification tells you which compliance programme is about to start.

the higher-value read is the change rather than any individual post, because one open role is noise whereas a company going from zero to five of the same title in a fortnight has clearly decided something. that version of the signal also survives contact with reality, since it does not depend on any single posting being fresh.

so treat the post as a document instead of an alert, which means reading the responsibilities section, working out which of those responsibilities is impossible on the stack they currently run, and leading with that instead of congratulating them on the growth.

where it breaks: posts sit up for months and get reposted to build a candidate pipeline, so a stale post is not a signal at all. an honest version of this needs the date the post first appeared rather than the date you scraped it, and that is the one field most job aggregators handle worst.

---

4. how to check a signal is real

a signal without evidence is just a claim, and the third column in every table above is there to make that difference real.

the rule here is short enough to say in a single line, which is that every signal should come with something somebody could open and a date printed on it. the filing, the permit, the job post, the award notice, the release note, the court docket entry, the support ticket.

if the answer to "what proves this" turns out to be "our model scored it", then what you have is a prediction. a prediction can be genuinely useful, but it does not belong in the same column as a record.

this is the layer I most often find missing from intent-data products, and I will not pretend to know why, though naming the document does invite a customer to go and check it. it also has a completely unglamorous benefit inside your own team, since a rep who can see the permit writes a different email from the one who has been handed a signal they cannot describe.

so, for full disclosure: I build a product in this category. Scale Intelligence is my company and it is the observe layer under my own engine, so I am not a neutral party on the paragraph above and you should read it that way.

there is a second reason to hold the line here, which is that records carry two dates and predictions carry none. an 8-K has a filing date and describes an incident that happened some time before it, while a WARN notice is filed 60 days ahead of the layoff it announces, so one of them points backwards and the other points forwards. a system that only stores the date it ingested the record has thrown away the part that decides urgency.

---

5. buying windows: why the combination is the product

everything in section 2 tells you what is out there to see, and almost none of it is worth much on its own. the unit that actually matters is several of those changes landing on the same company inside a short enough period to mean something.

a funding announcement on its own is about the most crowded signal there is, since every competitor you have receives the same alert on the same morning. that same funding round, plus a VP of the relevant function starting three weeks later, plus somebody from that team reading comparison content, plus a reply to an email you sent back in March, is a different object entirely.

a planning permission on its own is useful but slow, whereas that same permission, plus a registered charge over the site, plus confirmed ownership of the land, describes a funded project that is genuinely likely to start. it narrows a list of hundreds of permissions down to the dozen worth a phone call.

a breach disclosure on its own is news that everybody has, while the disclosure, plus a compliance deadline their sector is already working towards, plus evidence that the exposed technology is still running, describes a company with a forced response and a gap in it.

three weak observations do not add up to a strong one simply by arriving together, so the count is not the thing that makes those three examples work.

each of the combinations above pairs an event with the constraint that makes the event urgent. the event tells you something changed, the constraint tells you they cannot wait, and the third element usually tells you which team inside the company now owns the problem. that is the shape worth looking for, and it is the reason the observe layer of an engine is worth building at all instead of buying six alert feeds and forwarding them to sales.

it is also where Gartner's finding that buyers spend 17% of the whole purchase journey with all suppliers combined stops being a depressing statistic and turns into an instruction. if you are getting a fraction of a fraction of somebody's attention, the entire question is whether you spend it in the week their situation actually changed.

---

thanks

four things I would take from all of this:

1. fit is not intent, and most stacks confuse the two: industry and headcount tell you who could buy, only a change tells you when, and a filter dressed up as a trigger is the most common mistake there is.
2. where you saw it matters as much as what you saw: the same hiring change read from a public post and heard from a champion belong to the same row in the table, and to two completely different levels of trust. that is why the grid in section 1 has two sides to it.
3. no evidence, no signal: name the document and the date printed on it, or call the thing a prediction and treat it accordingly.
4. one signal is news, and several on one company inside a week is a window: the 27 tell you what is out there to see, and joining them up is what is actually worth building.

the one I would most like an answer to, if you are already running signals at any volume, is how you decide between two accounts that both look urgent on the same morning. that is the constraint I keep hitting, and no amount of extra coverage seems to fix it.

the next few pieces move into the plan layer, which is what an engine does with all of this once it has it, starting with how long a signal is genuinely worth acting on.

if you have read this far you should subscribe, since the whole thing is me building this engine in public and the next layer lands in a couple of weeks.

thank you.

roman

(the observe layer under everything above runs on Scale Intelligence, the market intelligence platform I am building for agents. you point it at your CRM or your site and it gives you a live view of every buyer in your market, which is where the signals in this piece stop being a list and start being a queue. if you want that wired up for your team, book a call here.)