Неделя клуба в одной сетке
Занятие знает свою продолжительность, тренера, зону и предел мест. Занятость считается из уже существующих броней, а не проставляется руками.
- Занятость видна в самом слоте
- Запись заводится в пустом слоте
Обсудить задачу
Зарядка
Собрали спортивному клубу собственную CRM и связали её с онлайн-записью так, что бронь клиента сразу становится работой администратора
Процессы у клуба были налажены. Врозь лежали данные: записи в одном месте, расписание в другом, клиентская база отдельно.
- Заказчик
- Спортивный клуб
- Срок
- 7 месяцев
- Роль
- Анализ, проектирование, разработка, внедрение
За семь месяцев прошли путь от разбора процессов до работы системы на объекте
Проект начался не с макетов, а с вопроса, что происходит с записью после того, как клиент о ней попросил. Весь цикл закрывали сами: бизнес-анализ, проектирование, интерфейсы, фронтенд, серверную логику, интеграцию и внедрение на объекте.
- Клиент
- Спортивный клуб
- Отрасль
- Спорт и фитнес, B2B
- Тип проекта
- Собственная CRM и онлайн-бронирование
- Пользователи
- Администраторы, тренеры и клиенты клуба
- Стек
- Angular, C#, PostgreSQL
- Задел
- Архитектура под другие клубы
Записи были в одном месте, расписание — в другом, клиентская база — отдельно
Клиенты записывались по телефону и в сообщениях, администратор переносил информацию руками, а свободное время приходилось уточнять отдельно. Простой сценарий записи зависел от сотрудника на каждом шаге.
- Клиент записывается по телефону или в сообщениях
- Администратор переносит данные руками
- Расписание живёт отдельно от клиентской базы
- Свободное время уточняется вручную
Чем больше ручных действий, тем выше цена одной ошибки
Готовые CRM решали слишком много лишнего и слишком мало нужного
Мы изучили существующие отраслевые системы, включая решения для фитнес-клубов. Возможностей в них много, но небольшому клубу требовалась малая их часть, а важные сценарии всё равно пришлось бы подстраивать под структуру самой системы. Задача была не в том, чтобы внедрить ещё одну CRM, а в том, чтобы собрать систему вокруг реальной работы клуба.
- Менять привычные процессыРаботу, которая у клуба уже налажена, пришлось бы подгонять под структуру чужой системы.
- Усложнять работу сотрудниковАдминистратор осваивал бы модули, которые в небольшом клубе никто никогда не откроет.
- Мириться с чужим виджетомФорма записи на сайте настраивается ровно настолько, насколько это предусмотрел её разработчик.
- Платить за неиспользуемоеОтраслевые системы для фитнес-клубов продаются набором целиком, а не той частью, которая нужна.
Сначала разобрали, как клуб работает на самом деле
До проектирования интерфейсов мы прошли весь путь записи — от первого обращения клиента до фактического посещения занятия.
- Какие услуги предоставляет клуб
- Как формируется расписание
- Как работает администратор
- Как учитывается занятость тренеров
- Что происходит при переносе и отмене
- Какие данные нужно хранить о клиенте
- Чем отличаются типы занятий
- Где возникает ручная работа
Продукт разделили на две части, которые работают как единое целое
Администратору нужен полный контроль над расписанием, клиентами и записями. Клиенту — самый простой способ выбрать услугу и свободное время. Интерфейса поэтому два, а данные и бизнес-логика под ними общие: спорить о том, где лежит правда, им не приходится.
Одна модель данных
Внутренняя CRM для сотрудников и онлайн-бронирование для клиентов стоят на ней обе.- Клиенты
- Услуги
- Расписание
- Сотрудники
- Бронирования
- Переносы
- Отмены
- Статусы записей
Четыре экрана, на которых держится клуб
Расписание, клиентская база, правила абонементов и виджет записи. Первые три — рабочий контур сотрудника, четвёртый — то, что видит клиент; данные под ними общие.
Клиент, абонемент и запись в одной строке
Администратору не нужно собирать картину из трёх источников: срок действия, остаток посещений, статус оплаты и текущая запись стоят рядом.
- Остаток посещений и срок действия
- Статус оплаты у каждой строки
У каждого абонемента свои правила
Длительность, число посещений, цена, срок заморозки и ограничение по дням задаются отдельно. Универсального типа занятия в системе нет.
- Заморозка и ограничение по дням
- Онлайн-продажа включается поштучно
Клиент выбирает время сам
Тот же слот, что администратор видит в сетке, клиент видит в виджете — с остатком мест, тренером и ценой. Перед созданием брони доступность проверяется ещё раз.
- Свободные места без звонка
- Проверка перед подтверждением
Разные услуги нельзя было загнать в одну жёсткую модель
В спортивном клубе услуги отличаются сильнее, чем кажется. Мы не стали строить систему вокруг одного универсального типа занятия — параметры конкретной услуги задаются отдельно.
Продолжительность
Полуторачасовое посещение бассейна и часовая тренировка в зале живут в одной сетке и занимают в ней разное место.
Стоимость
Разовое посещение, абонемент на двенадцать занятий и безлимит на полгода — это три разных способа оплатить одно и то же занятие.
Вместимость
У дорожки бассейна, кабины сквоша и тренажёрного зала предел разный, и считается он от зоны, а не от занятия.
Логика записи
Часть занятий набирает группу до предела, часть занимает ресурс целиком одним клиентом.
Привязка к сотруднику
Занятие может требовать конкретного тренера, а может не требовать никого — и во втором случае занятость тренера в расчёт не идёт.
Доступное время
Окна работы, ограничения по дням недели и период действия абонемента вместе решают, какие слоты клиент вообще увидит.
Клиент видит только то время, на которое можно записаться
Если клиент видит слот, которого уже нет, онлайн-запись перестаёт выполнять свою функцию. Поэтому внешний виджет связан с внутренним расписанием напрямую, а не копией.
Выбирает услугу
Каталог клуба, а не общий список всего, что происходит на объекте.
Смотрит доступные даты
Свободное время приходит из того же расписания, в котором работает администратор.
Выбирает время
В слоте видно, сколько мест осталось, и кто ведёт занятие.
Оставляет контактные данные
Клиент попадает в общую базу один раз и дальше узнаётся по ней.
Подтверждает запись
Перед созданием брони система ещё раз проверяет доступность слота — два человека не могут занять одно и то же место.
Виджет и CRM работают не как два сервиса, а как одна система
До внедрения часть работы начиналась уже после обращения клиента: прочитать сообщение, уточнить свободное время, завести запись руками. Теперь администратор меняет расписание — и это сразу видно клиенту; клиент создаёт запись — и сотрудник сразу видит её в CRM. Именно двусторонняя связь делает онлайн-запись частью рабочего процесса, а не формой на сайте.
Клиент
Виджет записи на сайте клуба.
- Выбор услуги
- Свободные слоты
- Новая бронь
- Контакты
Общая модель
Расписание, услуги, клиенты и брони лежат в одном месте и связаны между собой.
Сотрудник
- Слот в расписании
- Карточка клиента
- Занятость тренера
- Статус и оплата
Клиентская запись и работа администратора перестали существовать порознь
Система была установлена на объекте и использовалась сотрудниками в операционной деятельности — с записями, переносами, изменениями расписания и работой с клиентами. Клуб при этом не перестраивал работу под систему: логику собирали вокруг процессов, которые у него уже были, а сущности отделили друг от друга с расчётом на другие клубы.
Что осталось у клуба
- Единая клиентская базаКлиент, его абонемент, остаток посещений и текущая запись лежат в одной строке.
- Расписание как рабочий инструментЗанятия создаются, переносятся и отменяются там же, где видна занятость.
- Онлайн-запись без посредникаКлиент бронирует сам, а бронь сразу становится записью в сетке администратора.
- Защита от двойного бронированияДоступность проверяется в момент подтверждения, а не в момент показа слота.
Нужна CRM, которая работает по логике вашего бизнеса?
Исследуем процессы, проектируем внутренние системы и связываем их с клиентскими сервисами. Разрабатываем CRM, кабинеты, расписания и бронирование под реальные сценарии компании — без лишней функциональности и без необходимости перестраивать работу сотрудников вокруг ограничений готового ПО.