Client Database Corrections: Keep a Clear Decision Record
A client database correction process should explain what is wrong, which record is affected, and what evidence supports the replacement value. Keep proposed changes separate from confirmed client details until a reviewer decides how to resolve them.
At List to Data, we recommend treating a correction as a specific field decision. A label such as Outdated account does not explain whether the problem concerns the company name, contact person, phone, or location.
Create a correction queue
Give each issue a change reference linked to the client or contact ID. Record the disputed field, original value, proposed value, source of the proposal, and review owner. Leave the decision pending until the evidence has been assessed.
Our contact review workbook includes a Change log for this purpose. It is a manual starter file; it does not apply corrections or make database-matching decisions automatically.
Distinguish a contact move from an account change
Suppose a contact person starts working for another organization. Their new employer is a change in the person’s association. It is not a reason to rename the previous client account or transfer its historical transactions.
| Reported change | Review question |
|---|---|
| Person has a new employer. | Should the old association end and a new one be created? |
| Company uses a new trading name. | Is this the same account under a new label? |
| Branch phone changed. | Does the update apply to this location or the whole organization? |
| One email bounced. | What exactly failed, and is the result temporary or conclusive? |
Choose evidence appropriate to the field
A confirmed account interaction can support a contact change. A source page may support a business address. A file modification timestamp alone does not establish either fact. Document what the reviewer actually checked.
Keep an inconclusive result visible. A pending decision is preferable to a guessed replacement that looks confirmed to everyone else.
Apply the correction and check connected records
After approval, update the current value and review any association affected by it. Check exports, assigned tasks, and synchronization rules that may continue using the old detail. Record the actual application date separately if it differs from the decision date.
Do not reuse a correction process to override objections or contact preferences without reviewing the relevant evidence and purpose. A technically corrected address does not resolve every question about how it may be used.
Keep the database structure understandable
DB TO DATA’s client database article covers the relationships between accounts, contacts, and activities. If the correction arose during a system transfer, use Latest Mailing Database’s migration checklist to review the field map and import outcome.
For questions about an external List to Data selection, contact our team with the package reference and affected field. Avoid sending unnecessary personal details when a structural example can explain the issue.
Open the workbook instructions before starting a manual correction log.