A duplicate review starts with an entity question: do these records describe the same operating business at the same location? A matching name is useful evidence, but it is not an answer. Different branches can share a brand, independent tenants can share an address, and an old profile can remain online after a move. Treat AI grouping as a way to build a review queue rather than as permission to combine public records.
Define what one record represents
Before providing records to an AI tool, decide which fields distinguish a business, a branch and a department. Keep a stable identifier beside every source profile. Preserve the original name, address, telephone number and public URL, even if a cleaned version is used for comparison. This makes it possible to explain why two entries were grouped and to find them again without relying on a model's rewritten description.
Ask for an explanation, not a verdict
A useful task is to group candidate pairs and identify the fields that appear to match or conflict. Ask the system to leave missing information unresolved. Do not instruct it to pick a surviving listing from appearance alone. A polished profile with several photographs may still describe a closed branch. Require a person to inspect the source records before assigning an action.
Review strong conflicts first
Separate branch identifiers, different operating addresses and distinct customer contact routes deserve attention even when the names are nearly identical. A discrepancy does not always mean separate businesses: telephone routing can change and an address can be written differently. Record the specific conflict and the business contact or source that can resolve it instead of treating a numerical similarity threshold as sufficient evidence.
Keep the publication step separate
Store the candidate group, supporting fields and reviewer decision in a working register. Use the directory's normal support or correction process only after the decision has been approved. Do not connect an unreviewed AI queue directly to a merge or deletion action. Keep ownership questions and customer-contributed material visible, since a platform's handling of those elements may affect the request.
Check a rejected candidate as carefully as an accepted one
Review a small set of false matches to improve the instructions and identify fields that the system is overlooking. Record why a group was rejected so another editor does not repeatedly reopen it. When the information is insufficient, a pending status is a useful result. Accuracy comes from resolving the entity question, not from processing every candidate into a public change. Before using a larger collection, compare a few known separate branches and a few confirmed duplicate records.
Include cases with missing phone numbers and inconsistent address formatting. The purpose is to see what mistakes the instructions encourage, not to manufacture a confidence score. Keep the evaluation examples separate from the records awaiting action, and revise the task if the system repeatedly ignores a meaningful branch distinction. Only then use its grouping to organise the wider queue.
Before closing the review
- Source profile identifiers retained
- Matching and conflicting fields recorded
- Uncertainty remains visible
- Human decision recorded before any public action