У клиента была типичная «наследная» CRM-история: система жила больше пяти лет, пережила разные команды, обросла воронками, кривыми полями, полуручными отчётами и логикой, которую уже никто толком не мог описать. Снаружи это выглядело как знакомая CRM, а внутри — как слой накопленного операционного шума.
Поэтому задача была не просто перевезти записи из amoCRM в Twenty. Нужно было вычистить старые правила, понять, что вообще в системе живое, пересобрать модель данных и сделать так, чтобы после миграции появилась нормальная управленческая картина, а не новый красивый интерфейс над старым хаосом.
Исходный объём
10,5k+ записей
В старой CRM накопилось слишком много исторических сущностей, чтобы переносить всё подряд без отбора и ревизии.
Пилот миграции
50 активных сделок
Сначала тестовая партия: быстро проверить новую модель, логику маппинга и поведение данных в Twenty.
Рост качества данных
≈ 60% → 80–85%
После нормализации и разборки сущностей данные стали пригоднее для аналитики и управленческой работы.
Старт
Худшая стратегия в CRM-миграции — честно перенести весь накопленный беспорядок в новую систему и назвать это внедрением. Здесь такой путь только закрепил бы проблемы ещё сильнее.
За годы в системе накопились 15+ воронок, неравномерно заполненные поля, разные привычки менеджеров и отчётность, собранная на плагинах и ручных выгрузках. То есть проблема была не в одном баге, а в расползшейся модели работы.
Пока цифры собираются руками и регулярно расходятся с фактом, CRM перестаёт быть инструментом управления. Поэтому переезд нужно было строить вокруг аналитики и операционной прозрачности, а не вокруг механического переноса карточек.
Аудит
До первой выгрузки данных я сначала разбираю сам процесс: какие сущности реально живут в компании, что используется на практике и какая управленческая картинка должна появиться у руководителя после запуска.
Сначала — как команда реально работает, где начинаются сделки, как движутся этапы и что на самом деле считается результатом.
Проверили, какие объекты в CRM живые, а какие остались историческим шумом от прошлых итераций и старых команд.
Посмотрели, насколько данные пригодны для аналитики, где поля заполнены слабо и какие критичные атрибуты вообще спрятаны внутри названий сделок.
Сразу зафиксировали, какие дашборды и управленческие ответы нужны бизнесу, чтобы новая CRM не повторила судьбу старой.
Стратегия миграции
Когда в системе больше десяти тысяч записей, соблазн один: грузить всё, а потом разбираться. Но на практике это почти всегда означает перевезти мусор, дубли и старые управленческие ошибки в новую оболочку.
Вместо полной миграции старого архива мы начали с 50 активных сделок. Этого хватило, чтобы быстро протестировать структуру, проверить маппинг полей и увидеть, как новая модель живёт в реальности.
В amoCRM исторически осталось много воронок, но реально живых процессов было заметно меньше. Поэтому мы не тащили старую схему как святыню, а сводили её к рабочей структуре, которая отражает текущий бизнес, а не музей его прошлых состояний.
AI-слой
Перенос делал не оператор с бесконечными таблицами, а подготовленный OpenClaw-агент по имени Рафик. Но важен не сам факт ИИ, а то, что агент был встроен в контролируемый технический контур, а не запущен «на удачу».
Рафик работал с объектами данных обеих CRM напрямую, без кликанья в интерфейсах и без ручного копипаста между системами.
Подключение через MCP и доступ к GraphQL дали агенту возможность не только переносить записи, но и понимать модель Twenty глубже, чем при простом импорте CSV.
Сначала весь цикл был прогнан в тестовой среде: мы проверили логику маппинга, корректность структуры и отсутствие потерь, и только потом двинулись к реальным сделкам.
Нормализация данных
Старая CRM держалась на упрощённой модели: по сути там оставались только клиент, компания и сделка. Этого недостаточно, если вы хотите видеть продуктовую аналитику, узкие места процесса и адекватную картину по людям.
Пока продукт спрятан где-то внутри сделки, вы не видите нормальное распределение денег и нагрузки. После нормализации он стал отдельным объектом аналитики.
Там, где это было нужно, пришлось разлепить то, что раньше хранилось в одной куче. Это базовый шаг для нормальной CRM-модели, но его очень часто игнорируют.
Исторически в названия сделок было зашито сразу всё: продукт, компания, клиент, ответственный. Агент разобрал эти названия на составляющие и разложил сущности по правильным местам.
Часть логики была не проставлена или жила фрагментами. После пересборки стало понятно, где что должно лежать и как именно это отражается в аналитике.
Аналитика
Как только данные стали более чистыми и структура перестала врать, появилась нормальная почва для дашборда. И именно здесь CRM начинает приносить управленческую пользу, а не просто хранить карточки.
Стало видно, сколько сделок реально движется и на какие суммы, без полу-ручной сборки отчётов по кускам.
Появилась понятная картинка, где именно сделки висят и на каком участке процесса бизнес теряет темп.
После выделения продукта в отдельную сущность стало возможно нормально смотреть на сумму и объём сделок по продуктовому направлению.
Один из инсайтов был очень прикладной: почти 70% суммы зависало на этапе подготовки и отправки КП и технических характеристик. Это уже не мнение, а факт на дашборде.
Отдельная донастройка
Если параллельный процесс живёт внутри сделки без отдельной логики, аналитика быстро мутнеет. Поэтому апробации были отделены от сделок, чтобы перестать смешивать разные типы движения в одну строку отчёта.
После отделения стало видно, кто именно проводит апробации, по каким продуктам они идут и где возникают узкие места.
Сделка и апробация — не одно и то же. Когда это разделено на уровне сущностей, руководитель получает не «среднюю температуру», а понятную картину по каждому контуру.
Результат
На выходе появился не просто новый CRM-интерфейс, а более чистая операционная модель: с тестовой миграцией, лучшим качеством данных, понятной структурой сущностей и дашбордом, который показывает реальные узкие места в продажах.
Источник
Этот кейс собран на основе отдельной статьи про миграцию из amoCRM в Twenty. Если нужен первичный рассказ с деталями по аудиту, роли агента, нормализации и дашборду — открывайте исходный материал.
Кейсы
Кейс
Автономный контур синка транскриптов из Plaud в Notion с дедупликацией, миграцией структуры данных и рабочим UX.
Открыть →Кейс
Notion как центр управления задачами, где три ИИ-агента закрывают планирование, реализацию и проверку результата.
Открыть →Кейс
Контентный pipeline, где сырьё из Telegram, соцсетей и закладок превращается в черновики сайта через Notion-агента.
Открыть →Обычно проблема не в том, что «нужна другая CRM», а в том, что старая система слишком долго жила без правил, нормальной модели данных и внятной аналитики. Я могу помочь разобрать текущий контур, понять, что стоит переносить, а что лучше выкинуть, и собрать миграцию так, чтобы на выходе у вас появилась управляемая система, а не просто новый интерфейс.