Автоматизация фитнес-клуба: абонементы, продления, отток

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

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

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

Третий слой — AI-канал в мессенджере для типовых вопросов: расписание, свободные слоты, остаток занятий по абонементу, условия и лимит заморозки. Он снимает поток однотипных сообщений, которые сейчас идут на телефон администратора, но возвратом клиента не занимается. Разговор с тем, кто перестал ходить, — работа тренера или администратора, а не бота: массовая рассылка «мы вас потеряли» даёт обратный эффект. Человек остаётся в контуре, AI разгружает его от повторяющегося.

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

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

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

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

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

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

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

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

Результат фиксируется в трёх вариантах: вернулся, не вернулся с причиной, не дозвонились. Это скучная часть, но без неё контур не учится. Через месяц-два накопленные причины показывают, что в клубе действительно ломается: расписание групповых занятий, переполненность в вечерний час, конкретный тренер, цена продления, парковка. Причины оттока, собранные по единой формулировке, полезнее любого среднего показателя удержания, потому что по ним можно что-то изменить уже в следующий понедельник.

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

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

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

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

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

Собственнику не нужен отчёт «продано абонементов» — он не отвечает ни на один управленческий вопрос. Нужны показатели, которые показывают состояние базы и загрузку ресурсов, потому что именно они определяют выручку следующего квартала. Шесть отчётов ниже закрывают минимальный набор и собираются из тех же данных о визитах и продажах.

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

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

Честно про порядок работ: BI-слой не имеет смысла раньше учёта. Аналитика поверх неполных данных о посещениях даёт красивые графики с неверными выводами, а это хуже, чем отсутствие графиков вообще. Сначала фиксируем визиты, абонементы и заморозки в одном контуре, потом строим отчётность. Как правило, между этими этапами проходят недели, а не месяцы, но порядок менять нельзя.

Если у вас одна студия, расписание и абонементы уже ведутся в отраслевой системе клубного учёта — «1С:Фитнес клуб» или аналоге — и администратор не жалуется, отдельная CRM вам, скорее всего, не нужна. Мы исходим из презумпции в пользу того, что работает: замена живого инструмента на более общий почти всегда обходится дороже, чем кажется, и в деньгах, и в сопротивлении команды. Отраслевые сервисы делались именно под клубы, и журнал занятий, карты и контроль доступа в них закрыты по умолчанию.

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

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

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

Публичных кейсов именно по фитнес-клубам у нас нет — говорим об этом прямо. Но похожую механику абонементов и лояльности мы уже собирали в смежной отрасли услуг. Для сети из пяти банных комплексов в Санкт-Петербурге мы построили на коробочном Битрикс24 единый контур: «шахматку» бронирования кабинок как внутреннее приложение портала, рабочее место сотрудника с ролями (администратор комплекса, специалист, официант), POS-кассу кафе через REST API Битрикс24 и отдельный блок лояльности с выпуском сертификатов и абонементов. Решение работает в проде, мы ведём действующее сопровождение портала; клиент в публичной подаче анонимен.

Фитнес-клуб — не баня, и переносить выводы один в один мы не будем. Но техническая задача рядом: расписание ресурса, визит, абонемент, роль сотрудника и механика лояльности должны жить в одном контуре, а не в четырёх несвязанных сервисах, между которыми данные переносят руками. Именно эта часть — связка учёта визитов, абонементов и продаж внутри одной системы — у нас собрана и поддерживается в проде, а не существует в виде презентации.

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

Начните с короткого теста из трёх вопросов. Можете ли вы назвать, сколько клиентов из проданной базы приходили за последние 30 дней? Есть ли у вас список тех, кто пропал две недели назад, и ответственный сотрудник по каждому из них? Приходит ли клиенту напоминание о продлении раньше, чем за неделю до окончания карты? Три ответа «нет» означают, что вам не хватает не новой программы учёта, а контура удержания поверх учёта.

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

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