Clay Job Change Signals: How to Monitor Contacts for Moves and Where a Scheduled Check Runs Out

Short answer: Clay does detect job changes. The feature is called Monitor for job changes, it lives under the Actions menu on a table, and it needs each contact’s LinkedIn URL as the identifier. Each check consumes 1 action plus 0.2 data credits (Clay University). So the question is not whether Clay can do it. The question is whether a scheduled re-check of a list you maintain is the right shape for always-on champion coverage, and that depends on three design details most teams discover after they have already built the table.

This guide covers the setup, then the three details: what the LinkedIn key means for coverage, what “scheduled” means for latency, and how per-check pricing behaves when you multiply it by a real database.

What Clay’s job change signal actually is

Clay groups this under Signals, which its docs describe as “automated tracking systems that notify you of important changes related to your contacts and target companies” (Clay University). The default set covers new hires, promotions, job changes, and news and fundraising, plus custom signals. Most are available on any paid plan.

The job change signal is the people-level one. Clay’s documentation puts the use case plainly: “Job Change Signals notify you when monitored contacts switch roles, helping you transform existing relationships into new opportunities” (Clay University). The signal shipped in July 2024 (Clay changelog), and Clay’s marketing page for it claims you can know “within hours” when “your champion lands somewhere new” (Clay).

The important word in all of that is monitored. Clay is not watching the market and telling you which of your people moved. You hand it a list, and it re-checks that list on a cadence you choose. That is a legitimate architecture, and for a campaign it is a good one. It is a different thing from a continuously maintained feed, and the difference shows up in the three places below.

Setting it up

The mechanics are short, which is the appeal.

1. Build the table. One row per person. Clay’s docs are explicit about the requirement: the table “must contain the contact’s LinkedIn URL as an identifier” (Clay University).
2. Start the signal. “Click Actions, then select Monitor for job changes. Select your table of the contacts you want to monitor for job changes.”
3. Set the frequency. Clay’s lesson on configuring signals lists daily, weekly and monthly, and calls daily the option that is “ideal for job changes” (Clay University). Note that signals “can only be adjusted by frequency, not set to run at specific times” (Clay University).
4. Enrich the result. A detected move gives you a new company and title. It does not give you a working address, so you need an email step after it. More on that below.
5. Write it somewhere that reps see. Clay is a workspace, not an alerting layer. The move has to reach your CRM or your sequencer to matter.

If you want a scheduled refresh on individual columns rather than a signal, Clay also offers scheduled columns, which “automatically re-run your enrichments on a set schedule” at hourly (Enterprise only), day, week or month granularity (Clay University).

Detail one: the LinkedIn URL is the key, so coverage equals your key coverage

Because the signal is keyed on a LinkedIn profile URL, your job change coverage can never exceed the share of your contacts for whom you hold a correct, current profile URL.

For most CRMs that number is well under half, and it skews in an unhelpful direction. The records with clean LinkedIn URLs tend to be the ones someone recently prospected. The records without them tend to be older closed-won contacts, which is to say your actual champions. So you can end up monitoring your newest leads carefully and your most valuable relationships not at all.

Before you judge the signal, audit the key. Export your closed-won contacts, count how many have a populated LinkedIn URL, and treat that percentage as your ceiling. If it is 35%, a daily signal still misses roughly two thirds of your moves, and it will miss them silently, which is the worst failure mode a signal can have.

This is also why resolving identity on something more durable than a single profile URL matters. A person’s work email, name and employer history give you more than one way to recognize them after they move.

Detail two: scheduled means you learn on the next run

A periodic re-check introduces two lags that stack: the delay between the move becoming visible and your next scheduled run, plus the delay between the person starting the job and it showing up anywhere public at all.

Daily is a good cadence and it keeps the first lag small. Weekly or monthly, which teams often pick to control credits, does not. A champion who starts a new role on the 2nd and surfaces in a monthly run on the 30th is not a warm signal anymore. By then they have picked their stack, their first-quarter priorities are set, and someone else got there first.

The window is what you are buying here. Only about 6% of customer contacts tell a vendor they changed jobs. The other 94% never reach out, and 2 to 3% of your B2B contacts change jobs every month. A tool that surfaces the move late converts like cold outbound, because functionally that is what it has become.

So if you run this in Clay, run it daily on the population that matters rather than monthly on everyone. Which brings up the cost.

Detail three: per-check pricing multiplies

The published cost is 1 action plus 0.2 data credits per check (Clay University). Per contact, that is nothing. The thing to model is that it is per contact per run.

Work the arithmetic for your own list before you commit a cadence:

• Contacts monitored, times runs per month, equals checks per month.
• Checks per month, times 0.2, equals data credits consumed on detection alone.
• Then add the enrichment that happens after a hit: email waterfall, company lookup, any Claygent research.
• Then add the same math again for every other signal you want on the same people.

Clay’s own lesson states the obvious consequence: “More frequent runs consume more credits” (Clay University). The practical effect is that cost pushes you toward a less frequent cadence and a smaller list at exactly the moment coverage and speed are what you need. Teams resolve that tension by monitoring a tight, high-value population daily and accepting that the long tail goes unwatched.

That is a reasonable tradeoff to make deliberately. It is a bad one to make by accident because a credit balance ran low mid-quarter.

Getting the move out of Clay and in front of a rep

A detected move sitting in a Clay cell has produced zero pipeline. Clay gives you several exits, each with documented behavior worth knowing in advance.

HTTP API, outbound. Clay’s HTTP API “lets you send or retrieve data from any tool or database using an API endpoint, even when Clay doesn’t offer a native integration,” with configurable request rate limiting (Clay University). This is the flexible path if you have an internal service to receive the move.

Webhooks. Inbound webhooks let Clay “automatically receive data from other applications through HTTP POST requests in JSON format,” and are capped at 50,000 submissions, a limit that “persists even after deleting rows” (Clay University). On the outbound side, Clay’s public API signs deliveries with HMAC-SHA256 via an X-Clay-Signature header, and the docs are refreshingly direct that “webhook delivery is not guaranteed,” recommending polling as a fallback (Clay developer docs). Build the reconciliation job. If you want the general design pattern for consuming moves as events, we cover it in job change webhooks.

Salesforce. Clay can “create or update Salesforce records where the OAuth user has write access,” and by default “syncs Salesforce imports every 24 hours.” One line deserves a second read before you point this at production: “Once you update or create an object in Salesforce from Clay, you cannot undo these actions” (Clay University). Write to custom job-change fields rather than overwriting the primary company and email, and you keep an audit trail plus the ability to roll back by hand. Our Salesforce job change alert and HubSpot job change alert guides cover the field schema and the automation on the CRM side.

Do not skip the email step

Detection tells you someone moved. It does not tell you how to reach them, and the address in your CRM is now dead.

Clay’s work email waterfall runs providers in sequence and bills only for the one that hits: “You only pay credits for the provider that finds a match, making it one of the most credit-efficient ways to build email coverage at scale,” with the Infer Email step “completely free” (Clay University). Clay’s waterfall page describes the general approach as searching “sequentially across multiple tools until you find a valid match” (Clay).

One number from those docs should settle any argument about guessing patterns: in Clay’s internal testing on a software-industry dataset, the default [email protected] pattern returned a valid email roughly 31% of the time (Clay University). Pattern inference is a coin flip that loses. Use the waterfall, and set validation to Clay’s Conservative strategy, which its docs recommend when “deliverability matters (e.g. cold outreach where bounce rates affect sender reputation).”

This matters more on job change outreach than anywhere else, because the list is your warmest and the sender is usually a real rep’s mailbox. Burning that domain’s reputation on bounces is an expensive way to save a few credits. If you are doing this by hand, see our order of operations for finding a new work email.

Where Clay fits, and where a dedicated feed does

Clay is an excellent workbench. If your team has a GTM engineer who lives in it, the job change signal is a real feature and you should use it for campaigns, list builds and one-off plays. Nothing here argues otherwise.

The honest division is between a workbench and a subscription to a signal:

• A workbench is something you operate. Someone owns the table, the key coverage, the cadence, the credit budget, the enrichment chain, the write-back and the reconciliation job for undelivered webhooks. It is flexible precisely because it is assembled.
• A signal subscription is something that runs whether or not anyone is paying attention this quarter. Detection, identity resolution and email verification are maintained by the vendor, and the move arrives in the CRM as structured data.

Champion tracking is a bad fit for a side project because its value is entirely in continuity. A table that goes stale in week nine of a busy quarter produces no alerts, and nobody notices, because the absence of alerts looks exactly like a quiet month. That is the specific failure a maintained feed is for. Champions monitors the people already in your CRM, resolves the new employer and a verified work email, and writes each move back as a warm lead, with no app for reps to install and no new login. The how it works page walks the monitoring end to end, and the API page covers the event fields and delivery modes if you would rather pipe the moves into Clay or your own service yourself.

Why this signal earns the engineering time at all

Worth restating the reason to build any of this, because it is the strongest argument for daily cadence over monthly:

• Champion-sourced deals close at a 2.7x higher probability, in roughly half the sales cycle.
• You have a 60 to 70% chance of selling to an existing relationship, against 5 to 20% for a cold prospect.
• 65% of a company’s business comes from existing customers, and acquiring a new one costs 6x more than keeping one.
• On a 10,000-contact CRM, roughly 20% surface as hot leads on day one, then 200 to 300 new warm leads arrive per month.

That last line is the one that decides architecture. Two hundred to three hundred moves a month is a steady operational flow, not a campaign. Steady flows want a pipeline that runs itself. For how teams report on that flow as its own forecast category, see champion-sourced pipeline metrics and the RevOps use cases page.

Build versus buy: where the line falls

The line is not the table and it is not the automation. Building a Clay table with a job change signal is an afternoon, and Clay runs it well.

The line is sustained detection coverage, identity resolution after the move, and email verification, maintained continuously across thousands of relationships without anyone tending it. That is a data operations commitment, not a workflow one. If you have a GTM engineer with capacity to own it indefinitely, Clay is a credible way to run the motion. If the honest answer is that it will be someone’s third priority, the maintenance is the thing to buy.

Two differences to weigh if you compare tools, beyond cadence and credits. Champions monitors intent-to-move signals rather than only confirmed moves, which shifts the outreach window earlier. And the ROI is contractual: if champion-sourced revenue does not reach 2x the annual service fee, you are covered under our terms. Among the job change tools teams usually shortlist, that guarantee is specific to us. The job change tracking comparison lays the options side by side.

The bottom line

Clay’s job change signal is real, documented and cheap per check. Set it up on a LinkedIn-URL-keyed table, run it daily rather than monthly, waterfall the email instead of guessing the pattern, write to custom CRM fields rather than overwriting the record, and build the reconciliation job because webhook delivery is not guaranteed.

Then be clear-eyed about the three ceilings: your coverage equals your LinkedIn key coverage, your latency equals your run interval, and your cost scales with contacts times runs. If those ceilings sit above what you need, you are done. If champion coverage has to be complete and permanent, the detection layer is worth owning as a feed rather than a table.

Want the signal maintained for you and written straight into your CRM? Book a demo and we will map it against the list you are monitoring in Clay today. If you would rather just ask a question first, email [email protected].