Philippines staffing research
How many CRM merges lack a reversible source record?
Contents
A research protocol for measuring whether duplicate-record merges preserve the losing record's evidence, the survivor rule, and the approvals needed to reconstruct the change.
Question and scope
This study asks what share of CRM merges can be reconstructed from the surviving record, the approval packet, and the system history. It also asks whether a reviewer can identify the losing record's key fields and the rule that selected the survivor. The unit is one merge event. The study is about merge evidence, not about whether the merge was commercially correct. The scope includes the merge request, the comparison, the approval, the post-merge record, and any available restore or audit history. It excludes downstream business outcomes that occur after the merge unless they affect the ability to reconstruct the change. A merge that produced a good result but left no evidence is still a traceability failure.
Method and evidence frame
Use a retrospective record review. For each merge event, identify the surviving record, the merged record, the fields that changed, the related objects that moved, and the approval that authorized the action. Test whether the original values of the losing record can be recovered from a system history, an export, or the approval packet. Record the result as recoverable, partially recoverable, or not recoverable. The evidence frame separates the business decision from the technical action. The business owner decides which record should survive and whether a consent or contract term carries forward. The administrator performs the merge. The system history records what changed. A complete trail shows all three layers; a clean surviving record alone proves only that the final state looks tidy.
Population and unit of analysis
The population is all merge events completed during the observation window for the selected record types. The unit is one merge event, even if several related records moved at the same time. A bulk merge of many duplicates is a separate unit per surviving record, because the evidence for each merge can differ. Record the tool or method used, since automated merges may retain less evidence than manual ones. Define whether a merge that was reversed or restored is included. Include it, but label the reversal and the reason. Exclude merges that never completed, while recording them separately as attempted actions. Report the counts for completed, attempted, and reversed events so the denominator is transparent.
Definitions and measures
The primary measure is the share of merge events whose original record values can be recovered from an approved source. A secondary measure is the share with a documented survivor rule and a named approver. A third measure is the share with a post-merge check of related objects. Report each measure separately because a merge can be technically reversible but procedurally unapproved. Supporting measures include the number of fields lost, the number of related objects moved, the time between approval and merge, and the share of merges with a consent or communication-preference conflict. Record whether the system provides an undo window and whether the window had closed before the review. That last fact affects what can realistically be recovered.
Sampling and collection
Sample across record types, merge tools, administrators, and business owners. Include at least one manual merge, one bulk merge, and one merge with a related-object conflict if the population contains them. Use consecutive events where possible and record every exclusion. A sample of only the easy manual merges will overstate recoverability. Collect the merge request, the comparison, the approval, the surviving record, the related-object list, and the system audit history. Capture the record state as soon as possible after the merge, because later edits can overwrite the evidence. If the system does not retain the losing record, record that fact and the tool version rather than assuming the information never existed.
Analysis and reporting
Report recoverability by merge type and by record type. A high overall rate can hide a low rate for bulk merges or for records with many related objects. Group defects by missing comparison, missing approval, no system history, overwritten field, moved related object without a check, and closed undo window. Show the count and share for each category. Separate observation from interpretation. A merge with no recoverable losing record may still have been correct, but the reviewer cannot verify the decision after the fact. A high recoverability rate does not prove that the survivor rule was applied correctly; it proves that the evidence exists. The report should state which question it answers and which it does not.
Limits and sources of error
CRM platforms differ in their audit and restore capabilities, and a tool upgrade can change what is retained. The reviewer should record the platform and the tool version. A manual export made after the merge may not capture the original record if the administrator edited it first. Small samples are sensitive to one bulk operation, which can dominate the count if events are not weighted carefully. The study cannot establish that the merge complied with a specific privacy law, that consent was valid, or that the business relationship was correctly consolidated. It tests evidence recoverability. NIST Privacy Framework, the Federal Trade Commission, and the U.S. Government Accountability Office provide general control context, not a legal conclusion for a specific record.
Operational use
Use the result to change the merge checklist, require a comparison export before bulk merges, or restrict merges that cannot be reversed. A defect that appears across one tool or one record type is a process or configuration issue, not an individual performance problem. Assign the fix to the system owner and re-test after the change. A reversible merge record also makes customer conversations easier. When a customer disputes a merge, the team can show what was combined and who approved it instead of guessing from the final record. That is useful even when the original decision was sound.
Review cadence
Review merge evidence quarterly and after any change to the CRM, the merge tool, or the record-ownership policy. Keep the sample rule and the definitions stable so the comparison is meaningful. If a bulk cleanup occurs, review it as a separate cohort rather than mixing it with routine merges. Close the review with a named owner, a dated change, and a re-test date. Preserve the sampled evidence in an approved location so a later reviewer can repeat the test. A finding is not closed because the merge tool was updated; it is closed when a new sample shows the evidence can be recovered.