Як створити сайт бронювання готелю: номери, тарифи, наявність і оплата

Сайт бронювання готелю дає гостям змогу вибрати дати, побачити, які номери вільні на кожну ніч їхнього перебування, побачити загальну ціну і заплатити або внести депозит, не листуючись із адміністратором. Щоб його створити, потрібні типи номерів із кількістю кімнат, модель наявності по ночах, тарифи, що можуть змінюватися за датами, процес бронювання, який перевіряє наявність під час збереження, і адмін-панель для рецепції. Складне тут не гарні сторінки. Складно гарантувати, що номер ніколи не продається двічі, особливо якщо ви продаєте ще й на платформах бронювання.

Що має вміти сайт

Сторінки

• Публічні: головна, номери (фото, ліжка, розмір, зручності, максимум гостей), пошук за датами та кількістю гостей, результати із загальною ціною за тип номера, форма бронювання, оплата і сторінка підтвердження з посиланням для керування бронюванням.
• Допоміжні: локація та маршрут, правила (час заїзду й виїзду, скасування, діти, тварини), FAQ, контакти.
• Приватні (персонал): заїзди й виїзди на сьогодні, календарна сітка номерів по ночах, список бронювань, блокування дат, налаштування тарифів і номерів.

Дані

Зберігайте дати заїзду й виїзду як дати, а не час, і вважайте день виїзду виключним: проживання з 10-го по 12-те займає ночі 10-го та 11-го. Помилка тут спричиняє найпоширеніший збій наявності.

Права доступу

Гості бачать ціни та те, чи є тип номера в наявності, але ніколи не бачать, хто ще проживає. Співробітники рецепції бачать бронювання та дані гостей; тарифи й політику змінює лише власник. Тому потрібен вхід для персоналу з принаймні двома ролями.

Рішення та компроміси

Бронювання за запитом чи миттєве

Бронювання за запитом, коли гість надсилає дати та дані, а ви підтверджуєте листом, значно простіше і підходить для маленького гостьового будинку. Миттєве бронювання потребує бездоганної перевірки наявності та оплат, але конвертує краще. Багато закладів починають із запитів і згодом переходять на миттєве.

Продавати типи номерів чи конкретні номери

Гості зазвичай бронюють тип номера («двомісний з видом на море»), а конкретний номер персонал призначає пізніше. Продаж конкретних номерів простіший у реалізації, але календар важче заповнити.

Тарифи

Почніть з однієї ціни за тип номера за ніч із необов’язковими винятками для діапазонів дат (високий сезон, свята) і мінімальним строком проживання. Динамічне ціноутворення, промокоди та пакети залиште на потім.

Оплати

Варіанти в порядку зростання складності: оплата при заїзді; депозит через розміщений платіжний провайдер, наприклад Stripe Checkout; повна передоплата для тарифу без повернення коштів; або збереження картки для списання пізніше. Правила оплати, податки та місцеві збори залежать від країни: перевірте місцеві вимоги або зверніться до радника. Механіку розглядає наш гід з платежів.

Інші канали

Якщо номери також виставлені на онлайн-агентствах подорожей або платформах оренди житла, календарі треба тримати синхронізованими. Багато таких платформ уміють експортувати й імпортувати календарі через посилання iCal; така синхронізація поширена для невеликих закладів, але відбувається із затримкою, а не миттєво. Професійна відповідь — channel manager.

Перший промпт, який працює

Створи сайт прямого бронювання для Harbour House, гостьового будинку на 9 номерів у Тобермораї, Шотландія. Типи номерів: двомісний (4 номери, 2 гості, £120/ніч), twin (3 номери, 2 гості, £115), сімейний (2 номери, 2 дорослі + 2 дитини, £165). Гості шукають за датою заїзду, датою виїзду та кількістю гостей і бачать лише ті типи номерів, де є вільний номер на кожну ніч перебування, із загальною ціною. День виїзду виключний. Мінімальний строк проживання 2 ночі в липні та серпні. Форма бронювання збирає ім’я, email, телефон і час прибуття; зберігай її як «очікує» і перевіряй наявність знову на сервері перед збереженням. Зона персоналу з входом: заїзди й виїзди на сьогодні, календарна сітка номерів по ночах, список бронювань зі статусами і можливість блокувати дати. Показуй заїзд з 15:00 до 20:00, виїзд о 10:00 і політику скасування (безкоштовно за 7 днів до заїзду) на кожній сторінці бронювання. Спокійний прибережний дизайн, насамперед для телефону.

Кроки побудови

1. Спочатку змоделюйте номери та ночі. Типи номерів, номери, тарифи та перевірка наявності. Протестуйте до будь-якого дизайну.
2. Пошук і результати. Вибір дат, кількість гостей, загальна ціна за проживання, чіткі стани «немає місць».
3. Процес бронювання. Форма → повторна перевірка наявності на сервері → бронювання «очікує» → сторінка підтвердження з посиланням для керування.
4. Зона персоналу з входом: заїзди, виїзди, календарна сітка, блокування дат.
5. Лист-підтвердження через власного провайдера пошти: дати, сума, адреса та політика. Див. як надсилати email.
6. Депозити в тестовому режимі Stripe, підтверджуючи бронювання лише після успішної оплати. Вебхук платежів вимагає, щоб застосунок був опублікований за публічною адресою.
7. Синхронізація календарів з іншими каналами, якщо ви їх використовуєте, плюс щоденна ручна перевірка на початку.
8. Протестуйте крайні випадки: два браузери бронюють останній номер, проживання перетинає зміну тарифу, скасування звільняє ночі, одноденні проживання в період мінімального строку.
9. Опублікуйте і зробіть справжнє бронювання самі, перш ніж вимкнути старий процес.

Типові помилки

• Перевірка наявності лише в браузері. Два гості колись забронюють останній номер в один і той самий момент.
• Ніч виїзду вважається зайнятою (або ніч заїзду не рахується). Напишіть тест для проживання на дві ночі.
• Одна фіксована ціна. Більшості закладів потрібні принаймні сезонні винятки.
• Загальна сума прихована до останнього кроку. Показуйте повну ціну проживання, включно з відомими вам зборами, у результатах.
• Політики заховані у футері. Показуйте умови скасування поруч із кнопкою оплати.
• Синхронізацію iCal вважають миттєвою. Це не так; коли майже повністю заповнені, закривайте дати вручну.

Коли краще готовий продукт

Якщо у вас більше кількох номерів, ви продаєте через кілька онлайн-агентств подорожей або потрібні господарство, виставлення рахунків і звіти, найкраще підходить система управління готелем із вбудованим движком бронювання та channel manager. Такі продукти існують, щоб вирішувати проблему подвійного бронювання між каналами, і відтворити її якісно самостійно дорого.

Власний сайт має сенс для невеликих закладів, які переважно беруть прямі бронювання, для незвичайного інвентарю (кемпінг із глемпінгом, котеджі зі спільними зручностями, номери з пакетами активностей), або коли хочете власний дизайн і досвід гостя без щомісячної плати за номер. Деякі власники поєднують власний сайт із вбудованим хостинговим движком бронювання — часто це найкращий варіант із обох світів.

Створення з Mythex

У Mythex ви описуєте заклад у чаті, переглядаєте сайт в живому прев’ю (включно з рамкою телефону) і публікуєте, коли все працює. Бронювання, номери й тарифи зберігаються в базі Postgres, яку агент додає, коли застосунку потрібно зберігати дані; вона засинає в бездіяльності й прокидається із наступним запитом. Вхід персоналу, email-підтвердження й депозити підключені до ваших власних провайдерів і ключів: Mythex не має вбудованих продуктів для входу кінцевих користувачів, email чи платежів. Тому прочитайте рецепт Stripe, перш ніж додавати депозити. Команда /test дозволяє агентові пройти пошук і бронювання, а контрольні точки — відкотити зміну, яка зламала наявність.

Як стартовий промпт подивіться конструктор системи бронювання готелю, конструктор системи бронювання гостьового будинку або шаблон сайт бронювання глемпінгу. Для погодинного чи записного бронювання замість ночей див. гід зі створення застосунку для бронювання.

Запитання