Все проекты01 / 04Сеть клубов с абонементами
Заявки, звонки, переписка и удержание в одной платформе поверх 1С
CRM · ЛидыКанбан по воронке: заявки из звонков, мессенджеров и сайта, у каждой — источник, клуб, приоритет, ответственный и непрочитанные сообщения.
Контекст
При масштабировании бизнеса сеть клубов столкнулась с нехваткой инструментов для оперативного управления клиентской базой и продажами. Мы разделили IT-ландшафт компании: 1С сохранила функцию бэкенда для финансового учёта, биллинга и контроля счетов. При этом весь операционный контур — работа с трафиком, обработка омниканальных заявок и контроль KPI сотрудников, отвечающих за коммуникацию, — был выведен на единую специализированную платформу.
Ограничения
- Потеря лидов на входеОбращения «провисали» между разрозненными каналами связи до того, как их брали в работу.
- Поздний сигнал об оттокеСистема не отслеживала снижение частоты визитов в моменте. О потерянных клиентах узнавали из закрытых отчётов за месяц, когда спасать сделку было уже поздно.
- Перегруженная системаИз-за глубокой внутренней кастомизации базовая корпоративная система стала слишком перегруженной для линейного персонала. Неинтуитивный интерфейс замедлял обработку заявок и критически увеличивал время на обучение новых сотрудников (time-to-productivity).
Как было
Каждый шаг выполнялся, но между шагами заявка ждала, пока её перенесут вручную. Ответственный появлялся только после записи в 1С, а паузу в посещениях замечали по итогам месяца.
Гипотеза
Если звонки, сообщения и заявки с сайта собраны в одной воронке с ответственным и датой следующего контакта, а тренер видит, кто выпал из своего ритма посещений, обращение чаще доходит до оплаты, а клиент возвращается раньше. 1С при этом остаётся учётной системой.
Модель операции
Этапы заявки повторяют путь человека до оплаты, после оплаты платформа следит за ритмом посещений. Обычный интервал клиента считается по его визитам за 120 дней; если пауза дольше двух интервалов и дольше трёх недель, но не больше 90 дней, клиент попадает в очередь тренера с причиной и следующим касанием.
Интерфейс
Рабочие места администратора и тренера
Канбан по воронке: заявки из звонков, мессенджеров и сайта, у каждой — источник, клуб, приоритет, ответственный и непрочитанные сообщения.
- 1Не взятая заявка отмечена красной точкой, фильтр «Не взятые» считает такие
- 2Удержание заявки за отделом продаж с таймером
- 3Канал и клуб на каждой карточке
- 4Ассистент видит открытый экран и отвечает по нему
Слева всё о человеке и заявке, справа переписка из мессенджеров; этапы полосой, передача сотруднику, в другой клуб или в 1С — в шапке.
- 1Метки под именем: этап, клуб, канал, приоритет, кто ведёт
- 2Передать сотруднику или в клуб, передать в 1С
- 3Звонки по клиенту из телефонии
- 4Переписка рядом с карточкой
Очередь удержания: кому звонить и почему, ценность клиента, что предложить и чем закончилось касание.
- 1Четыре состояния очереди: обработать, ждём, вернулись, не вернулись
- 2Причина, почему клиент в очереди
- 3Ценность клиента и предложение под причину
- 4Звонок и мессенджер в одно касание
Тренер видит на телефоне своих клиентов, выпавших из ритма, и отмечает причину одним касанием; вкладки — под большим пальцем.
Галерея проекта: экраны и крупные фрагменты
Экраны собраны на тестовых данных, без данных и бренда клиента. Нажатие открывает экран крупно.
Спецификация для технической команды
По коду рабочей платформы. Данные, доступы и бренд клиента в публичную копию не переносятся.
- Интерфейс
- React 19, TypeScript, Tailwind 4. Веб-приложение с манифестом и сервис-воркером, пуш-уведомления.
- API
- Единый слой запросов к серверу на /api/*, сессия в cookie, 112 методов: обращения, клиенты, визиты, удержание, кабинет специалиста, администрирование.
- Данные
- Сотрудники и роли, клиенты и их события, обращения, звонки, диалоги, визиты, причины потерь, касания удержания, задачи, уведомления, журналы вебхуков.
- Интеграции
- Учётная система через API и обмен файлами, телефония, агрегатор мессенджеров, вебхуки сайта, облачное хранилище медиа, вход через внешний аккаунт, внешняя языковая модель для ИИ-агента.
- Роли
- Администратор БД, руководитель, финансовый директор, управляющий клуба, маркетинг, отдел продаж, администратор клуба, тренер. Права настраиваются по матрице: разделы, данные и действия для каждой роли, у тренера — свой кабинет.
- Экраны
- 36 экранов в 11 разделах меню: заявки, клиенты, переписка, звонки, продажи, посещения, RFM, кабинет тренера, аналитика, команда, интеграции.
- Интерфейс тренера
- На телефоне экраны кабинета — вкладками внизу, остальное — в «Ещё»; приложение ставится на главный экран, пуш-уведомления приходят сразу.
- Доступ
- Экраны и действия по ролям. Ключи и доступы лежат в хранилище секретов облака, в коде их нет.
- Учёт
- Продажи и движения счёта остаются в учётной системе, рабочий слой читает их через интеграцию.
Что изменилось в работе операции
Изменения описаны качественно. Значения публикуются после согласования с клиентом.
- 01Одна воронкаЗвонки, сообщения и заявки с сайта попадают в одну воронку, у каждой заявки есть ответственный и дата следующего контакта.
- 021С на местеЗаявка переносится в 1С через поиск клиента, абонементы и продажи остаются в учётной системе.
- 03Ритм посещенийТренер видит, кто выпал из своего обычного ритма, отмечает причину одним касанием и возвращается к клиенту в срок.
Показатели
- Доля обращений, дошедших до визитаотслеживается
- Время до первого ответаотслеживается
- Возвраты регулярных клиентовотслеживается
- Причины потерь по каналамотслеживается