Новости и разборы
Миграция CRM: как проверить данные и работу команды
Как принять перенос CRM: сопоставление полей, дедупликация, пробная загрузка, история контактов и проверка работы менеджеров.
Перенос CRM можно закончить технически и не закончить для команды. Контакты импортированы, сделки открываются, но менеджер не находит последнее обещание клиенту, напоминания приходят дважды, а руководитель видит другую сумму открытых возможностей. Приёмка миграции должна отвечать на конкретный вопрос: сможет ли команда продолжить работу с нужной историей и понятными правилами?
В материале Close о четырёх этапах миграции собраны рекомендации руководителей продаж: проверять повседневные действия на пробном доступе, заранее определять нужные поля, сохранять исходные идентификаторы при временном использовании двух систем и вовлекать менеджеров до запуска. Это опыт участников публикации поставщика CRM, а не обещание одинакового результата для любого бизнеса. Практическая ценность подхода — в переходе от перечня функций к проверке работы.
Сначала определить, что переезжает
Представим небольшую команду, которая переносит активные продажи и обслуживание клиентов. В старой системе есть компании, контакты, сделки, письма, звонки и задачи. Переезд не обязательно должен охватывать всю историю одинаковым способом. Для активной сделки недавняя переписка нужна непосредственно в работе; для давно закрытого договора может быть достаточно доступного архива с возможностью найти запись.
По каждому типу данных стоит зафиксировать назначение, владельца и способ переноса. Кто использует поле «категория клиента» и для какого решения? Где хранятся вложения? Нужно ли переносить внутренние заметки? Как сохраняются ограничения доступа? Удаление ненужного поля и потеря нужной информации выглядят одинаково в импорте, поэтому решение должно предшествовать загрузке.
Смысл статусов необходимо согласовать до их сопоставления. Если это ещё не сделано, пригодится разбор правил воронки продаж. Миграция затем проверяет сохранение этих правил: например, закрытая сделка не должна случайно стать открытой из-за совпадения названий этапов.
Таблица соответствий важнее первого импорта
Для каждого поля запишите исходное значение, целевое поле, преобразование и действие при ошибке. Телефон может требовать нормализации, дата — явного часового пояса, справочник отраслей — таблицы замен. Пустое значение не следует автоматически превращать в «нет»: отсутствие информации и отрицательный ответ могут запускать разные действия.
В статье Close о качестве CRM-данных отдельно рассматриваются дубликаты, несогласованные пользовательские поля, устаревшие статусы и разорванные потоки между инструментами. Авторы предлагают начинать с данных, которыми команда пользуется ежедневно, и назначать ответственных за их состояние. Для переноса это полезная отправная точка: сначала исправить правила, иначе новый интерфейс сохранит старые противоречия.
Дедупликация требует отдельного решения. Одинаковое название компании не доказывает совпадение организаций, а общий телефон может принадлежать нескольким контактам. Определите, какие записи объединяются автоматически, какие требуют просмотра и что происходит с историей после объединения. Сохраните исходные ID в таблице соответствий: они помогут объяснить, откуда возникла новая запись.
Пробный перенос должен включать неудобные записи
Загрузите выборку, отражающую реальную работу: сделку с несколькими контактами, компанию с дубликатом, запись без телефона, вложение, смену ответственного и незавершённую задачу. Проверка только чистых карточек показывает, что импорт умеет обрабатывать чистые карточки.
Сверяйте не только число записей. Проверьте связи, суммы по активным сделкам с учётом валют, даты ближайших задач и доступность файлов. Расхождения следует записывать с причиной и решением: ошибка преобразования, согласованное исключение или данные, которые остаются в архиве. Это даёт основу для обсуждения, а не спор о том, какая система «правильнее».
Работа с такими связями относится к интеграции CRM. Описание проекта GoHighLevel можно использовать как контекст связанной работы с CRM; наличие такого проекта не подтверждает перенос конкретной базы или результаты будущей миграции.
Переключение требует одного места записи
На время перехода решите, где менеджеры создают новые сделки и изменяют существующие. Без этого появляется двусторонняя гонка: две системы получают разные обновления, а повторный импорт затирает часть изменений. План переключения должен описывать момент остановки старой записи, загрузку изменений после пробного переноса и проверку актуальности.
Отдельно проверьте формы, телефонию и автоматические сообщения. Старая интеграция может продолжить создавать лиды, даже когда люди уже перешли. Если одновременно выбирается голосовой инструмент, полезно заранее решить что покупать, а что разрабатывать, чтобы не пересобрать телефонию дважды.
Для отмены переключения нужен конкретный сценарий. Какие изменения успели попасть только в новую CRM? Можно ли вернуть их обратно? Кто принимает решение об откате? Доступный экспорт сам по себе не отвечает на эти вопросы.
Приёмка глазами менеджера
Попросите участников команды выполнить короткую последовательность: найти клиента, прочитать историю, записать результат разговора, назначить следующий шаг и передать сделку коллеге. Проверяйте доступы под реальными ролями, включая руководителя и сотрудника с ограниченными правами.
Передача клиента после продажи тоже должна сохранить контекст. Для этого полезно сопоставить миграционные проверки с онбордингом B2B-клиента: цель покупки и согласованные условия важнее заполненности второстепенных полей.
Итог приёмки — список проверенных действий, известных исключений и владельцев оставшихся проблем. После запуска собирайте обращения команды в одном месте и сравнивайте причины, а не только количество. Так становится видно, где требуется обучение, где нарушено преобразование данных и где новый процесс ещё не соответствует повседневной работе.