01
Начните с процессов клуба, а не списка красивых функций
Перед сравнением систем опишите один обычный день. Откуда приходит заявка, кто связывается с клиентом, как назначается пробное занятие, где продаётся абонемент, кто открывает проход, как тренер отмечает группу и как закрывается кассовая смена. Этот маршрут быстро показывает, связаны ли модули между собой.
Отдельно выпишите исключения: заморозка, поздняя отмена, возврат, долг, потерянная карта, ребёнок с родителем, корпоративный плательщик, переполненная группа, замена тренера и пропавшая связь с контроллером. Именно исключения создают основную нагрузку на администратора и показывают зрелость продукта.
На демонстрации просите выполнить сценарий целиком под одной тестовой карточкой. После продажи статус клиента должен измениться, членство появиться в приложении, QR начать учитывать правила доступа, а оплата попасть в смену и отчёт. Раздельные демонстрационные экраны дают мало информации о согласованности данных.
- лид и пробное занятие;
- продажа, оплата и фискальный документ;
- вход, визит и посещение тренировки;
- отмена, заморозка и возврат;
- продление и измеримая retention-кампания.
02
Проверьте клиентскую базу и модель членства
Карточка клиента должна показывать актуальное состояние и объяснять его. Спросите, где видна история абонементов, посещений, оплат, записей, обращений и согласий. Проверьте поиск по телефону и имени, создание дубля и последующее объединение. Узнайте, как система различает лида, действующего члена и бывшего члена клуба.
Баланс абонемента лучше хранить как журнал движений, а не одно редактируемое число. Тогда можно понять, почему осталось восемь занятий, кто сделал корректировку и какое правило сработало при отмене. Такой подход особенно важен для возвратов, спорных ситуаций и финансовой сверки.
Для детских секций проверьте отдельные профили ребёнка и родителя. Для корпоративного фитнеса нужны договор, roster сотрудников, лимиты и координатор компании. Простое поле с именем родителя не даёт безопасного доступа к нескольким детям и корректного разделения участника и плательщика.
03
Оцените расписание на реальном конфликте
Создайте повторяющееся групповое занятие, назначьте тренера и зал, затем попробуйте поставить пересекающуюся тренировку. Система должна предупредить о конфликте до публикации. Измените одно событие серии, отмените будущее занятие и проверьте уведомления записанных клиентов.
Заполните группу до лимита и добавьте клиента в лист ожидания. После отмены одного участника проверьте, как освобождённое место предлагается следующему человеку. Повторите запрос записи дважды: зрелый API сохранит одно бронирование. Проверьте позднюю отмену и возврат занятия в баланс.
Тренерское приложение должно показывать только назначенные занятия и допустимые данные участников. Попросите отметить всю группу, затем исправить одного участника. В истории должны сохраниться автор и время. Эти детали влияют на зарплату тренера, безопасность клиента и достоверность отчёта.
04
Разберите СКУД как бизнес-процесс и как оборудование
Надпись об интеграции со СКУД ещё не гарантирует рабочий проход. Уточните поддерживаемые контроллеры, способ связи, время ответа, offline-режим и повторную доставку событий. Попросите показать причины отказа: просроченный абонемент, неверная зона, повторный вход, закрытый временной интервал и отозванный QR.
Короткоживущий QR безопаснее постоянной картинки. Сервер должен уметь отозвать доступ, а контроллер иметь отдельный secret и журнал здоровья. При потере сети нужен ограниченный offline-набор правил с версией и сроком. После восстановления события должны загрузиться без дублей.
Физическое оборудование всегда проходит отдельную приёмку. Запланируйте стенд с реальным турникетом и сценариями входа, выхода, повторного скана, потери связи и аварийного ручного доступа. До такой проверки честный поставщик обозначает интеграцию как готовую программно и ожидающую FIELD-тест.
05
Проверьте деньги, склад и электронные документы
Откройте смену, продайте абонемент и товар бара одной корзиной, разделите оплату и выполните возврат. Убедитесь, что продажа, платёж, движение товара и членство имеют связанные идентификаторы. Повторный webhook платёжной системы не должен создавать вторую оплату.
Для Узбекистана проверьте UZS, Click, Payme, выбранный OFD, Didox и процесс электронной подписи. Хорошая интеграция создаёт черновик документа после подходящего события, а бухгалтер подтверждает и подписывает его. Автоматическая отправка без контроля уполномоченного сотрудника создаёт юридический риск.
Склад клуба должен различать поставку, продажу, списание, резерв и инвентаризацию. Оборудование лучше вести отдельно от товаров бара: у тренажёра есть дефект, план обслуживания, work order и запасные части. Смешивание этих задач в одном остатке затрудняет эксплуатацию.
06
Посмотрите клиентское и тренерское приложение
Проверьте авторизацию, расписание, запись, отмену, оплату, QR-пропуск, уведомления и смену семейного профиля. Клиентское приложение должно получать данные через ограниченный self-service API. Попытка открыть чужой booking или расширить разрешённый URL обязана завершаться безопасным отказом.
White-label приложение требует больше, чем замену иконки. Нужны bundle identifiers, branding profile, privacy links, push credentials, signing, Android и iOS build, staged release, история статусов и rollback. Узнайте, кто владеет аккаунтами магазинов и как клуб получает сборку после обновления платформы.
Тренер работает с другим набором прав. Его интерфейс должен быть быстрым на телефоне, иметь крупные touch targets и не раскрывать кассу, полную CRM или данные других тренеров. Авторизация через Telegram удобна, если backend дополнительно проверяет membership, роль, tenant и состояние сессии.
07
Потребуйте доказательства безопасности и изоляции клубов
У SaaS для нескольких клубов каждое чтение и изменение должно учитывать tenant и organization. Одного фильтра во фронтенде недостаточно. Спросите про Row Level Security, scoped ORM, защиту сырого SQL, роли, branch scope, аудит, CSRF, подписи webhook и хранение секретов.
Проверьте действия отрицательными тестами. Менеджер одного филиала не должен видеть другой филиал, тренер не должен открыть чужую группу, клиент не должен получить чужую запись, а неизвестный BFF-маршрут должен закрываться. Система должна безопасно отказывать при отсутствии upstream, а не показывать фиктивный успех.
Уточните backup, PITR и восстановление. Наличие дампа не доказывает возможность восстановления. Нужен регулярный drill в одноразовой базе, проверка checksum, запуск физической копии, контроль WAL и метрика последнего успешного теста. Для обновлений нужен понятный rollback приложения и совместимые миграции.
08
Согласуйте аналитику до импорта данных
Определите показатели и их формулы: лид, пробное, продажа, активный член, посещение, выручка, возврат, долг, загрузка, retention и churn. Уточните часовой пояс, валюту, момент признания оплаты и правила филиала. Иначе два отчёта будут показывать разные цифры при технически правильных запросах.
Для marketing attribution сохраните UTM, источник, рекламную кампанию и связь с первой продажей. Для удержания нужны объяснимые сегменты и журнал запусков. Экспорт должен соблюдать те же права, что и экран, и фиксировать автора выгрузки.
Проверьте drill-down от итоговой цифры к исходным операциям. Руководителю важно увидеть, из каких продаж сложилась выручка и почему клиент попал в churn-сегмент. График без возможности проверки быстро перестаёт вызывать доверие у команды.
09
Оцените поддержку, API и управление изменениями
Уточните, кто отвечает за onboarding, импорт, обучение и инциденты. Попросите показать журнал состояния интеграций и способ сообщить номер проблемной операции. Поддержке нужны tenant, request ID и безопасный диагностический контекст, а не пароль сотрудника или полный экспорт клиентской базы.
Если клуб планирует собственный сайт, приложение или BI, изучите API до покупки. Должны быть документированы аутентификация, tenant context, pagination, idempotency, rate limits, webhook signatures и версии контрактов. Отдельный service account получает минимальные permissions и может быть отозван без смены паролей сотрудников.
Спросите, как обновляется платформа. Зрелая архитектура включает product manifest, module gates, additive migrations и проверку совместимости с соседними продуктами. Новая фитнес-функция должна включаться для ProGym и не менять поведение ресторанного, клинического или marketplace-продукта на том же ядре.
Проверьте release process мобильных приложений и интеграций. Нужны staging, production credentials, история версий, управляемый rollout и понятный rollback. Секреты не должны попадать в build или интерфейс администратора. После ротации ключа старый доступ прекращается, а событие фиксируется в аудите.
Согласуйте время реакции по уровням инцидента и резервный рабочий процесс клуба. При временной недоступности online payment продажа не должна считаться оплаченной. При потере связи со СКУД действует заранее утверждённая offline-политика. При ошибке внешнего EDO документ остаётся в проверяемом статусе, бухгалтер видит причину и может повторить действие.
Попросите доступ к тестовому контуру и выполните обновление роли, отзыв сессии и ротацию device secret. После каждого действия проверьте фактический результат и audit log. Такая короткая проверка показывает, насколько операционная команда сможет управлять системой после запуска без прямого вмешательства разработчика.
Обратите внимание на экспорт и удаление данных. Экспорт клиента должен собирать разрешённую историю в машиночитаемом формате, а запрос на удаление проходить управляемый workflow с учётом юридического хранения финансовых документов. Массовая выгрузка сотрудников или клиентов требует отдельного права и записи автора действия.
Наконец, попросите показать мониторинг. Полезны метрики доступности, p95, error rate, доставка очередей, свежесть backup и последний restore drill. Один зелёный health endpoint не подтверждает здоровье tenant database, provider или фоновой очереди. Наблюдаемость должна приводить к конкретному ответственному и runbook.
- канал поддержки и уровни критичности;
- API contract и webhook policy;
- история релизов и совместимость миграций;
- ротация секретов и audit trail;
- безопасная деградация внешних providers.
10
Проведите пилот с критериями приёмки
Выберите один филиал, реальных сотрудников и ограниченный период. Импортируйте клиентов, активные абонементы, долги, расписание и остатки. Сначала выполните dry run, исправьте ошибки и повторите импорт. Повторный запуск не должен создавать дублей.
Составьте таблицу сценариев с ожидаемым результатом и ответственным. Включите продажи, расписание, доступ, тренерскую отметку, закрытие смены, отчёт, возврат, семейный профиль и потерю связи с provider. Зафиксируйте внешние gates: ключи платежей, конкретный СКУД, электронную подпись и аккаунты магазинов.
Решение готово к запуску, когда сотрудники проходят рабочий день без параллельной таблицы, цифры сверяются с операциями, роли ограничивают данные, а восстановление и rollback имеют проверяемый процесс. Цена и список функций важны, но именно этот результат определяет качество внедрения.
- назначьте владельца пилота со стороны клуба;
- зафиксируйте исходные данные и правила миграции;
- проверьте позитивные и негативные сценарии;
- снимите performance и security evidence;
- подпишите критерии перехода в production.