How to resolve duplicate participant names

A matching name is a starting point for a search, not proof that the selected record belongs to the guest at the desk. Give staff a consistent second check and keep it proportionate to the information needed for the visit.

Use the visit context first

Compare the activity, booking or session information available to the desk. Ask a neutral clarifying question rather than reading another person's details aloud. A confirmation code can help the guest point staff to their intended record.

Avoid inventing a new collection requirement simply because duplicate names occur. Use the identifying context your organization already collects for a defined purpose.

Confirm before recording an arrival

Show staff which person and document they are about to select. A clear confirmation step is useful when search results look similar. Keep the action pending until the correct record is chosen instead of recording an arrival and investigating afterward.

If the match remains uncertain, use the escalation process. Do not choose the first result just to clear the queue, and do not make the guest sign a second form merely because the desk has not searched carefully.

Preserve the distinction in your own records

Use stable record IDs in exports and integrations. Names can change or match other names, so they are poor database keys. Keep a participant ID, waiver ID and arrival ID separate when your system uses all three.

Train with two sample people sharing a name and different visit contexts. Confirm that a new staff member can select the correct one without seeing unnecessary answers or relying on the trainer's memory.

Before you call it ready

• Search results include enough appropriate visit context.
• Staff have a neutral second check.
• Uncertain matches have an escalation owner.
• Exports and integrations use stable IDs rather than names alone.