Овербукинг — кошмар любого, кто сдаёт недвижимость на нескольких платформах. Один гость уже купил билеты и летит из Москвы, второй — из Сиднея. Оба забронировали одну и ту же виллу на одни даты. Именно так выглядит овербукинг, и он полностью разрушает репутацию.
Мы управляем 25 виллами через Airbnb, Booking.com и Agoda одновременно. За 6 месяцев работы Channel Checker — ни одного случая овербукинга. Рассказываю, как это работает.
Почему происходит овербукинг
Корень проблемы — задержка синхронизации между платформами. Гость бронирует виллу на Airbnb. Booking.com узнаёт об этом через 15–30 минут (или несколько часов при сбоях API). В этом окне второй гость успевает забронировать те же даты.
Стандартное решение — channel manager. Но стандартные channel manager'ы стоят $50–200/месяц, имеют задержки синхронизации 5–15 минут и не дают алерты при сбоях API.
Мы построили свой Channel Checker — легче, быстрее и с мониторингом.
Архитектура Channel Checker
eZee Channel Manager API
↓ (каждые 15 минут)
Channel Checker (Python)
↓
PostgreSQL (booking_status)
↓
Проверка на пересечения дат
↓
Конфликт? → Telegram алерт
Нет конфликта → всё ок
Ключевой элемент — eZee Channel Manager. Он агрегирует все платформы в одном месте и предоставляет единый API. Channel Checker подключается к eZee, а не напрямую к Airbnb/Booking — это снижает сложность в 3 раза.
Алгоритм проверки конфликтов
Каждые 15 минут система делает следующее:
async def check_for_conflicts():
# Получаем все активные бронирования
bookings = await ezee_client.get_bookings(
status=['confirmed', 'tentative']
)
# Группируем по виллам
by_villa = group_by_villa(bookings)
for villa_id, villa_bookings in by_villa.items():
# Сортируем по дате заезда
sorted_bookings = sorted(
villa_bookings, key=lambda b: b.check_in
)
# Проверяем каждую пару на пересечение
for i in range(len(sorted_bookings) - 1):
current = sorted_bookings[i]
next_b = sorted_bookings[i + 1]
if current.check_out > next_b.check_in:
# КОНФЛИКТ!
await alert_manager(
villa_id=villa_id,
booking1=current,
booking2=next_b,
conflict_dates=(next_b.check_in, current.check_out)
)
await create_urgent_task(
type="overbooking_conflict",
priority="critical"
)
Что происходит при обнаружении конфликта
Если система находит пересечение дат — менеджер получает алерт в Telegram в течение 15 минут после появления проблемы. В сообщении:
Вилла: Villa Sunset Ubud
Бронирование 1: #AirBnB-28471
Иванов Петр, 10–17 апреля
Бронирование 2: #Booking-91234
John Smith, 15–22 апреля
Пересечение: 15–17 апреля (2 ночи)
Источник конфликта: синхронизация eZee
Обнаружено: 2 мин назад
Менеджер видит точные данные и может немедленно связаться с одним из гостей для переноса или перебронирования на другую виллу.
Дополнительная защита: заморозка дат
Когда поступает новое бронирование, система автоматически блокирует эти даты на всех платформах через API eZee — до того как произойдёт «естественная» синхронизация. Это закрывает то самое окно уязвимости в 15–30 минут.
async def on_new_booking(booking: Booking):
# Сразу блокируем даты на всех каналах
await ezee_client.block_dates(
villa_id=booking.villa_id,
check_in=booking.check_in,
check_out=booking.check_out,
reason="new_booking_lock"
)
# Сохраняем в БД
await db.save_booking(booking)
# Уведомляем команду
await notify_manager(booking)
Результаты
| Метрика | До | После |
|---|---|---|
| Инциденты овербукинга/месяц | 3–5 | 0 |
| Время обнаружения конфликта | 1–24 часа | < 15 минут |
| Время ручной проверки в день | 30–60 мин | 0 мин |
| Загрузка вилл | ~55% | 70–80% |
Рост загрузки — не только от синхронизации. Уверенность в отсутствии конфликтов позволила нам агрессивнее размещать виллы на всех платформах одновременно, не боясь проблем.
Нужен ли вам Channel Manager?
Если вы управляете 1–2 объектами на одной платформе — встроенных инструментов платформы достаточно.
Если у вас 3+ объекта на 2+ платформах — Channel Manager необходим. Каждый день без него — это риск овербукинга, который стоит репутации и штрафов от платформ.
Полный кейс про автоматизацию 25 вилл — в разделе Проекты. Там подробно о всех 20 модулях системы.