A demonstration in which a phone number retrieves a member profile does not prove that a CRM can manage identity conflicts. The harder questions appear when two people share a phone number, a customer changes accounts, or a mistaken merge is discovered after points have been spent.
OneID should provide a stable internal member identity with controlled relationships to external identifiers. The proof of concept needs to test when those relationships may be established, when they should be rejected and how an error can be corrected without losing transaction history.
Define the acceptance baseline first
A phone number, membership card, OpenID or UnionID is an identifier with a particular source and scope. None should be treated as an unconditional proof of a unique real-world person. Phones can be shared or reassigned; WeChat identifiers refer to platform accounts within the applicable scope.
Before testing, agree five items:
- Which verified conditions permit automatic linking, and which require review.
- How competing identifiers are prioritized and how an unresolved conflict is handled.
- Which source owns profile fields and how provenance and history are retained.
- How benefits, frozen balances and stored value are treated during a merge or separation.
- Which audit records and downstream acknowledgments are required.
Run cases against independent fixtures or reset the baseline between them. Otherwise an earlier merge or phone change can alter the expected result of a later case. Each test needs initial data, the action, expected result and retained evidence.
Ten OneID proof-of-concept cases
1. Link a store member to a WeChat mini-program
Create member A at the POS with phone A and card C001. In the mini-program, obtain the required verified phone information through the agreed WeChat or SMS process. When the identifiers and rules support the match, link the channel identity to the existing OneID rather than create an unnecessary second master.
Then test a different WeChat account or conflicting phone evidence. The system should follow the conflict rule, not overwrite the existing relationship. Apply the welcome-gift policy once according to the agreed eligibility rule; linking channels should not automatically create duplicate benefits.
2. Use UnionID within its valid platform scope
Test two channel-specific OpenIDs that legitimately share a UnionID under the relevant WeChat Open Platform conditions. Preserve each OpenID’s application scope while linking the supported relationship to the member master.
Also test a missing UnionID and an existing conflicting linkage. Missing data should not force a guessed match, and a conflict should enter the agreed review process. A matching UnionID is evidence about a WeChat account within that framework, not universal proof of a person across every platform.
3. Change a member’s phone number
Change phone A to an unused phone B after the required verification. Keep the OneID, transaction history and benefits. Record who performed the change and when the old number was unbound or placed into the agreed transition state.
Repeat with phone B already attached to another member. The system should not silently take that number away from the other profile. Verify the approved conflict and recovery route.
4. Replace a lost membership card
Replace card C003 with C004 under the brand’s card policy. Retain the member master and history, and mark the old card invalid or in its approved transition state. Repeat the replacement request and confirm it does not issue an extra active card or duplicate benefits.
5. Register concurrently through two channels
Submit near-simultaneous registrations for the same verified membership identity. Confirm that concurrency controls and retries produce the intended single master and channel relationships.
Then test two WeChat accounts presenting a shared phone number. The expected outcome depends on the brand’s agreed identity policy. Concurrency handling must not become a shortcut that exposes one person’s profile or benefits to another.
6. Handle a legitimately shared phone number
Create two distinct people who use the same contact number. If the brand allows only one member per phone, verify the controlled rejection and support process. If shared contact numbers are permitted, use the approved alternative identity rules to keep the people separate.
Neither outcome should reveal the other member’s history, coupon inventory or stored value. A contact field and a unique identity key need not always be the same thing.
7. Simulate a reassigned phone number
Use a dormant member and a new claimant with the same number but different account or profile evidence. Confirm that the risk rule requests additional verification, manual review or a separately approved new master as designed.
A new device or different WeChat account can be a risk signal; it does not prove that a telecom operator reassigned the number. If operator verification is part of the proposed solution, test the actual authorized integration rather than describe a heuristic as confirmed reassignment detection.
8. Reject a duplicate card during import and API binding
Attempt to import card C002 for a second member. The staging or validation process should identify the conflict before it corrupts the master data. Retain the rejected row and reason for correction.
Attempt the equivalent binding through the API. It should also apply the agreed uniqueness rule and should not overwrite the original relationship. Evidence must cover both import and online interface paths.
9. Merge confirmed duplicate profiles with controlled benefits
Use two profiles confirmed to represent the same person, with no duplicated transactions in the fixture. Profile A is Gold, has 9,000 growth units valid to 30 June 2027, 1,200 available points, 100 frozen points, two valid coupons, one used coupon and RMB300 stored value. Profile B is Silver, has 1,200 growth units valid to 31 March 2027, 500 available points, 50 frozen points, one valid coupon, two used coupons and no stored value.
Under this test’s explicitly agreed merge policy, the expected growth total is 10,200, Gold remains valid to 30 June 2027, available points total 1,700 and frozen points total 150. Three valid coupon instances remain after identity-based deduplication, and the three used-coupon records remain in history.
These results are test-policy choices, not universal merge rules. If transactions or entitlements overlap, they need deduplication rather than addition. Stored value requires its own ownership and transfer approval; preserve the source funds ledgers instead of assuming that a member-profile merge authorizes a cash transfer.
10. Correct a mistaken merge after new activity
After an intentionally incorrect merge, create a new transaction, redeem points and use a coupon. Then perform the approved correction workflow. Test which identifier relationships can be restored and which later records require explicit reassignment or compensation.
Completed transactions should remain in the audit trail with corrective relationships. Benefits compensation should require the appropriate approval. Verify the downstream systems’ final state as well as CRM’s screen.
Do not accept an unconditional promise of a perfect “unmerge.” Some effects may need manual investigation or compensating entries. The demonstrated recovery boundary is part of the acceptance result.
Retain six kinds of evidence for every case
- Inputs: initial profiles, identifiers, balances and channel scope.
- Rule decision: the matching or rejection rule and any required verification.
- Master relationship: OneID, active bindings, previous bindings and effective changes.
- Benefits: points, coupon instances, growth, tier and any separately governed funds outcome.
- Interface results: requests, retries, responses and downstream acknowledgments.
- Audit: actor, time, approval, reason and original-to-correction linkage.
Compare the observed outcome with the agreed baseline, including rejected or pending cases. “Manual review required” can be a valid result when the policy calls for it. An unexplained automatic merge is not necessarily a better outcome.
Apply the tests to the actual PEKON CRM scope
PEKON CRM supports a member OneID within a brand and connections to relevant POS, WeChat and e-commerce touchpoints. Phone numbers, membership cards and OpenIDs can form part of the identity relationships, with conflicts handled through the agreed rules and review procedures. UnionID use depends on platform conditions and the project’s authorized integration.
Marketplace identifiers and protected or encrypted phone data from platforms such as Tmall or Douyin require their own interface permissions and scope. Do not assume they can be matched freely to a WeChat account or copied into a common profile.
Separate brand clubs also require separate treatment. A group-level technical architecture does not automatically authorize cross-brand sharing of member benefits, consents or personal information.
Where stored value is involved, confirm which account platform is authoritative and how the POS queries or uses it. If an existing funds platform remains in place, profile matching and balance ownership must follow the agreed integration rather than imply that CRM owns the money.
For each POC case, record whether the requirement is standard capability, configuration, an integration dependency, additional development or unsupported. This makes the result useful for procurement and implementation planning.
Frequently asked questions
Is a phone number sufficient as the only OneID key?
It is a useful identifier, but sharing, reassignment and changes require explicit rules. Keep a stable internal member ID and controlled external relationships.
Can UnionID automatically unify every customer channel?
No. Its availability and scope depend on WeChat platform conditions. Other platforms and conflicting relationships need separate evidence and permissions.
Should duplicate profiles always be merged automatically?
No. Confirm that they represent the same membership identity and apply the approved benefits and audit policy before merging.
Can stored value be added together during a profile merge?
Only through the approved funds ownership and transfer process. A profile merge alone is not sufficient authority.
Can every incorrect merge be completely undone?
Not necessarily, especially after new transactions or benefit use. Test the actual correction process, compensation rules and downstream results.