Автоматизация бани: бронирование, лояльность, учёт

Автоматизировать в бане нужно не «запись», а весь путь гостя и операционку вокруг него. Гость бронирует кабинку на конкретное время, приходит, берёт услуги, что-то заказывает в кафе, платит и — если понравилось — возвращается по абонементу или дарит сертификат. Каждый шаг оставляет данные. Вопрос автоматизации ровно один: окажутся эти данные в одном месте или в пяти.

Типичная стартовая точка — разрозненность. Бронь ведётся в бумажном журнале или общей таблице, кафе бьёт чеки в отдельной кассе, смены считаются в третьем файле, а постоянные гости существуют только в памяти администратора. Пока комплекс один и загрузка ровная, это как-то работает. Как только объектов становится несколько, появляются двойные брони, споры о том, кто обслуживал гостя, и невозможность быстро ответить на вопрос «сколько сеть заработала вчера».

Так было и в проекте, о котором пойдёт речь: сеть из пяти банных комплексов в Санкт-Петербурге, где бронирование кабинок, обслуживание гостей, учёт персонала и продажи в кафе жили порознь. Задача звучала не как «поставить CRM», а как «собрать это в один контур с механикой лояльности». Ниже — блоки, из которых такой контур состоит.

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

Битрикс24 в этой схеме — не «CRM для продаж», а платформа: клиентская база, задачи, права доступа, портал, телефония и открытый REST API, через который к порталу подключается собственный код. Отраслевую специфику не выжимают из коробочных возможностей, а дописывают приложениями поверх. В кейсе сети банных комплексов сработал ещё один аргумент: Битрикс24 у клиента уже был и по нему велось сопровождение. Расширять действующий контур приложениями оказалось разумнее, чем ставить рядом вторую систему и потом синхронизировать две базы гостей.

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

«Шахматка» — это внутреннее приложение Битрикс24, в котором администратор видит занятость кабинок и ставит брони. Визуально это сетка: по одной оси — кабинки и комплексы, по другой — время. Свободный слот виден глазом, попытка наложить вторую бронь на занятую кабинку видна тоже — до того, как гость приедет и обнаружит, что его место занято.

Данные бронирования хранятся в собственной базе приложения, а не в сделках CRM. Это осознанное решение, а не обход ограничений. Сетка занятости — плотная таблица интервалов, к которой обращаются постоянно и сразу по нескольким объектам; собственная база даёт нужную структуру и скорость, а связь гостя, визита и денег остаётся в контуре портала. Технически приложение построено на Node.js и Fastify, данные лежат в PostgreSQL, кэш — в Redis, интерфейс администратора — на React.

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

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

Логика простая: сотрудник видит то, что нужно ему для смены, и не видит остального. Администратор бани работает с бронями и визитами своего комплекса. Специалист видит, кого и когда он обслуживает и какие услуги оказал. Официант работает с заказами кафе. Админ настраивает систему и смотрит картину по всем объектам сети.

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

Заказы кафе проходят через POS-кассу, работающую по Bitrix24 REST. Это принципиальный момент: касса не стоит «сбоку» отдельной системой, из которой в конце месяца выгружают итог, а обращается к порталу напрямую — по тому же API, на котором работает остальной контур. Кафе перестаёт быть отдельным бизнесом внутри бани.

Разница видна на простом сценарии. Гость парится в кабинке и заказывает чай и еду. Если касса автономна, официант пробивает заказ в своей системе, а связь заказа с визитом держится на памяти администратора и на бумажке. Если касса — часть контура, заказ относится к конкретному визиту, попадает в общий счёт и в историю гостя. Отсюда же берётся ответ на вопрос о выручке: не «баня плюс кафе из двух разных отчётов», а одна цифра из одного источника.

У REST-подхода есть и инженерный эффект: кассу можно дорабатывать, не перенастраивая портал. Точка стыка одна и описана, поэтому новая функция в кассе не превращается в переделку всей системы. Такие вещи относятся уже к заказной разработке — готового продукта «POS для банного комплекса на Битрикс24» не существует, он собирается под процессы конкретной сети.

Лояльность и выпуск сертификатов и абонементов сделаны отдельным блоком внутри той же системы. Смысл в том, что карта гостя, сертификат и абонемент опираются на одну и ту же историю визитов — ту, которую видит администратор в шахматке и официант в кассе. Отдельной «программы лояльности» со своей базой клиентов не появляется.

Сертификат и абонемент — это обязательства перед гостем, и учитывать их нужно как обязательства. Сертификат выпущен, продан, предъявлен, погашен: каждый шаг фиксируется. Абонемент — остаток посещений или часов, который списывается при визите. Пока это бумажные бланки и тетрадь, вопрос «сколько у нас непогашенных сертификатов на руках» не имеет быстрого ответа, а защита от повторного использования держится на внимательности конкретного администратора.

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

Сеть — это не «то же самое, только пять раз». Появляются вопросы, которых нет у одиночного объекта: гость купил абонемент в одном комплексе, а пришёл в другой; сотрудник выходит в смену на разных площадках; выручку надо видеть и по объекту, и по сети целиком; правила лояльности должны быть одинаковыми везде.

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

Второй эффект — тиражируемость. Открытие нового объекта не требует нового внедрения: добавляются кабинки, сотрудники и права, а процессы уже описаны. Это работает и в обратную сторону — изменить правила лояльности или состав услуг нужно один раз, а не в пяти независимых системах, где пятая обязательно окажется забытой.

Стоимость работ мы называем после бесплатного экспресс-аудита на 30 минут. Честной цифры «от» здесь не существует: на объём влияет число объектов и состав модулей — нужна только шахматка или сразу касса кафе и лояльность, есть ли уже Битрикс24 и в каком он состоянии, сколько ролей, какие интеграции требуются. Предсказуема только цена платформы: это официальные тарифы из таблицы выше для облака или лицензия коробочной версии.

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

Что смотреть дальше. Страница внедрения Битрикс24 — про фундамент, порядок работ и то, что входит в настройку портала. Кейс сети банных комплексов — про шахматку, POS-кассу и лояльность, которые работают в проде с действующим сопровождением. Страница заказной разработки — про приложения, порталы и POS, которых нет в готовых продуктах и которые собираются под процессы. Начать проще всего с аудита: он бесплатный и нужен, чтобы понять масштаб задачи, а не чтобы продать самый большой проект.