Расписания и слоты для SPA-системы бронирования

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

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

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

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

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

Шаблоны помогали снизить ручную работу, но при этом требовали аккуратной логики редактирования. Администратор должен был понимать, меняет ли он конкретный день, повторяющееся правило или будущие даты по шаблону

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

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

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

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