CRM для учебного центра: заявка, оплата, удержание

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

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

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

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

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

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

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

AI-слой здесь закрывает именно рутину первого контакта. AI-чат-бот отвечает на вопросы о расписании, стоимости, адресе и возрасте групп круглосуточно — по вашим документам, а не по общим представлениям о курсах, — и сам предлагает слот на пробное. Нестандартный вопрос («у ребёнка особенности, подойдёт ли группа») он передаёт администратору вместе с историей диалога: человек остаётся в контуре, и именно он принимает решения. Для первой воронки мы обычно делаем связку из внедрения Битрикс24 или другой CRM, подключения каналов и AI для продаж на первичных ответах и дожиме.

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

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

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

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

Основная ежедневная рутина учебного центра — не продажи, а расписание и его изменения. Группа, время, аудитория, преподаватель, перенос, замена, отмена из-за погоды или карантина. Каждое изменение нужно донести до двух разных аудиторий — учеников и плательщиков, — и именно здесь чаще всего горит администратор: он вручную пишет в десять чатов и кому-то неизбежно не напишет. Автоматизация тут скучная и очень окупаемая: расписание групп живёт в одном месте, а сообщение о переносе уходит по составу группы в тот канал, которым человек пользуется.

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

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

LMS и CRM решают разные задачи, и попытка заменить одну другой заканчивается одинаково плохо. LMS — платформа обучения (от learning management system): уроки, материалы, домашние задания, тесты, прогресс по программе, доступ к записям. CRM — система про клиента и деньги: заявка, сделка, оплата, история общения, задачи сотрудников. Платформа обучения не ведёт продажи и не напоминает про оплату, CRM не хранит уроки и не проверяет домашние задания. Если вы онлайн-школа, у вас с большой вероятностью будут обе системы — и это нормально.

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

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

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

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

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

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

Третье — честная оговорка. Состав согласий, требования к договору, лицензионные требования к образовательной деятельности и правила получения налогового вычета меняются и в разных форматах (лицензированный центр, ИП без лицензии, онлайн-курсы) применяются по-разному. Конкретику сверяйте с юристом и действующей редакцией нормативных актов. Наша часть работы — чтобы процесс и CRM умели собирать нужные согласия, документы и журнал доступа, а не чтобы текст статьи заменял правовую консультацию. Чек-лист по клиентской базе и 152-ФЗ мы подробно разбирали в отдельной статье журнала: там про согласия, хранение данных на серверах в РФ и права доступа.

Начните с четырёх вопросов. Сколько заявок пришло в прошлом месяце и из каких каналов? Сколько было записей на пробное и какая доля дошла до оплаты? У кого сейчас лежит отметка о посещаемости и в какой день она появляется в системе? Кто и когда напоминает об оплате следующего модуля? Если на два из четырёх вопросов нет уверенного ответа, проблема не в выборе платформы, а в том, что воронки не оформлены.

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

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

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