The Meeting Attendee Used a Different Email or Display Name: Reconcile Identity Before Logging the Outcome

A prospect you invited joins the call, but the name in the participant list does not match the contact record. The email differs. The display name is an alias, a generic label, or a phone number. The dial-in shows only digits. You need to decide: is this the right person, a colleague attending on their behalf, or someone entirely different?

Meeting platforms obscure attendee identity by design. Zoom exposes a stable conf_user_id only for signed-in Zoom accounts. Microsoft Teams provides a user_id tied to the tenant. Google Meet does not expose a stable identifier at all for signed-in participants across meetings, according to Recall.ai's participant identification documentation. When the observed join identity does not match the invited contact, you must reconcile manually before logging the outcome and updating attribution.

This guide walks through the evidence types that link a mismatched attendee to the correct CRM contact, the decision rules for when to match versus flag, and the fields to update once reconciliation is complete.

What evidence links a different attendee email or display name to the invited prospect?

The reconciliation process searches for matches using a weighted set of fields. The strongest signals are email address and phone number. Weaker signals include name fragments, company domain, role title, and calendar acceptance.

Veeva's CRM event management system documents a weighted search function for walk-in attendee reconciliation that prioritizes email, then phone, then last name, then postal code and territory, then city and first name. The last name field is required to initiate a search. This hierarchy reflects the reliability of each identifier: an exact email match is definitive; a first-name-only match in a large database is not.

Microsoft Teams logs participant type and tenant ID. If the user_id in the meeting transcript belongs to the same tenant as the invited contact and the role is listed as attendee or presenter, the match is strong. Microsoft's Teams Rooms People Recognition documentation describes how enrolled users are attributed by voice or face profile when joining from a Teams Room, but external participants or those not enrolled still appear as generic labels.

Zoom logs conf_user_id for signed-in accounts. If the participant record contains a conf_user_id, that identifier is consistent across meetings and can be stored in a custom CRM field to enable automatic matching in future calls. The user_guid field is not stable and should not be used for cross-meeting identification, per Recall.ai guidance.

Google Meet provides no stable identifier. The static_participant_id is null for anonymous or non-signed-in participants, and even when populated it is not consistent across meetings for a signed-in participant. Reconciliation must rely on display name parsing, email address if provided in the invitation acceptance, and contextual signals such as the participant speaking first or responding to a direct question addressed to the invited contact.

Calendar acceptance provides indirect confirmation. If the invited contact accepted the calendar invitation and the meeting platform shows one attendee joined at the scheduled time with a name substring that matches the contact's first or last name, the probability of a correct match is high. This signal is weaker when multiple attendees join simultaneously or the display name is a generic label like 'iPhone' or 'Conference Room 3.'

When must the identity remain unresolved?

Leave the identity unresolved when the available evidence does not meet your organization's matching confidence threshold. Forcing a low-confidence match corrupts downstream attribution, contaminates engagement scoring, and undermines the CRM data that revenue operations teams depend on for forecasting and territory analysis.

Dismiss rather than guess. Veeva's walk-in reconciliation feature includes a 'Dismiss' action that sets the attendee's status to Dismissed_vod. Dismissing indicates the attendee does not need to be matched to a CRM account for tracking purposes. The attendee record is not deleted; it remains available for audit. This pattern applies to any scenario where identity cannot be confirmed: an executive assistant who joined to take notes, an unexpected participant from a partner organization, or a dial-in number that cannot be traced.

Flag for follow-up when identity matters. If the attendee participated substantively (asked questions, raised objections, expressed interest), log the meeting as completed but create a follow-up task assigned to the account owner to confirm identity. Include the observed display name, join time, participation duration, and any contextual clues from the transcript. The account owner can confirm identity through a direct follow-up email or a question on the next call.

Do not auto-match on first name alone. A single-field match on first name in a large database produces false positives. If your CRM contains five contacts named 'Sarah' across different accounts, an attendee who joins as 'Sarah's iPhone' cannot be matched without additional evidence. The search result should surface all five, ranked by territory and recent engagement, but the final match must be confirmed manually or flagged.

Respect platform privacy boundaries. Microsoft Support documentation on managing meeting attendance reports notes that participants can hide their identity in attendance reports by toggling 'Identify me in attendance reports' off in their privacy settings. When a participant exercises this option, the attendance report will not include their name or email. Attempting to infer identity through side channels violates the participant's explicit privacy choice and may breach your organization's data handling policies.

Which attribution and outcome records may be updated after resolution?

Once identity is resolved, update the meeting activity record, the contact engagement history, the opportunity stage if applicable, and any downstream automation triggers. Do not silently overwrite historical records; append a reconciliation note to the activity record audit trail.

Update the activity record attendee field. Replace the placeholder or mismatched attendee entry with the matched CRM contact ID. If your platform supports multiple attendees per activity, add the matched contact without removing the original placeholder record, so the audit trail preserves the observed join identity alongside the resolved identity.

Advance opportunity stage only if outcome is Completed. Apollo.io's guide to automatic meeting logging includes a field mapping table that shows opportunity stage should advance only when meeting outcome equals Completed. If the outcome is No-Show, Rescheduled, or Cancelled, do not advance stage. If identity was unresolved and outcome was Completed, flag the opportunity record for manual review before stage advancement.

Trigger follow-up tasks. When a meeting is logged with a matched contact and outcome Completed, create a follow-up task automatically. The task should include AI-generated next steps extracted from the transcript and a due date based on the agreed-upon timeline. If identity remains unresolved, the follow-up task should be assigned to the account owner with a subject line that explicitly requests identity confirmation.

Store platform-specific identifiers for future calls. If the meeting platform provided a stable identifier (conf_user_id for Zoom, user_id for Teams, webex_id for Webex), write that identifier to a custom field on the CRM contact record. This enables automatic matching on future calls when the same participant joins under a different display name or from a different device.

Log no-show status separately. Do not count a no-show as a completed meeting. Apollo's field mapping specifies a Disposition picklist value of No-Show, which should trigger a re-engagement sequence rather than a stage advancement. If the invited contact did not join but someone else did, log the meeting as Completed with the matched attendee, and create a separate no-show activity record linked to the invited contact.

How do RevOps teams govern identity matching at scale?

RevOps teams set matching confidence thresholds, deduplication rules, and audit policies before enabling automatic or bulk reconciliation. Without governance, the reconciliation process creates more data quality problems than it solves.

Set a minimum confidence score for auto-matching. Veeva's event management system supports an Attendee_Automatch_Mode_vod setting that enables automatic matching when a single account or user has an exact match on email address or first and last name. A value of 1 enables auto-matching; a value of 0 disables it. For organizations with large contact databases or common names, disable auto-matching entirely and require manual confirmation for every match below a defined confidence threshold.

Deduplicate against existing activity records. Before writing a new meeting activity, check for an existing activity record with the same contact, date, and activity type within a 30-minute window. If a match exists, update the existing record rather than creating a duplicate. Use a unique external ID (the meeting ID from the platform) on every activity record to enable idempotent writes, so retries do not create duplicate records.

Flag unmatched attendees for enrichment. If an attendee email does not match any CRM contact, create a stub contact record and assign it to an enrichment queue for manual review. Never silently drop unmatched meetings. Every dropped record is a pipeline blind spot. Apollo's CRM integration strategy recommends logging unmatched activities to a holding account or queuing them for RevOps triage rather than discarding them.

Audit reconciliation actions quarterly. Review the distribution of match confidence scores, the volume of dismissed attendees, and the rate of manual overrides. If more than 10% of meetings require manual reconciliation, the matching algorithm or the data quality of invited contacts needs attention. If the dismissal rate exceeds 5%, investigate whether legitimate prospects are being incorrectly excluded.

Limit OAuth scopes to least privilege. Every integration that writes to CRM is part of the revenue data attack surface. Request only the scopes required: write activities, read contacts, match accounts. Do not grant read-all or admin permissions. Enable token rotation and session timeout policies. Audit connected app permissions quarterly and revoke unused integrations. A 2025 incident involved compromised OAuth tokens tied to a third-party sales app that was used to target Salesforce customer instances and export data at scale, as reported by Google's Threat Intelligence Group and cited in Apollo's security checklist.

What does a complete post-call identity resolution record look like?

A complete identity resolution record captures the invited identity, the observed join identity, the evidence used to match them, the resolver (system or user), the confidence state, the attribution update, and the audit trail. This structure makes every reconciliation decision auditable and reversible.

Invited identity block: CRM contact ID, email, full name, account ID, and invitation status (accepted, declined, tentative, no response).

Observed join identity block: Platform participant ID, display name as it appeared in the meeting, join timestamp, leave timestamp, and platform-specific identifier if available (conf_user_id, user_id, webex_id).

Evidence block: Matching fields used (email exact match, phone match, name substring plus domain, calendar acceptance), confidence score (0 to 100), and any contextual notes (spoke first, responded to direct question, mentioned role or company).

Resolution block: Final matched CRM contact ID, resolver type (auto-matched, manual, dismissed), resolver user ID if manual, and resolution timestamp.

Attribution update block: Activity record ID, outcome (Completed, No-Show, Rescheduled, Cancelled), stage advancement (yes or no), follow-up task created (yes or no), and next-step summary.

Audit trail block: Original activity creation timestamp, resolution timestamp, any subsequent edits, and the user or system that made each change.

This record lives in a custom object or a structured JSON field on the activity record. It enables quarterly audits of match accuracy, training data for machine-learning match models, and rapid investigation when attribution disputes arise.