Turn New Hires at Target Accounts Into Outbound

To turn new hires at target accounts into outbound, watch your market with a Sales Navigator job-change search for the roles you sell to, qualify the company each new person joined against your ICP, and put only the fits in front of a rep with the reason and the links. A person in a new role has a fresh mandate and no loyalty yet to the vendor in place, so the play is worth most in their first months, and least when it reaches the channel as noise.

New-hire detection is the signal play customers ask Cargo for most often. The new-hire-detection cookbook is that pipeline as a worked example your coding agent adapts; this page covers the end-to-end flow, the spend, and where it hands over to your sequencer.

Deploy it #

npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com

cargo-ai cdk add cookbook/new-hire-detection     # inside a Cargo project
# or: cargo-ai cdk init new-hires --cookbook new-hire-detection && cd new-hires && npm install

Count the search before you extract anything. searchPersonMetrics returns total_leads for one Sales Navigator URL:

cargo-ai orchestration action execute \
  --action '{"kind":"connector","integrationSlug":"salesNavigator","actionSlug":"searchPersonMetrics"}' \
  --data '{"url":"<the search url printed from infra/new-hire-detection/models/new-hires.ts>"}' \
  --wait-until-finished

Then cargo-ai cdk plan and cargo-ai cdk deploy. The model ships as a pilot (limit: 10, no schedule) and the play ships disabled, so the first deploy extracts nothing until you sync it.

How it works, end to end #

Sales Navigator people search: titles x industry x headcount x region
  + changed jobs, under a year at the company, under a year in the position
  -> new_hires model, one row per person (fetchLeadSearch)
  -> play route_new_hires, for rows added since the last sync:
       enrich the company from its LinkedIn page
       no website?  -> stop: no_domain
       qualifier agent reads the ICP in your workspace context
       not ICP?     -> stop: not_icp, with the rationale
       ICP          -> one Slack post: person, company, tier and score, rationale, links

The market, not your book. The search is built from four facets read from your ICP: the titles you sell to (quoted, with words like interim and fractional excluded), the industries, the headcount band and the regions. Three job-change filters stay in every URL, because together they drop internal promotions at long-tenured employees, which look like new hires and are not. For people already in your CRM who moved, use track-job-changes instead.

Enrich, guard, then judge. A Sales Navigator lead carries a company page, not firmographics, so the play enriches the company first with LinkedIn enrichCompany. A company page with no website stops there. The qualifier agent then reads the description, specialties and headcount against context/icp.md, and returns is_icp, a fit_score from 0 to 100, a fit_tier and a two-sentence rationale. Only is_icp: true is posted.

Posted once. The play runs on changeKinds: ["added"], so a person creates a run the first sync they appear in and never again. The Slack channel is a constant in the play, so no run can post anywhere else.

Cargo platform data, 90 days to Oct 16 2026: LinkedIn company enrichment, the step this play runs on every new person, ran 1.06 million times on Cargo.

From the post to outbound #

The play ends at the Slack post. Nothing is written to a CRM and nothing is sent to the person. Turning the signal into outbound is one of the cookbook’s variations, each a choice with its own cost:

Sending stays with your own sequencer, after a person has read the post.

What it needs #

• A Cargo project on @cargo-ai/cdk 1.0.88 or later, and authorized Sales Navigator, LinkedIn, LLM and Slack connectors. No LinkedIn seat, user or cookie.
• Your ICP in the workspace context, because the search is shaped from it and the qualifier reads it on every company. A missing ICP leaves the qualifier judging against nothing.
• A Slack channel id resolved through the connector’s autocomplete. A CRM only for the CRM variations.

What it costs #

Extraction is the main spend and it repeats: fetchLeadSearch is not incremental, so every sync re-extracts the whole search, including people already in the model. A search counted at 400 people, synced on the default cadence of the 1st and the 15th, is 400 × 0.2 × 2 = 160 credits a month of extraction before any qualifying. The cadence is the dial. One URL returns at most 2,500 people; above that, split the market by region or headcount band, one counted URL each. Plays also bill orchestration steps, 1 credit per 100 steps.

What it will not do #

• Message the new hire. No email, connection request or InMail, and no draft unless you add draft_first_touch. A play that sends on a job-change signal mails people in their first week with nobody reviewing it.
• Post every new hire. The qualifier’s verdict gates the post; a channel that hears about everyone stops being read.
• Watch a named account list. The search is a market slice defined by facets. For hiring signals on a fixed list of accounts, see monitor buying signals on a list of accounts.
• Flag an empty search for you. A URL encoded once instead of twice loads an empty search, and the sync reports success with zero rows. The cookbook builds the URL from a search object for that reason; a sync that lands nothing is a failure to investigate, not a quiet week.

The cookbook is marked to-be-approved: treat its acceptance list as the test, pilot ten rows, read every run, and only then raise limit and add the schedule. Deploy it from the new-hire-detection cookbook. Related: how long a buying signal is worth.