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