96 000 $ в год за PMS, которая считала деньги мимо

Готовая система брала 16 $ за квартиру в месяц. На парке в 500 квартир — 96 000 $ в год. И при этом неправильно считала выплаты собственникам.

96 000 $ в год → 3 000 $

Коротко

Что было

Готовая PMS брала 16 $ за квартиру в месяц — 8 000 $ на парке в 500 квартир, и сверху шла подписка Monday: расширить PMS было нельзя, поэтому уборки и часы клинеров вели на отдельной доске. При этом она считала выплаты собственникам без НДС и без части комиссии Booking.com и не хранила даже вместимость квартир.

Что сделали

Переводим компанию на собственную систему постепенно, квартира за квартирой, не останавливая работу. Переключили площадки на нашу базу, пересадили динамическое ценообразование на партнёрскую интеграцию, запустили свой сайт бронирования и операционку с уборками, посадили ИИ на первую линию переписки с гостями, а расчёт с собственниками пересобрали по строкам учёта.

Что болело

Компания управляет посуточной арендой в Великобритании. Пятьсот квартир. Вся операционка жила в готовой PMS: календари, брони, гости, расчёты с собственниками.

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

Система брала 16 $ за квартиру в месяц. На пятистах квартирах это 8 000 $ ежемесячно и 96 000 $ в год — за софт, который последние годы не менялся. Сверху шла подписка Monday, потому что без неё операционка не жила.

Но дорогая подписка — не главная претензия.

Система считала деньги неправильно

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

В этой формуле нет НДС. И нет дополнительных 2–2,5 %, которые Booking.com берёт сверх основной комиссии. То есть каждый месяц, по каждой квартире, по каждой броне выплата расходилась с реальностью.

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

И чего в ней просто не было

39 квартир без названия

Назывались «Untitled», а те, что назывались, дублировали друг друга. Найти нужную в списке — отдельное упражнение.

Валюта не заполнена у 44 из 166

У четверти активных квартир в системе не указано, в чём считать деньги. Систему это не смущало.

Время выезда пустое у 39 из 166

В базе лежит «0» или пусто, хотя в интерфейсе у той же квартиры стоит 11:00. Уборку по такому не спланируешь.

Тип жилья не заполнен ни у кого

Пусто во всех строках без исключения — квартира, дом или студия, система не знала.

Вместимости нет вообще

Сколько человек помещается в квартиру — такого поля в системе не существует. А это первое, что спрашивает гость.

Часовой пояс тоже пуст

Для бизнеса, где всё завязано на время заезда и выезда, — странное место для пробела.

Что сделали

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

Тот же парк на новой системе стоит 250 $ в месяц — 3 000 $ в год вместо 96 000 $. Подписка Monday отпала совсем: операционка теперь внутри. И это до того, как посчитаны прямые брони без комиссии площадок и выплаты собственникам, которые наконец сходятся.

01.

Переезд без потерь и без остановки

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

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

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

Квартиры переезжают по одной, видно, что уже переехало
02.

Площадки берут данные из нашей системы

Раздачей на Booking.com, Airbnb, Expedia и Vrbo занимается channel manager — отдельный сервис, который умеет разговаривать с каждой площадкой. Свою интеграцию с ними писать не нужно и не надо.

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

Источник правды один. Правки, сделанные в чужом интерфейсе, перезапишутся следующей отправкой, и это осознанно: как только источников становится два, они начинают расходиться.

Каждая отправка и каждый ответ пишутся в журнал. Раньше на вопрос «а ушла ли новая цена на Booking» ответа не было вообще. Теперь ошибка не роняет операцию — она становится видимой задачей для оператора.

Цена меняется у нас — площадки забирают её сами
03.

Динамические цены переехали вместе с нами

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

Очевидный путь — подключиться к нему клиентским API и разрешить писать цены прямо в channel manager — разобрали и отбросили. В таком режиме он становится вторым писателем: не знает про ручные фиксации цены оператором и молча перезаписывает их на площадках. А так как цены обратно никогда не читаются, этого бы никто и не заметил.

Поэтому написали интеграцию по партнёрскому протоколу — нашу PMS он видит так же, как видел бы любую коммерческую. Мы отдаём квартиры, календарь и брони, он присылает рекомендованные цены обратно нам. В каналы он не пишет ничего. Ручная фиксация цены оператором живёт до заданной даты и всё это время перебивает автоматику.

Заодно появилось то, чего раньше не было: история цены. Каждое изменение пишется с пометкой «было, стало, кто поставил».

Алгоритм присылает рекомендации, фиксация оператора их перебивает
04.

Свой сайт бронирования

Все брони приходили с площадок, каждая уносила 15–18 % комиссии. Собственного канала продаж не было: даже повторные гости бронировали через Airbnb.

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

Доступность перепроверяется вживую перед расчётом и перед оплатой. Гонка с площадкой превращается в честное «дата только что ушла», а не в двойную бронь.

Свободные даты перепроверяются перед оплатой
05.

Уборки рождаются вместе с бронью

Раньше уборки жили на отдельной доске в Monday, а часы клинеров сводили руками в конце месяца. Доска не знала про брони, брони не знали про доску — связь держалась на человеке, который помнил и то и другое.

Теперь появилась бронь — тут же появились заезд, выезд и задача на уборку, поставленная на момент выезда. Одинаково для брони с площадки и для прямой. Отдельной доски и отдельной подписки под это больше не нужно.

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

Клинер сдаёт отчёт по факту. Если фактические часы разошлись с плановыми, отчёт не уходит в оплату, пока супервизор его не проверит. Свою зарплату клинер видит сам: часы на ставку, по месяцам, и только свою.

Задача появляется сама, человека на неё ставит менеджер
06.

Деньги считаются правильно

Ради чего всё и затевалось. Платёж гостя раскладывается на строки учёта: проживание, сборы, налоги, комиссия площадки, скидки, платежи и возвраты. НДС и дополнительная комиссия Booking.com теперь на своих местах, а не выброшены из формулы.

Комиссионная модель привязана к квартире журналом с датами: поменялась в середине месяца — расчёт сам разрежется по границе.

Собственник видит расчёт в своём кабинете и больше не пишет «а откуда такая сумма».

Платёж гостя раскладывается на строки учёта
07.

ИИ на первой линии переписки

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

Теперь простые вопросы берёт на себя ИИ, а всё, что выходит за рамки, отдаётся менеджеру. Все обращения к моделям идут через один общий слой: реестр промптов, защита от подстановок в текст гостя, таймауты, повторы и учёт стоимости в одном месте.

Простое закрывает ИИ, остальное уходит менеджеру

Цена вопроса

Было96 000 $в год за чужую PMS16 $ за квартиру в месяц, и сверху отдельная подписка Monday
Стало3 000 $в год за свою систему0,50 $ за квартиру в месяц, Monday больше не нужен

Экономия — 93 000 $ в год. Прямые брони без комиссии площадок и сошедшиеся выплаты собственникам здесь не посчитаны.

Что из этого умеет ИИ-ассистент

Главная работа здесь не «переезд с PMS», а связь между системами: площадки, цены, уборки, банк и переписка перестали жить порознь и начали передавать данные друг другу сами.

Это одно из шести применений ИИ-ассистента для бизнеса. Украинскому бизнесу та же история знакома по связке CRM, бухгалтерии, склада и Новой Почты: системы разные, а человек посередине один и тот же.

Результат

Показатель
До
После
Платёж за софт
8 000 $ в месяц плюс Monday
250 $ в месяц
Расчёт выплат собственникам
без НДС и части комиссии
по строкам учёта
Откуда площадки берут цены
из старой PMS
из нашей, с журналом каждой отправки
Динамические цены
привязаны к чужой PMS
своя интеграция и история цены
Комиссия на прямой броне
15–18 %
0 %
Задачи на уборку
отдельная доска в Monday
появляются вместе с бронью
Простые вопросы гостей
набирал человек
отвечает ИИ
Зависимость от чужого API
критичная
нулевая, данные у нас

Похожая задача?

За 30 минут разберём ваши процессы и скажем, что из этого можно повторить у вас.