Кейс продукта · Архитектура платформы
Единый механизм бронирования для почасовых, посуточных услуг и услуг с переменной продолжительностью
Anolla построена вокруг ресурсов, доступности и правил, а не по шаблону одной отрасли. Поэтому одно и то же базовое ядро может управлять встречами, групповыми услугами, помещениями и арендными услугами без необходимости создавать отдельный программный продукт для каждой модели обслуживания.
В этом техническом обзоре описывается, как Anolla моделирует различные способы планирования с помощью единой логики ресурсов и доступности.
Основные модели планирования: почасовая, посуточная и с переменной продолжительностью.
Охват конфигурацииПоддерживаемые типы ресурсов в текущей модели конфигурации.
Проверенные возможности платформыЕдиный механизм проверки доступности и конфликтов.
Архитектурный принципКакую проблему решает единый механизм бронирования?
Многие системы планирования изначально представляют собой календарь встреч с фиксированной продолжительностью, к которому позднее добавляются исключения. Anolla использует противоположный подход: отдельно определяются объект бронирования, продолжительность его использования и условия, которые должны быть выполнены. Так формируется единая многократно используемая основа для сервисных компаний разных типов.
Задача
Для встречи может потребоваться один специалист на 45 минут, услуга аренды может резервировать объект на несколько дней, а групповая услуга — допускать нескольких участников на одно и то же время.
Проектное решение
Ресурсы, время и ограничения моделируются отдельно, чтобы доступность можно было рассчитывать на основе повторно используемых компонентов.
Результат платформы
Единое базовое ядро поддерживает различные сценарии бронирования посредством общей модели управления, при этом клиентский опыт остается единообразным.
Почему одного календаря ещё недостаточно для полноценной системы бронирования?
Простой календарь может показывать свободное и занятое время. Система бронирования, работающая в производственной среде, должна определять, что можно забронировать, какие ресурсы для этого нужны, как задаётся продолжительность, остались ли свободные места и не изменило ли другое бронирование ситуацию до подтверждения.
Эти решения усложняются, когда платформа обслуживает более одной бизнес-модели. Создание отдельного календаря для каждой категории привело бы к дублированию логики, фрагментации пользовательского опыта и усложнило бы управление будущими изменениями.
Встречи
Требуют наличия специалиста, заданной продолжительности услуги и буферного времени между клиентами.
Групповые услуги
Требуют управления количеством мест вместо эксклюзивного бронирования одного временного интервала.
Помещения и площадки
Могут бронироваться с определёнными интервалами и зависеть от часов работы и правил доступа.
Объекты аренды
Могут использовать посуточные периоды, временные окна передачи и доступность на несколько дней.
Категория услуги должна описывать контекст деятельности компании, а не определять границы механизма планирования.
Какие принципы позволяют использовать единый механизм для разных моделей обслуживания?
Модель бронирования Anolla состоит из независимых уровней. Каждый уровень отвечает на вопрос определённого типа и может повторно использоваться при добавлении новой отрасли или сценария бронирования.
01 · Ресурсоцентричная структура
Всё, что ограничивает доступность, можно рассматривать как ресурс: специалиста, помещение, площадку, оборудование, стол, транспортное средство, место обслуживания или другой бронируемый объект.
02 · Независимая от отрасли модель планирования
Услуга может использовать почасовой интервал, посуточный период или переменную продолжительность без отдельной архитектуры продукта для каждой категории.
03 · Централизованная оценка ограничений
Графики, вместимость, буферное время, окна бронирования и пересекающиеся бронирования оцениваются совместно перед предложением времени и повторно перед подтверждением.
04 · Единая модель для клиентских и административных процессов
Публичная страница бронирования и инструменты администрирования используют одну и ту же логику доступности, снижая риск противоречивых вариантов.
Как конфигурация поступает в механизм определения доступности?
Механизм исходит не из названия сферы деятельности, а из ресурсов, модели планирования и ограничений, необходимых для оцениваемого бронирования. Одна и та же логика принятия решений используется как для публичных бронирований, так и для бронирований, созданных через панель управления.
Входные параметры конфигурации
Механизм управления доступностью
Рассчитать · сопоставить · проверить
Единый механизм объединяет конфигурацию, проверяет доступность и применяет правила бронирования перед возвратом результата.
Результаты работы механизма
Концептуальная схема описывает процесс принятия решений о доступности, а не полную техническую архитектуру внутренних систем Anolla.
Как один и тот же механизм работает с разными сценариями оказания услуг?
Конфигурация меняется в зависимости от сценария, однако основной механизм всегда отвечает на одни и те же вопросы: какие ресурсы необходимы, на какой срок, с учётом каких ограничений и какой объём бронирования ещё доступен?
| Сценарий | Модель планирования | Что оценивает механизм | Повторно используемая логика платформы |
|---|---|---|---|
| Приём у специалиста | Переменная продолжительность | Продолжительность услуги, график специалиста, время на подготовку или уборку, а также существующие бронирования. | Доступность ресурса, расчёт продолжительности, срок предварительного уведомления и проверка конфликтов. |
| Групповое занятие | Фиксированная продолжительность | Расписание занятия, инструктор, помещение, максимальное количество участников и количество свободных мест. | Проверка нескольких ресурсов, учёт количества мест, окна бронирования и правила подтверждения. |
| Площадка или помещение | Почасовая модель | Часы работы, интервал бронирования, занятость ресурса, время на подготовку и дополнительные опции. | Формирование доступных для бронирования временных интервалов, исключение пересекающихся бронирований и отображение доступности. |
| Объект аренды | Посуточная модель | Дата начала и окончания, окна передачи объекта, доступность объекта и пересекающиеся периоды аренды. | Проверка периода, состояние ресурса, правила бронирования и окончательная проверка доступности. |
Как одна и та же система поддерживает комбинации из нескольких услуг?
Одно бронирование не всегда означает одну услугу. Клиент может захотеть последовательно получить несколько связанных услуг, а поставщик услуг может определить, какие услуги можно бронировать отдельно, а какие — только вместе с другой услугой.
Для системы бронирования выбранные услуги рассматриваются как единое целое: их продолжительность, перерывы, цены и необходимые ресурсы образуют комбинацию, на основе которой подбирается подходящее время и создаётся одно бронирование.
Одно бронирование, несколько услуг
Клиент может выбрать в рамках одного бронирования несколько совместимых услуг без необходимости создавать отдельные бронирования.
Управляемые комбинации
Поставщик услуг может определить, какие услуги можно бронировать отдельно, а какие образуют комбинацию.
Единый расчёт доступности
Доступность рассчитывается на основе общей продолжительности комбинации, перерывов и необходимых ресурсов.
Для комбинирования услуг не требуется отдельная система бронирования. Одна и та же логика ресурсов, продолжительности и доступности позволяет оценивать возможность бронирования как одной услуги, так и комбинации из нескольких услуг.
Как конфигурация превращается в подтверждённое бронирование?
Процесс бронирования следует единой последовательности, даже если видимая пользователю услуга и модель планирования различаются.
Определите, что можно бронировать
Поставщик услуг определяет основной ресурс и все дополнительные ресурсы, необходимые для оказания услуги.
Определите модель планирования
Для услуги используется почасовой временной интервал, посуточный период или продолжительность, зависящая от услуги и дополнительных параметров.
Примените расписания и ограничения
Рабочие часы, вместимость, буферное время, сроки предварительного уведомления, окна бронирования и другие правила ограничивают теоретическую доступность.
Найдите варианты для отображения клиенту
Система возвращает только те интервалы времени или периоды, которые соответствуют конфигурации, активной на момент запроса.
Повторно проверьте доступность перед подтверждением
Повторная проверка защищает от конфликтующих изменений, возникших в процессе выбора.
Какие возможности обеспечивает единый механизм бронирования?
Результат заключается не в том, что все компании используют идентичную конфигурацию. Различные конфигурации могут опираться на один и тот же протестированный механизм принятия решений и общие принципы управления.
Единая модель управления
Пользователи управляют ресурсами, услугами, расписаниями и правилами с помощью единых понятий.
Повторно используемые правила проверки
Проверки конфликтов и ограничения управляются централизованно, благодаря чему улучшения применимы к нескольким моделям услуг.
Единый путь клиента
Встречи, помещения и услуги аренды могут следовать привычному процессу бронирования даже при разных правилах доступности.
Расширяемая основа платформы
Новые категории ресурсов и комбинации услуг можно добавлять, расширяя конфигурацию и правила.
Что именно означают утверждения в этом исследовании?
Это исследование продукта, а не история клиента. В нём описываются текущая модель бронирования Anolla, поддерживаемые конфигурации ресурсов и функциональный процесс принятия решений. Показатели масштаба характеризуют возможности платформы и не являются результатом, обещанным конкретной компании.
Основа возможностей
Текущая конфигурация платформы, система поддерживаемых типов ресурсов и существующие модели планирования.
Функциональное подтверждение
Сценарии бронирования, которые оцениваются посредством единой проверки доступности и конфликтов.
Использование данных
В исследовании не используются данные клиентов, позволяющие установить их личность, или индивидуальные показатели деятельности какой-либо компании.
Интерпретация
Страница демонстрирует масштаб платформы и возможность повторного использования архитектуры, а не гарантированные результаты клиентов.
Ограничения. Гибкое ядро не делает рабочие процессы всех отраслей идентичными. Отраслевые требования, индивидуальные интеграции, физические системы контроля доступа или нестандартные правила ценообразования могут потребовать дополнительной настройки или разработки. Точность данных о доступности зависит от качества расписаний, ресурсов и правил, введённых поставщиком услуг.