Как перейти на другую CRM и сохранить клиентскую базу и историю сделок

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

Поэтому миграцию CRM стоит принимать по рабочим сценариям. Ниже разберём, как определить состав переноса, проверить ограничения двух систем и организовать переключение. Это план подготовки для руководителя проекта, а не инструкция по конкретному импортёру.

Сначала определите, что должно остаться доступным

Начните не с выгрузки, а с разговора с сотрудниками. Какие сведения нужны для открытых сделок? Где хранится история обслуживания? По каким данным бухгалтерия сопоставляет заказ и оплату? Ответы помогут отделить рабочую информацию от записей, которые достаточно сохранить в архиве.

Составьте перечень сущностей. Обычно в нём есть компании, контакты, сделки, задачи, товары, документы и события. Но набор зависит от процессов. Например, сервисной компании могут быть важнее объекты обслуживания и заявки на ремонт, чем стандартная воронка продаж.

Для каждой группы определите назначение, период хранения в новой системе, владельца данных и способ проверки. Отдельно перечислите то, что не переносится. Формулировка «перенос клиентской базы» без такого перечня оставляет слишком много неясного.

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

Проверьте возможности переноса до выбора даты запуска

Выгрузка в таблицу, доступ через API и резервная копия решают разные задачи. Таблица может содержать основные поля карточки, но не вложения и историю изменений. API позволяет работать с теми объектами и операциями, которые поддерживает конкретная система. Копия базы полезна для восстановления исходной CRM, но не становится автоматически данными для другой.

Попросите команду проверить не только экспорт из старой системы, но и загрузку в новую. Можно ли передать исходную дату события? Как назначается автор комментария? Что произойдёт с задачей уволенного сотрудника? Доступны ли файлы после отключения старого сервиса? Ответы нужно получить на небольшом пробном наборе, а не после выгрузки всей базы.

Даже штатный импорт требует учитывать правила продукта. Например, справка Битрикс24 по связанным элементам описывает последовательную загрузку компаний, контактов и сделок. В этом сценарии связи зависят от совпадения названий. Там же указано, что импорт не обновляет существующие сделки, а загружает их повторно. Эти правила относятся к описанному способу импорта, а не ко всем вариантам переноса через API.

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

Согласуйте соответствие полей и связей

Таблица соответствий объясняет, куда попадёт каждый элемент исходных данных. В ней указывают исходное поле, новое поле, тип значения, правило преобразования и порядок обработки исключений. Её должны понимать и разработчик, и сотрудник, который принимает результат.

Допустим, в старой CRM есть стадии «Предложение отправлено» и «Ожидаем ответ», а в новой обе попадают в «Переговоры». Технически это несложно. Но руководитель потеряет прежнее разделение в отчётах, если отдельно не сохранить исходную стадию или не принять такое изменение. Это решение о процессе, а не просто о названиях полей.

Отдельно проверьте связи между объектами. Сделка должна относиться к правильному клиенту, документ к нужной сделке, задача к ответственному. Для нестандартного переноса полезен журнал соответствия старых и новых идентификаторов. Он помогает разбирать ошибки и повторно обрабатывать отдельные записи, не полагаясь только на похожие названия.

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

Сделайте пробный перенос с неудобными примерами

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

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

После загрузки проверьте три уровня результата.

• Полнота. Все предусмотренные записи попали в систему, а пропуски и исключения отражены в отчёте.
• Содержание. Значения, даты, суммы, файлы и ответственные соответствуют правилам переноса.
• Работа. Сотрудник находит клиента, открывает историю и выполняет следующий шаг с доступами своей роли.

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

Запланируйте переключение входящих обращений

Пока идёт подготовка, в старой CRM появляются новые заявки и меняются сделки. Нужно определить момент, до которого данные считаются исходными, и способ переноса изменений после первой выгрузки. Иначе часть записей останется между двумя системами.

Есть разные варианты. Для одного проекта допустима согласованная пауза в изменении данных. Другому нужен перенос накопившихся изменений перед запуском. Третий требует временной синхронизации. Выбор зависит от возможностей систем и допустимого перерыва в работе, а не от общего правила «переезжаем за выходные».

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

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

Договоритесь, что делать при неудачном запуске

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

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

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

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

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

Полезно заранее подготовить несколько приёмочных сценариев. Менеджер находит действующего клиента и последнее предложение. Руководитель получает согласованную выборку открытых сделок. Новая заявка с сайта создаётся один раз и назначается нужному сотруднику. Пользователь без расширенных прав не видит закрытые для него данные.

Итоговый протокол должен содержать состав перенесённых данных, результаты сверки, известные исключения и порядок доступа к архиву. Нерешённые замечания не стоит скрывать за общим статусом «готово». Для них нужны ответственные и согласованные сроки.

Если система ещё не выбрана, начните со статьи о готовой CRM и разработке под заказ. Если выбор уже сделан, следующий шаг практичнее: описать данные, провести пробный перенос и согласовать приёмку. При разработке CRM в Sibcode состав миграции можно включить в требования к проекту, чтобы новая система принималась вместе с рабочими данными, а не отдельно от них.