01
Рабочий день клуба в ProGym
Утром администратор открывает кассовую смену и видит занятия, пробные визиты, долги и незавершённые обращения. Менеджер получает новые заявки с сайта и рекламных каналов. Тренер открывает Telegram-авторизацию и видит свои группы. Руководитель контролирует выручку, посещаемость и план продаж по филиалам.
Во время дня клиент записывается в приложении, оплачивает абонемент, открывает QR-пропуск и получает уведомления. Каждое действие меняет общий контекст сразу после подтверждения сервером. Вечером смена закрывается со сверкой, тренировки имеют фактическую посещаемость, а задачи по лидам и продлениям остаются у ответственных.
- CRM и пробные занятия;
- абонементы, касса и склад;
- расписание и Trainer App;
- СКУД, QR и ресепшен;
- аналитика, удержание и NPS.
02
Локальные интеграции Узбекистана
ProGym поддерживает UZS, часовой пояс Asia/Tashkent и интерфейсы на русском, узбекском и английском. Платёжный контур подготовлен для Click и Payme, электронные документы для Didox и процесса E-IMZO. Конкретные ключи и юридические реквизиты подключаются при onboarding клуба.
Telegram используется для авторизации сотрудников, тренеров и клиентов, а также для уведомлений и глубоких ссылок. Webhook проверяет секрет и подпись, сессия хранится в защищённой HttpOnly cookie. Роли и организация проверяются на backend при каждом действии.
03
Фитнес, wellness и клиентский сервис
Тренер проводит фитнес-тестирование по версионному шаблону, назначает программу и фиксирует фактическое выполнение. Клиент видит план, цели, результаты и привычки в своём кабинете. Чувствительные wellness-данные доступны по согласию и отдельным правам.
Клуб может запускать соревнования, challenges, реферальную программу, loyalty points, новости, VOD и community-каналы. Обращения клиента и NPS собираются в поддержку. Автоматизации удержания используют понятные сегменты и журнал отправок.
- фитнес-тесты и тренировочные планы;
- питание, привычки и wearable connections;
- лояльность, referrals и challenges;
- соревнования и результаты;
- поддержка, NPS и уведомления.
04
Переход с таблиц или другой CRM
Миграция начинается с выгрузки клиентов, абонементов, долгов, расписания и справочников. Повторяемый import batch проверяет формат, показывает ошибки и сохраняет соответствие исходных идентификаторов. Тестовый запуск можно повторить после исправления данных без создания дублей.
Пилот ограничивается одним филиалом и согласованным набором сценариев. Команда клуба проходит их от начала до конца: лид, продажа, вход, тренировка, закрытие смены, отчёт и продление. После приёмки подключаются остальные филиалы, оборудование и provider credentials.
05
Критерии запуска первого филиала
До старта клуб утверждает владельца внедрения, список сотрудников, роли, справочник услуг, правила абонементов и источник исходных данных. Для каждого внешнего подключения назначается ответственный: платежи, OFD, Didox, СКУД, домен, Telegram bot и мобильные store accounts. Такой реестр позволяет отделить готовность продукта от ожидания ключей или оборудования.
Приёмка проходит по рабочим ролям. Менеджер создаёт и конвертирует лид, администратор продаёт абонемент и закрывает смену, тренер отмечает группу, клиент записывается и открывает QR, бухгалтер проверяет документ, руководитель сверяет отчёт с операциями. Отрицательные проверки подтверждают ограничения между ролями и филиалами.
На дату запуска фиксируются резервная копия, план rollback, канал поддержки и показатели первых семи дней. Команда наблюдает ошибки импорта, неопознанные проходы, расхождения кассы, доставку уведомлений и скорость ответов. Изменения правил выполняются через согласованный configuration flow, чтобы локальная правка одного клуба не влияла на Taska Core и другие продукты платформы.
Решение о расширении пилота принимается по журналу сценариев и цифрам. Успешный вход подтверждается событием контроллера, оплата связана с продажей, остаток товара сходится, посещение попадает в группу, а итоговая выручка раскрывается до операций. Такая проверка даёт владельцу клуба понятное основание для запуска сети.
Отдельно проверяются уведомления, фоновые очереди и повторные запросы. Временная ошибка provider остаётся видимым статусом и не превращается в фиктивно успешную оплату, подпись или проход. Ответственный сотрудник получает причину и безопасный способ повторить операцию.
- владелец внедрения и матрица ролей;
- подписанный набор приёмочных сценариев;
- реестр внешних credentials и оборудования;
- backup, rollback и канал инцидентов;
- контроль метрик после запуска.