Customer database: keeping one that is still accurate in three years

A customer database is the record of who has bought from you, what they bought, and how to reach them. Building one is easy and nobody struggles with it. Keeping one that still answers questions correctly three years later is a different exercise, and it fails in three predictable places: duplicates, ownership, and deletion.

It helps to separate three things that get conflated. The fields you collect on an individual contact are a narrower question, covered in contact list template. The discipline of using the data to manage relationships is customer relationship management. This article is about the record itself — how it stays true.

The structure that survives

• One record per customer, with a stable identifier that never changes. Email addresses change and company names change; whatever you key on should not.
• A clear distinction between a person and an organisation. Selling to businesses without that separation produces a database that cannot answer how many customers you have.
• Source and date on every record. Where it came from and when explains, later, why a record looks the way it does.
• Status rather than deletion for customers who left. A former customer is information; an erased one is a gap you will fill in wrongly.
• An owner field where sales are involved. Unowned records are the ones nobody updates.
• Consent and contact preference, if you market to these people at all — a separate concern with its own rules, covered in marketing database.

Duplicates, which are the real problem

1. Decide the matching rule before you have a problem: same email, or same company plus same domain, or same phone. Write it down.
2. Prevent at entry. A lookup before create catches most duplicates at the only moment it is cheap.
3. Merge rather than delete, keeping the older record as the survivor so history is not lost.
4. Run a duplicate check quarterly. It takes twenty minutes and the number never goes to zero on its own.
5. Treat imports as the main risk. Nearly every duplicate problem starts with a spreadsheet somebody merged in without checking.

The most common design mistake is keying on email address. It looks unique and stable, and it is neither: people change jobs, share inboxes, and give a personal address one week and a work one the next. Key on an identifier the database owns, and treat email as an attribute that can change — otherwise every address change either creates a duplicate or destroys history.

Deletion and retention

Every database eventually accumulates people who have no relationship with you and should not still be listed. Decide the rule while it is abstract: how long after the last transaction a record is archived, what happens to it then, and what you keep for accounting purposes regardless. Under privacy regimes such as the GDPR, keeping personal data indefinitely without a reason is itself the problem, and a deletion request has to be actionable — which in practice means knowing every place a customer record exists. The retention side is covered in data retention policy, and the specifics of what your jurisdiction requires are worth checking properly rather than assuming.

Where it lives

Ettex Contacts holds the records with the fields you define, filtered by any of them, and the same store carries suppliers and internal people — the difference is a field rather than another system. Where the sales process matters, Ettex CRM sits on top of the same contacts, so a customer is one record rather than one per tool.

The limits, stated plainly: there is no automatic data enrichment from third-party sources, no identity resolution across marketing channels, no customer data platform features, and no built-in deduplication engine — the matching rule above is one you apply, not one the software guesses at. If your problem is stitching a customer identity across a dozen systems, that is a category of product and this is not it.