Практика фитнес-клуба

Как запустить подарочные абонементы и сохранить порядок в оплатах

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

01

Сначала определите сам подарочный продукт

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

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

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

  • короткое название, понятное без консультации менеджера;
  • точный состав доступа и занятий;
  • цена и валюта оплаты;
  • срок членства после активации;
  • срок, до которого действует код.

02

Разделите покупателя, получателя и плательщика

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

При оформлении достаточно попросить имя получателя и необязательное пожелание. Телефон получателя лучше оставить необязательным: покупатель может не знать актуальный номер или предпочесть передать подарок лично. Сам код становится способом связать оплаченную операцию с человеком, который авторизовался в клубе. После активации система знает точный customer ID и выпускает абонемент в его карточке.

Сотруднику нужен ограниченный обзор. Он должен найти покупку по имени, тарифу, сумме, платежу и статусу. Исходный код и личное сообщение для этого не нужны. В ProGym staff API исключает оба поля, а клиентский API показывает секрет только в нужный момент. Такое разделение снижает риск случайного раскрытия и оставляет администратору достаточно данных для поддержки.

03

Сделайте путь покупки коротким и устойчивым к обрывам

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

Цена всегда приходит с сервера. Браузер передаёт идентификатор тарифа, а Taska Core сам читает опубликованный план и создаёт неизменяемый снимок. Это закрывает подмену суммы через инструменты разработчика и сохраняет корректную валюту. Платёж получает отдельное назначение membership gift, поэтому его можно отличить от обычной покупки абонемента, продления или товара бара.

Мобильная сеть способна пропасть сразу после нажатия. Покупатель повторит действие, если увидит пустой экран. Для защиты нужен idempotency key, который сохраняется на время попытки. Повтор с теми же параметрами возвращает исходную покупку. Повтор с изменённым тарифом или получателем получает conflict и требует нового осознанного действия. В результате одна оплата соответствует одному подарку даже при нескольких запросах.

  • серверный выбор цены;
  • один устойчивый ключ на одну попытку;
  • понятный экран ожидания оплаты;
  • возврат в кабинет после callback;
  • повторный запрос без второй операции.

04

Относитесь к коду как к денежному инструменту

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

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

Покупателю код показывается после подтверждённой оплаты. Если ответ потерялся, кабинет должен помочь безопасно выпустить новый. Ротация требует отдельного подтверждения, аннулирует старое значение и показывает новый секрет один раз. ProGym использует постоянный idempotency key для повтора ротации, поэтому потерянный сетевой ответ не приводит к цепочке новых кодов.

05

Активируйте подарок атомарно

Получатель входит через Telegram и вводит код в своём кабинете. Сервер проверяет организацию, успешную оплату, статус ready, срок применения и отсутствие предыдущего владельца. Затем в одной транзакции помечает подарок активированным, создаёт membership и записывает gift redemption в финансовый журнал. Если любой шаг падает, состояние остаётся прежним и код можно применить повторно после устранения ошибки.

Членство создаётся по снимку покупки. В нём есть название плана, срок, занятия, цена и валюта на дату оплаты. Свежая редакция каталога не влияет на подарок. Дата начала обычно совпадает с моментом активации, а дата окончания рассчитывается по сохранённому количеству дней. Для клуба с календарными тарифами правило можно расширить отдельной политикой, но оно должно быть известно покупателю до оплаты.

Повтор получателем возвращает уже созданное членство. Другой клиент с тем же кодом получает отказ, даже если успел отправить запрос одновременно. Блокировка строки и уникальные ограничения закрывают гонку. В истории остаются подарок, покупатель, получатель, платёж и membership, поэтому поддержка может объяснить результат без ручного редактирования базы.

  • одна транзакция для статуса, членства и ledger;
  • точный получатель из авторизованной сессии;
  • защита от конкурентной активации;
  • безопасный replay того же клиента;
  • неизменяемая связь с платежом.

06

Подготовьте поддержку и финансовую сверку

Операционный экран должен отвечать на простые вопросы: оплачен ли подарок, ждёт ли он активации, истёк ли срок, кто покупатель, как называется тариф и к какому платежу относится сумма. Фильтры по статусу и поиск сокращают время ответа. Коды и пожелания остаются в клиентском контуре. Сотрудник предлагает покупателю войти и выполнить перевыпуск самостоятельно.

Для бухгалтерии платёж подарка является отдельной операцией с назначением membership gift. Конкретная модель признания выручки зависит от учётной политики и законодательства клуба. Система должна как минимум сохранить сумму, валюту, дату, provider reference, статус оплаты и связь с последующей активацией. Эти поля позволяют сверить банк, кассу и членство, не сопоставляя операции по имени вручную.

Отмена до оплаты закрывает pending-операцию. Возврат после оплаты требует отдельного бизнес-процесса, особенно если подарок уже активирован и посещения начались. Правило клуба фиксирует допустимый срок, основание и согласование. История сохраняет исходную покупку и корректирующее действие. Удаление строки разрушает сверку и усложняет спор с клиентом.

07

Продвигайте подарок в правильные моменты

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

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

Для поискового спроса полезны отдельная продуктовая страница и практические материалы. Они должны описывать реальный процесс и ограничения. Schema.org SoftwareApplication подходит странице функции, Article подходит руководству, BreadcrumbList помогает структуре. Canonical, sitemap и внутренние ссылки связывают подарок с оплатами, CRM и абонементами. Обещания на странице сверяются с доступными функциями продукта.

  • сезонные кампании и дни рождения;
  • прямой переход к покупке;
  • UTM и источник продажи;
  • инструкция покупателю и получателю;
  • onboarding после активации.

08

Считайте воронку и качество процесса

Базовая воронка включает просмотр страницы, начало оформления, созданный платёж, успешную оплату, активацию и первый визит. Между оплатой и активацией может пройти несколько недель, поэтому события связываются устойчивым gift ID. Персональные идентификаторы и секреты не нужны в маркетинговом датасете. Достаточно тарифа, суммы, источника, дат, статуса и агрегированного времени до активации.

Руководителю полезны конверсия оформления в оплату, доля активированных подарков, медианное время до активации, выручка по тарифам, доля перевыпусков кода и первый визит после активации. Высокая доля перевыпусков укажет на слабую инструкцию. Большое число истёкших подарков потребует напоминаний или изменения периода. Низкий первый визит покажет проблему onboarding, хотя сама продажа уже состоялась.

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

09

Проведите приёмку до публичного запуска

Начните с тестовой покупки реального опубликованного тарифа. Проверьте сумму, валюту и снимок условий. Отправьте одинаковый запрос дважды и убедитесь, что gift и payment остались в единственном экземпляре. Измените тариф в каталоге и подтвердите, что ранее купленный подарок сохранил старую цену, срок и занятия.

Получите код, выполните перевыпуск и попробуйте применить старое значение. Затем активируйте новый код получателем, повторите команду тем же профилем и отправьте её из другого профиля. Ожидаемый результат: один membership, безопасный replay владельца и отказ постороннему клиенту. Проверьте истечение срока на тестовой записи и отсутствие скрытого выпуска членства до активации.

Откройте staff-реестр и найдите операцию по покупателю, получателю, тарифу и статусу. В сетевом ответе не должно быть кода, хеша, ciphertext или личного пожелания. Проверьте мобильный интерфейс на ширине 390 пикселей, клавиатурный фокус, подписи полей, сообщения ошибок и три языка. Завершите сверкой payment, gift, membership и ledger. После такого прогона клуб может включать кампанию и измерять реальные продажи.

  • покупка, replay и conflict;
  • оплата и неизменяемый снимок;
  • ротация и отказ старого кода;
  • активация, повтор и защита от кражи;
  • staff privacy, mobile UX и локализация;
  • финансовая связь всех операций.

Демонстрация

Проверьте сценарии на примере своего клуба

Подготовим роли, филиал, расписание и путь клиента. Покажем работающие функции в системе.

Покажем CRM, расписание, кассу, СКУД и приложения на сценарии вашего клуба.