Розробка системи бронювання на 1С-Бітрікс

Овербукінг — головний біль будь-якого готельного бізнесу. Коли два гості одночасно бронюють останній номер, стандартний Бітрікс не може гарантувати, що не виникне подвійного запису. Втрати від таких конфліктів можуть сягати 500 000 руб на рік для невеликої мережі. Ми розробили кастомну систему бронювання на 1С-Бітрікс, яка повністю виключає овербукінг завдяки транзакційному блокуванню рядків та автоматичному звільненню прострочених броней. Кастомна розробка системи бронювання на 1С-Бітрікс починається з проєктування схеми даних: таблиця bl_booking, індекси та транзакції. Під капотом — SELECT FOR UPDATE, агент та AJAX-календар. Нижче — архітектура та реальний кейс.

Згідно з документацією 1С-Бітрікс, для складної логіки бронювання рекомендується використовувати кастомні таблиці замість інфоблоків. Ми використовуємо саме такий підхід: інфоблок rooms для опису номерів, а кастомну таблицю bl_booking для обліку зайнятості. Це дає гнучкість у запитах та продуктивність.

Чому стандартний інфоблок не підходить для бронювання?

Для календарного обліку доступності потрібна окрема схема. Інфоблок не дозволяє ефективно перевіряти перетинання дат і блокувати слоти.

Таблиця об'єктів — інфоблок типу room із властивостями PROPERTY_ROOM_TYPE, PROPERTY_CAPACITY та прив'язкою до готелю.

Таблиця броней — користувацька таблиця bl_booking:

CREATE TABLE bl_booking (
    id          SERIAL PRIMARY KEY,
    room_id     INT NOT NULL,
    user_id     INT,
    date_from   DATE NOT NULL,
    date_to     DATE NOT NULL,
    status      VARCHAR(20) NOT NULL,  -- pending, confirmed, cancelled, expired
    order_id    INT,
    price_total NUMERIC(12,2),
    created_at  TIMESTAMP DEFAULT NOW(),
    expires_at  TIMESTAMP,
    guest_name  VARCHAR(255),
    guest_phone VARCHAR(50),
    guest_email VARCHAR(255)
);
CREATE INDEX idx_booking_room_dates ON bl_booking(room_id, date_from, date_to, status);

Як працює перевірка доступності з захистом від race condition?

Ключовий запит — перевірка перетинів:

SELECT COUNT(*) FROM bl_booking
WHERE room_id = :room_id
  AND status IN ('pending', 'confirmed')
  AND date_from < :date_to
  AND date_to > :date_from;

Якщо COUNT > 0 — номер недоступний. Запит обертаємо в транзакцію з SELECT FOR UPDATE, щоб виключити race condition. Кроки реалізації:

1. Відкрити транзакцію.
2. Виконати SELECT FOR UPDATE по запису номера.
3. Перевірити перетини дат.
4. Якщо вільно — INSERT в bl_booking зі статусом pending.
5. Commit транзакції.

При паралельних запитах другий запит чекає завершення першої транзакції, що гарантує відсутність подвійних броней. Кастомна перевірка на основі bl_booking відпрацьовує в 5 разів швидше, ніж спроба реалізувати аналогічну логіку на стандартних інфоблоках.

Як обробляється таймаут оплати?

Після створення броні в pending запускається таймер. Якщо оплата не надійшла за 15–30 хвилин, бронь переводиться в expired і слот звільняється.

Реалізація через агента:

function ReleasExpiredBookings(): string
{
    $expiredIds = BookingTable::getList([
        'filter' => [
            'STATUS' => 'pending',
            '<=EXPIRES_AT' => new \Bitrix\Main\Type\DateTime(),
        ],
        'select' => ['ID'],
    ])->fetchAll();

    foreach ($expiredIds as $row) {
        BookingTable::update($row['ID'], ['STATUS' => 'expired']);
    }
    return __FUNCTION__ . '();';
}

Реєструється через CAgent::AddAgent() з інтервалом 60 секунд.

Як влаштований інтерфейс вибору дат?

Календар доступності будується на AJAX-запиті /bitrix/services/main/ajax.php?action=BookingModule:getAvailability. Бекенд повертає зайняті дати. На фронті використовуємо Flatpickr з розміткою недоступних днів.

AJAX-контролер, спадкоємець \Bitrix\Main\Engine\Controller:

class BookingController extends \Bitrix\Main\Engine\Controller
{
    public function getAvailabilityAction(int $roomId, string $month): array
    {
        // повертає зайняті дати за місяць
    }
}

Кейс з нашої практики: мережа апарт-готелів (3 об'єкти, 47 номерів)

Завдання: замінити ручне бронювання через дзвінки, виключити овербукінг.

Вихідна ситуація: менеджери вели Excel-таблицю, раз на тиждень звірялися — періодично траплялися подвійні броні, скандали з гостями. Втрати від овербукінгу до впровадження становили близько 500 000 руб на рік.

Реалізовані рішення:

• Інфоблок rooms з 47 елементами, кожен з галереєю та властивостями (FLOOR, VIEW, BED_TYPE)
• Таблиця bl_booking з індексом по діапазону дат
• AJAX-контролер перевірки доступності (відповідає за 80–120 мс)
• Інтеграція з еквайрингом через модуль sale.payment: бронь переходить в confirmed по вебхуку від платіжного шлюзу
• Агент звільнення прострочених броней кожні 2 хвилини
• Адміністративний модуль з календарним представленням завантаження номерів

Результат: нульові овербукінги за 14 місяців роботи, конверсія форми бронювання 4.2% (була 0% — все йшло через дзвінок). Витрати на розробку окупилися за 2 місяці.

Процес розробки

Строки можуть варіюватися залежно від складності інтеграцій та кількості об'єктів.

Порівняння підходів

Що включає розробка системи бронювання?

• Проєктування моделі даних з урахуванням типів номерів і сезонних цін
• Розробка механізму перевірки доступності з захистом від race condition
• Інтерфейс вибору дат з візуалізацією зайнятості
• Агент автоматичного звільнення прострочених броней
• Інтеграція з модулем sale для виставлення рахунку та прийому оплати
• Адміністративний розділ управління бронюваннями
• Налаштування сповіщень для гостя та адміністратора (email/SMS)

Отримайте консультацію по вашому проєкту. Замовте розробку системи бронювання під ключ — ми підготуємо комерційну пропозицію протягом 1 робочого дня. Зв'яжіться з нами для оцінки термінів та вартості розробки під ваші завдання.

Channel Manager — головна технічна головоломка готельного сайту

Гість бронює через ваш сайт, а номер автоматично закривається на Booking.com, Ostrovok та в PMS. Під капотом — двостороння синхронізація через API Travelline або Bnovo, обробка конфліктів (два бронювання за одну секунду на різних каналах), сезонне ціноутворення з десятками тарифних планів. Ми збираємо такі рішення на 1С-Бітрікс для готелів, хостелів та апартаментів. Розробка сайту готелю під ключ — це не просто landing page, а повноцінний інструмент прямих продажів. Замовте розробку сайту готелю — отримайте безкоштовний аудит поточного каналу бронювання та детальний прорахунок вартості.

Наша команда має 10+ років досвіду з 1С-Бітрікс та реалізувала понад 50 готельних проектів — від міні-готелів до мереж з кількома об'єктами.

Чому готель втрачає значні кошти на комісіях OTA?

Booking.com бере 15–18% комісії, Ostrovok — 10–15%. Готель на 50 номерів при завантаженні 70% та середньому чеку віддає агрегатору понад 1,5 млн грн на рік. Власний Booking Engine на Бітрікс вирішує три завдання:

• Прямі бронювання без комісій — навіть 30% переведеного потоку окупає сайт за 2–3 місяці.
• Best Rate Guarantee — ціна нижча, ніж на агрегаторі, і гість бронює напряму.
• Власна база гостей (Booking не віддає email — тільки relay-адресу) та допродажі: трансфер, SPA, ресторан.

Приклад: міський готель на 40 номерів після впровадження двигуна збільшив частку прямих бронювань з 10% до 35% за квартал. Overbooking знизився до нуля. Економія на комісіях — близько 300 000 грн на рік.

Booking Engine: ядро проекту

Модуль бронювання — не форма «залиште заявку», а движок з бізнес-логікою. Booking Engine окупається в 10 разів швидше, ніж оплата комісій агрегаторам.

Пошук та доступність

Гість вводить дати та категорію — бачить реальні вільні номери. Під капотом: таблиця доступності в інфоблоці з типом booking_availability, перевірка перетинів дат через SQL BETWEEN, врахування мінімального терміну проживання та обмежень заїзду.

Тарифікація

Сезонне ціноутворення — найболючіша частина. Реалізуємо через властивість інфоблоку PRICE_CALENDAR з цінами за датами, націнки за вихідні та свята, знижки за тривале проживання (7+ ночей), корпоративні тарифи за промокодом. Калькулятор перераховує на льоту.

Мультирумне бронювання

Сім'я бронює два номери в одній заявці — без повторного введення дат. Реалізуємо через кошик sale.basket з кастомними властивостями елементу кошика.

Додаткові послуги та оплата

Трансфер, сніданок, паркування — додаються до бронювання як пов'язані товари з прив'язкою до дат. Оплата: повна передоплата, депозит (перша ніч) або холдування картки з генерацією чеків по 54-ФЗ через sale.cashbox.

Як Channel Manager вирішує проблему overbooking?

Channel Manager — двостороння синхронізація через API агрегаторів. Travelline, Bnovo, Wubook підключаємо через їх протоколи:

• Бронювання на сайті → закриття номера на Booking, Ostrovok, Яндекс.Подорожі.
• Бронювання на OTA → закриття номера на сайті.
• Зміна ціни → оновлення на всіх каналах.

Граблі: API Travelline працює через XML із затримкою 1–5 хвилин. У пікові дати (Новий рік, травневі) ставимо подвійну перевірку — перед підтвердженням броні робимо повторний запит доступності. У проекті для мережі з трьох готелів це виключило 100% овербукінгу у високий сезон.

Як відбувається PMS-інтеграція?

Property Management System — мозок готелю. Інтегруємося через:

• Синхронізацію номерного фонду та статусів (вільний, зайнятий, на прибиранні).
• Автоматичне створення броні в PMS при онлайн-замовленні через вебхук.
• Отримання статусів (підтверджено, заселено, виїхав) для особистого кабінету гостя.

Особистий кабінет гостя та CRM Бітрікс24 — екосистема лояльності

Профіль гостя — не просто «історія замовлень». Історія проживань, програма лояльності з балами та статусами, збережені вподобання (високий поверх, тип подушки) — зберігаються в UF_* полях. Постійний гість цінує, коли його пам'ятають.

CRM на базі Бітрікс24 доповнює PMS. Картка гостя з витраченою сумою, вподобаннями, автоматичними ланцюжками роботів:

• Pre-arrival (за 3 дні до заїзду) — email з інформацією, пропозиція трансферу.
• Check-out +1 день — подяка, запит відгуку.
• Check-out +30 днів — персональна пропозиція на повтор.

Що входить у вартість розробки готельного сайту?

SEO та мобільна версія: конкуренція з Booking

Booking домінує в органіці. Запорука успіху — довгий хвіст та локальні запити:

• Локальне SEO — оптимізація під «готель в центрі Сочі з басейном».
• Schema-розмітка Hotel, LodgingBusiness, Offer з цінами — розширені снипети підвищують CTR на 20–30%.
• Google Hotel Ads — фід через Google Hotel Center, ціни поруч з OTA.
• Контент з путівниками та пам'ятками.

Мобільна версія — 60%+ бронювань. Форма в 3–4 кроки, нативний date picker, автозаповнення для повторних гостей, PWA з push-сповіщеннями. Інтеграція з картами — маршрут до готелю в один тап.

Типові помилки при розробці готельного сайту

• Ігнорування кешування (BX_COMPOSITE_CACHE) — сторінки бронювання завантажуються по 10+ секунд.
• Неврахування часових поясів — гість з іншого регіону бачить неправильний час заїзду.
• Однотаблична модель доступності без індексів — SQL-запити на 50+ номерів виконуються 2–3 секунди.
• Відсутність обробки холдування картки при недобросовісних гостях.

Виправлення кожної помилки в середньому економить готелю 15–20% втрачених броней.

Процес роботи

Терміни розробки

Вартість розраховується індивідуально після аналізу вашого проекту. Розробка сайту готелю на 1С-Бітрікс — інвестиція в прямі продажі, яка окупається за 2–3 місяці. Зателефонуйте або напишіть нам, щоб отримати детальний розрахунок та терміни для вашого об'єкта.