Уменьшили потерянные обращения до 1–3%
До начала работы с нами потери составляли 10–15%.
В этом кейсе показываем:
- как разделить первичные продажи и продления, чтобы они не искажали друг друга;
- как хранить семью, ребёнка, филиал, тренера, документы и начисления без постоянного дублирования;
- как связать Bitrix24, amoCRM и ZERO и подготовить контролируемую миграцию большой базы.
В сети школ художественной гимнастики CRM не заканчивается после продажи первого абонемента. После сделки начинается основной цикл работы: ребёнок закрепляется за филиалом, группой и тренером, появляются начисления, оплаты, посещения, документы, задолженность и следующие продления.
Проблема проекта была не в отсутствии CRM. Продажи уже велись в amoCRM, операционный учёт учеников — в ZERO. Но системы жили отдельно, первичные продажи и продления смешивались, а простой перенос старой базы в Bitrix24 сохранил бы старую логику вместе с её ограничениями.
Поэтому проект начали не с импорта, а с новой модели данных и процессов.
Отрасльсеть школ художественной гимнастики
Масштаб14 филиалов
Исходная CRMamoCRM
Целевая CRMBitrix24
Учётная системаZERO
Объём базы4 300+ сделок к переносу
Точка А - с чего всё начиналось
У клиента уже была работающая CRM, поэтому внешне задача могла выглядеть как обычная миграция. Но данные клиента были распределены между несколькими системами, а сущности CRM не соответствовали реальному устройству бизнеса.
- лиды и продажи находились в amoCRM;
- ученики, группы, тренеры, посещения, начисления и оплаты - в ZERO;
- первичная продажа и работа с действующим учеником существовали в одной общей логике;
- данные ребёнка приходилось повторно использовать в разных сделках;
- для сети из 14 филиалов требовалась отдельная оргструктура, права и контроль по подразделениям;
- массовый перенос старой базы без новой архитектуры создавал риск дублей и переноса старых проблем в новый портал.
Почему нельзя было решить задачу «в лоб»
Самый очевидный вариант - выгрузить сделки из amoCRM и загрузить их в Bitrix24. Мы от него отказались как от основного сценария.
Причина: старая карточка сделки не должна была становиться постоянной карточкой ученика. В новом контуре нужно было отдельно хранить семью, ребёнка, продажу, продление и начисления. Только после этого имело смысл проектировать миграцию.
Как строили решение
Этап 1. Разделили первичную продажу и продление
Проблема / контекст. Новый клиент и действующий ученик проходят принципиально разные циклы, но в старой структуре эти процессы пересекались.
Что сделали. Спроектировали отдельную воронку первичной продажи и отдельную воронку продления. Для продлений предусмотрели статусы начисления, оплаты, долга, отпуска и отчисления.
Что изменилось. Менеджер видит, где находится новый лид, а администратор - что происходит с действующим учеником. Конверсии новых продаж и удержание можно анализировать отдельно.
Этап 2. Перестроили модель данных вокруг семьи и ребёнка
Проблема / контекст. Если хранить постоянные данные ребёнка внутри каждой сделки, при каждом новом абонементе появляются повторы и расхождения.
Что сделали. Разделили сущности: компания - семья/родитель, контакт - ребёнок, сделка - конкретная продажа или продление. Постоянные данные ребёнка вынесли в карточку контакта: ИИН, дата рождения, филиал, группа, тренер, документы и сроки их действия.
Что изменилось. Ребёнок существует в CRM один раз, а сделки и продления создаются вокруг него. История не разрывается между абонементами.
Этап 3. Спроектировали связь ZERO → Bitrix24
Проблема / контекст. Операционные данные продолжают формироваться в ZERO, поэтому отказ от учётной системы привёл бы к двойному вводу или потере функциональности.
Что сделали. Разделили ответственность систем. В ZERO остаются группы, тренеры, посещения, начисления, оплаты и задолженность. Bitrix24 отвечает за продажи, задачи, коммуникации и CRM-контроль. Для синхронизации предусмотрели API и идентификацию ученика по ИИН.
Что изменилось. CRM и операционный учёт перестают конкурировать друг с другом: каждая система отвечает за свой контур, а данные связываются по понятным правилам.
ZEROAPIBitrix24
ZERO
Группы, тренеры, посещения, начисления, оплаты, задолженность
Bitrix24
Продажи, задачи, коммуникации, CRM-контроль
Идентификация ученика по ИИН
Этап 4. Добавили отдельную работу с действующими учениками
Проблема / контекст. После первой оплаты клиент не должен исчезать из поля зрения отдела, основная ценность возникает на удержании и продлениях.
Что сделали. Спроектировали отдельный процесс статуса ученика и сценарии касаний: после начала занятий, через несколько недель, в конце месяца и на более длинных интервалах. Предусмотрели работу со статусом риска ухода.
Что изменилось. CRM начинает сопровождать клиента после продажи, а не только фиксировать факт первого абонемента.
Этап 5. Проверили структуру на тестовой миграции
Проблема / контекст. Массовая миграция более 4 300 сделок без проверки соответствия полей могла создать тысячи неверных карточек.
Что сделали. Сначала провели тестовый перенос ограниченной выборки и проверили воронки, пользовательские поля, данные ребёнка, ИИН, филиал, тренера, источники, оплаты и даты.
Что изменилось. Массовый перенос можно выполнять по проверенной схеме, а ошибки ловить до загрузки всей базы.
Что сознательно не делали (что изменили по ходу проекта)
- не переносили старую amoCRM «как есть» в Bitrix24;
- не пытались превратить Bitrix24 в замену ZERO там, где ZERO остаётся источником операционных данных;
- не объединяли первичную продажу и продление в одну универсальную воронку;
- не запускали массовую миграцию до проверки тестовой выборки.
Точка Б - к чему пришли
Итог проекта - не просто новый портал Bitrix24, а целевая модель работы сети, в которой понятно, где живёт каждый тип данных и какой процесс запускается после каждого события.
ТОЧКА А / ДОТОЧКА Б / ПОСЛЕ
Первичные продажи и продления пересекаются
Два самостоятельных бизнес-процесса
Данные ребёнка повторяются в сделках
Одна постоянная карточка ребёнка
Продажи и операционный учёт живут раздельно без общей модели
Определена роль Bitrix24 и ZERO и схема синхронизации
Риск дублей при переносе
Идентификация ученика и тестовая миграция
CRM заканчивается после первой продажи
Есть контур действующих учеников, касаний и риска ухода
Подтверждённый опыт и факты проекта
14
филиалов в оргструктуре проекта
4 300+
сделок в исходной базе, которую готовят к контролируемой миграции
3
системы в общей архитектуре: amoCRM, Bitrix24 и ZERO
Карточка ученика
настроены поля и карточка ученика; проектируются связи, автоматизации и миграция
Результат
Почему решение работает
- архитектура строится вокруг реальных сущностей бизнеса, а не вокруг стандартной карточки сделки;
- каждый тип данных имеет понятный источник истины;
- продажа и удержание считаются отдельно;
- миграция происходит после проектирования целевой модели, а не до неё.
Что можно развивать дальше
- завершить массовую миграцию и сверку данных;
- добавить автоматическую синхронизацию оплат, задолженности и посещений;
- расширить аналитику по филиалам, тренерам, продажам и удержанию;
- добавить дополнительные сценарии работы с риском ухода и просроченными документами.
Результат
Важно. Цифры ниже - модельные ориентиры для макета, а не подтверждённые результаты клиента. На публичной странице их нужно заменить замерами или явно подписать как целевой эффект.
1–3%
Уменьшили потерянные обращения до 1–3%
До начала работы с нами потери составляли 10–15%.
<5%
Сократили долю заявок без следующего действия до 5%
До начала работы с нами без следующего действия оставались 20–30% заявок.
Автоматизированы
Автоматизировали касания и задачи по продлениям абонементов
До начала работы с нами продления контролировались вручную.
Единый дашборд
Создали единый дашборд по филиалам, автоматизировав всю сводку в единое окно
До начала работы с нами сводка по филиалам собиралась вручную.
Итог
Для сети спортивных школ CRM должна связывать не только лид и менеджера, но и всю дальнейшую жизнь ученика. Поэтому ключевым решением проекта стала не миграция сама по себе, а новая модель бизнеса внутри CRM.
