Refresh stale CRM records before you reach out
A Claude prompt that takes a list of CRM contacts and re-verifies each one against live data. It returns three things per record: whether the person is still at the company, whether their title still matches what’s in the CRM, and whether their phone and email are still verified. Anything that’s changed gets flagged with the corrected value. Anything that can’t be confirmed gets marked, not guessed.
B2B contact data decays at roughly 30% a year — people change jobs, get promoted, leave. A list that was clean six months ago is now one in six records pointing at someone who moved. Reps don’t find out until the call connects to a stranger or the email bounces, and by then the touch is spent and the sequence is poisoned. This prompt runs the decay check before the first touch, so the list a rep works is the list that’s actually true today.
Once Lusha is connected in Claude, the connector runs in the background — no special syntax needed. Paste the contacts and run.
Images on this webpage are for illustrative purposes only. Any named individuals shown in live demo outputs are real, with last names abbreviated for privacy.
The prompt
<context>
I'm about to work a list of CRM contacts. Before I do, I want to re-verify each one against live data — confirm the person is still at the company, the title still matches, and the phone and email are still good. I'd rather drop a stale record than burn a touch on it.
My list (paste from CRM export):
- Each row: [NAME, TITLE, COMPANY, EMAIL ON FILE, PHONE ON FILE, DATE RECORD LAST UPDATED]
</context>
<task>
For each contact, use Lusha to verify against live data:
1. Still at the company
- Confirm the person is currently at the company on file
- If they've left, flag it and surface where they are now if Lusha returns it
2. Title still current
- Confirm the title on file matches their current title
- If it changed (promotion, lateral move), return the current title
3. Contact details still verified
- Confirm the email on file is a current verified work email; if stale, return the verified one
- Confirm the phone on file is a current direct line; if stale, return the verified one
4. Return a per-record status:
- CURRENT — person, title, email, and phone all confirmed. Work this record as-is.
- UPDATED — record corrected. Show exactly what changed (old → new) so I can update the CRM.
- DEPARTED — person has left. Drop from this list; surface the replacement contact if available.
- UNVERIFIED — could not confirm. Flag it; don't guess.
5. End with a one-line summary: how many records are current, updated, departed, and unverified, so I know the real size of the list I'm working.
</task>
<constraints>
- Each check is binary — the person is at the company or they aren't, the title matches or it doesn't. Don't soften with "likely still there."
- Show every correction as old → new so the CRM update is a copy job, not a re-research job.
- Do not invent contacts, titles, emails, or phone numbers. Surface only what Lusha returns.
- A CURRENT record is safe to work today. An UNVERIFIED record is not — keep them separate.
</constraints>What you'll get back
Input: A 6-row CRM export pulled for an outbound push, last updated between 4 and 11 months ago. Contacts at Snowflake, Datadog, and HashiCorp.
Output: Of 6 records, 3 current, 2 updated, 1 departed. The push was about to go out against all six. Below is the real result from running the prompt against the live Lusha connector.
Refresh summary: 3 current · 2 updated · 1 departed · 0 unverified
One in three records on this list had decayed since the last update. A rep working the raw export would have hit a changed title on two calls and a dead seat on one — three of six touches degraded before dialing.
Per-record status
| Contact (on file) | Company | Status | What changed |
|---|---|---|---|
| Keegan R., SVP Sales Americas | Snowflake | CURRENT | Person, title, email, phone all confirmed |
| Patrick H., VP RevOps | Snowflake | CURRENT | Confirmed; same role, same scope |
| Dwarak R., VP AI Engineering | Snowflake | UPDATED | Title now VP & Head of AI Engineering — email unchanged, phone unchanged |
| Marcus L., Director of Sales Ops | Datadog | UPDATED | Promoted to Senior Director, Revenue Operations — verified email changed (old → new returned) |
| Priya N., VP Marketing | Datadog | CURRENT | Person, title, email, phone all confirmed |
| Tomer A., Head of Growth | HashiCorp | DEPARTED | No longer at HashiCorp — replacement in seat: Eli K., Director of Growth (verified) |
What this means for the push
- Work today (3): Keegan R., Patrick H., Priya N. — clean, no change.
- Update CRM, then work (2): Dwarak R. (title), Marcus L. (title + email). Both corrections returned as old → new — copy into the CRM and dial.
- Drop and re-route (1): Tomer A. has left HashiCorp. Replacement Eli K. surfaced and verified — add the new contact, retire the old record.
The real list is six rows; the workable list is five, and two of those need a CRM correction before the first touch. Running the raw export would have spent three touches learning what this check returned in 60 seconds.
The verified contact data reused from earlier gallery runs — zero new credits consumed.
Why use Lusha in Claude
Contact data doesn’t go stale on a schedule a rep can see. A record updated in January looks identical to one updated last week — same fields filled in, same confidence on the surface. The decay is invisible until the touch fails. This prompt makes the decay visible before the touch, which is the only point where finding it still saves the touch.
The check is binary on every field. The person is at the company or they aren’t. The title matches or it doesn’t. A real refresh doesn’t hedge with “probably moved on” — it confirms the record or returns the correction. Reps trust a list more when the unverifiable rows are pulled out and labeled, not quietly left in to fail later. Honesty on what couldn’t be confirmed is what makes the rest of the list workable.
The corrections come back as old → new, so updating the CRM is a copy job, not a second round of research. A title change isn’t just flagged — the current title is returned. A stale email isn’t just marked bad — the verified one replaces it. The prompt closes the loop it opens, which is the difference between a list that gets cleaned and a list that gets a to-do attached to it.
The departed-contact path is where a refresh earns its keep. A contact who left isn’t a dead end — it’s a routing problem with an answer. Lusha surfaces the replacement in seat, verified, so the record gets re-pointed instead of retired. The list doesn’t shrink by one; it gets corrected by one. That’s the gap between data that decays and data that stays callable.
Data drawn from 300M+ verified contacts under GDPR, CCPA, SOC 2, ISO 27701, ISO 31700, and TRUSTe.
FAQ
How many records should I refresh at once?
A working list — the contacts you’re about to sequence or dial this week — is the right batch. Re-verifying a contact you won’t touch for three months means re-verifying it again when you do. Run the refresh against the list at the moment you’re about to work it, not the whole database on a schedule.
What counts as "stale" enough to re-verify?
Any record more than a quarter old is worth a check, since B2B data decays at roughly 30% a year. Records under a month old are usually still current. The prompt doesn’t need you to pre-judge which ones decayed — it checks them all and tells you which moved.
Does it update my CRM automatically?
No — it returns the corrections as old → new so you can update the CRM yourself, or hand the output to a paired Sheets or CRM workflow that writes them back. The prompt’s job is to find and verify the changes; the write-back is a separate step you control.
What if Lusha can't verify a record?
It gets marked UNVERIFIED and kept separate from the workable list — never guessed. An unverifiable record isn’t the same as a bad one; it just couldn’t be confirmed against live data. Keeping those apart is what lets a rep trust the CURRENT rows.
Is a departed contact a dead record?
Not if there’s a replacement. When someone has left, the prompt surfaces the verified person now in the seat, so the record gets re-pointed instead of retired. A departure is a routing change, not a loss — the account is still the account.
How is this different from enriching a new list?
Enrichment fills in contacts you don’t have yet. This refresh re-verifies contacts you already have but can no longer trust. Different starting point, same end state — a list that’s true today. If you’re building from scratch, start with the prospecting plays; if you’re working an existing list, start here.
Ready to build this?
Get started with Lusha and set up this play in minutes.
