Hiring signals: read job ads as evidence of a budgeted problem

A software company posts three openings for support agents in Leeds.

That single fact is a lead for at least three different sellers. It is a lead for whoever sells support automation, because the company has just proven it has more support volume than headcount. It is a lead for a recruiter. And it is a lead for whoever fits out the office those three people will sit in.

One event, three sellers, three completely different reads, which is exactly why "hiring signals" as a feature is usually built wrong.

Why there is no "hiring signals" listener type here

There used to be one, and removing it is the most useful thing on this page.

A listener type called hiring encodes exactly one reading of one situation: a posting means someone is scaling a function, so they need software for it. Fine reading. It is one of three, and the other two could not be expressed at all.

Worse, it made job postings the only situation the product could reason about that way. A funding round, a new lease, a regulatory fine, a migration announcement and a store opening are all the same shape of evidence (a company has taken an action that implies a budgeted need), and none of them had anywhere to live.

So the abstraction moved up. Job boards are ordinary sources on an ordinary listener, and a posting is read the same way a lease or a funding round is:

A situation happens, and depending on what you sell, it is an opportunity.

The inversion that makes it work

This is the part a keyword list cannot do, and the reason the input is your website rather than a search query.

Nobody advertises for an "AI receptionist".

If you sell one, the titles that matter are "receptionist", "front desk coordinator", "patient services representative" and "scheduling coordinator": the human job your product replaces. Working that list out requires reasoning about what your product does, not about what it is called, and nobody is going to type it into a keyword box because nobody thinks of it.

analyse-website crawls your site and derives that vocabulary, returning it as an editable plan alongside the keywords, exclusions and per-source queries. You review it before the first run. Every competitor's equivalent onboarding step is an empty keyword box, or a catalogue of preset triggers where "started hiring" is one undifferentiated entry.

The scoring change that makes derived leads rank

purchaseIntent is worth 30 points and it used to ask "did they say they want to buy". That scored zero for every derived opportunity, capping them at 70, so a company that had hired three support agents ranked below someone idly asking Reddit for recommendations.

One of them spent money. The other typed a sentence.

That middle band is the one no mention-monitoring tool can produce, because it requires reasoning about what a company did rather than what a keyword matched.

The label vocabulary had to move with it, which is the kind of thing that silently undoes a change like this: the old content label listed "job ads" as an example of "nobody to talk to", so the classifier would correctly follow the evidence to a real lead and then file it as marketing.

The guardrail

ALLOWED     "hiring 3 support agents in Leeds"
              → scaling support in Leeds          [stated: role, count, place]
              → you sell support software          hops = 1

REFUSED     "photos from a beach party"
              → attendees are probably affluent    [ASSUMED: not in the post]
              → they buy luxury cars               → no opportunity

One hop, and the evidence must be in the post. Two stacked assumptions is indistinguishable from invention. Every signal records inferenceHops, and the prompt says which way to err: a wrong lead costs a salesperson a morning; a missed one costs nothing they will ever notice. Prefer to miss.

Sources, and what they actually return

Job boards are a snippet source, and the wizard says so before you commit. The classifier is judging a title, a company and a snippet rather than the full posting body. That is a real constraint and it is labelled rather than left for you to discover. Postings also carry jobMeta: company, location, work mode, seniority, and compensation where stated.

Work companies, not postings

A company posting four roles in a week should not become four leads. The accounts roll-up collapses them:

GET /v1/companies?listenerId=…&days=30

One row per company: count, the count for the previous window, ranked themes and the strongest quote. Three support roles in a month is a different signal from one, and three this month against zero last month is different again. Sort on trend, not count.

This is the same table as the rivals and places roll-ups: one component, one mental model, different subject.

Getting them into the CRM

Derived leads arrive before the prospect starts shopping, which is the whole point and also the reason they have to reach a human early. Signed webhooks (signal.created fires on insert only, so a posting seen on an earlier run does not re-notify you every six hours), a scoped REST API with keyset pagination, and CSV export in HubSpot's own import headers.

accountKey resolves for most postings, which is what makes this mode CRM-shaped in a way market and rivals are not: the target is a company, not a pseudonymous forum handle.

The honest limits

Derived leads are earlier and colder than stated ones. A purchaseIntent of 18 means the need follows from an action they took, not that they are shopping. The right first message is relevant and specific, not a demo request.

One hop, not two. If your product's connection to a situation genuinely needs two inferences, this pipeline refuses it and is right to. That is a real constraint on which businesses this works for, and better known in week one.

Snippets, not full postings. See the coverage table above.