Customer Database Audit Before CRM Implementation: Cleanup Plan

Why audit the database before implementing a CRM

If you upload your customer database into a CRM “as is,” problems appear on day one. Duplicates become two different “customers,” empty fields don’t show who is responsible for a deal, and inconsistent phone and city formats break search and filters. The CRM looks “broken,” although the cause is almost always the source data.

Usually three groups of issues surface.

The first: the same client is recorded differently — "TОО Romashka", "Romashka LLP", "Romashka TOO", plus different phones and emails.

The second: cards lack basic details — IIN/BIN, positions, cities, lead source, responsible manager.

The third: data is filled inconsistently — numbers with and without spaces, emails in uppercase, addresses sometimes in one line and sometimes in five.

This affects not only the database’s appearance but how people work.

A manager calls the same person again because they see a “new” contact. Support can’t quickly find the right customer representative and spends time clarifying. A manager looks at pipeline reports and sees an inflated number of active clients because the same customer is counted multiple times.

An audit before CRM implementation is needed to agree on what counts as “quality data” and to bring records to a clear standard. Minimal criteria usually are:

• a company (and a contact) exists in the database only once;
• each record has a way to contact (phone or email) and a clear status of currency;
• key fields are filled in consistently and in one format (names, phones, cities);
• each record has an owner (responsible person) and a clear origin history.

A good audit result is not just “cleaned Excel,” but a set of concrete artifacts: a problems report (how many duplicates, how many empty cards), rules for merging, a list of mandatory fields, and a list of people responsible for ongoing data quality. Then the CRM starts with understandable data and users trust it from day one.

What to gather and how to prepare data for review

Before the audit, collect contacts in one place and record where they came from. Usually data is scattered across department Excel files, email (signatures and threads), phone books, messengers, as well as accounting systems and the service desk. If you miss even one source, you’ll later get “empty” cards and disputes about “where the correct number was.”

Collect a single export file that is convenient to review and clean, not a perfect table. A good practice is to add a "Source" column and not overwrite original values when editing: better to add a normalized version next to it (for example, "Phone (original)" and "Phone (normalized)"). That way it’s easier to roll back and see who changed what.

At the start, record the minimum fields that help find duplicates and assess contact value:

• full name (or contact name if it’s a general address)
• company
• phone and email
• IIN/BIN (if relevant to your work)
• role/position and region

To prevent cleaning from turning into guesswork, add operational fields. They are often more important than they seem: they show who to ask and which records can be confidently closed.

A practical set of tags: contact owner (manager), last update date, record status (for example, "raw import", "verified"), consent flag for communications (if you track it).

Example: in a company selling IT equipment and projects (e.g., workstations or servers for organizations), the same person may appear in sales proposals from email, in a tender spreadsheet, and in an engineer’s correspondence. If the source and owner are saved, you can quickly clarify current data with the right employee when discrepancies appear.

Before review, do basic preparation: normalize phone formats, trim extra spaces, split "Full name in one field" into separate columns, and check encoding so names and companies don’t turn into gibberish. This takes an hour but saves days during cleaning.

How to identify and merge duplicates

Duplicates appear almost always, even if the database seems neat. Reasons are simple: the same client recorded as "Ivanov I.I." and "Ivanov Ivan", the phone saved with different codes, a company changed its name, or a contact moved to a new email. In B2B this is intensified because one person can be both a "procurement contact" and responsible for contracts, so they may be entered twice.

To avoid relying on eyeballing, set clear rules for finding duplicates. Start with unique identifiers, and only then move to "similar" matches:

• phone (after normalization: country code, no spaces or brackets)
• email (lowercase, no extra spaces)
• IIN/BIN (if you store these fields)
• combination of name + company (or name + email domain) for cases without a phone
• combinations (phone + name, email + company) to filter out matches by a single field

It’s important not just to "stitch" records together, but to pick a master card and merge carefully. A convenient rule: the master is the record with the most complete information and current contacts. If you have a long sales cycle, the communication history is especially valuable: losing notes, meetings, and deal statuses is costly later.

Before merging, check:

• where the current phone and email are;
• where requisites are filled (BIN, legal name, address) and who entered them;
• which record contains more "live" history (emails, calls, comments, documents);
• whether there are conflicts (different companies for the same name, different positions, different IIN/BIN).

To make sure everyone acts the same, prepare a short rules document with examples. For example: "if phones match, it's one contact even if the name is written differently" or "if BIN matches, it's one company; contacts within may be different." Add 5–10 typical cases from your base and the solution for each. Then merging duplicates becomes a team standard rather than a one-off cleanup.

How to find "dead" contacts and decide their fate

A "dead" contact is a record you can no longer reach and there are no signs the contact is still needed. Don’t confuse such records with silent clients who might return.

Rely on criteria you can verify with facts, not feelings. Common signals: phone does not exist or is constantly unreachable, emails bounce, the company domain is down, the card has no successful touches for a long time, and managers can’t recall the context.

Quick validity check

To avoid spending weeks, run a short check with a simple scenario and log the result directly in the data. Usually 2–3 attempts through different channels in a reasonable timeframe are enough. For part of the database it’s useful to ask sales to confirm a contact’s "aliveness": sometimes a person changed a number but remains key.

Working minimum checks:

• one call during business hours and a repeat call on another day;
• one email asking to confirm relevance (and note delivery/failure);
• cross-check with the last successful contact: date, channel, result;
• quick company check: does the organization exist, has the name changed;
• confirmation from the responsible manager if the contact is tied to a deal or invoices.

What to do if there’s no response

Do not delete such records immediately. Deleting breaks history and reports and can remove important traces (for example, from past projects). Safer is to introduce statuses and retention rules: "under review", "not current (unreachable)", "archived", "requires sales confirmation". For each status set rules: how many contact attempts, how many days to wait, who decides.

Archiving is practical: the contact doesn’t clutter active lists but remains for history. If new information appears later, the record can be restored to active status.

Restore a contact if it’s linked to a major client, tender, service case, or if the company still operates but contact details changed. Log the outcome consistently: date of attempt, channel, result ("wrong number", "asked to call back", "found new email") and what was updated in the card. This disciplines the process and reduces repeated pointless attempts.

Incomplete cards: which fields are mandatory and where to get data

Incomplete cards break search, segmentation, and basic functions like mailings or task assignments. Before loading into CRM decide what is a "card ready for import" and what should be sent for completion.

First define a baseline that works for all departments. It should allow you to unequivocally find a client and contact them even if other information comes later:

• entity type (company or contact) and full name/title;
• one main identifier (IIN/BIN or internal code);
• phone or email (at least one channel);
• city/region;
• responsible employee (record owner).

Then add process-specific fields only where they’re actually used. Otherwise people will fill them formally or skip them.

For sales it's usually lead source, stage, estimated amount, next step date. For service — product/service, serial number or contract, priority. For accounting — requisites, billing address, payment method. For procurement — delivery terms and tender contact. For management — industry, segment, potential, last contact date.

To make mandatory fields consistent, fix allowed values. "Region" should not be sometimes "Almaty", sometimes "г. Алматы", sometimes "Almaty". Create reference lists for city, industry, source, and client type. Also define input rules: phone format, a single style for company names, what to do with Latin letters and abbreviations.

When the list of fields is clear, plan where to get missing data. Reliable sources often already exist in the company: contracts, invoices, proposals, correspondence, meeting minutes, call recordings, service requests, ERP or accounting data. For many B2B and government orders, some requisites can be restored from tender documents.

Example: a record for "TOO Romashka" lacks BIN and a contact person but has a contract number in the comment. From the contract you can quickly find requisites and legal address, and from the email chain related to the contract — the responsible manager and a working email. The card then clearly shows the owner and the contact channel.

Final rule: "we don’t import then fill later." If a field is mandatory, a record should not enter the CRM without it; exceptions are handled by a specific role (for example, a data coordinator or department head). That way cards stop "thinning" over time and the database remains usable.

Step-by-step audit and cleanup plan before CRM import

Working step-by-step helps you know in advance what will go into the system and who is responsible. This reduces post-launch chaos when managers are already using the CRM and fixes are harder.

Six steps that work for most companies

Start simple: agree on what you consider a "good" database. For example: "95% of contacts have a phone or email, 90% have a company, and duplicates are no more than 2%." These numbers help accept the work and avoid subjective arguments.

Then follow the plan:

• Set goals and quality criteria: which segments matter (active clients, leads, suppliers), which fields are mandatory, what counts as a duplicate.
• Gather sources in one place and make a backup: Excel, email, requests, telephony, old CRMs, department files.
• Normalize data: phones in one format, consistent city and region names, unified rules for names and companies.
• Find and handle duplicates by the rules: matching phone, email, IIN/BIN (if present), plus similar names. Record merges in a separate log to review or rollback if needed.
• Process "dead" contacts: unreachable numbers, non-existent emails, companies without signs of activity. Assign statuses ("invalid", "archived", "requires verification") instead of deleting.

Final step before import — close mandatory fields and do a spot check. Take a small sample (e.g., 100 cards across segments) and manually verify: no repeats, key fields filled, statuses correct. If typical errors reappear (e.g., inconsistent phone formats), fix the normalization rule, not just individual records.

This way the CRM receives a database you can be proud of and that has clear maintenance rules.

Roles and responsibilities: who does what

An audit often fails because of missing responsibility, not tools. If you don’t assign people and rules, cleaning becomes endless edits and after launch the database quickly gets dirty again.

You need someone to approve rules and resolve disputes. Usually the process owner (commercial director or head of service) together with the sales/service leader decide which data is "truth", which fields are mandatory, and how records are merged or archived.

Who performs the work and who is accountable

Assign people by name. Practically, roles are distributed as:

• process owner (sales/service): approves rules, priorities, and final decisions on disputed cases;
• CRM administrator or data owner: configures reference lists, controls import/merge, maintains the change log;
• department owners (sales, service, marketing, accounting): confirm the relevance of their clients and data sources;
• operators/assistants: perform bulk cleanup according to a checklist (duplicates, empty fields, phone formats, addresses);
• record owner: maintains the currency of a specific record after import.

Assigning the record owner is simple: whoever communicates actively or is responsible for the contract/service is the owner. If a client is "shared," the account manager may be the owner while service acts as a co-executor without rights to change key requisites.

How to check quality and resolve disputes

Quality control should not be by eye. Spot checks and clear metrics work: duplicate rate after cleanup, percentage of records missing mandatory fields, number of returns for rework.

Set a simple approval flow for disputes:

• an operator flags a record as disputed and states the reason;
• the department owner responds within 1–2 business days;
• if departments disagree, the process owner decides;
• the CRM administrator records the outcome (what was merged/split and why) so the rule can be repeated.

Example: two contacts share the same IIN/BIN but have different organization names from different sources. By rule, the identifier outweighs the name, so records are merged and the second name is kept as an alternative (for example, in a note) to preserve context.

How to lock in data hygiene after the audit

An audit only has lasting effect if you lock in simple daily rules. The goal is not a perfect database but to avoid returning to chaos in a month.

1) Clearly separate: contact, company, deal

Decide what you create in the CRM in different situations. If someone emails from a personal address and you don’t know where they work, create a contact. If you negotiate with an organization, create a company and link contacts to it. When a concrete inquiry with amount and timing appears, create a deal.

A short rule helps: "no confirmed company — don’t create a company; there is a request — create a deal." This reduces empty cards and accidental duplicates.

2) Enforce unified field formats (and make them convenient)

Most dirt comes from inconsistent input. Agree on standards for key fields: phone, email, position, address, industry. Less freedom means fewer mistakes.

A minimal standard that sticks:

• phone: one format for the country (for example, +7...), no spaces or comments;
• email: work email, not "test@", no commas or extra characters;
• position and department: chosen from a short list, not freeform;
• address and city: a consistent order, without mixing "legal/physical" in one field.

Add hints in field names or a one-page guideline.

3) What to do on matches and new duplicates

Make the rule simple: if the system finds a match by phone or email, don’t create a new contact until the existing card is checked. If only name and company match, act cautiously: verify via signature, website, business card, or call before merging.

Limit merging to a small circle of people (for example, the CRM admin or data owner) to reduce the risk of accidentally combining different people into one card.

4) Update regimen: when and what to recheck

Set the frequency to check fields that age fastest: phone, email, position, company, client status. Often quarterly for active clients and semi-annually for others is enough. Recheck after key events: manager change, client return, big deal.

Decide the fate of "dead" records in advance: for example, no activity for 12–18 months and unconfirmed contacts -> archive, not delete.

5) Minimal metrics of data hygiene

Without numbers, rules are quickly forgotten. Three metrics to track monthly are enough:

• duplicate rate (e.g., by phone/email);
• completeness of mandatory fields;
• share of archived/non-current cards.

Assign owners: who monitors metrics, who fixes typical errors, who approves changes. Then data hygiene becomes routine, not a one-off job.

Common mistakes and traps when preparing the database

The most common problem is auditing by eye. The team quickly edits a table, merges similar rows, and deletes extras, but a month later nobody remembers why it was done that way. History is lost, disputes appear, and the database unravels again.

Typical mistakes:

• merging duplicates without rules (merging by matching last name even though they are different people) or choosing the "most complete" card and overwriting a current phone;
• deleting records instead of archiving, losing context: who called, when a proposal was sent, why the client "went cold";
• requiring too many mandatory fields so employees start faking values (dashes, invented positions, random addresses);
• mixing contact and company in one field: writing "Ivanov, TOO Romashka" in one field while putting the department phone in another;
• leaving cards without an owner: nobody maintains currency and data ages quickly.

A useful habit is to record decisions. For merging duplicates have a simple rule: which signs indicate identical records (phone, email, IIN/BIN, domain), which card is "master", and what to do with conflicting fields. If in doubt, send the record for manual review rather than merging incorrectly.

Be cautious with deletion. Often better to mark a record as "not current" or "archived" than to erase it. In B2B sales a contact might have left a company but the correspondence and agreement history are valuable to the next manager.

For mandatory fields follow the rule: "minimum that delivers value." Usually name (or company), one reliable contact channel, and a record owner are enough. Collect the rest gradually.

Also don’t mix company and contact levels from the start. If a systems integrator works with government or large organizations, keep company, individual contacts, and their roles separate. Then communications and client reports remain clear without manual decoding.

Quick check and next steps

Before importing to CRM, do a short final review. It doesn’t replace a full audit but catches errors that later cause chaos in deals and tasks. If the main cleanup is done, this final check usually takes 30–60 minutes.

Review the final export (the file to be imported), not the original tables:

• Duplicates: no obvious repeats by key fields (phone, email, IIN/BIN, company name), or marked plans for merging after import.
• "Dead" contacts: have a clear status (e.g., "not current", "archived") and won’t be included in active calls and mailings.
• Mandatory fields: filled for things that make the card meaningful (name/company, phone or email, source and owner).
• Unified format: phones are in a single style, cities and industries aren’t duplicated as variants.
• Owners: each record has an owner or a rule to assign one, otherwise it becomes ownerless.

Save a few simple reports to document quality. Usually enough are: records before and after cleanup, number of found and merged duplicates, share of cards with mandatory fields filled, list of "dead" contacts with actions (archive/verify), and list of disputed records needing business decisions.

Then run a pilot import on a small sample (for example, 200–500 contacts and 50–100 companies).

Check three things: field mapping correctness (e.g., "Position" didn’t end up in "Comment"), how the CRM handles matches (creates a duplicate or suggests merging), and how access rights and owner assignments work. A good test: ask 2–3 users to find 10 specific clients and create tasks. If they struggle or don’t know what to fill, refine the rules.

During the first 2–4 weeks after launch maintain control or the database will become dirty again. Set short regular checks: weekly reviews of new duplicates, cards without phone/email, records without owners, and reasons why managers bypass rules (missing field, inconvenient list, unclear status).

If you lack internal resources for change support and data discipline, consider engaging an external partner for infrastructure and operations. For example, GSE.kz (gse.kz) as a manufacturer and systems integrator can handle workplace equipment, servers, support, and implementation so the CRM project doesn’t stall due to lack of hardware or maintenance after launch.