Управление виллами без вендорной зависимости: как мы перестроили WhatsApp-стек за один день

Через 18 месяцев управления виллами на Бали у нас было 12 операционных скриптов, каждый из которых зависел от одного внешнего сервиса. Каждое WhatsApp-сообщение гостю — напоминание о заезде, подтверждение оплаты, инструкции по прибытию — проходило через одного провайдера. Каждое входящее сообщение от уборщиц, каждый сигнал о поломке, каждое обновление расписания возвращалось через вебхук того же провайдера. Сервис назывался wa-sms.com, и в марте 2026 года небольшое изменение их схемы потребовало добавить 400 строк обходного кода в 4 разных скрипта.

Это стало последним аргументом. 18 мая 2026 года мы отключились от провайдера и перенесли всю WhatsApp-инфраструктуру на собственный стек. Миграция заняла один рабочий день плюс 8 часов ожидания переноса номера. Вот как мы это планировали, что построили, и что это значит для тех, кто управляет пятью и более объектами.

Почему внешние мессенджер-сервисы становятся проблемой в долгосрочной перспективе

Когда управляешь 2-3 виллами, сторонний WhatsApp-сервис оправдан: настройка занимает 2 часа, ежемесячная плата небольшая, об инфраструктуре думать не нужно. Проблема не в самом сервисе — а в структуре зависимости, которая формируется со временем.

При 16 виллах операционная коммуникация имеет требования, для которых универсальные мессенджер-сервисы не проектировались. Нам нужна точность тайминга исходящих сообщений: напоминание о заезде, запаздывающее на 30 минут из-за задержки вебхука, имеет реальные операционные последствия. Нам нужно, чтобы каждое сообщение логировалось против конкретной записи о бронировании. Нам нужно менять форматы сообщений без цикла деплоя вендора. Нам нужно добавлять новые типы уведомлений — сигналы о техобслуживании, подтверждения уборки, напоминания об оплате — за часы, а не ждать пока фича попадёт в дорожную карту провайдера.

400 строк обходного кода в марте — самый очевидный симптом, но не единственный. За 18 месяцев накопилось 7 отдельных обработчиков краевых случаев, каждый из которых компенсировал поведение внешнего сервиса, которое мы не могли изменить. Сервис был нормальным — просто не рассчитанным на наш сценарий использования. В какой-то момент это становится одним и тем же.

Экономическая логика проста: внешний сервис сэкономил примерно 40 часов первоначальной настройки. К моменту миграции накопленные обходные пути обходились нам в сопоставимое количество часов ежегодного обслуживания. Точка пересечения была пройдена.

Как выглядел наш WhatsApp-стек до миграции

До 18 мая наша WhatsApp-коммуникация работала через два канала, оба зависящих от внешнего провайдера. Первый — прямые сообщения гостям: 12 скриптов, обрабатывающих разные этапы жизненного цикла бронирования, обращались к одному REST-эндпоинту с номером телефона и телом сообщения. Второй — сообщения в сообщественных группах: 4 WhatsApp-группы по аренде вилл, которые мы ведём для рынка Бали, сегментированные по ежемесячному бюджету.

Группы по аренде — значимая часть нашего присутствия на рынке. Мы ведём их как ресурс для рынка недвижимости Бали: место, где владельцы публикуют краткосрочную аренду, а потенциальные арендаторы ищут варианты по бюджету. Группы охватывают 4 ценовых диапазона: до 5 миллионов рупий в месяц, 5-10 миллионов, 11-20 миллионов и 21-99 миллионов. Суммарно более 3000 участников, требующих постоянной модерации: удаление объявлений не по теме, соблюдение ценовых диапазонов, работа с аккаунтами, постящими спам в нескольких группах одновременно.

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

Архитектура миграции: три независимые фазы

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

Фаза 1: нормализация схемы контактов

Внешний сервис использовал проприетарные идентификаторы контактов — форматированную строку, объединяющую код страны, номер телефона и суффикс сервиса. Наша внутренняя база данных использовала стандартный международный формат. Каждый скрипт, которому нужно было отправить сообщение, запускал функцию трансляции между двумя форматами.

Фаза 1 расширила таблицу контактов для хранения обоих форматов, с миграционным скриптом, заполнившим 847 существующих записей задним числом. После этой фазы любой скрипт мог искать контакт по нашему внутреннему идентификатору и получать нужный формат без трансляции. Когда внешний формат ушёл, скриптам нужно было только перестать вызывать функцию трансляции — больше ничего не менялось.

Фаза 2: универсальный помощник отправки

Фаза 2 — архитектурное ядро миграции. Вместо того чтобы 12 скриптов самостоятельно поддерживали вызов к внешнему API, все они теперь вызывают единственную внутреннюю функцию: send_whatsapp(contact_id, message_type, payload). Эта функция обрабатывает маршрутизацию, ограничение частоты, логику повторов, логирование подтверждений доставки и выбор механизма доставки. Под капотом — маршрутизация через Baileys для WhatsApp-доставки, через прямой API-путь для определённых типов сообщений, или через SMS-резерв для критичных по времени сообщений.

Эта абстракция сделала миграцию единым переключением, а не последовательным обновлением 12 скриптов. В день миграции мы изменили одну строку в конфигурации маршрутизации. Все 12 скриптов немедленно начали отправлять через новый стек без каких-либо изменений в своём коде. Оценочная экономия за счёт избежания рефакторинга — около 1500 строк бизнес-логики, которые пришлось бы переписывать под новый формат API.

Фаза 3: адаптер входящих сообщений

Фаза 3 обрабатывала входящий трафик — сообщения от уборщиц, отчёты о техобслуживании, ответные WhatsApp-сообщения от гостей. Внешний сервис нормализовал эти сообщения в стандартный формат перед передачей на наш внутренний вебхук. Наш Baileys-экземпляр делал то же самое, но формат вывода должен был совпадать с тем, что выдавал внешний сервис, — иначе каждый нижестоящий процесс потребовал бы отдельных изменений.

Мы построили тонкий слой адаптера: приёмник Baileys принимает входящие сообщения, применяет трансформацию формата и передаёт их на тот же внутренний вебхук-эндпоинт. Построение и тестирование адаптера заняло 3 часа и было валидировано на 90 днях исторических образцов сообщений.

Сам перенос номера — переключение рабочего номера с внешнего провайдера на наш стек — потребовал обязательного периода ожидания после отключения, обычно 6-8 часов. Мы отключились в полдень, завершили все три фазы днём и зарегистрировали номер на собственном стеке вечером. Критичные по времени уведомления гостям в этот промежуток шли через SMS-резерв.

Новые возможности модерации, построенные в ходе миграции

Во время миграции мы расширили Baileys-экземпляр возможностями модерации сообщества, которые внешний сервис принципиально не мог поддержать. Теперь они работают непрерывно во всех 4 группах аренды.

Автоматическое применение ценовых диапазонов

До обновления обработка объявления не в той группе требовала от модератора: заметить ошибку, написать публикатору вручную, дождаться ответа и принять решение об удалении. Новая система делает это автоматически. Когда объявление появляется в неправильной группе, модератор отправляет публичное уведомление с тегом публикатора и 90-секундным окном для исправления. Если публикатор редактирует сообщение в этом окне — объявление остаётся. Если нет — удаляется с перенаправляющим сообщением: «Ваше объявление лучше подойдёт здесь — [прямая ссылка]».

Время ручной модерации для случаев несоответствия диапазону упало с примерно 8 минут на инцидент до нуля.

Применение правил по идентификатору аккаунта во всех группах

Раньше аккаунт мог получать нарушения в нескольких группах, не достигая порога блокировки ни в одной, — а затем продолжать работу в группах, где порог ещё не был достигнут. Новая система отслеживает нарушения на уровне идентификатора аккаунта во всех группах одновременно. Три нарушения в любой комбинации групп приводят к исключению из всех четырёх и постоянной записи в чёрный список.

Система бана по номеру телефона

Удаление нежелательного аккаунта раньше требовало навигации через мобильный интерфейс администратора группы WhatsApp — для каждой группы отдельно. Теперь наш управляющий бот принимает номер телефона, находит аккаунт во всех активных группах, выполняет исключение из каждой и записывает действие в журнал модерации. Время от команды до исполнения: менее 5 секунд для всех групп одновременно.

Проблема 1770 неактивных участников

В ходе миграции выявилось сопутствующее операционное ограничение. Группы WhatsApp имеют жёсткий лимит в 1024 участника. Три наши крупнейшие группы аренды приближались к этому потолку, то есть мы не могли добавлять новых активных владельцев или покупателей, не удаляя кого-то из существующих.

Мы экспортировали историю сообщений из всех 3 групп через нативную функцию экспорта WhatsApp, которая выдаёт текстовый файл. По этому файлу запустили парсер, классифицировавший каждого участника по активности: общее число сообщений, дата последнего поста и наличие более одного поста за всю историю. Во всех 3 группах 60-70% участников написали ровно одно сообщение с момента вступления. Итого неактивных кандидатов: 1770 аккаунтов.

Очистка неактивных — операционное решение по ёмкости, а не наказание. 1770 неактивных аккаунтов в переполненной группе уменьшают доступное место для активных участников и увеличивают область проверки при аудите модерации. Baileys-инфраструктура выполняет удаление программно, без ручного взаимодействия с интерфейсом для каждого аккаунта.

Что это значит для владельцев вилл, выбирающих управляющую компанию

Если вы владеете виллой на Бали и оцениваете управляющие компании, инфраструктура за ежедневными операциями — значимый критерий, даже если она не видна снаружи. Компания, работающая полностью на сторонних продуктах для коммуникации, управления бронированиями и отчётности, не просто платит вендорские комиссии — она принимает ограничения на то, что вообще возможно настроить под вашу виллу.

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

В Solar Property Bali каждый компонент операционного стека работает на инфраструктуре, которую мы контролируем и можем изменять. Коммуникация с гостями, координация уборок, синхронизация бронирований и ценовая автоматизация работают на наших серверах с кодом, который мы можем изменить за несколько часов, когда этого требует ваша вилла. 16 вилл под нашим управлением — операционный полигон для этой инфраструктуры и одновременно доказательство, что она работает в масштабе на Бали.

Миграция WhatsApp — один пример паттерна, повторяющегося во всём нашем стеке: используем внешний инструмент, пока важна скорость, определяем момент, когда контроль становится важнее скорости, и строим замену. Замена всегда оказывается мощнее оригинала, потому что создаётся под реальные операционные требования, а не под продуктовые решения вендора.

Операционная независимость как конкурентное преимущество на рынке аренды Бали

Мы не независимы от вендоров полностью и не претендуем на это. Мы используем eZee PMS для синхронизации бронирований по всему портфолио и интегрируемся с Airbnb, Booking.com и другими платформами через их стандартные API. Это интеграции платформ — каналы, через которые мы распространяем загрузку, а не инфраструктура, от которой зависит управление объектами.

Различие важно для понимания того, какая оптимизация вообще возможна. Интеграции платформ дают доступ к рынку. Независимость операционных инструментов даёт возможность оптимизироваться внутри этого рынка без разрешения вендора. На рынке аренды вилл Бали в 2026 году объекты, которые опережают по загрузке и среднесуточной ставке, почти всегда те, которые могут реагировать на рыночные условия быстрее, чем позволяет дорожная карта чужого продукта.

Следующие запланированные дополнения инфраструктуры — единый коммуникационный дашборд, агрегирующий WhatsApp, электронную почту и сообщения с OTA-платформ в один интерфейс оператора, и собственный SMS-резерв, устраняющий последнюю оставшуюся внешнюю зависимость по мессенджингу. Ни одно из них не срочное — фундамент, делающий оба выполнимыми, уже на месте. Миграция WhatsApp завершила этот фундамент.

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