One line: run this when you want the CRM's contacts to reflect where those people actually work now,
and to catch champions who moved to a new account. It produces a reviewed batch of CRM changes, never a
silent rewrite.
Golden rule: propose, then confirm. Collect every proposed change and show it as one table before
touching the CRM. And never act on the wrong person — if the enriched identity doesn't match the
contact, it goes to "can't confirm", not to a write.
Setup (once)
Before the first run, capture the operator's configuration and save it — see
references/setup-checklist.md. It records: the CRM and whether writes
are allowed; the match keys for a person (record id, email, LinkedIn URL) and a company (domain,
LinkedIn company URL, name); the four data sources the play needs (a LinkedIn-URL finder, a work-history
source that returns current + past roles, an email lookup, a company-enrichment source); the tier
rules that define a create-worthy account; the opt-out rules that mark a move as a dead end; and
the CRM field names to write. On a later run, load the saved config; if none exists, run setup first.
The play (per contact)
- Confirm the contact is in the CRM using the person match keys, and read their current company,
title, and LinkedIn URL.
- Have a LinkedIn URL? If not, look one up from name + company and validate the found profile's
name against the contact before trusting it. Retry once. Still nothing → mark can't confirm and stop.
- Pull current + past roles from the work-history source. Validate the returned person's name against
the contact. On a name mismatch → the stored URL is likely wrong → mark can't confirm (re-find), stop.
- Compare the current employer to the CRM company using the matching rules in
references/matching.md — domain and LinkedIn-page agreement decide it; a name
alone never does. Three outcomes:
- Still there → propose refreshing title/tenure if they changed; otherwise mark verified. Done.
- Can't confirm (weak or conflicting signals) → propose re-finding the URL or flag for review. Never guess. Done.
- Confirmed left → separate old (the CRM company) from new (the current employer), and continue.
- Is the new company already in the CRM? Match it with the same rules.
- Yes → apply the opt-out rules. If the new company is a customer, competitor, or otherwise
disqualifying → flag & opt out (stop outreach, record the move). Otherwise → update the
contact to the new company/title and re-associate to the existing account.
- No → enrich the company, then tier it against the rules in
references/tiering.md. A fit account → propose creating the account,
then update the contact onto it. A non-fit account → skip & flag (don't create it), but still
update the contact's new company/title so the record is honest. Both paths end at an updated contact.
- Approve & apply. Present the batch as one table — contact, old → new company, outcome, fields to
write, and the evidence/confidence behind it. Apply only what's approved. If writes are disabled,
export the table instead of writing.
What good looks like
A great run leaves every still-employed contact quietly verified, every real mover refreshed to their
actual new role, and every champion who landed at a net-new fit account surfaced as a new opportunity —
with a one-glance approval table the operator can trust and audit. Confidence is earned from domains and
LinkedIn pages, not from fuzzy name overlap; acquisitions and rebrands are treated as "same company" only
when the hard identifiers agree.
The mediocre version pollutes the database: it overwrites a contact because two company names looked
similar, acts on a same-name stranger's profile, creates duplicate accounts for a company already in the
CRM under a different name, or auto-writes a pile of changes no human ever saw. The tell of the expert:
they trust "confirmed left" only when the new employer is hard-identified, and they would rather leave a
record as "can't confirm" than write a confident lie.
Rules
- MUST propose every CRM create/update in a single review step and apply only what a human approves.
- MUST validate the enriched person's name against the contact before using any profile; on mismatch, route to "can't confirm".
- MUST decide company sameness from domain / LinkedIn-page agreement first; a name-only match is never sufficient to write.
- MUST keep the old company as previous-role history when a contact is updated — never erase where they came from.
- NEVER create a new account for a company that already exists in the CRM under a different name or domain.
- NEVER opt a contact out, or overwrite their role, on low-confidence or single-signal evidence.
- NEVER continue when writes are disabled — export the proposed changes instead.
1---2name: track-contact-job-changes3description: Use this skill when you need to find which contacts in the CRM have changed jobs and act on it — a quarterly database refresh, a "did anyone move?" sweep, a churn-risk or new-champion check, or a job-change signal firing on a known contact. It reads each contact's current role from their work history, compares it to what the CRM believes, and routes the movers: still-there contacts get refreshed, confirmed leavers get their old and new roles separated, movers to non-fit companies get flagged and opted out, and movers to net-new fit companies get the company enriched, tiered, and optionally created as an account. Every CRM write is proposed for approval first — the database is never polluted and no contact is silently overwritten. Also known as: job change detection, contact data refresh, champion tracking, buyer-moved alerts.4---56One line: run this when you want the CRM's contacts to reflect where those people actually work now,7and to catch champions who moved to a new account. It produces a reviewed batch of CRM changes, never a8silent rewrite.910**Golden rule: propose, then confirm.** Collect every proposed change and show it as one table before11touching the CRM. And **never act on the wrong person** — if the enriched identity doesn't match the12contact, it goes to "can't confirm", not to a write.1314## Setup (once)1516Before the first run, capture the operator's configuration and save it — see17[references/setup-checklist.md](references/setup-checklist.md). It records: the CRM and whether writes18are allowed; the **match keys** for a person (record id, email, LinkedIn URL) and a **company** (domain,19LinkedIn company URL, name); the four data sources the play needs (a LinkedIn-URL finder, a work-history20source that returns current + past roles, an email lookup, a company-enrichment source); the **tier21rules** that define a create-worthy account; the **opt-out rules** that mark a move as a dead end; and22the CRM field names to write. On a later run, load the saved config; if none exists, run setup first.2324## The play (per contact)25261. **Confirm the contact is in the CRM** using the person match keys, and read their current company,27 title, and LinkedIn URL.282. **Have a LinkedIn URL?** If not, look one up from name + company and **validate the found profile's29 name against the contact** before trusting it. Retry once. Still nothing → mark *can't confirm* and stop.303. **Pull current + past roles** from the work-history source. Validate the returned person's name against31 the contact. On a name mismatch → the stored URL is likely wrong → mark *can't confirm* (re-find), stop.324. **Compare the current employer to the CRM company** using the matching rules in33 [references/matching.md](references/matching.md) — domain and LinkedIn-page agreement decide it; a name34 alone never does. Three outcomes:35 - **Still there** → propose refreshing title/tenure if they changed; otherwise mark verified. Done.36 - **Can't confirm** (weak or conflicting signals) → propose re-finding the URL or flag for review. Never guess. Done.37 - **Confirmed left** → separate old (the CRM company) from new (the current employer), and continue.385. **Is the new company already in the CRM?** Match it with the same rules.39 - **Yes** → apply the opt-out rules. If the new company is a customer, competitor, or otherwise40 disqualifying → **flag & opt out** (stop outreach, record the move). Otherwise → **update the41 contact** to the new company/title and re-associate to the existing account.42 - **No** → **enrich the company**, then **tier it** against the rules in43 [references/tiering.md](references/tiering.md). A **fit** account → propose **creating the account**,44 then update the contact onto it. A **non-fit** account → **skip & flag** (don't create it), but still45 update the contact's new company/title so the record is honest. Both paths end at an updated contact.466. **Approve & apply.** Present the batch as one table — contact, old → new company, outcome, fields to47 write, and the evidence/confidence behind it. Apply only what's approved. If writes are disabled,48 export the table instead of writing.4950## What good looks like5152A great run leaves every still-employed contact quietly verified, every real mover refreshed to their53actual new role, and every champion who landed at a net-new fit account surfaced as a new opportunity —54with a one-glance approval table the operator can trust and audit. Confidence is earned from domains and55LinkedIn pages, not from fuzzy name overlap; acquisitions and rebrands are treated as "same company" only56when the hard identifiers agree.5758The mediocre version pollutes the database: it overwrites a contact because two company names looked59similar, acts on a same-name stranger's profile, creates duplicate accounts for a company already in the60CRM under a different name, or auto-writes a pile of changes no human ever saw. The tell of the expert:61they trust "confirmed left" only when the new employer is hard-identified, and they would rather leave a62record as "can't confirm" than write a confident lie.6364## Rules6566- MUST propose every CRM create/update in a single review step and apply only what a human approves.67- MUST validate the enriched person's name against the contact before using any profile; on mismatch, route to "can't confirm".68- MUST decide company sameness from domain / LinkedIn-page agreement first; a name-only match is never sufficient to write.69- MUST keep the old company as previous-role history when a contact is updated — never erase where they came from.70- NEVER create a new account for a company that already exists in the CRM under a different name or domain.71- NEVER opt a contact out, or overwrite their role, on low-confidence or single-signal evidence.72- NEVER continue when writes are disabled — export the proposed changes instead.
swan-gtm