Monitor CRM contacts for promotions and company changes

<context>
I have an existing CRM contact list. I want to know which of these contacts had a role change — promotion or company move — in the last 12 months. Both events open a re-engagement window.
</context>

<task>
1. Take this CRM contact list (one row per line, with name and current company):
   [PASTE CONTACT LIST]

2. For each contact, run two parallel lookups:
   - Signals layer: query Lusha's contact signals (promotion, companyChange) for time-series events in the window
   - Contact lookup: query Lusha's contact record for the contact's current jobStartDate and previousJob fields

3. Combine the results. A role change is detected if EITHER:
   - The signals layer returned a promotion or companyChange event in the window
   - The contact's jobStartDate is more recent than the CRM record's lastUpdated date and the title or company has changed

4. Output a role-change table:
   Name | CRM record | Current Lusha record | Change type | Detected by | Signal date | Action

5. Assign a change type per row:
   - PROMOTED — same company, new title or expanded scope (re-engage with first-90-days framing)
   - MOVED — new company since the CRM record was created (update the row, re-engage at the new employer)
   - NO CHANGE — Lusha confirms the CRM record is still current (no action needed)
   - NO MATCH — Lusha cannot resolve the contact (re-research or archive)

6. Summarize at the top: total contacts scanned, total promoted, total moved, total no change, total no match.
</task>

<constraints>
- Use two detection paths. The signals layer is a time-series of discrete events; the contact record is the current state. Role changes show up faster in the contact record's jobStartDate than in the signals stream, so check both.
- A PROMOTED row carries the strongest re-engagement signal. Surface the job start date so the rep can time the message inside the first-90-days window.
- A MOVED row is two rows of work — update the CRM (old record is dead) and re-engage at the new employer.
- Do not invent fields. If both detection paths return nothing and the contact's current record matches the CRM, the row is NO CHANGE.
</constraints>

Input: 5-contact CRM list (Brian R. at Snowflake, Tori M. at Notion or Pigment, Sean K. at Datadog, Namrata R. at Notion, Laura F. at DevRev). Window — last 12 months.

Output: 3 role changes detected via the contact-record path, 0 fired in the signals layer for this batch. The page shows both outcomes so the reader understands how the two detection paths complement each other.

Names abbreviated for privacy. Full records — including emails and direct dials — are returned inside your Claude session.

The Sean K. row demonstrates a recent promotion caught by the contact record’s jobStartDate. The two MOVED rows demonstrate the dual benefit: both contacts left the CRM-recorded company over a year ago and now sit at new employers (Pigment and Together AI). The CRM record at the old company is dead; the contact at the new company is callable today.

One credit consumed for the signals-layer scan. The contact-record lookups reused data already verified earlier in the gallery, so the demo burned minimal credits.