Hiring signals: a practical guide for GTM engineers

What a hiring signal is

A hiring signal is an observable change in a company's hiring activity. The clearest one is a new job requisition: the company publishes a posting for a role it wants to fill. Other signals derive from that same stream. A req closes. A team posts several matching roles inside a month. Hiring speeds up, slows down, or spikes.

The key word is observable. A hiring signal points to a public artifact. You can open the posting, read the text and link it in an email. That one property separates signals from scores, and it shapes everything in this guide.

For a GTM engineer, a hiring signal is also a machine event. It arrives as a payload: company, posting title, location, the board it was detected on, and the ATS link. That makes it a trigger you can build on, not a chart you look at.

Why a new req is a strong account signal

Most account signals tell you a company might care about a problem. A new req tells you two things most signals cannot: the budget is committed, and the pain is written down.

Budget is committed

A job requisition is not an idea. It is the output of an internal process. Someone asked for headcount. A manager justified the cost. Finance approved a salary. Only after all of that does the posting go live. When you see a new req, you see money already assigned to a named problem.

Compare that with a funding announcement. Funding means money exists. A req means money is allocated. The account is past the question of whether to invest in the problem. It is now deciding how, and who with. That is the window where a relevant vendor gets a reply.

The pain is named in the posting text

A job description is a public statement of need. It lists the problems the hire must solve, the tools the team runs, and the outcomes the manager wants. Nobody writes that text for you. The company writes it, in its own words, with detail no enrichment vendor can match.

That text is raw material for relevance. If the posting says the team is scaling outbound, your outbound product is on topic. If the req names a stack, you know the stack. Your first line can echo the account's own language, and your prospect can click the same posting you read.

The signal also arrives early. A company posts the req before the hire starts, and the new hire needs time to ramp. If your product solves part of the problem the req describes, you can reach the account while the pain is still open.

Signal vs inferred intent

Intent data vendors model interest. They watch content consumption across a network of sites, aggregate it to a company and output a topic score. The method can work, but you cannot inspect it. When a prospect asks "why are you emailing me", a score is not an answer.

A hiring signal is the opposite. It is an observed event with a receipt. Reqbeat delivers the real posting with the board it was detected on and the ATS link, never an inferred intent score. Every claim in your email traces to a public page.

The practical differences:

• Auditability. A signal links to its source. A score links to a methodology page. You can defend a signal to a prospect, a client or your own team.
• Latency. A posting is a discrete event you can detect within hours. A modeled score updates on the vendor's schedule, after aggregation.
• Message. A signal gives you words to quote. A score gives you a topic. "Saw your req for a platform engineer" beats "noticed interest in DevOps".

Both have a place. Scores help you rank a large market. Signals win where the message must be specific and the timing must be tight. For a same-day play, use the signal.

How to score and route signals

A raw stream of postings is not a play. Turn it into one with a simple score and a routing rule. Keep both small enough to explain in one sentence each.

Score on fit, magnitude and age

• Fit. Does the role match your ICP? Most of this work happens upstream: a watch already filters by role and geo, so everything that arrives is a candidate. Within that, weight exact role matches above adjacent ones.
• Magnitude. One req is a signal. Several matching reqs in a month is a stronger one. Hiring pulse gives you the fields to score this: new roles in 30 days, velocity, direction and a surge flag.
• Age. A req detected today outranks one detected last week. The edge of this whole motion is timing, so the score must decay.

One rule protects the whole model: never score absence as a negative. A company with no ATS or board coverage answers with coverage_status: "no_ats_signal". That means "unknown", not "not hiring". Treat it as missing data, and leave the account's score alone.

Route by tier

• Hot. Target account plus a matching req, detected today. Push it straight to the rep or the sequence. This tier is why you use webhooks: a watch fires, you do not poll.
• Warm. ICP fit, but not a named account. Batch these into a weekly segment and run a campaign against it.
• Hold. Partial fit or low magnitude. Keep the account on a watch and wait for the next event.

The tiers map onto primitives. Hot runs on watches and webhooks. Warm runs on scheduled search pulls. Hold costs nothing while it waits, because a watch bills only when your endpoint accepts a delivery.

How to act the same day

A hiring signal loses value every day you sit on it. Other vendors see the same posting. The hiring manager's inbox fills. The play below keeps the loop inside one day.

Let the watch do the watching. Save a watch for the role and geo that define your ICP, with your webhook as the delivery target. The corpus refreshes every 3 hours, so a watch on an active search typically fires the same day the posting goes live. No cron, no polling code.

Enrich on arrival. The payload carries the company, the posting title, the location, the board it was detected on and the ATS link. Pipe it into your enrichment flow, find the likely hiring manager and verify the email. The Clay same-day outreach recipe walks through this step by step, and runs on the free tier.

Open with the receipt. "Saw you opened a req for [title] this week." Quote the posting, link nothing extra, and make the relevance obvious in one line. Specific beats clever. The point is that you knew, same-day.

Keep it one loop. Trigger, data, send. Every added approval step spends the freshness you paid for. If a human must review, give them a queue that empties daily, not weekly.

If an agent runs your workflow instead of a human, the same loop works over MCP. The hiring pulse agent recipe shows an agent that gates accounts with is_hiring and ranks them by pulse, and the MCP server page documents every tool.

Keep reading

• Job posting data: sources, freshness and deduplication. The data layer under every signal, and the questions to ask any provider.
• Signal-based selling for agencies. Turn this play into a retainer deliverable across many clients.
• All recipes, or jump straight to the quickstart: first signal in about 5 minutes, the key is on screen at signup. The API docs hold the full reference.