Matching the attendee list to the CRM: where AI helps and where it quietly breaks things

Seventy-six percent of organizations say less than half of their CRM data is accurate and complete, according to Validity's 2025 survey of 602 companies (Validity, 2025). The same survey found CRM users spend an average of 13 hours a week searching for basic information, and 37% of staff regularly fabricate data for leadership. Validity sells data quality software, so read the numbers with that in mind. They are still hard to wave away.

Into that system, event teams pour a spreadsheet after every dinner, roundtable and reception. The join between that spreadsheet and the CRM is where event reporting succeeds or fails. It is fiddly work, and it is increasingly handed to AI.

That is reasonable, up to a point. Validity's 2024 survey of CRM admins lists the problems a matching workflow has to handle: incomplete data (68%), missing data (65%), incorrect data (61%), duplicate records (53%) and expired data (49%) (Validity, 2024). A model can help with several of those. It can also make each of them worse without anyone noticing.

Here is a seven-step workflow that keeps the speed and contains the damage.

Step 1: Normalize both files before matching anything

Export two tables. From the registration tool: name, email, company as typed, title as typed, attendance status. From the CRM, for the accounts likely to be involved: contact ID, name, email, account name, account domain, owner, last activity date.

Then clean both the boring way:

- Lowercase and trim every email address.
- Split out the email domain into its own column.
- Strip legal suffixes from company names (Inc, LLC, Ltd, GmbH, Corp).
- Trim stray spaces from names.

Spreadsheet formulas do this reliably. There is no reason to involve a model in a step that has one correct answer. Deterministic work should stay deterministic.

Step 2: Take the exact matches first, without AI

Match on work email. For registrations collected with a required work email field, this resolves the easy rows immediately. Mark each one in a new column, match_method = exact, so you can tell later how every record was joined.

Only the leftovers go to AI. Those are the hard cases: personal email addresses, typos, company name variants, and people who changed jobs.

Step 3: Hand the leftovers to AI, with a strict contract

The prompt should make the model propose, explain and never act.

You are helping match event attendees to existing CRM contacts. You
will receive two tables: UNMATCHED ATTENDEES and CRM CONTACTS.

For each unmatched attendee, return one row:
attendee_name | proposed_crm_contact_id | match_type | confidence
(high/medium/low) | reason

match_type must be one of:
- SAME_PERSON_SAME_COMPANY
- SAME_PERSON_NEW_COMPANY (possible job change)
- COMPANY_MATCH_ONLY (the account exists, this person does not)
- NO_MATCH

Rules:
- Never propose a match on first and last name alone. A match needs
  at least two of: name, email domain, company name, email username.
- If two CRM contacts could fit, return both and mark confidence low.
- Use only information in the two tables. Do not infer job titles or
  use outside knowledge about any person.
- Do not merge, edit or delete anything. You are proposing matches
  for human review.

Each rule closes a specific failure. The two-signal rule prevents the classic false merge between two people with common names. The "return both" rule forces ambiguity into the open instead of letting the model pick one silently. The ban on outside knowledge stops it from filling in a title or employer from whatever it absorbed in training, which may be years old.

Step 4: Build the company alias table separately

Company names are the messiest field in any registration export. Abbreviations, old brand names, regional entities and plain typos all show up. This is a job AI does well, as long as it shows its work.

Group the company names below where they plausibly refer to the same
organization. For each group, give the reason: shared email domain,
abbreviation, spelling variant, or known parent company. Mark any
grouping based on your general knowledge rather than the data in
this list as UNVERIFIED.

[paste distinct company names with their email domains]

The UNVERIFIED flag matters most for parent companies and subsidiaries. A subsidiary is often a separate account in the CRM, with its own owner and its own opportunities. Fold it into the parent and an attendee can end up credited to the wrong account executive's deal. A person who can see the CRM's account hierarchy makes that call.

Step 5: Treat personal emails and job changers as special cases

Personal email addresses remove the strongest matching signal. A match on name plus company is medium confidence at best, and should be reviewed every time. The durable fix sits upstream: require a work email at registration, or ask for company and title as separate required fields.

Job changers are where quiet damage happens. When the model returns SAME_PERSON_NEW_COMPANY, the tempting move is to update the existing record with the new employer. Don't. That erases the person's history at the previous account and can pull them off an open opportunity there. Create a new contact at the new account, and mark the old record as departed using whatever convention your CRM team already follows.

And remember what the model actually knows. It noticed that the name matches and the company doesn't. It cannot confirm the move. A person checks.

Step 6: What to check

This is where the workflow earns its keep. A few rules of thumb:

• A false merge is worse than a missed match. A miss creates a duplicate you can fix later. A wrong merge attaches one person's history to another, and can credit an opportunity that had nobody in the room. Review every medium and low confidence row. Spot-check about one in ten high confidence rows.
• Verify that every proposed ID exists. Look up each proposed_crm_contact_id against the export. Models occasionally return IDs that look right and match nothing.
• Check the account as well as the person. The right person on the wrong account still produces the wrong report.
• Watch the common names. Any match where the name is shared by more than one contact at the same company gets a second look.
• Keep the data where it belongs. Attendee lists are personal data. Use an AI tool your company has approved for it, never a personal account. Planners already name data security and privacy as their top AI concern, at 59% (PCMA, 2025).

Step 7: Write back with an audit trail

Before importing, add three columns: match_method (exact, ai_proposed_approved, manual, new_contact), approved_by and date. Then import. Save the alias table and reuse it at the next event, so each list gets a little easier than the last.

Then name an owner. In Validity's 2024 survey, 35% of organizations were unsure who owns CRM data accuracy, and 55% had no full-time employee dedicated to it (Validity, 2024). A year later, 57% had moved to manual data cleaning while cutting dedicated data staff (Validity, 2025). In practice, that means the attendee-to-CRM join lands on the event team whether or not anyone assigned it. Better to assign it on purpose.

Validity's Cynthia Price described organizations "layering AI on top without addressing foundation" (Validity, 2025). Salesforce, a vendor, reports that 74% of sales professionals are now prioritizing data cleansing (Salesforce, 2026). This workflow is a small, concrete piece of that foundation.

The model will do this faster than you. It will also, once in a while, merge two different people named Chris Lee with complete confidence. Build the workflow around that row.