Как мы автоматизировали посуточную аренду: AmoCRM, RealtyCalendar и Telegram

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

Контекст: что было

Клиент управлял несколькими квартирами в посуточной аренде. Брони приходили из трёх агрегаторов: Авито, Суточно, Яндекс Путешествия. Команда работала в WhatsApp и Telegram, расписание держала в RealtyCalendar. Никакой автоматизации не было.

Стандартный путь брони:

Гость бронирует через агрегатор
Менеджер видит бронь в RealtyCalendar
Менеджер открывает WhatsApp, копирует шаблон, подставляет данные гостя
Через два дня напоминание о времени заселения
В день заезда инструкции, пароль Wi-Fi, код двери (свой для каждой квартиры)
В день выезда напоминание про чек-аут
После выезда задача клинерам

Каждый шаг ручной. Каждая квартира со своим набором паролей и кодов. С ростом квартир время на коммуникацию росло линейно, а с ним росло количество ошибок. Не тому гостю отправили код, забыли инструкцию, прислали вчерашние данные.

Цель

Сделать так, чтобы команда занималась только нестандартными ситуациями: разрешение конфликтов, ранний заезд, поздний выезд, отмены. Всю рутину (раздачу инструкций, паролей и напоминаний) забрать в автоматизацию.

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

Архитектура

Главное архитектурное решение: не пытаться сделать всё в одном инструменте. Каждый компонент делает то, в чём он силён, и общается с соседями через API и webhooks.

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   Агрегаторы    │    │ RealtyCalendar  │    │     AmoCRM      │
│ Авито, Суточно, │───▶│ единое расписа- │───▶│ воронка по эта- │
│ Я.Путешествия   │    │ ние, синхрон    │    │ пам брони       │
└─────────────────┘    └─────────────────┘    └────────┬────────┘
                                                       │
                                                       │ webhook
                                                       ▼
                       ┌─────────────────┐    ┌─────────────────┐
                       │  WhatsApp,      │    │   Наш бэкенд    │
                       │  Telegram       │◀───│ подтягивает     │
                       │  через          │    │ инструкцию для  │
                       │  Salesbot/Pact  │    │ конкретной      │
                       └─────────────────┘    │ квартиры        │
                                              └─────────────────┘

Каждый блок:

Агрегаторы уже подключены к RealtyCalendar. Это типовая интеграция, мы ничего не трогали.
RealtyCalendar агрегирует брони со всех платформ в единое расписание. У него уже есть нативная интеграция с AmoCRM, мы её использовали как есть.
В AmoCRM живёт основная логика воронок. На каждую бронь отдельная сделка с переходами по этапам.
Наш бэкенд ловит webhook'и из AmoCRM, считает, какую инструкцию слать, и пересылает в WhatsApp/Telegram.
Salesbot и Pact работают как инструменты доставки в мессенджеры. Pact умеет WhatsApp Business API, Salesbot встроен в AmoCRM.

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

Воронка в AmoCRM

Самое интересное здесь это структура сделки. Каждая бронь проходит через одну воронку с фиксированными этапами:

Этап	Триггер перехода	Что отправляется гостю
Забронировано	Создание сделки из RealtyCalendar	Подтверждение брони + данные оплаты
Инструкция отправлена	За 1 день до заезда	Полная инструкция: адрес, как добраться, Wi-Fi, коды
Ранний заезд	По запросу гостя, ручной этап	Подтверждение времени, доплата
Поздний выезд	По запросу гостя, ручной этап	Подтверждение времени, доплата
Заселение	В день заезда, по времени бронирования	Приветственное сообщение, контакт менеджера
Проживание	После 24 часов с момента заезда	(Тишина, гость в квартире)
Выселение	За 4 часа до конца брони	Напоминание о чек-ауте
Уборка	После выезда	Задача клинерам на уборку

Каждый автоматический этап триггерит webhook в наш бэкенд. Бэкенд решает, что именно отправлять.

Почему бэкенд, а не только AmoCRM

Можно было бы сделать всё внутри AmoCRM через Salesbot. Не сделали, и вот почему.

Инструкции уникальны для каждой квартиры. В одной квартире код двери 1234, в другой 5678. В одной Wi-Fi называется Home, в другой Apartment2. Хранить это всё в шаблонах Salesbot это путь в ад. Каждая новая квартира требует копирования и редактирования всей воронки.

Решение: квартиры хранятся в нашей базе как сущности с полями: адрес, код двери, имя Wi-Fi, пароль Wi-Fi, инструкция, контакт уборщицы, время заезда. Бэкенд по ID квартиры из сделки AmoCRM подтягивает нужные данные и вставляет в текст сообщения.

Логика разная по типу гостя. Гость с первой бронью получает развёрнутую инструкцию. Гость, который уже жил, получает короткое сообщение «дверь та же, код тот же». В AmoCRM такую логику ветвить через Salesbot можно, но сложно. В коде пять строк.

Платёжная информация считается на лету. Цена плюс комиссия агрегатора плюс страховой депозит. AmoCRM не умеет такие расчёты, бэкенд считает в момент отправки.

Как реально работает один цикл

День минус 1. Гость забронировал через Суточно за неделю до заезда. RealtyCalendar получил бронь, создал сделку в AmoCRM. Сделка автоматически попала в этап «Забронировано». В AmoCRM сработал триггер, отправилось подтверждение через Salesbot в Telegram (если гость указал Telegram) или в WhatsApp через Pact.

День 0, утро. Триггер «за 24 часа до заезда» сработал в AmoCRM. Сделка перешла в этап «Инструкция отправлена». В наш бэкенд прилетел webhook с ID сделки. Бэкенд:

Подтянул из AmoCRM ID квартиры и время заезда
Из своей базы достал данные квартиры: адрес, Wi-Fi, код двери, инструкцию
Из AmoCRM достал телефон гостя и его имя
Собрал текст сообщения по шаблону квартиры
Отправил через Pact API в WhatsApp гостя
Записал в AmoCRM комментарий «Инструкция отправлена в 09:00»

День 0, время заезда. Сделка перешла в «Заселение» по расписанию. Гость получил «приятного отдыха, если что-то нужно, пишите менеджеру».

День 1-N, тишина. Никаких сообщений. Гость живёт.

День выезда, минус 4 часа. Сделка в «Выселение». Гость получил напоминание про чек-аут.

После выезда. Сделка в «Уборка». Уборщица получила в WhatsApp адрес и время.

Команда клиента весь этот цикл не трогала. Они открывают AmoCRM раз в день, смотрят воронку и вмешиваются только в исключения: ранний заезд, конфликт, отмена.

Что получилось

Полная автоматизация от брони до коммуникации с гостем. Команда не пишет шаблонные сообщения вручную.
Каждое сообщение с актуальными данными конкретной квартиры. Кода 1234 не уйдёт в квартиру, где код 5678.
Воронка в AmoCRM прозрачна. На любой стадии видно, что происходит с бронью.
Добавление квартиры это минутная операция. Заходишь в админ-панель бэкенда, заполняешь поля квартиры, она автоматически подхватывается в воронку.

Что не сработало

Pact для WhatsApp. Иногда WhatsApp Business API подвисает или отклоняет сообщения. Мы добавили retry с экспоненциальным бэк-оффом, это спасает в 90% случаев, но иногда сообщения всё равно не доходят. Фолбэк такой: менеджер получает уведомление, что сообщение не ушло, и отправляет вручную.

Telegram-боты не закрывают всех гостей. Около половины гостей не используют Telegram. WhatsApp в России работает, но с оговорками (часть аудитории его не использует или у них устаревшая версия). Идеального универсального канала нет, поэтому мы делаем мультиканальную отправку с приоритетом: Telegram, WhatsApp, SMS как фолбэк.

Webhook'и из AmoCRM иногда задерживаются. AmoCRM в редких случаях шлёт webhook с задержкой в 5-10 минут. Это не критично для нашей логики (мы не отправляем секундочные сообщения), но было неприятно при отладке.

Что я бы сделал иначе сейчас

Положил бы данные квартир в отдельный admin-инструмент. Сейчас они в Postgres, и для редактирования нужен разработчик. Я бы построил мини-админку на тех же Next.js и подключил её к этой базе. Клиент бы сам редактировал квартиры, без обращения к нам.

Добавил бы AI-агента для нестандартных ситуаций. Сейчас «ранний заезд» переводит сделку вручную. AI-агент в Telegram-боте мог бы вести диалог с гостем, понимать, что он просит ранний заезд, и сразу переводить сделку. Технологически это решаемо (мы похожее делаем в MeerBot). На момент проекта стек ещё не дозрел.

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

Когда такое решение подходит

Если у вас:

Бизнес с повторяющейся клиентской коммуникацией (аренда, доставка, обучение, услуги по графику)
Множественные точки, филиалы, объекты с уникальными параметрами (как квартиры в этом кейсе)
Несколько источников лидов или заказов
Команда, которая зашивается в шаблонных сообщениях

Это рабочий шаблон. Конкретный стек можно заменить (вместо AmoCRM Bitrix или amoUSe, вместо RealtyCalendar другой инструмент по нише). Логика остаётся: разделить интеграции, иметь центральную базу данных по объектам, связать воронку CRM с собственным бэкендом для подстановки актуальных данных.

Что дальше

Думаете автоматизировать клиентскую коммуникацию или CRM-процессы? Напишите мне, обсудим вашу цепочку, посмотрим, что можно убрать из ручного режима. Если хотите грубо понять бюджет, калькулятор поможет за минуту.