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 хвилин розберемо ваші процеси і скажемо, що з цього можна повторити у вас.