agent mixed up two leads with the same first name - sent the pricing follow-up to the wrong person with the wrong...
Fixes an SDR agent that confuses two contacts who share a first name and sends personalized details - pricing, numbers, context - to the wrong person. Use when the agent keys outreach on first name or other non-unique fields instead of a stable lead id. Not for duplicate records in the CRM, or for wrong data on the right person.
TL;DR
Never let the agent address or personalize by first name alone. Every send must resolve to a unique lead id (or normalized email) first, and the drafting step must show the resolved identity - full name, company, and the numbers it plans to send - so a mismatch is visible before anything goes out.
agent mixed up two leads with the same first name - sent the pricing follow-up to the wrong person with the wrong numbersSteps
Make lead id (or normalized email) the only identity the send path accepts. Strip any step that looks up "the Sarah" or matches on first name. Expected: a search for first-name-only lookups in the workflow finds zero send paths using them.
Add an identity line at the top of every draft the agent produces: full name, company, lead id, and the specific figures in the message. Reviewers - human or automated - check this line first. Expected: every draft carries the identity line, and a wrong-person draft is catchable at a glance.
Before any message containing pricing, quotes, or account-specific numbers, the agent must re-fetch the lead record by id and confirm the numbers belong to that record. Expected: the re-fetch happens in the run log right before the send, with the record id visible.
Dedupe or flag near-duplicate contacts in the CRM - two records with the same first name at different companies are the setup for this exact failure. Expected: a report lists same-first-name contacts the agent touched in the last 30 days, so you can see the blast radius.
For the lead who got the wrong pricing, have the AE send a clean correction quickly and note the correct figures; do not let the agent "fix it" with another automated follow-up. Expected: the correction goes out from a human within a day, referencing the right numbers for the right person.
Use this when
- two contacts share a first name (or last name) and the agent confuses them
- personalized numbers or details went to the wrong person
- the agent's lookup step matches on non-unique fields
Not for this skill when
- the CRM has literal duplicate records for one person - that is a dedupe job
- the right person got wrong data - that is a data-quality problem
- the agent emailed the wrong address for the right contact - that is a contact-data problem
Variant phrasings
- agent confused two leads with the same name
- pricing follow-up sent to the wrong Sarah
- first-name lookup hit the wrong contact
- personalized details went to the wrong person
Why it happens
"Hi [first_name]" templates train everyone - including the agent's prompts - to think of the lead as a first name. Lookup steps written casually ("find Sarah") return the first match, and the drafting step happily personalizes with whatever record came back. The identity was ambiguous from the start; the send just made it permanent.
Edge cases
- Common names at the same company (two Sarahs on one team) - the identity line must include title or department, not just company.
- The lead replies from a different email than the record - re-resolve identity on reply, do not assume the thread belongs to the original record.
- Nicknames vs legal names ("Mike" vs "Michael") - normalize at lookup time so both resolve to the same id.
- Merged records can carry the wrong id forward - after a CRM merge, verify the surviving record before the next send.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_CHgo1PqSRhArP1xRz2Xycw