Экспорт агентской CRM: как забрать данные вместе с их смыслом

Простая выгрузка CSV даёт строки, но теряет связи, вложения и смысл статусов. Разбираем, как собрать паспорт пакета и проверить переносимость до запуска полного переноса.

Экспорт агентской CRM — это переносимый пакет: строки объектов, карта идентификаторов, связи, файлы с версиями, справочники кодов, права доступа, время событий с часовым поясом и следы агентских действий. Переносимость проверяют по паспорту пакета на условной выборке: связность, повторный импорт без дублей, порядок дат, читаемость справочников и круг доступа. Оговорка: состав пакета зависит от конфигурации конкретной системы.

В условной компании «Северный контур» руководитель отдела продаж нажимает «Экспорт» и получает файл с контактами, сделками и задачами. Через неделю новая система показывает знакомые названия, но менеджеры не открывают историю: часть сделок висит без клиентов, вложения не найдены, статусы выглядят привычно, но означают другое. Формально данные выгружены; работать с ними по-прежнему нельзя.

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

Строка выгрузки и переносимый пакет: приёмка начинается с манифеста

В условном проекте из одной CRM в другую переносят 1 200 контактов, 340 сделок и 2 100 активностей. CSV-файлы сходятся по числу строк: 1 200, 340, 2 100. На этом внешняя проверка заканчивается. Внутри пакета обнаруживаются 46 активностей со ссылкой на отсутствующие сделки, 18 вложений без файлов и семь статусов, которые в новой системе называются так же, но стоят в другом месте воронки. Числа условные, но именно так выглядит разница между выгрузкой и переносимым набором.

Кнопка «Экспорт» создаёт ощущение завершённости: файл есть, размер приличный, открывается. Дальше начинается скучная часть — доказать, что каждая строка пришла со своим контекстом. Для этого нужен манифест: перечень объектов, их количество, версия источника, время выгрузки, карта идентификаторов, список справочников, правила доступа и контрольные суммы. Без манифеста приёмка превращается в пересчёт строк и надежду.

Документация Microsoft описывает экспорт данных в Excel как выгрузку таблицы, а не как перенос связей и вложений: экспорт данных в Excel. Это полезный внешний ориентир для терминов, но он не доказывает наличие тех же возможностей в другом продукте.

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

Эпизод с оборванными связями: строка есть, а сделки за ней нет

Условная компания переносит клиентскую базу из старой CRM. В старой системе у контакта был внутренний номер 1842, у сделки — 9031, у задачи — 7715. В новой системе автонумерация начинается с единицы. Контакты импортируются первыми и получают новые номера. Сделки импортируются вторыми, но поле «клиент» в файле содержит старый номер 1842. Новая система такого клиента не находит: он уже не 1842, а 17. Сделка создаётся с пустой связью. Задачи ссылаются на старую сделку 9031, которой в новом пространстве тоже нет.

На экране остаются правдоподобные строки: название сделки, сумма, ответственный. Менеджер открывает карточку и не видит клиента. Он идёт в контакты, находит человека с тем же именем, привязывает вручную. Через день выясняется, что это дубль: настоящий контакт был создан позже, с другим номером. История разговоров осталась на первом дубле, задачи — на сделке без клиента. Формально перенос завершён, фактически собрана новая, менее полная версия прошлого.

Причина не в том, что новая система «плохая». Причина в том, что идентификатор — это не украшение строки, а несущая конструкция. Если в пакете нет карты соответствия «старый ID → новый ID» и правила для повторных импортов, автонумерация уничтожает связи. Рекомендация для приёмки: требовать не только файлы объектов, но и отдельную таблицу связей с устойчивыми внешними ключами. Тогда повторный импорт обновляет запись, а не создаёт ещё одного двойника.

Паспорт пакета: что экспорт обязан назвать до первой строки

Рабочий объект приёмки — паспорт пакета. Это не эссе о важности данных, а таблица, по которой сотрудник может сказать «принято» или «не принято». В паспорте фиксируют источник, дату и время выгрузки с часовым поясом, перечень объектов, количество строк по каждому объекту, версию справочников, карту идентификаторов, список файлов, правила доступа и ответственного за разбор ошибок.

Паспорт полезен ещё и тем, что делает спор предметным. Вместо «данные вроде перенеслись» появляется вопрос: «В паспорте 340 сделок, в новой системе 338. Где две и почему у них нет внешнего ключа?» Это уже не эмоция, а задача с адресом.

Идентификаторы и связи: автонумерация новой системы не восстанавливает историю

Связи бывают разной природы. Контакт относится к компании, сделка — к контакту и компании, активность — к сделке или контакту, файл — к записи и версии, комментарий — к автору и объекту. Если выгрузить только «главные» объекты, связи исчезают не потому, что их забыли, а потому, что для них не было отдельного места в пакете. Поэтому в паспорте нужен раздел «связи», а не только «сущности».

Устойчивый внешний ключ не обязан быть красивым. Это может быть составной ключ: код источника, тип объекта, старый номер. Важнее правило поведения при совпадении. Если контакт уже существует, импорт обновляет его или создаёт новый? Если сделка была удалена в источнике, она исчезает в приёмнике или помечается как архивная? Ответы на эти вопросы фиксируют до первой строки, иначе команда приёмки будет решать их вручную в случайном порядке.

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

Вложения: файл без версии и папки — уже другой файл

В условном проекте отдел продаж выгружает сделки вместе с «документами». В CSV есть колонка «вложение» со значением «КП_финал.pdf». В новой системе карточка сделки показывает это имя, но при открытии возникает пустая страница. Выясняется, что выгружали имена файлов, а не сами файлы. Часть вложений лежала в сетевой папке, часть — в почте, часть — в самом хранилище CRM. Имя совпало, содержимое — нет.

Второй слой проблемы — версии. У файла «КП_финал.pdf» могло быть три редакции: для клиента, для внутреннего согласования и последняя, отправленная вчера. Если пакет хранит только последнюю, история решения исчезает. Если хранит все, но без даты и автора, непонятно, какая редакция была согласована. Для приёмки нужен не просто список имён, а связь «файл — запись — версия — владелец — контрольная сумма».

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

Даты и часовой пояс: событие без смещения теряет порядок

Условная сделка закрыта 31 марта в 23:40 по времени офиса в Калининграде. В выгрузке осталась дата «2025-03-31 23:40» без смещения. Новая система читает её как локальное время сервера в другом поясе и показывает 1 апреля. Отчёт за март недосчитывается сделки, а менеджер получает вопрос, почему закрытие «переехало» на следующий день. Данные не потерялись, но смысл даты изменился.

Для событий нужны как минимум две вещи: момент времени с явным смещением или в UTC и бизнес-дата, если компания считает результат по календарю офиса. Это не одно и то же. Звонок мог произойти в 23:55, а решение по сделке — быть зафиксировано утром следующего дня. Если пакет хранит только одно поле «дата», приёмка не сможет восстановить порядок.

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

Справочники и коды: поле без словаря нечитаемо

В старой CRM этап сделки хранился кодом «S4». В новой системе есть статус «Согласование», но нет уверенности, что «S4» — это он. Рядом в выгрузке лежит справочник: «S1 — новый, S2 — квалификация, S3 — предложение, S4 — согласование, S5 — закрыт». Без этого справочника колонка «S4» выглядит как технический мусор. С ней можно сделать только одно — угадать, а угадывание в переносе данных плохо заканчивается.

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

Рекомендация: в паспорт пакета включать не только список справочников, но и правило сопоставления. «S4» может стать «Согласованием», а может — «Внутренним согласованием». Это разные этапы, и от них зависит, кому уходит задача. Если правило не записано, приёмка снова превращается в устный перевод.

Права и чужая команда: экспорт доступа — отдельный объект проверки

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

Экспорт прав — не то же самое, что экспорт записей. Здесь нужно ответить на три вопроса: кто имел доступ, на каком основании и должен ли этот доступ пережить переезд. Роли безопасности и полномочия в Microsoft описаны отдельно: роли безопасности и полномочия. Это внешний пример того, что доступ — самостоятельная сущность, а не побочный эффект импорта контактов.

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

След агентских действий: что пакет должен доказать без пересказа

Если в контуре работает агентская CRM «Цифра» — с поиском клиентов, подготовкой карточек, согласованными сообщениями и звонками, — то в переносимом пакете важен не только результат, но и основание. Изменение этапа, суммы или ответственного согласует сотрудник. Значит, в пакете должны быть видны предложенное изменение, решение сотрудника, время и объект, которого это касается. Иначе новая система получит сумму, но не объяснит, почему она изменилась.

Для «голосового агента» — ИИ-продавца в звонках по согласованному сценарию — существенны фиксация интереса и передача задачи менеджеру. В экспорте это не «магия ИИ», а след: какой сценарий применялся, что зафиксировано, какая задача создана и кому передана. Если останется только запись «интерес есть», приёмка не сможет отличить содержательный результат от случайной пометки.

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

Смена смысла статуса: приёмка на переходах, а не на названиях

Условная компания переносит воронку. В старой системе статус «В работе» означал, что менеджер взял сделку и начал подготовку. В новой системе ближайший по названию статус «В работе» означает, что отправлено коммерческое предложение и ждём ответа. Названия совпали, смысл сместился. Через месяц руководитель удивляется: половина сделок «в работе», но ни одного отправленного предложения нет.

Заказ и его строки в Microsoft рассматриваются как связанный объект: создание и обработка заказа. Это ещё один внешний пример того, что статус — не изолированная этикетка, а часть конструкции с позициями, суммами и действиями. При переносе нужно сравнивать не названия, а правила перехода: из какого состояния в какое можно попасть, кто утверждает, какие поля обязательны.

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

Интерфейс сотрудника: экран приёмки вместо папки с файлами

Папка с экспортом — плохой интерфейс для приёмки. В ней нет ответа на вопрос, что уже проверено, а что нет. Сотруднику нужен экран, где видно: пакет, паспорт, количество объектов, расхождения, очередь ошибок, ответственный и решение. Не отчёт на сто страниц, а рабочая поверхность с понятными действиями.

Такой экран не обязан быть красивым. Он обязан не прятать исключения. Если сотрудник видит «1 198 из 1 200», он должен иметь возможность открыть две недостающие записи, а не искать их вручную по всему файлу. Если видит «файлов 300, проверено 12», это честнее, чем зелёная галочка «экспорт успешен».

Трудные исключения: удалённые, объединённые и чужие записи

Удалённые записи — первое исключение, которое ломает простую логику «выгрузить всё». Если сделка удалена в источнике, она может отсутствовать в экспорте, но на неё могут ссылаться активности и файлы. Тогда в пакете появляются сироты. Решение зависит от цели переноса: архивная запись нужна для истории или нет. Но правило должно быть в паспорте, а не в голове администратора.

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

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

Тесты переносимости: пять проверок на условной выборке

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

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

Практикум: сто записей, одна связь и один понятный отказ

Возьмите условный набор из ста записей: сорок контактов, двадцать компаний, двадцать сделок, пятнадцать активностей, три файла, один справочник этапов и одну запись о согласованном изменении. Соберите паспорт пакета, карту идентификаторов и таблицу сопоставления статусов. Импортируйте набор в тестовый контур новой системы. Затем откройте одну сделку и пройдите по ней до контакта, последней активности и файла.

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

Последний шаг практикума — намеренно сломать одну связь. Уберите из карты идентификаторов один старый ключ и посмотрите, как система сообщит об ошибке. Хороший результат: появляется понятное сообщение с номером строки и объектом, импорт не создаёт сироту, ответственный видит задачу. Плохой результат: запись создаётся с пустым клиентом, а ошибка всплывает через неделю в разговоре с менеджером.

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

Соседний вопрос разобран отдельно: Внедрение CRM: перенос данных и приёмка AI-CRM. Здесь основной предмет — выход из CRM: связи, вложения, права, результаты агентов и приёмка переносимого пакета; не импорт при внедрении.