Given these issues, simply updating your existing records can be an act of data corruption. The faulty update can case receipts and other official communication goes to the wrong place, or can interrupt the sales cycle. Neither of these symptoms will be particularly endearing to the CRM user community.

So the intentional creation of duplicate records is again not a bad strategy - as long as you have (and live up to) an SLA around the reconciliation of data updates.

When merging records that have been intentionally created as dupes, you'll need to use some subtlety and guile. Conventional merges collapse records together using static rules (such as "most recently updated" or "best data quality"). Since the merges are typically done at the record level - rather than cell-by-cell - the losing record might have some values in it that get wiped out by the winning record.

With the intentionally created dupes, it may be appropriate for bits of the losing record to survive (such as a new phone number or additional email address). If you're going to be using standard merge logic, then, you'll need to copy these valuable parts of the losing record into "spare fields" to the merge. We typically do this with a long-text field, concatenating the extra bits of data using an "XML-lite" style (e.g., "OtherPhone:800-555-1212, AssistantEmail:joan@didion.com"). However, there are situations where a more explicit "extras" field works better.