Guide

Signal-based selling for agencies: the playbook

Run hiring-signal monitoring across many client lists, sell it as a retainer deliverable, and report with receipts your clients can click.

The model: sell the signal, not the list

Every agency can buy the same database export, and every prospect can tell. The signal-based model sells something different: "we email companies that posted a matching req this week, and here is the posting". The deliverable is timing and relevance, not volume. Every claim in the campaign has a receipt the client can click.

For an agency the model does double duty. It wins campaigns for clients, and it wins the pitch itself. "We only email companies that opened a matching req this week" is a one-line answer to "how are you different", and you can prove it in the first report. Few positioning claims survive contact with a procurement call. This one does, because the evidence is public.

This playbook assumes you know why a new req is a strong account signal: budget is committed, and the pain is named in the posting text. If that case is new to you, read the hiring signals guide first. This page covers the agency layer: many clients, one operation.

Run monitoring across many client lists

One Reqbeat account serves many client workspaces. The unit of monitoring is a per-client ICP query: the role and geo that define that client's buyer. "Companies hiring sales roles in the UK this week" is one search. Each client gets its own.

Two modes cover every client type:

  • Scheduled searches for clients who want net-new volume. One pull per client ICP per week returns one row per company with its matching active reqs. The output maps 1:1 to a campaign audience.
  • Watches for clients with named target accounts. A watch fires a signed webhook when a matching req is detected, so the hot tier moves same-day instead of waiting for the weekly pull.

Prove each query before you commit it. Sign up, copy the API key on screen, and tune role and geo from your terminal until the rows match the client's ICP. Then keep one config per client: the query, the geo, the suppression list and the sequencer destination. When a client churns, you delete one config, not untangle a shared list.

One caution to bake into the operation: a company with no ATS or board coverage answers with coverage_status: "no_ats_signal". That means "unknown", not "not hiring". Never report an uncovered account to a client as cold.

Package signals as a retainer deliverable

The retainer line item is simple to name: a weekly segment of companies that posted a matching req this week, each row carrying the posting title and the ATS link. Write it into the contract in those words. It is concrete, it is fresh by definition, and no competitor with a static database can copy it.

The economics work in your favor:

  • Searches bill per sourced company row, at $0.10 per row. A weekly 50-company segment is a small line item per client. An empty week costs nothing.
  • Watches bill only when your endpoint accepts a delivery. Duplicates and failed deliveries cost nothing.
  • Every self-serve plan has a hard spend cap already set, so a runaway workflow stops instead of running up a bill across your client base.

Price the retainer on the outcome, not the data. The data cost is a rounding error next to the value of a reply from a company that committed budget this week. What the client pays for is the operation: queries that match their ICP, segments that arrive on schedule, and openers with receipts.

Route per-client segments

The n8n weekly segments recipe is the exact build: cron, search, dedupe against last week, load into Instantly or Smartlead. Four nodes per client, about 45 minutes to a first live workflow. Clone the workflow per client and change only the query and the destination.

Deduplication runs per client. Keep a per-client set of contacted company IDs, drop rows the client already emailed, and let the same company flow to a different client where it fits. One company can be a fresh signal for two clients with different offers. It must never get the same email twice from one client.

For clients on the watch tier, deliveries are signed with X-Plane-Signature and endpoint registration is idempotent, so retries never create duplicate endpoints. If the client's stack lives in Clay instead of a sequencer, the Clay same-day outreach recipe is the same play with rows landing in a Clay table.

You can prove the whole operation before a client pays. The free tier is permanent, and signup grants a 14-day trial on top of it: no card, no demo call, the API key on screen immediately. Run one pilot segment for your most responsive client, show the replies, then roll the pattern out across the roster.

Report with receipts

Signal-based reporting writes itself, because every row carries its own evidence. A monthly report needs four blocks:

  • Segment volume. Companies that posted matching reqs this period, per week. This is the freshness story in one number.
  • Activity. Emails sent against the segment, replies and meetings. Standard agency metrics, now tied to a trigger the client understands.
  • Receipts. A sample of the actual postings that triggered outreach, with ATS links. This block renews retainers. The client sees exactly what their money watches.
  • Coverage notes. Accounts with no_ats_signal listed as unknown, not cold. Clients trust reports that state their own limits.

For quarterly reviews, add direction. Hiring pulse fields such as new roles in 30 days, velocity, direction and the surge flag summarize how an account's hiring is moving, which turns a list of events into a narrative about the client's market.

Keep the report honest about what the data is. It is observed postings from public boards and ATS pages, deduplicated, with the source named on every row. If a client asks harder questions about sample, refresh or dedup, the job posting data guide gives you the answers in their language, and the method page is the source of truth.

Keep reading

One account, many client campaigns. The first segment is one query away.