Как вести клиентскую базу: какие данные хранить и как поддерживать порядок
Клиентская база полезна тогда, когда по ней можно продолжить работу без звонка коллеге с вопросом «а что у нас с этим клиентом?». В карточке должны быть только данные, которые помогают найти человека, восстановить контекст, увидеть ответственного, активные сделки и следующее действие. Все остальное имеет смысл хранить только при понятной рабочей или законной цели.
Для небольшой компании достаточно держаться четырех правил:
Для небольшой компании достаточно нескольких базовых правил. Храните только те данные, которые нужны для конкретной рабочей цели, и не смешивайте контакты, компании, сделки и проекты в одну сущность. У активной работы должен быть понятный владелец и следующее действие, а сама база нуждается в регулярной проверке дублей, устаревших записей и лишних полей.
Зачем бизнесу клиентская база и какие задачи она должна решать
Клиентская база — организованный набор данных о клиентах и взаимодействиях с ними, который позволяет продолжать работу без потери контекста. Если база используется только как телефонная книга, большая часть ее ценности теряется.
| Рабочая задача | Что должна дать база | Минимально нужные данные |
|---|---|---|
| Быстро найти клиента | Понятную карточку и контакт | Имя/название, телефон или email |
| Продолжить работу после передачи | Историю и ответственного | Владелец, последние договоренности, история |
| Управлять активной продажей | Связанные сделки и следующий шаг | Сделка, этап, сумма/диапазон, задача |
| Вернуться к клиенту позже | Дату и причину следующего контакта | Статус отношений, дата, комментарий |
| Сегментировать под конкретное действие | Группу по проверяемому признаку | Поле/тег, который реально используется |
| Анализировать источники | Понимание, откуда пришел клиент | Источник и связанные сделки |
Объем базы сам по себе не является показателем качества. Десять тысяч неактуальных записей без владельцев и истории хуже тысячи карточек, по которым команда понимает, что делать.
Разделите контакт, компанию, сделку и проект
Одна из причин хаоса — попытка хранить все в одной строке.
Контакт — конкретный человек.
Компания — организация, с которой связан один или несколько контактов.
Сделка — отдельная коммерческая возможность: конкретная продажа, имеющая сумму, этап и исход.
Проект — выполнение согласованного объема после продажи, если работа длительная и состоит из задач.
Пример B2B:
Компания «Альфа» работает с вами три года. В ней есть директор Иван и маркетолог Анна. За это время было четыре сделки и два больших проекта. Создавать новую компанию при каждом запросе не нужно: одна компания связывает контакты, а сделки отражают отдельные коммерческие возможности.
В B2C компания может отсутствовать: контакт напрямую связан со сделками и историей.
Важно не копировать одни и те же данные в каждую сущность. Реквизиты организации относятся к компании, а сумма и этап — к конкретной сделке.
Минимальная карточка клиента: какие поля действительно нужны
Не пытайтесь заполнить двадцать полей в момент первой заявки. Часть информации становится нужна только позже.
| Поле | Сущность | Когда заполнять | Зачем | Кто обновляет |
|---|---|---|---|---|
| Имя / название | Контакт или компания | При создании | Идентификация | Создатель записи |
| Проверенный канал связи | Контакт | При первом контакте | Связаться с человеком | Ответственный |
| Источник | Контакт/сделка | При создании | Анализировать происхождение | Автоматически или менеджер |
| Ответственный | Контакт/сделка | Сразу | Понятный владелец | Руководитель/маршрутизация |
| Статус отношений | Контакт/компания | По процессу | Понимать актуальность | Ответственный |
| Последний контакт | История | После взаимодействия | Восстановить контекст | Автоматически/ответственный |
| Следующее действие и дата | Сделка/задача | Для активной работы | Не потерять продолжение | Ответственный |
| Связанные сделки | Сделка | При появлении возможности | Видеть коммерческую историю | Менеджер |
| Основание/согласие, где требуется | По правилам компании | В применимой ситуации | Контроль законности обработки | Ответственная роль |
Для B2B могут быть важны компания, должность и роль в принятии решения. Для B2C — чаще достаточно самого контакта и истории сделок.
Поле становится обязательным не потому, что оно «может когда-нибудь пригодиться», а потому, что без него нельзя выполнить конкретный этап процесса.
Правила ввода: как сохранить единый формат
Хорошая база держится не только на программе, но и на коротком регламенте. Его должны понимать сотрудники без отдельного курса.
Пример правил:
Правила качества базы лучше зафиксировать заранее. Перед созданием новой записи сотрудник должен проверить клиента по телефону, email и компании. Телефоны, названия компаний и значения справочников стоит приводить к единому формату, а источник обращения — фиксировать при создании записи, потому что позже его часто уже невозможно восстановить. Активной карточке нужен ответственный, договоренность лучше хранить как итог разговора, а конкретное действие — как задачу со сроком. Суммы, даты и статусы удобнее держать в отдельных полях, а не прятать в свободном комментарии. После значимого контакта контекст лучше обновлять сразу, пока детали еще свежи.
Плохо:
«Созвон был, вроде интересно, вернуться потом».
Лучше:
Итог: рассматривает запуск в ноябре.
Статус: пауза до бюджета.
Следующая задача: написать 3 октября.
Ответственный: Мария.
Как бороться с дублями и устаревшими записями
Очистка базы не должна начинаться с массового удаления.
Пошаговый алгоритм:
1. сделайте резервную копию или выгрузку;
2. определите ключи для поиска совпадений — телефон, email, компания;
3. найдите очевидные дубли;
4. выберите основную запись;
5. перенесите в нее актуальные контакты, историю и связи;
6. проверьте ответственного и активные сделки;
7. исправьте устаревшие данные;
8. пометьте неактуальные контакты;
9. архивируйте или удаляйте только по утвержденному правилу;
10. зафиксируйте причину решения, если это важно для контроля.
| Ситуация | Действие |
|---|---|
| Два контакта с одним подтвержденным телефоном и тем же человеком | Объединить после проверки истории |
| Один человек сменил email | Обновить контакт, старый адрес пометить неактуальным |
| Две компании с похожим названием, но разными реквизитами | Не объединять автоматически |
| Клиент давно неактивен, но хранение еще обосновано | Архивировать/изменить статус |
| Данные больше не нужны для цели и нет другого основания хранения | Рассмотреть удаление по правилам компании |
Автоматическое слияние по одному слабому признаку может быть опаснее самого дубля. Например, общий корпоративный домен еще не доказывает, что две записи — одна компания.
Сегментация только ради действия
Теги и сегменты полезны тогда, когда меняют действие команды.
Хороший вопрос перед созданием нового признака: что мы будем делать по-разному для этой группы?
| Сегмент | Какое действие меняется | Какие данные нужны | Когда обновлять |
|---|---|---|---|
| Тип услуги | Отправляется другой сценарий предложения | Услуга/интерес | После квалификации |
| Стадия отношений | Разная коммуникация с новым и действующим клиентом | Статус | При изменении отношений |
| Дата продления | Появляется задача на продление | Дата окончания | После договора/продления |
| Отрасль | Используется отдельный продукт или кейс | Отрасль компании | При подтверждении |
| Активность | Запускается проверка или реактивация | Последний контакт/сделка | Автоматически или аудитом |
Если для тега нет действия, отчета или ответственного, скорее всего, он не нужен.
Не создавайте чувствительные или предположительные характеристики «для маркетинга» без понятной цели и юридической оценки.
Жизненный цикл записи: создание, обновление, архив и удаление
Клиентская база меняется постоянно, поэтому важно определить события, после которых карточка должна обновляться.
| Событие | Что сделать | Кто отвечает | Что проверить |
|---|---|---|---|
| Новое обращение | Создать/найти запись, сохранить источник | Менеджер/автоматизация | Нет ли дубля |
| Первый контакт | Проверить канал, уточнить имя/компанию | Ответственный | Данные подтверждены |
| Новая сделка | Связать с существующим клиентом | Менеджер | Не создан ли новый контакт без причины |
| Значимое взаимодействие | Обновить итог и следующую задачу | Ответственный | Контекст понятен другому сотруднику |
| Смена владельца | Передать ответственность и открытые действия | Руководитель/PM | Нет задач без владельца |
| Завершение отношений | Изменить статус и закрыть активные действия | Ответственный | Причина зафиксирована |
| Регулярный аудит | Проверить качество и актуальность | Владелец базы | Дубли, пустые поля, старые записи |
| Архив/удаление | Действовать по утвержденному правилу | Ответственная роль | Есть основание и резервная копия, если нужна |
Универсального срока хранения для любой клиентской базы нет: он зависит от цели, закона, договорных обязательств и других оснований.
Персональные данные: минимизация, точность и безопасность
Этот раздел не является юридической консультацией; конкретные основания обработки, формы согласия, сроки хранения и требования к информационным системам нужно проверять применительно к вашему бизнесу.
По состоянию на 8 сентября 2026 года статья 5 Федерального закона №152-ФЗ «О персональных данных» закрепляет несколько принципов, напрямую связанных с клиентской базой:
По состоянию на 8 сентября 2026 года статья 5 Федерального закона №152-ФЗ «О персональных данных» закрепляет несколько принципов, напрямую связанных с клиентской базой. Обработка должна иметь конкретные, заранее определенные и законные цели, а сами данные должны соответствовать этим целям и не быть избыточными. Компания также должна обеспечивать точность и при необходимости актуальность информации, а срок хранения должен соответствовать цели обработки, если иной срок не установлен законом или применимым договором.
Практически это означает: не нужно собирать дату рождения, домашний адрес или личные характеристики только потому, что CRM позволяет создать такие поля. Сначала определите, зачем конкретные данные нужны и на каком основании вы их обрабатываете.
Проверьте у себя:
• определена ли цель каждого набора персональных данных;
• нет ли полей «на всякий случай»;
• кто может видеть данные;
• как исправляется неточная информация;
• как документируется применимое основание обработки;
• есть ли правила хранения, архивирования и удаления;
• отделены ли операционные данные по договору от маркетинговых коммуникаций.
Источник для правовой проверки: Федеральный закон от 27.07.2006 №152-ФЗ, статья 5; актуальную редакцию перед публикацией нужно повторно сверить в официальной системе правовой информации или правовой базе.
Метрики качества клиентской базы
Не задавайте универсальные нормы вроде «95% карточек должны быть заполнены». Сначала определите критичные поля и действия именно для своего процесса.
| Метрика | Пример формулы | Что делать при ухудшении |
|---|---|---|
| Активные записи с владельцем | записи с владельцем / активные записи | Проверить маршрутизацию и передачу |
| Сделки со следующим действием | активные сделки с задачей / активные сделки | Разобрать этапы без next step |
| Полнота критичных полей | карточки с заполненным набором / проверенные карточки | Уточнить момент обязательного заполнения |
| Доля дублей | подтвержденные дубли / проверенные записи | Исправить правила создания и импорта |
| Невалидные контакты | нерабочие контакты / проверенные контакты | Ввести верификацию |
| Возраст обновления | время с последнего значимого обновления | Запустить аудит активных карточек |
Метрика полезна только тогда, когда за ней следует действие владельца процесса.
Ежемесячный аудит базы: короткий чек-лист
Раз в выбранный компанией период проверьте:
□ очевидные дубли;
□ активные записи без владельца;
□ сделки без следующего действия;
□ просроченные задачи;
□ невалидные телефоны и email;
□ пустые критические поля;
□ активные карточки, которые давно не обновлялись;
□ устаревшие роли и доступы сотрудников;
□ сегменты и теги, которыми никто не пользуется;
□ записи, для которых нужно проверить статус хранения или основания;
□ качество последней выгрузки/резервной копии;
□ повторяющиеся причины ошибок и решение по ним.
Назначьте одного владельца качества базы. Это не значит, что он должен сам исправлять каждую карточку, но кто-то должен видеть общую картину и доводить правила до команды.
Как это можно организовать в Yoori. Функции сверены 8 сентября 2026 года. На официальных страницах Yoori подтверждены отдельные карточки контактов и компаний, возможность связывать человека с организацией, настраиваемые поля, поиск, фильтрация, экспорт в Excel, роли, история изменений, сделки, задачи и дедлайны. На странице «Общение и контроль» также описаны комментарии, файлы, история и управление доступом команды.
Эти функции полезны только при наличии правил: CRM не решит проблему дублей, если сотрудники продолжают создавать новые карточки без поиска, и не сделает данные актуальными, если никто не отвечает за обновление.
Частые вопросы
Какие данные обязательно хранить о клиенте?
Только те, которые нужны для законной цели и рабочего процесса. В базовом сценарии это идентификация, проверенный контакт, ответственный, история, активные сделки и следующее действие. Точный набор зависит от модели бизнеса.
Как часто обновлять клиентскую базу?
После значимых взаимодействий и событий жизненного цикла. Дополнительно полезен регулярный аудит критичных полей, дублей, владельцев и просроченных действий.
Нужно ли удалять неактивных клиентов?
Не автоматически. Решение зависит от цели и основания хранения. Сначала определите правило и проверьте применимые обязательства; в разных ситуациях правильным действием может быть обновление, архивирование или удаление.
Чем тег отличается от поля?
Поле хранит конкретный атрибут по единому правилу, а тег обычно используется для гибкой группировки. И то и другое имеет смысл только при понятном действии или отчете.
Можно ли хранить клиентскую базу в Excel?
Можно при простом процессе с одним владельцем. Когда появляются несколько сотрудников, история, права и следующие действия, стоит оценить CRM как рабочую систему, а Excel оставить для расчетов или анализа.