Detect the Move

Outcome: a weekly detection run producing a clean list of real movers, with title cleanups and out-of-centre moves filtered out before anyone is contacted.

Surface: App and MCP server
Level: Intermediate
Uses: check_job_change
Credits: ~1 per person checked
Prerequisite: Lesson 02's tracked list with a baseline

How detection works

check_job_change compares a person’s current profile against the company you have recorded for them, and reports whether they have moved.

Two things follow, and both shape the design:

It bills per person checked, not per mover found. Your weekly cost is your tracked population, not your result count.
It depends on the person updating their profile. Detection lags reality by however long that takes.

Reference: check_job_change, Job change.

The lag

Time after starting	Typical profile-update state
Week 0–1	Many have not updated
Week 2–4	Most have
Week 4–8	Almost all

So a weekly check finds people roughly two to four weeks into their new role — which lands neatly inside the week 3–12 window from lesson 01. Weekly is the right cadence not because it is fast, but because it catches people as they become findable.

A monthly check adds its own delay on top of the profile lag. Combined, that puts the average detection at six to eight weeks after the start date — past the halfway point of the window, and after most tooling conversations have begun.

Filter the output

Detection reports change. Not all change is a trigger.

Detected change	Trigger?	Why
New company, comparable or senior role	Yes	The core case
New company, junior role or a pivot out of your buying centre	No	Relationship intact, authority gone
Same company, promotion into authority	Yes — lesson 04’s trigger
Same company, title normalization	No	Nothing changed
Contract, interim or advisory role	Usually no	No budget authority
Company renamed or acquired	No	The person did not move

That last row is worth a specific check: an acquisition changes the company name on a profile without anyone moving, and it looks exactly like a job change in the raw output.

Handle the near-misses

Three states, not two.


moved            → qualify the new company (lesson 05)
not moved        → leave in the tracked list, check again next week
uncertain        → flag for review, do not contact

Uncertain cases — an ambiguous title change, a company that may or may not be the same entity — should never go straight to outreach. A wrong “congratulations on the new role” to someone who did not move is a specific and memorable embarrassment.

The weekly cost

Detection bills per person checked, so the cost is predictable:

Tracked population	Weekly cost	Annual
200	~200 credits	~10,400
500	~500	~26,000
1,000	~1,000	~52,000

Two ways to control it, in order of preference:

Prune the untrackable and the irrelevant. People who left your buying centre entirely, people at companies you no longer sell to, rows that never resolve.
Tier the cadence. Past customers weekly, evaluators monthly. The highest-value population gets the fastest detection.

Do this now

Run detection across the tracked list

The first run finds everyone who already moved — expect a batch.

Apply the trigger filter

Drop title cleanups, junior moves and renames.

Check for acquisitions specifically

A renamed company is not a move.

Split into three states

Moved, not moved, uncertain.

Record the detection date

Not just the fact. The window is computed from it.

Compute the weekly cost

Tracked population × cost per check.

Decide the cadence per population

Weekly for customers, monthly for evaluators if cost matters.

Check your work

Detection ran against the full tracked list
Title cleanups and out-of-centre moves are filtered out
Acquisitions are distinguished from moves
Uncertain rows are flagged, not contacted
Detection date is stored per mover

Where this breaks

Treating every detected change as a move produces messages congratulating people who did not move — after a company rebrand, an acquisition, or a title normalization. These land badly precisely because the recipient knows nothing happened, and it is the clearest possible evidence that an automated system is watching them. Filter before contacting, always.

Further automation

The same run doubles as contact-data hygiene: everyone it flags as moved has an email and title that are now wrong in your CRM. Writing the change back keeps records current for a fraction of what a blanket re-enrichment costs — the loop CRM Enrichment builds out.

Next lesson

04 — Promotions as a second trigger, the quieter signal inside accounts you already know.

Reference for this lesson: check_job_change, Job change, Current role, Past role.