Separate matching from permission to merge
When choosing a PMS, test two records belonging to one fictional person and two different fictional people with similar names. Inspect the surviving profile, conflicting fields, linked reservations and recovery limits. For a boutique hotel, apartment business or short-term-rental operator, knowing when to stop matters alongside speed. This practical demonstration needs no real guest records, identity documents or production account. Give the supplier your expected results before starting, then compare the demonstration against them. A successful button click alone does not establish that the right records were combined.
What the documentation establishes
The Oracle OPERA Cloud 25.4 profile documentation makes automatic merging conditional on an enabled control. Mews documentation says a merge cannot be undone. Both official pages were opened on 18 October 2026. These narrow examples do not describe every PMS. Ask about the version, settings and scope being offered to you. A feature not demonstrated is different from a feature confirmed absent: record unanswered items as unverified. Reopen the official source links before deciding. The following steps are proposed buyer checks, rather than a claim that any supplier supports the whole checklist.
Case A: similar names, different people
Give fictional profiles A1 and A2 the same displayed name, different contact details and reservation references TEST-A and TEST-B. They represent different people and should remain separate. Ask why the system suggests a match and how an operator rejects it. Name similarity alone is not your approval to merge. Introduce a shared family contact as a verbal variation and ask whether it is treated as conclusive identity evidence. If the match remains uncertain, stop. Record the outcome, explanation and unanswered question. A more complete profile does not prove that both records belong to one person.
Case B: one person, two records
State explicitly that fictional B1 and B2 represent the same test person. Give one an old communication preference and the other a current preference; attach TEST-C and TEST-D separately. Choose the surviving profile and write down the expected value of each conflicting field before proceeding. Compare the before and after views. Acceptance requires explainable field choices and both references remaining associated with the correct person. Do not hide a missing reference by creating a replacement reservation. If the supplier proposes another workflow, restore the starting conditions and repeat against the same criteria.
Acceptance checklist for the demonstration
Mark each item passed, failed or not shown. Not shown means evidence remains outstanding.
- Case A: A1 and A2 remain separate, with TEST-A and TEST-B correctly attached.
- Case B: the surviving profile and expected conflicting-field values are recorded in advance.
- After merging: open TEST-C and TEST-D individually and verify their person links and selected values.
- Permissions: demonstrate the boundary using a test role without merge authority, rather than only an administrator screen.
- Traceability: ask where the acting role, time and change can be inspected; leave unavailable evidence unresolved.
- Error handling: demonstrate the scope of reversal if available; otherwise request written support steps, possible corrections and irreversible limits.
Turn the evidence into a shortlist decision
Reject this workflow if case A merges different people or case B leaves unexplained links. For missing evidence, request an owner, version and repeat-demo date instead of accepting a verbal promise. Lack of reversal does not imply the same decision for every property; assess the approval workload and support boundary with your team. Write the shortlist condition using both test results and remaining questions. The related room-move and outage-recovery demonstrations help examine connected workflows. This exercise provides evidence for an operational choice; it does not measure accuracy rates, legal compliance or revenue gains. Keep the decision note to three lines: demonstrated version and test date; results for cases A and B; owners and closure conditions for outstanding items. Apply the same checklist to every candidate. Showing one supplier only the easy case and another only the difficult case makes the comparison unequal. Also clarify whether the prepared sample records will remain in the demo environment or be cleared afterward; do not switch to testing with real guest data.