Кейс · CRM и системная интеграция

CRM для сети школ художественной гимнастики

Как связать филиалы, родителей, детей, первичные продажи, продления и учёт учеников в одной архитектуре CRM.

Продажи уже велись в amoCRM, а операционный учёт — в ZERO. Вместо переноса старой структуры в Bitrix24 проект начали с новой модели данных и процессов.

Разобрать CRM вашей школы Смотреть решение

aamoCRMПервичные продажи · источник данных

ZZEROУченики · учёт · оплаты

B24Целевая архитектура

Bitrix24

Продажи, продления, карточка ребёнка и CRM-контроль

14 филиалов

4 300+ сделок

14филиалов

4 300+сделок в исходной базе

3системы в архитектуре

2отдельных процесса продаж

01 / О проекте

Не просто перенос данных.
Переосмысление CRM.

После продажи первого абонемента начинается основная работа с учеником: занятия, документы, начисления, оплаты и следующие продления.

Продажи отдельно от продлений

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

Единая история ребёнка

Семья, ребёнок, филиал, тренер, документы и сделки связываются без повторного создания постоянных данных.

Контролируемая миграция

Связать amoCRM, ZERO и Bitrix24, сначала проверив целевую структуру на ограниченной выборке.

ОтрасльСеть школ художественной гимнастики

Исходная CRMamoCRM

Целевая CRMBitrix24

Учётная системаZERO

02 / Точка А

Что мешало работать как единой сети

CRM уже существовала, но разделённые системы и сущности не отражали реальную структуру бизнеса.

Лиды и продажи жили в amoCRM, а группы, тренеры, посещения, начисления и оплаты — в ZERO.

Первичные продажи и действующие ученики пересекались в общей логике.

Постоянные данные ребёнка повторно использовались в разных сделках.

Для 14 филиалов требовались отдельная оргструктура, права и контроль по подразделениям.

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

Решение

Сначала спроектировать процессы и данные. Только потом переносить сделки.

Почему не перенесли amoCRM «как есть»?

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

03 / Архитектура решения

Пять этапов проектирования

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

Этап 01 / Процессы

Отдельные воронки для продажи и продления

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

Решение. Спроектировали самостоятельные воронки. Для продления предусмотрели начисление, оплату, долг, отпуск и отчисление.

Что меняетсяНовые продажи и удержание можно анализировать отдельно.

Схематичная визуализация воронок

Первичная продажа

Новый лид

В работе

Продажа

Продление

Начислено

Ожидает оплаты

Оплачено

Этап 02 / Модель данных

Постоянная карточка ребёнка вместо дублей

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

Решение. Компания — семья/родитель, контакт — ребёнок, сделка — продажа или продление. В контакт вынесли ИИН, дату рождения, филиал, группу, тренера и документы.

Что меняетсяОдин ребёнок — единая история и несколько связанных сделок.

Логическая модель сущностей

КомпанияСемья / родитель

↓

КонтактРебёнокИИН · группа · тренер · документы

↓

Первичная продажа

Продление

↓

Связанные данныеНачисления и оплаты

Этап 03 / Интеграция

ZERO и Bitrix24: разделённая ответственность

Проблема. Операционные сведения продолжают формироваться в ZERO. Их нельзя просто заменить CRM без потери функций.

Решение. ZERO остаётся источником учёта, Bitrix24 — инструментом продаж и контроля. Для связи предусмотрены API и сопоставление учеников по ИИН.

Что меняетсяУ каждого типа данных есть определённый источник.

Проектируемый обмен данными

ZEROГруппы · тренеры · посещения · начисления · оплаты · долг

APIИИН — ключ сопоставления

Bitrix24Продажи · задачи · коммуникации · CRM-контроль

Этап 04 / Удержание

Работа с учеником продолжается после оплаты

Проблема. После первого абонемента ученик не должен исчезать из процесса взаимодействия.

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

Что меняетсяCRM охватывает не только привлечение, но и сопровождение.

Плановый сценарий сопровождения

01Начало занятийПервое касание

02Через несколько недельКонтакт с семьёй

03Конец месяцаПодготовка к продлению

04Риск уходаОтдельный сценарий

Этап 05 / Миграция

Проверка данных перед массовым переносом

Проблема. Более 4 300 сделок нельзя переносить без проверки полей и связей.

Решение. Провели тестовый перенос ограниченной выборки, проверили воронки, ИИН, филиалы, тренеров, источники, оплаты и даты.

Что меняетсяОшибки можно обнаружить до массовой загрузки базы.

Пример структуры карты соответствия · без реальных данных

amoCRM · исходное полеBitrix24 · целевое поле

Данные ребёнкаКонтакт / ребёнок

ФилиалПоле филиала

ИИНИИН контакта

Сумма / датаПоля сделки

ИсточникИсточник сделки

04 / Границы проекта

Что сознательно не делали

Не копировали старую структуру amoCRM в Bitrix24 без пересмотра.

Не заменяли ZERO там, где он остаётся источником операционного учёта.

Не объединяли продажу и продление в универсальную воронку.

Не начинали массовую миграцию до проверки тестовой выборки.

05 / Точка Б

От разрозненных данных к понятной модели

Итог текущего этапа — целевая архитектура сети. Это не заявление о завершённой массовой миграции или работающих интеграциях.

Первичные продажи и продления пересекаютсяДва самостоятельных процесса

Данные ребёнка повторяются в сделкахОдна постоянная карточка ребёнка

Нет общей модели продаж и операционного учётаРоли Bitrix24 и ZERO определены

Риск дублей при миграцииСопоставление по ИИН и тестовый перенос

CRM заканчивается после первой продажиПредусмотрены касания, продления и работа с риском ухода

Подтверждённый объём и статус

Архитектура прежде масштабирования

В контуре проекта 14 филиалов и более 4 300 сделок в исходной базе. Настроены поля и карточка ученика. Связи, автоматизации и миграция находятся на стадии проектирования и подготовки.

14филиалов

4 300+сделок к переносу

3системы

Посмотреть модельные показатели для будущих замеров

Важно: это сценарные ориентиры из ТЗ, а не подтверждённые показатели клиента и не достигнутые результаты.

ПоказательМодель «до»Целевой ориентир

Потерянные обращения10–15%1–3%

Заявки без следующего действия20–30%Менее 5%

Контроль продленийПреимущественно вручнуюАвтоматизация основных касаний

Сводка по филиаламРучной сборЕдиный отчёт / дашборд

06 / Почему подход работает

Сначала модель.
Потом автоматизация.

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

Что можно развивать дальше

01Завершить массовую миграцию и сверку данных

02Автоматизировать синхронизацию оплат, долгов и посещений

03Расширить аналитику по филиалам, тренерам и удержанию

04Развить сценарии риска ухода и контроля документов

Обсудить ваш проект

CRM должна сопровождать ученика от первой заявки до продления

Разберём, как разложить вашу сеть на сущности, воронки и автоматизации: что должно жить в CRM, а что — в учётной системе.