Гигиена данных в CRM. Что проверить до автоматизации и AI

Откройте список активных сделок и посмотрите на него глазами руководителя. Можно ли понять, с кем менеджер должен связаться сегодня, почему сделки задерживаются и откуда пришли клиенты? Если для ответа нужно писать каждому сотруднику, данные в CRM пока не поддерживают управление продажами.

Роботы, отчеты и AI используют то, что записано в карточках. Пропущенный источник и случайная причина отказа попадут в аналитику. Старый номер телефона попадет в сценарий повторного контакта. Сделка без следующего действия останется активной, хотя клиент давно отказался.

Гигиена данных начинается с короткого списка правил: какие данные нужны, кто их заполняет, в какой момент и для какого решения.

Как выглядит CRM, которой нельзя доверять

Проверку можно начать без сложного аудита. Откройте одну воронку и найдите следующие признаки:

• один клиент создан несколько раз с разным написанием имени или компании;
• активные сделки месяцами находятся на одной стадии без запланированного дела;
• у контакта нет телефона или электронной почты, хотя канал нужен для работы;
• источник обращения заполнен значением «сайт» независимо от реального канала;
• в полях стоят прочерки, случайные цифры и комментарии «уточнить»;
• причина проигрыша в большинстве карточек указана как «другое»;
• у сделки нет ответственного или он уже не работает в компании;
• сумма и предполагаемая дата закрытия обновляются только перед отчетом;
• одинаковое значение записывают и в поле, и в комментарий, и в отдельную таблицу.

Один такой дефект не требует перестройки всей CRM. Несколько дефектов в одном процессе уже влияют на отчетность, автоматизацию и работу с клиентской базой.

Начните с назначения данных

У каждого поля должно быть рабочее назначение. Если значение никто не использует в фильтре, отчете, автоматизации или следующем действии, требовать его заполнения сложно.

Для каждого важного поля зафиксируйте четыре ответа:

Такой разбор быстро показывает лишние поля и недостающие правила. Если бюджет становится известен только после разговора, его не нужно требовать при создании сделки. Если источник приходит из формы или телефонии, менеджер не должен каждый раз выбирать его вручную.

Шесть зон проверки

1. Контакты, компании и дубли

Сначала определите, что в вашем процессе считается клиентом. В B2B один контакт может работать в компании, а у компании может быть несколько сделок. В рознице основным объектом чаще становится контакт. Эта модель влияет на поиск и объединение дублей.

Проверьте:

• единый формат телефонов и электронной почты;
• правила создания контакта и компании;
• поиск существующей карточки перед созданием новой;
• дубли по телефону, почте и реквизитам;
• карточки, связанные с уволенными сотрудниками;
• порядок объединения, если в двух карточках есть полезная история.

В Битрикс24 контроль дубликатов настраивается отдельно для лидов, контактов и компаний. Автоматическое объединение нужно включать только после проверки правил. Две карточки с одинаковым общим телефоном могут относиться к разным людям или подразделениям.

2. Воронки и стадии

Стадия должна описывать состояние работы, которое можно проверить. «В работе» не сообщает, что уже сделано и какое действие ожидается. «КП отправлено» можно проверить по документу и дате отправки. «Ждем оплату» можно проверить по счету и сроку.

Для каждой стадии определите:

• условие входа;
• обязательное действие менеджера;
• данные, которые должны появиться в карточке;
• условие перехода дальше;
• допустимый срок без активности.

Разные процессы лучше разводить по отдельным воронкам, когда у них отличаются этапы, ответственные и правила работы. Разделение только ради красивого отчета добавляет менеджерам лишние переходы и усложняет контроль.

3. Обязательные поля

Большой список обязательных полей при создании сделки приводит к формальному заполнению. Менеджер еще не знает бюджет, срок или состав заказа, но система уже требует значение. В карточке появляются нули и прочерки.

В Битрикс24 поле можно сделать обязательным на определенной стадии. Поэтому требование лучше включать в тот момент, когда данные действительно должны быть известны.

Пример последовательности:

• новая заявка: канал, телефон и ответственный;
• квалификация: потребность, регион, тип клиента и следующий шаг;
• предложение: состав, сумма, срок действия и документ;
• договор: реквизиты, условия оплаты и ответственные;
• успешная сделка: фактическая сумма и данные для передачи в исполнение.

Набор полей зависит от процесса. Важно, чтобы обязательность помогала выполнить следующий этап, а не собирала информацию на будущее без понятного применения.

4. Следующее действие

Активная сделка без запланированного действия требует отдельной проверки. Запись «перезвонить» в комментарии не попадет в календарь и не создаст просрочку. Нужны конкретное действие, срок и ответственный.

Для ежедневного контроля достаточно трех выборок:

1. Сделки без запланированного дела.
2. Просроченные дела.
3. Сделки без активности дольше допустимого срока стадии.

Эти списки полезнее общего количества карточек в работе. Они показывают, где процесс остановился и кому нужно принять решение.

5. Причины проигрыша и справочники

Причина отказа должна помогать определить следующее управленческое действие. Значения «дорого» и «другое» слишком широкие, если по ним нельзя разделить ситуации.

Рабочий справочник может различать:

• нет бюджета в текущем периоде;
• не согласован состав работ;
• не подошел срок запуска;
• выбран другой поставщик;
• обращение не соответствует профилю клиента;
• клиент перестал отвечать после указанного этапа;
• создана повторная или тестовая карточка.

Справочник не должен быть бесконечным. Начните с причин, которые меняют решение: вернуть клиента позже, пересмотреть предложение, исправить квалификацию или исключить карточку из продаж.

6. Ответственные, права и интеграции

У каждой активной карточки должен быть ответственный. Отдельно проверяются очереди новых обращений, записи уволенных сотрудников и сделки, где ответственный не имеет доступа к связанному контакту или документу.

Интеграции тоже влияют на качество. Форма может создать новый контакт вместо обновления существующего. Телефония может сохранить номер в другом формате. Обмен с 1С может вернуть статус заказа в текстовое поле, которое никто не использует.

Для каждого канала запишите:

• какую сущность он создает;
• по каким признакам ищет существующего клиента;
• кто становится ответственным;
• какие поля заполняются автоматически;
• что происходит при ошибке передачи;
• где сотрудник увидит, что заявка не дошла.

Короткая ежедневная проверка

Менеджер перед завершением рабочего дня проверяет:

• у всех активных сделок назначено следующее действие;
• результат последнего контакта записан в карточке;
• новые контакты не дублируют существующие;
• сделка находится на фактической стадии;
• обещанные клиенту документы и сроки зафиксированы задачей или делом.

Руководителю полезно смотреть отчет по отклонениям вместо всех карточек подряд:

• новые заявки без ответственного;
• сделки без активности;
• просроченные дела;
• карточки без ключевых полей;
• проигранные сделки без причины;
• сделки с измененной суммой или датой закрытия.

Такой контроль можно собрать фильтрами и отчетами. Сотрудник видит конкретную ошибку, руководитель получает список для разбора, а не общий призыв «вести CRM внимательнее».

Еженедельная гигиена

Раз в неделю выберите одну воронку и пройдите по отклонениям:

1. Закройте сделки, по которым работа закончена.
2. Назначьте действия по живым сделкам без активности.
3. Проверьте новые дубли и спорные объединения.
4. Посмотрите распределение причин проигрыша.
5. Разберите пропуски в полях, которые участвуют в отчетах.
6. Проверьте заявки, созданные интеграциями.
7. Зафиксируйте одно изменение правила или настройки на следующую неделю.

Не нужно одновременно чистить всю базу и перестраивать все воронки. Сначала исправляется один повторяемый процесс. После проверки правило можно переносить на остальные направления.

Что проверить перед автоматизацией

До запуска робота нужно пройти его условия на реальных карточках. Если робот реагирует на стадию, проверьте, одинаково ли сотрудники понимают эту стадию. Если он использует поле, посмотрите, кто и когда его заполняет. Если отправляет сообщение, исключите проигранные и тестовые сделки.

Минимальная проверка:

• событие запуска однозначно;
• все используемые поля имеют допустимые значения;
• понятен ответственный за результат;
• предусмотрена повторная попытка или уведомление об ошибке;
• действие записывается в историю;
• массовый запуск сначала проверяется на ограниченной выборке.

Автоматизация ускоряет выполнение правила. Поэтому сначала нужно проверить само правило и данные, от которых оно зависит.

Что проверить перед подключением AI

Для AI-сценария дополнительно нужен эталон результата. Если модель должна заполнять поля из разговора, заранее определите перечень полей, допустимые значения и случаи, когда значение должен подтвердить человек.

Перед пилотом зафиксируйте:

1. Одну задачу, которую выполняет AI.
2. Источник данных и границы доступа.
3. Формат результата.
4. Поля или действия, которые нельзя менять автоматически.
5. Человека, который проверяет результат.
6. Критерий успешного пилота.

AI можно подключать к классификации, резюме и подготовке черновиков, когда компания договорилась о терминах и правилах. Если одинаковая ситуация записана в CRM пятью способами, сначала приводятся в порядок справочники и стадии.

Чек-лист готовности CRM

• Для одной воронки описаны стадии и условия перехода.
• Определены ключевые поля и момент их заполнения.
• Настроен поиск дублей по основным идентификаторам.
• У всех активных карточек есть ответственный.
• У каждой активной сделки есть следующее действие.
• Причины проигрыша помогают определить дальнейшее решение.
• По интеграциям видны ошибки передачи.
• Руководитель получает отчет по отклонениям.
• Массовая автоматизация проверяется на ограниченной выборке.
• Для AI определены права, эталон и ручная проверка.

Продолжить работу можно с аудита действующей CRM или проверки клиентской базы. Для самостоятельной проверки доступен чек-лист клиентской базы.