Кейс продукту · Архітектура платформи
Єдиний механізм бронювання для погодинних, подобових послуг і послуг зі змінною тривалістю
Anolla побудована навколо ресурсів, доступності та правил, а не за шаблоном однієї галузі. Завдяки цьому те саме базове ядро може керувати зустрічами, груповими послугами, приміщеннями та послугами оренди без необхідності створювати окремий програмний продукт для кожної моделі послуг.
У цьому технічному огляді описано, як Anolla моделює різні способи планування за допомогою єдиної логіки ресурсів і доступності.
Основні моделі планування: погодинна, подобова та зі змінною тривалістю.
Обсяг конфігураціїТипи ресурсів, що підтримуються в поточній моделі конфігурації.
Перевірені можливості платформиЄдиний механізм перевірки доступності та конфліктів.
Архітектурний принципЯку проблему вирішує єдиний механізм бронювання?
Багато систем планування починаються з календаря зустрічей із фіксованою тривалістю, до якого згодом додають винятки. Anolla дотримується протилежного принципу: окремо визначають, що бронюється, на який термін це потрібно та які умови мають бути виконані. Так створюється спільна багаторазово використовувана основа для підприємств сфери послуг різних типів.
Виклик
Зустріч може потребувати одного фахівця на 45 хвилин, послуга оренди — резервування об’єкта на кілька днів, а групова послуга — допускати кількох учасників на один і той самий час.
Проєктне рішення
Ресурси, час і обмеження моделюються окремо, щоб доступність можна було розраховувати на основі компонентів багаторазового використання.
Результат платформи
Єдине базове ядро підтримує різні сценарії бронювання за допомогою спільної моделі керування, водночас клієнтський досвід залишається цілісним.
Чому самого календаря ще недостатньо, щоб бути механізмом бронювання?
Простий календар може показувати вільний і зайнятий час. Система бронювання, що працює у виробничому середовищі, повинна визначати, що можна забронювати, які ресурси потрібні, як задається тривалість, чи залишилися вільні місця та чи не змінило інше бронювання ситуацію до моменту підтвердження.
Ці рішення ускладнюються, коли платформа обслуговує більше ніж одну бізнес-модель. Створення окремого календаря для кожної категорії дублювало б логіку, фрагментувало користувацький досвід і ускладнювало керування майбутніми змінами.
Зустрічі
Потребують фахівця, визначеної тривалості послуги та буферних інтервалів між клієнтами.
Групові послуги
Потребують керування кількістю місць замість ексклюзивного резервування одного часового проміжку.
Приміщення та майданчики
Можуть бронюватися з певними інтервалами та залежати від годин роботи й правил доступу.
Об’єкти оренди
Можуть використовувати подобові періоди, часові вікна передачі та багатоденну доступність.
Категорія послуги повинна описувати контекст діяльності компанії, а не визначати межі механізму планування.
Які принципи дають змогу використовувати єдиний механізм для різних моделей послуг?
Модель бронювання Anolla складається з незалежних рівнів. Кожен рівень відповідає на запитання одного типу та може повторно використовуватися під час додавання нової галузі або сценарію бронювання.
01 · Ресурсоцентрична структура
Усе, що обмежує доступність, можна розглядати як ресурс: спеціаліста, приміщення, майданчик, обладнання, стіл, транспортний засіб, місце обслуговування або інший об’єкт, доступний для бронювання.
02 · Незалежна від галузі модель планування
Послуга може використовувати погодинний часовий інтервал, подобовий період або змінну тривалість без окремої продуктової архітектури для кожної категорії.
03 · Централізоване оцінювання обмежень
Графіки, кількість місць, буферний час, вікна бронювання та бронювання, що перекриваються, оцінюються разом перед пропонуванням часу й повторно перед підтвердженням.
04 · Єдина модель у клієнтських та адміністративних процесах
Публічна сторінка бронювання та інструменти адміністрування використовують однакову логіку доступності, зменшуючи ризик суперечливих варіантів.
Як конфігурація надходить до рушія доступності?
Рушій виходить не з назви сфери діяльності, а з ресурсів, моделі планування та обмежень, необхідних для оцінюваного бронювання. Та сама логіка ухвалення рішень використовується як для публічних бронювань, так і для бронювань, створених через панель адміністрування.
Вхідні дані конфігурації
Механізм доступності
Обчислити · порівняти · перевірити
Єдиний механізм поєднує конфігурацію, перевіряє доступність і застосовує правила бронювання перед поверненням результату.
Вихідні дані рушія
Концептуальна схема описує процес ухвалення рішень щодо доступності, а не повну технічну архітектуру внутрішніх систем Anolla.
Як один рушій обслуговує різні сценарії надання послуг?
Конфігурація змінюється залежно від сценарію, однак базовий рушій завжди відповідає на ті самі запитання: які ресурси потрібні, на який час, відповідно до яких обмежень і який обсяг бронювань ще доступний?
| Сценарій | Модель планування | Що оцінює рушій | Багаторазово використовувана логіка платформи |
|---|---|---|---|
| Прийом у спеціаліста | Змінна тривалість | Тривалість послуги, графік спеціаліста, час на підготовку або прибирання та наявні бронювання. | Доступність ресурсу, розрахунок тривалості, термін попереднього бронювання та перевірка конфліктів. |
| Групове заняття | Фіксована тривалість | Розклад заняття, інструктор, приміщення, максимальна кількість учасників і кількість вільних місць. | Перевірка кількох ресурсів, відстеження кількості місць, вікна бронювання та правила підтвердження. |
| Майданчик або приміщення | Погодинна | Години роботи, інтервал бронювання, зайнятість ресурсу, час на підготовку та додаткові опції. | Формування доступних для бронювання часових інтервалів, виключення бронювань, що перетинаються, і відображення доступності. |
| Об’єкт оренди | Подобова | Дата початку й завершення, вікна передавання, доступність об’єкта та періоди оренди, що перетинаються. | Перевірка періоду, стан ресурсу, правила бронювання та остаточна перевірка доступності. |
Як одна система підтримує комбінації з кількох послуг?
Одне бронювання не завжди має означати одну послугу. Клієнт може забажати отримати послідовно кілька пов’язаних послуг, а постачальник послуг може визначити, які послуги можна бронювати окремо, а які — лише разом з іншою послугою.
Для системи бронювання вибрані послуги розглядаються як єдине ціле: їхня тривалість, перерви, ціни та необхідні ресурси утворюють комбінацію, на основі якої визначається відповідний час і створюється одне бронювання.
Одне бронювання, кілька послуг
Клієнт може вибрати кілька сумісних послуг у межах одного бронювання без створення окремих бронювань.
Контрольовані комбінації
Постачальник послуг може визначати, які послуги можна бронювати окремо, а які утворюють комбінацію.
Спільний розрахунок доступності
Доступність розраховується на основі загальної тривалості комбінації, перерв і необхідних ресурсів.
Комбінування послуг не потребує окремої системи бронювання. Та сама логіка ресурсів, тривалості та доступності може оцінювати придатність бронювання як однієї послуги, так і комбінації з кількох послуг.
Як конфігурація перетворюється на підтверджене бронювання?
Процес бронювання відбувається в однаковій послідовності, навіть якщо видима користувачеві послуга та модель планування відрізняються.
Визначте, що можна бронювати
Постачальник послуг визначає основний ресурс і всі додаткові ресурси, необхідні для надання послуги.
Визначте модель планування
Послуга використовує погодинний часовий інтервал, період, визначений у днях, або тривалість, що залежить від послуги та додаткових опцій.
Застосуйте графіки та обмеження
Робочий час, кількість місць, буферний час, строки попереднього повідомлення, вікна бронювання та інші правила обмежують теоретичну доступність.
Знайдіть варіанти для відображення клієнту
Система повертає лише той час або ті періоди, які відповідають конфігурації, активній на момент запиту.
Повторно перевірте доступність перед підтвердженням
Повторна перевірка захищає від конфліктних змін, що виникли під час процесу вибору.
Які властивості забезпечує єдиний механізм бронювання?
Результат полягає не в тому, що всі компанії використовують ідентичну конфігурацію. Різні конфігурації можуть спиратися на той самий перевірений механізм ухвалення рішень і спільні принципи керування.
Єдина модель керування
Користувачі керують ресурсами, послугами, графіками та правилами за допомогою спільних понять.
Багаторазово використовувані правила перевірки
Перевірки конфліктів і обмеження керуються централізовано, завдяки чому вдосконалення приносять користь кільком моделям послуг.
Єдиний шлях клієнта
Зустрічі, приміщення та послуги оренди можуть використовувати звичну схему бронювання навіть за різних правил доступності.
Масштабована основа платформи
Нові категорії ресурсів і комбінації послуг можна додавати шляхом розширення конфігурації та правил.
Що саме означають твердження в цьому дослідженні?
Це дослідження продукту, а не історія клієнта. У ньому описано поточну модель бронювання Anolla, підтримувані конфігурації ресурсів і функціональний процес ухвалення рішень. Показники масштабу характеризують можливості платформи й не є результатом, обіцяним конкретній компанії.
Основа можливостей
Поточна конфігурація платформи, система підтримуваних типів ресурсів і наявні моделі планування.
Функціональне підтвердження
Сценарії бронювання, які оцінюються за допомогою однакової перевірки доступності та конфліктів.
Використання даних
У дослідженні не використовуються дані клієнтів, які дають змогу встановити їхню особу, або індивідуальні показники ефективності будь-якої компанії.
Інтерпретація
Сторінка демонструє масштаб платформи та можливість повторного використання архітектури, а не гарантовані результати клієнтів.
Обмеження. Гнучке ядро не робить робочі процеси в усіх галузях ідентичними. Галузеві вимоги, спеціалізовані інтеграції, фізичні системи контролю доступу або нестандартні правила ціноутворення можуть потребувати додаткового налаштування чи розробки. Точність даних про доступність залежить від якості розкладів, ресурсів і правил, введених постачальником послуг.