track-contact-job-changes

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)

1. Confirm the contact is in the CRM using the person match keys, and read their current company, title, and LinkedIn URL.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.