Как не словить двойное бронирование: единственная шпаргалка хосту

Своё первое настоящее двойное бронирование я устроил вовсе не из-за лага синхронизации. Я закрыл пятницу на Booking.com — друг сказал, что приедет, — забыл продублировать блок на Airbnb, и через два часа на ту же пятницу прилетел instant-book. Лаг — ноль. Просто два календаря говорили разное, потому что я отредактировал один и не отредактировал второй.

Эта история важна, потому что большинство статей «как избежать двойных бронирований» зациклены на окнах опроса iCal и игнорируют куда более частую причину: хост правит одну площадку и забывает про остальные. Это та шпаргалка, которой мне тогда не хватало.

Шпаргалка

Пять правил. По убыванию пользы.

1. Один канонический календарь. Выберите один источник истины для ручных блоков (своих, семейных, ремонтных). Все остальные площадки импортируют из него. Никогда не вбивайте ручной блок одновременно на две площадки.
2. Самый частый опрос на каждом импортированном фиде. Airbnb, Booking, Vrbo — откройте каждый и выкрутите частоту обновления импорта на минимум, какой есть. Меньше двух часов нигде нет; это нормально.
3. Один день буфера — иногда. Там, где уборка в день выезда силами внешней бригады, ставьте 1 день блока после заезда. На маленьком объекте, который вы убираете сами за два часа, — пропустите: упущенный доход больше риска.
4. Аудит за 24 часа до заезда. За день до прибытия гостя откройте обе площадки и убедитесь, что даты совпадают. 30 секунд. Ловит редкий 1-из-300 молчаливый сбой синхронизации.
5. Шаблон извинения наготове. Когда редкое двойное бронирование всё-таки случится, вы будете в метро / спать / за рулём. Держите вежливый, спокойный шаблон: объяснение, возврат проигравшему, ссылка на один альтернативный объект поблизости.

Если вы делаете все пять, частота двойных бронирований падает ниже частоты сорванных оплат, no-show и заклинивших кодовых замков. Не до нуля. Примерно до уровня «попасть под машину, которую вы не заметили».

Интервал синхронизации: крутим ручку правильно

Большинство хостов помнит, что iCal обновляется «раз в несколько часов», но фактическую настройку не проверяет. А она важна.

У каждой площадки своя. На момент написания то, что можно крутить:

1. Airbnb — импортированные календари обновляются по расписанию Airbnb (2–4 часа, хост не настраивает). Исходящие экспорты — примерно раз в 2 часа.
2. Booking.com — в экстранете можно вручную обновить отдельный фид; автоматическое обновление — раз в 2–6 часов. UI ускорить это не позволяет.
3. Vrbo — самый медленный из тройки. В тяжёлых случаях наблюдалось до 12 часов. Если фид завис на 24+ часа — пересоздайте URL.

Что вы реально можете менять — это собственный исходящий опрос. Если у вас промежуточный слой вроде open-source RentTools, выставьте на нём минимально допустимый интервал входящего опроса — 10 минут разумно; меньше — это уже сжигание трафика Airbnb впустую, потому что площадка-получатель всё равно опрашивает медленно.

Почему iCal в принципе упирается в «раз в несколько часов» и не умеет push — разобрано в нашей статье о синхронизации календарей Airbnb и Booking.com.

Буферные дни: когда добавлять и когда не надо

Большинство хостов выставляют «1 день буфера» по дефолту и больше не возвращаются. На самом деле это компромисс, и правильный ответ — для каждого объекта свой.

Цифры: 1 буферный день на оборот — минус одна ночь дохода. При $90 за ночь и 30 оборотах в год это $2 700 упущенной выручки до налогов. Польза — то, что вы избежали (а) проблем с качеством уборки и (б) редкого хаоса с одновременным выездом и заездом.

Правила, по которым решаю я:

1. Студия / однушка, которую я сам убираю меньше чем за 90 минут: ноль буферных дней. Заезд в день выезда работает. Экономия больше, чем маржинальный риск по уборке.
2. Семейная вилла с внешней клининговой бригадой и оборотом 4 часа: 1 буферный день. Зазор между выездом до 11:00 и заездом с 15:00 слишком тугой; буфер даёт реальный запас.
3. Объект с редкими гостями на 7+ ночей: 1 буферный день. Упущенный доход небольшой (длинные гости — меньше оборотов в год), а длительные гости придирчивее к чистоте.
4. Объект синхронизирован только через iCal (без channel-manager API): ставьте буфер на ведущей площадке и пусть он растечётся через iCal. Никогда не выставляйте на принимающей стороне: буфер должен прийти к ней до её опроса, а не после.

Совсем без буфера живите, если обороты идут на автопилоте, а уборщица — ваш проверенный человек. Возвращайте буфер сразу после первого инцидента с уборкой.

Правила ручного ввода: ловушка офлайн-календаря

Это то самое, на чём я попался с пятницей. Правило простое и негибкое: никогда не вбивайте ручной блок одновременно на две площадки. Выбираете канонический — остальное iCal сам разнесёт.

Три варианта канона:

1. Booking.com как канон. Блокируете дату в экстранете Booking. Airbnb импортирует iCal Booking — блок прилетит в окне опроса Airbnb (2–4 часа). Подходит, потому что у Booking самый плотный календарный UI среди тройки.
2. Airbnb как канон. Блокируете дату в Airbnb. Booking импортирует iCal Airbnb. Та же логика, в обратную сторону.
3. Внешний календарь как канон. Google Calendar (или ваш RentTools) для личных блоков. И Airbnb, и Booking импортируют из него. Удобно, когда личных блоков много (ремонты, межсезонье, использование для семьи).

Какой бы вариант ни выбрали — поставьте обои на телефоне, напишите на стикере, набейте татуировку. В следующий раз, когда друг напишет «свободна ли квартира на выходные», ответ — «сейчас закрою на $КАНОН». А не «давай я закрою сразу там и там, минуту».

Если объектов несколько и совладельцев несколько (формат co-host), договоритесь о правиле и зафиксируйте его письменно. Половина чужих историй про двойные бронирования, которые я слышал в Ташкенте, — это совладелец закрыл дату на той площадке, к которой у основного хоста нет доступа.

Аудит за 24 часа до заезда

Скучный спасатель. Перед каждым бронированием — проверка за сутки.

Аудит — 30 секунд:

1. Откройте бронирование на той площадке, где оно пришло.
2. Зафиксируйте точные даты.
3. Откройте календарь того же объекта на второй площадке.
4. Подтвердите, что даты помечены занятыми.
5. Если не помечены — закройте их вручную на второй площадке (у вас редкий сбой синхронизации или сломан ваш собственный setup). Разберётесь после заезда гостя.

Проблему вы найдёте примерно один раз на 200–400 бронирований. Почти всегда это какая-то транзиентная ерунда, которую иначе вы бы не поймали: исходник тихо сменил ссылку фида, кронджоб на сервере умер, перевод стрелок сбил полуночный cron.

На длинных бронированиях аудит не пропускайте: там цена коллизии выше, потому что трёхнедельного гостя так просто не пересадить.

Часть аудита можно автоматизировать. RentTools перед заездом отправляет письмо «конфликтов не найдено, увидимся через 24 часа». У многих channel manager есть аналог. Руками тоже норм, если бронирований у вас меньше 20 в месяц — это пара минут в неделю.

Одно мнение, не нейтральное

Если у вас 1–3 объекта и вы переживаете из-за двойных бронирований — самое полезное, что вы можете сделать на этой неделе, это правило канонического календаря плюс аудит за 24 часа. И то и другое бесплатно. На настройку — пять минут. Вместе они ловят 90% сбоев, которые крутые инструменты обещают «решить».

Те самые крутые инструменты (channel manager, платные PMS) — реальные и нужные, но для хостов с большим объёмом. Для маленьких хостов это налог за проблему, которую можно было закрыть бесплатно стикером. Сначала стикер.