Customer database in CRM: how to stop losing customers and keep the database when a manager leaves

A customer database is a list of contacts and the history of the relationship with each of them: who the customer is, where they came from, what they bought, what was agreed and on what grounds the company may write to them. It becomes a company asset under four conditions. Contacts land in the system automatically from every channel; each customer has one identity key instead of three records; access and export are restricted and logged; every record has a legal basis for processing and a retention period. Until at least one of those conditions is met, the database in the CRM stays an incomplete copy of what sits in managers' phones and private chats.

What follows is a look at the database as an asset rather than as a screen in a program. Where it physically lives and how to check that in a single evening. Why duplicates appear and how they turn into lost deals. Who owns the database legally when a manager leaves, and which five measures the trade secret law demands. How to restrict exports and see who made one. What Federal Law 152-FZ, Russia's personal data protection law, requires of your contacts, and how consent to marketing differs from consent to processing. And how the database fills itself — from the website, the phone system and 1C, the accounting and ERP platform most Russian companies run on, instead of by hand. Manager behaviour and adapting the system are covered separately in why a CRM fails to take root; this piece is about the safety and quality of the data itself.

Where does the customer database actually live?

Short answer: in four places at once — in the CRM, in spreadsheets, in managers' phones and in private chats — and only the first of them belongs to the company.

The database lives wherever the contact and the agreement live, not wherever records have been created. The customer writes to the manager in a personal messenger, the manager replies from a personal number, the details are settled by voice, and what reaches the system is a line reading "call, thinking it over". Formally, the customer is in the database. In practice, the company knows their surname and phone number.

A CRM is rarely the only place a company works with data. In a survey by J'son & Partners Consulting and Bitrix24, a Russian CRM and collaboration suite (1,000 companies across all federal districts, November 2025 – January 2026), 98.7% of companies use their CRM alongside other software, most often office applications. The survey says nothing about employees' personal messengers and phones; every company has to measure that share for itself. The same survey shows how this parallel life of data tends to end: 20% of respondents adopted a CRM only after they had already lost deal data.

The check takes an evening and requires nothing but honesty. Take one manager and imagine they did not come to work tomorrow. Is the negotiation history on their customers visible? Are the terms on open deals known — deadlines, discounts, promises? Would an inbound message from one of their customers reach the company? Every no is a piece of the database the company does not have.

Why do duplicates appear, and what do they cost?

Short answer: duplicates are born where channels meet and where the same thing is spelled differently, and they cost lost deals plus advertising money spent showing ads to your own customers.

A customer submits a form on the website, calls a week later, and writes on Telegram a fortnight after that. If the system has no check at the point of entry, three records appear: an email address in the first, a phone number in the second, a username in the third. Then come the spellings — "Romashka LLC", "Romashka, LLC", "Romashka" with no legal form and an empty INN field. A year on, the same company lives in the database under three spellings, and none of them matches another by key.

The cost of duplicates shows up in money:

• Two managers work the same customer. The customer receives two different proposals and forms an opinion of the company before forming one about the price.
• Ads are served to existing customers. Acquisition budget is spent on people who have already bought, and the channel report shows an inflated conversion rate.
• A discount is granted twice. The purchase history is split across two records, and the "third purchase gets a discount" rule fires on the wrong deal.
• The funnel report does not match the money. The lead count is overstated by the number of duplicates and conversion is understated by the same amount. Which figures are actually worth showing the owner is covered separately in the owner's dashboard.

Industry measurements show this is not a rare case. Validity's report The State of CRM Data Management in 2025 (July 10, 2025) is based on a survey of 602 CRM users and administrators in the US, the UK and Australia. Of those surveyed, 76% consider less than half the data in their system accurate and complete. Lost revenue directly attributable to data quality was confirmed by 37% of organisations, with an average loss of 16 deals per quarter. Around 13 hours a week goes on hunting for basic information inside the system.

Validity's second measurement covers a different audience and is not directly comparable with the first. The 2026 report (August 25, 2026) surveyed 500 marketing professionals in the US, the UK, Brazil, Australia and New Zealand. Direct revenue loss from data quality was reported by 62% of organisations. Almost a third of teams spend six or more hours a week correcting and reconciling data, and 63% said poor data had created regulatory compliance risks. No comparable Russian measurements are publicly available; the mechanics by which duplicates cost money, though, do not depend on the jurisdiction.

The fix is not a one-off clean-up. First you choose an identity key — INN for legal entities, a normalized phone number and email for individuals — and put the check on that key at the point of entry into the system. Then you write down the merge rules: which record is the master, what to do when the owners differ, how to keep both negotiation histories. Only after that is it worth sorting out what has accumulated.

Who owns the database when a manager leaves?

Short answer: the company — but that is only provable where a trade secret regime has been introduced and all five statutory measures are in place, rather than a single non-disclosure agreement having been signed.

Article 10 of Federal Law 98-FZ of July 29, 2004 "On Trade Secrets", Russia's trade secret law, lists the measures for protecting confidentiality. There are five. The first three are organisational: define the list of information constituting a trade secret; restrict access to it through a handling procedure and monitoring of compliance with that procedure; keep a record of the people granted access. The other two are contractual and formal: cover the use of such information in employment contracts with staff and in civil law contracts with counterparties, and apply a "Trade Secret" label to the media. Part 2 of the same Article states the condition without qualification:

A trade secret regime is considered established after the holder of the information constituting a trade secret has taken the measures specified in Part 1 of this Article — Federal Law 98-FZ, Article 10, Part 2.

What that means in practice for an owner: the point about keeping a record of people granted access and the point about a handling procedure are closed by system settings, not by paperwork alone. If every manager in the CRM has "see everything" rights and nobody knows who exported contacts or when, the list may be approved but access is not in fact restricted. And the rule says exactly one thing: without all the measures in place, the company has no right to invoke the trade secret regime. A dispute with a former employee then has to be built on other grounds — the terms of the employment contract, unfair competition law, personal data processing rules.

Russian figures show how far this is from theory. In the annual survey by SearchInform, a Russian information security vendor, covering more than 1,000 information security specialists and published on February 20, 2025, 48% of companies experienced leaks caused by their own employees in 2024. What leaks most often is precisely what this article is about: customer and deal information in 44% of cases, personal data in 36%. In 67% of cases the cause was named as mistakes and ignorance of basic rules rather than intent — which is to say most leaks happen routinely, with no malice involved.

How do you restrict exports and see who downloaded the database?

Short answer: with record-level rights, an export cap, a log of views and an alert on anomalies — and all of it is configured before the resignation, not after.

In the same SearchInform survey, leak channels overall broke down as follows: messengers 54%, email 53%, removable media 34%, photographing the screen with a smartphone 29%. The survey gives no channel breakdown specific to customer data; all that is known is that customer and deal information is the most frequently leaked category. The screen-photography figure matters as a limit on expectations: you cannot fully close off a data grab, the task is to make it expensive and visible.

A working set of measures looks like this:

1. Rights on records, not on sections. A manager sees their own customers, a head of department sees the department, marketing sees anonymized slices. The check sits on the server side: hiding a button in the interface is not enough, the request for the data goes out without the button too.
2. Export as a separate right. The export right is granted to roles and capped by volume. The "export the whole database" option is available to one or two people, not to everyone with a login.
3. A log of views and exports. Who, when, how many records they opened and what they downloaded. Without it, a conversation about a leak comes down to one person's word against another's.
4. Alerts on anomalies. Three hundred records opened in an hour, or contacts exported at night, is grounds for a signal the same day rather than a discovery a month later.
5. Contact masking. Calls and messages go through the system, and the manager is never shown the customer's full number. It is a harsh measure, justified where the database is the main asset.
6. Corporate channels instead of personal ones. Messengers and telephony are connected to the company, not to an employee's personal number. That closes a leak channel and fills the database with negotiation history at the same time.

One thing has to be checked separately, because it is remembered last: access to the system itself and to its backups. If the server, the domain and the database are registered to an employee's personal account, none of the measures above matter.

What does Federal Law 152-FZ require of a contact database?

Short answer: every record must have a legal basis, a purpose, a retention period and a storage location — and consent to marketing is a separate document, not a by-product of an enquiry.

Part 7 of Article 5 of Law 152-FZ sets the limit on retention:

Personal data must be stored in a form that permits identification of the data subject for no longer than the purposes of processing the personal data require... Personal data being processed is subject to destruction or anonymization once the purposes of processing have been achieved or the need to achieve them has been lost — Federal Law 152-FZ, Article 5, Part 7, ConsultantPlus.

For a customer database that means "keep everything forever" stops being a harmless habit: contacts collected for a purpose that closed long ago turn from a reserve into a liability. The second requirement concerns location: Part 5 of Article 18 of the same law requires the recording, systematisation, accumulation, storage, updating and retrieval of Russian citizens' data to use databases located inside Russia. What happens when customer data travels out to external services is covered in the article on neural networks without data leaks.

Marketing messages are governed by a separate law, and this is where mistakes are most common. Part 1 of Article 18 of the Advertising Law states the rule and allocates the burden of proof:

The distribution of advertising over telecommunications networks... is permitted only on condition of the prior consent of the subscriber or addressee to receive advertising. Advertising is deemed to have been distributed without the prior consent of the subscriber or addressee unless the advertising distributor proves that such consent was obtained — Federal Law 38-FZ "On Advertising", Article 18, Part 1, ConsultantPlus.

The company is the one that has to prove it, which means the CRM stores a provable event: date and time, channel, the wording the customer agreed to, and a note of withdrawal if there was one. The price of getting it wrong is set by Part 4.1 of Article 14.3 of the Code of Administrative Offences, Russia's administrative penalties code, introduced by the law of April 6, 2024 No. 78-FZ. Breaching the requirements for advertising over telecommunications networks costs individuals 10,000–20,000 rubles, officers of a company 20,000–100,000, and legal entities 300,000 to 1 million rubles.

Hence the minimum requirements for a customer record: data source, purpose of processing, the date of consent to marketing separately from consent to processing, the date of withdrawal and the retention period. No manager will fill any of those fields in by hand — they are set by whichever system brought the contact into the database.

How does the database fill itself, without manual entry?

Short answer: the customer record is created by the channel the customer arrived through, and that same channel brings the source, the consent and the history.

Five entry points cover almost the whole flow:

• Website forms. An enquiry creates a record with the source, the ad tracking parameters, the text of the request and a recorded fact of consent. This is the one place where consent is obtained correctly by default.
• Telephony. An inbound call finds the customer by number or creates a new one; the record keeps the call recording and its transcript. A missed call becomes a task instead of a forgotten number.
• Messengers and email on corporate accounts. The whole conversation is attached to the record. This is the point that closes the main hole — history that lives in a personal phone.
• 1C. Company details, shipments, payments and outstanding balances come from accounting rather than being re-entered. Who owns what and how the exchange is built is covered in the article on system integration: approaches and stages.
• First-line support. Routine enquiries are qualified by an AI agent on the first line: it collects the basic details, checks the customer against the identity key and hands the manager a record that is already filled in.

All five entry points share one key requirement: the duplicate check sits at the entry. An enquiry is first looked up by INN, normalized phone number and email, and only then is a new record created. Without that check, automated collection accelerates the problem instead of solving it: duplicates used to be created by hand at ten a day, now the channels deliver a hundred.

If part of the database still lives in spreadsheets, the order of work is described in the piece on when a business should move off Excel: first you agree which system counts as the system of record, and only then do you build the exchange.

How do you check that the database is in good shape?

Short answer: with six metrics, each of which is calculated by querying the system rather than by asking the head of sales for an opinion.

Each company sets its own threshold for identity key coverage; in acceptance testing we usually take at least 90% as the benchmark, because the remainder cannot be deduplicated at all. The last row of the table is usually the answer to the question in the title of this article. If exactly one person has dealt with half your customers and the entire history of that contact is in their chat window, the database belongs to the managers, whatever the trade secret policy says.

What do you need for this to work at your company?

Short answer: six things, and half of them are settled inside the company before any work starts.

1. A documented process for working with a customer. Who is responsible for the customer at each stage, when the owner changes, what happens to the customer after the deal. Without this, access restrictions get invented on the fly.
2. A chosen identity key. What exactly defines "the same customer" in your business: INN, phone number, contract number, property. That decision is the business's to make, not the developer's.
3. Access to your accounting systems. A technical user in 1C, read and write rights, a test environment for checking the exchange. This is also the precondition for the database filling itself.
4. A matrix of roles and rights. Who sees contacts, who sees amounts, who may export and how much. The list of roles is easier to draw up before development than to retrofit after the first leak.
5. The legal side. The list of information constituting a trade secret, the handling procedure, the record of people granted access, the wording in employment contracts, the texts of the consents to processing and to marketing. The legal and technical parts are done at the same time, otherwise the regime does not count as established.
6. A database owner and ongoing support. Someone who is accountable for data quality and resolves disputed merges, plus an agreement on maintaining the system. A database degrades on its own: contacts go stale, companies are renamed, the people at your customers change.

The first two points require no development budget and deliver a noticeable part of the result by themselves. They are also why timing and cost cannot be quoted over the phone: the price is built from the number of channels, the depth of the link to accounting and the number of exceptions in your process.

Off-the-shelf, or a system built around your process?

An off-the-shelf CRM covers the standard scenario, and where the scenario is standard it is enough: lead, call, invoice, payment, basic access rights. What is available off the shelf on the Russian market and how to choose between those systems is covered separately in how to choose a CRM.

The fork in the road runs through three things, and all three are different at every company. The first is reference data and the identity key: at one company the customer is defined by INN, at another by a property or a contract number, and the record merge logic follows that rather than the platform's settings. The second is access rights and exceptions: who sees the contacts after a customer is handed over, what happens to the database when the owner changes, who may export and how much. The third is connectedness with accounting: without a two-way exchange with 1C, the database becomes one more place where the same counterparties are kept separately and drift apart from the books. An off-the-shelf product runs all of this on somebody else's model, and the gap between its model and yours is closed by staff working by hand — which is the moment the licence savings run out. We have covered the choice between an off-the-shelf product and a system built around your own process separately in your own system or a boxed product.

At INCUBE AI we do both. For a fast start there are ready-made solutions from our catalogue, each adapted to your process. When the platform starts getting in the way, we build a system around the task as custom development: collecting the database from every channel, deduplication at the entry, roles and rights, an export log, exchange with 1C, consents and retention periods under 152-FZ. We work under contract, and the data stays in Russia. If you suspect your database lives in your managers' phones, tell us about the task: we will look at what can be collected automatically, what can be closed off with access rights, and what it will cost.

Sources

• J'son & Partners Consulting and Bitrix24: CRM selection criteria, survey of 1,000 companies, November 2025 – January 2026 — 98.7% of companies use a CRM alongside other software, most often office applications. 20% adopted a system after losing deal data. Bitrix24 is used by 49% of companies, 1C:CRM by 20%, amoCRM by 9%
• Validity, The State of CRM Data Management in 2025, July 10, 2025 — survey of 602 CRM users and administrators in the US, the UK and Australia. 76% of respondents consider less than half their data accurate and complete, 37% lost revenue because of data quality, on average 16 deals per quarter, and around 13 hours a week goes on searching for information in the system
• Validity, The State of CRM Data Management in 2026, August 25, 2026 — survey of 500 marketing professionals in the US, the UK, Brazil, Australia and New Zealand. 62% of organisations reported revenue lost to data quality, almost a third of teams spend 6+ hours a week correcting and reconciling data, and 63% note regulatory compliance risks. The sample differs from the 2025 measurement, so the figures are not directly comparable
• SearchInform: 48% of Russian companies experienced leaks caused by employees, CNews, February 20, 2025 — survey of more than 1,000 information security specialists. Customer and deal information leaks in 44% of cases, personal data in 36%. Leak channels overall: messengers 54%, email 53%, removable media 34%, photographing the screen 29%; in 67% of cases the cause is mistakes rather than intent
• Federal Law 98-FZ "On Trade Secrets" of July 29, 2004, Article 10 — the five confidentiality protection measures and the rule that a trade secret regime is considered established only after all of them have been taken
• Federal Law 152-FZ "On Personal Data" of July 27, 2006, Article 5, Part 7, ConsultantPlus — personal data is stored no longer than the purposes of processing require, and is then destroyed or anonymized
• Federal Law 38-FZ "On Advertising" of March 13, 2006, Article 18, Part 1, ConsultantPlus — advertising over telecommunications networks only with the subscriber's prior consent; the burden of proving consent lies with the advertising distributor
• Code of Administrative Offences of the Russian Federation, Article 14.3, Part 4.1, ConsultantPlus — breach of the requirements for advertising distributed over telecommunications networks (the provision was introduced by the law of April 6, 2024 No. 78-FZ): individuals 10,000–20,000 rubles, company officers 20,000–100,000, legal entities 300,000 to 1 million rubles