Система бронирования и онлайн-записи: как она устроена внутри

Под общим словом живут три разных продукта с разной логикой.

Ключевая ошибка простых календарей — считать, что услуга занимает одного исполнителя. В реальности она занимает набор ресурсов одновременно.

Комбинация ресурсов. Окрашивание занимает мастера, кресло и мойку в конце; диагностика — механика и подъёмник; УЗИ — врача, кабинет и аппарат. Свободным слот считается, только когда свободны все нужные ресурсы.

Длительность зависит от параметров. Стрижка мужская и женская — разное время; ТО зависит от модели; массаж бывает на 30 и 90 минут. Длительность привязывается к услуге, а иногда к паре «услуга + исполнитель»: опытный мастер делает быстрее.

Буферы. Уборка кабинета, дезинфекция, перестановка зала, подготовка оборудования — время, которого нет в прайсе, но которое ресурс занимает. Задаются до и после услуги.

Шаг сетки. Слоты по 15 минут дают гибкость и дыры в расписании; слоты по часу — плотность и отказы. Разумный подход — привязать шаг к самой частой услуге и разрешить системе предлагать «подтягивание» записей к соседним, чтобы не рвать день на куски.

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

График работы — не константа, а набор правил с исключениями, и именно исключения дают большую часть заявок в поддержку.

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

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

Самая частая техническая жалоба: два клиента записались на одно время. Причина не в интерфейсе, а в том, что между показом свободного слота и подтверждением записи проходит время.

Гонка за слот. Двое одновременно видят свободное окно и нажимают «записаться». Без блокировки на уровне базы данных оба получают подтверждение. Решение — атомарная проверка занятости в момент записи, а не при показе календаря.

Удержание. Если клиент проходит несколько шагов (выбор услуги, данные, оплата), слот нужно придержать на несколько минут с обратным отсчётом. Не удержали — клиент теряет время; удержали слишком надолго — расписание блокируется несостоявшимися записями.

Повторная отправка. Клиент нажал «подтвердить» дважды или сеть подвесила запрос — без ключа операции появляются две записи на одно имя. Идемпотентность здесь так же обязательна, как в платежах.

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

Деньги превращают простую запись в финансовую операцию со своими требованиями.

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

Дополнительно с 1 января 2026 года в чеках применяется основная ставка НДС 22% — при переходе периодов и по авансам, полученным раньше, расчёт нужно проверять отдельно, а настройки кассы сверять до запуска, а не после первой продажи.

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

Неявка — прямой убыток: ресурс простоял, другому клиенту отказали. Работает набор мер, а не одна.

• Напоминание за сутки и за пару часов — самый дешёвый инструмент, снимает большую часть забывчивости. Канал выбирается по клиенту: push, мессенджер, СМС.
• Подтверждение брони в один клик — кнопка «буду» в сообщении; неподтверждённые записи можно освобождать за несколько часов.
• Предоплата или депозит — работает жёстче всего, но снижает конверсию витрины: применяется к дорогим услугам, длинным слотам и повторным неявкам.
• Лист ожидания — освободившийся слот автоматически предлагается ожидающим; закрывает дыру за минуты.
• История клиента — счётчик неявок в карточке и правило «третья неявка — только по предоплате». Здесь удобно опираться на данные системы лояльности, если она уже есть.

Правила отмены — первое, о чём спрашивает клиент, и последнее, что обычно описывают в системе.

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

Техническая часть: перенос — это не удаление и создание, а изменение с сохранением истории. Иначе теряются связь с платежом, счётчик переносов и возможность разобраться в спорной ситуации.

Записи приходят не только с вашего сайта. Типичный набор: собственная витрина, приложение, агрегаторы и карты, телефон, мессенджеры, повторная запись на выходе после визита.

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

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

• Онлайн-касса и эквайринг — оплата, чеки на аванс и зачёт, возвраты.
• Учётная система — услуги и цены, расходники, зарплата исполнителей по выполненным записям; механика обмена разобрана в материале про интеграцию с 1С.
• CRM и рассылки — карточка клиента, история визитов, сегменты, напоминания.
• Телефония — звонок с определением клиента, запись из разговора, обратный звонок при отмене.
• Календари сотрудников — двусторонняя синхронизация с личными календарями, чтобы личные встречи не превращались в двойную запись.
• Агрегаторы и карты — витрина записи там, где клиент вас ищет.

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

Приложение оправдано для повторных клиентов: абонементы, история, баланс, быстрая перезапись в два тапа, push вместо СМС. Для сотрудников мобильная версия часто важнее клиентской: мастер смотрит расписание с телефона, отмечает приход клиента, добавляет услуги по факту. Такие вещи мы обычно и делаем в связке веб + мобильное приложение, где веб закрывает первый визит, а приложение — удержание.

Рынок готовых решений плотный: для салонов и клиник — YCLIENTS, DIKIDI, EasyWeek и другие; для гостиниц — TravelLine, Bnovo, Frontdesk24. Для стандартного бизнеса услуг они закрывают почти всё за абонентскую плату.

Стоимость определяют модель ресурсов, число каналов и наличие денег внутри системы. Витрина записи для одной точки и платформа бронирования с тарифами, депозитами и агрегаторами — проекты разного порядка.

Календарь без модели ресурсов. Записи ставятся на мастера, а кресло занято — конфликт всплывает в зале, а не в системе.

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

Правила отмены только в тексте на сайте. Система их не знает, администратор трактует по-своему, клиент спорит и уходит в отзывы.

Напоминания шлются одним каналом. СМС не дошло — клиент не пришёл; связка «push, мессенджер, СМС» с подтверждением работает заметно лучше.

Записи из агрегатора попадают в систему с задержкой. Двойные брони при этом неизбежны, и виноватым выглядит ваш администратор.

Первое — описать ресурсы и услуги: что занимает каждая услуга, сколько длится, какие буферы нужны, кто и где может её выполнять. Это документ на одну-две страницы, и он определяет половину сложности проекта.

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

Третье — посчитать текущую загрузку и неявки хотя бы приблизительно. Эти две цифры показывают, что вообще должна улучшить система и на чём считать окупаемость.