Що писати гостю, якщо він знайшов ціну дешевше на OTA

О 22:14 у вхідних з’являється повідомлення:

«Добрий вечір. Хотів забронювати у вас напряму, але на Booking цей самий номер на 1 180 грн дешевший. Додаю скриншот. Чому на вашому сайті дорожче?»

На скриншоті видно знайомі фотографії номера, дати й перекреслену ціну. У правому верхньому куті — майже розряджений телефон. Гість, імовірно, відкрив уже п’ять вкладок і хоче завершити пошук сьогодні. У готелю є кілька хвилин, щоб показати не «найкращу техніку заперечень», а якість власної роботи.

Найгірші відповіді народжуються саме з поспіху: «У нас ціна правильна», «це Booking щось накрутив», «бронюйте там, якщо дешевше» або поспішна знижка без жодної перевірки. Перша фраза заперечує те, що гість бачить. Друга перекладає відповідальність. Третя зачиняє прямий канал. Четверта може приховати системну помилку й привчити команду торгуватися замість керувати тарифами.

Правильна відповідь має іншу послідовність: подякувати → відтворити точний кошик → визначити тип розбіжності → чесно пояснити або визнати її → запропонувати рішення → залишити один наступний крок.

Це не сценарій «перемогти OTA». Це спосіб допомогти людині порівняти справді однакові пропозиції й зберегти довіру незалежно від того, де завершиться бронювання.

Спочатку дайте гостю відчути: його не збираються переконувати всупереч фактам

Перша відповідь не повинна починатися з виправдання. Почніть із вдячності та короткого зобов’язання перевірити.

Базова перша відповідь
Дякуємо, що надіслали скриншот. Ви правильно робите, що порівнюєте повну вартість перед бронюванням. Я зараз звірю однакові дати, номер, склад гостей, умови скасування, харчування та остаточну суму — і повернуся до вас із конкретною відповіддю протягом 10 хвилин. Будь ласка, надішліть ще посилання на пропозицію, якщо воно відкривається у вас. Особисті й платіжні дані на скриншоті можна закрити.

У цій відповіді немає обіцянки «ми точно зробимо дешевше». Є щось цінніше: гість бачить, що його спостереження прийняли як факт для перевірки, назвали критерії та встановили строк.

Якщо команда не працює вночі, не вигадуйте миттєву перевірку. Напишіть точний реалістичний час: «Перевіримо до 09:30 за місцевим часом». Але якщо номер може зникнути, скажіть і про це без штучного тиску: «Наявність і ціни можуть змінитися до моменту перевірки; ми зафіксували ваш запит, але поки не можемо утримувати номер».

Порівнюйте не цифру, а весь кошик

«Той самий номер» на двох екранах часто виявляється двома різними продуктами. Ціну формують не лише категорія й дати. Потрібно відтворити пропозицію так, як її бачив конкретний гість о 22:14:

• точний об’єкт і тип номера;

• дати, кількість ночей, кількість дорослих і дітей, вік дітей;

• кількість номерів;

• харчування та інші включення;

• строк і вартість скасування;

• передоплата, момент списання та можливість зміни;

• усі обов’язкові податки й збори;

• валюта показу, валюта списання та можливий збір банку;

• статус входу в обліковий запис, рівень програми лояльності;

• мобільний, географічний, партнерський чи закритий тариф;

• промокод, бонус, кешбек або знижка, яку фінансує не готель;

• час перевірки й доступність пропозиції зараз.

Це не бюрократія. Навіть умови Booking.com для порівняння ціни визначають «однаковість» через той самий об’єкт і тип розміщення, дати, кількість гостей, план харчування, політику скасування та інші умови. Там же пояснено, що частину знижок може фінансувати сама платформа, а деякі пропозиції доступні лише учасникам програм, після входу або за іншої дії користувача.

Політика точності цін Google Hotel Center застосовує ту саму логіку з іншого боку: ціна після переходу має відповідати вибраним датам і заповнюваності, бути реально доступною для бронювання, містити обов’язкові платежі й чітко показувати умови повернення. Google окремо підтримує умовні та приватні тарифи, які можуть залежати від пристрою, країни, мови, входу в обліковий запис або членства. Тому різні люди справді можуть чесно бачити різні ціни.

Шість причин однієї розбіжності

Не кожен нижчий тариф є помилкою, і не кожна різниця є «нечесною знижкою». Практично корисно класифікувати випадок до того, як команда обере тон і компенсацію.

Класифікація потрібна не для внутрішньої статистики заради статистики. Вона не дає команді назвати «помилкою OTA» те, що виявилося власним неправильно налаштованим тарифом, і не змушує дарувати знижку, коли дешевша пропозиція є неповоротною, без сніданку та з негайною оплатою.

Відповідь складається з шести рухів, але звучить як нормальна людська розмова

Після перевірки не надсилайте гостю звіт на дві сторінки. Зберіть відповідь у коротку дугу.

1. Подяка: «Дякуємо, ви справді знайшли нижчу суму».

2. Відтворений кошик: «Ми порівняли номер, дати, двох гостей і фінальну оплату».

3. Тип розбіжності: «Нижча ціна діє після входу в програму лояльності» або «це наша помилка синхронізації».

4. Чесне пояснення: лише те, що підтверджено даними.

5. Рішення: зрівняти тариф, виправити ціну, пояснити відмінну цінність або дозволити гостю спокійно обрати OTA.

6. Один наступний крок: одне посилання, одне «підтвердіть», одна передача працівникові — не меню з п’яти варіантів.

Важлива деталь: пояснення не повинно звучати як лекція про дистрибуцію. Гостеві не потрібно знати вашу комісію, договір із channel manager або внутрішню тарифну сітку. Йому потрібно зрозуміти, чи порівнюються однакові умови, скільки він заплатить і що робити зараз.

Готові відповіді для шести реальних випадків

1. Пропозиції різні за умовами

Дякуємо — нижча ціна на скриншоті справді є. Ми звірили пропозиції: на OTA тариф оплачується одразу й не повертається, а на нашому сайті доступне безкоштовне скасування до 18:00 12 вересня та оплата пізніше. Номер, дати й кількість гостей однакові; різниця саме в гнучкості. Якщо вам підходить неповоротний тариф, ось пряме посилання на наш еквівалентний варіант за ___ грн. Якщо важлива можливість скасування, залишаємо гнучкий тариф за ___ грн. Який один із двох зафіксувати для вас?

2. OTA показує тариф після входу, мобільну або власну знижку

Ви праві: у вашому обліковому записі OTA відображається ___ грн. Ми перевірили однакові дати й умови. Це закрита/мобільна пропозиція платформи, доступна за вашого статусу; частина зниження не відображається як наш публічний тариф. Ми не будемо називати її помилковою. Напряму можемо запропонувати ___ грн і ___ [лише реальна включена перевага]. Якщо для вас головне саме найнижча фінальна сума, можете безпечно обрати доступний вам тариф OTA.

3. На прямому сайті справді дорожче, і готель зрівнює ціну

Дякуємо, що допомогли це помітити. Ми відтворили той самий кошик: [номер], [дати], [кількість гостей], однакові умови скасування. На нашому сайті справді була вища ціна — це наша помилка, не ваша. Ми виправляємо налаштування й готові підтвердити вам пряму ціну [сума] грн. Ось захищене посилання; воно діятиме до [час] за місцевим часом, якщо номер залишатиметься доступним. Перейти до оформлення?

4. Готель не зрівнює ціну

Дякуємо за скриншот. Ми перевірили: пропозиції зіставні, і зараз OTA справді дешевша на ___ грн. Ми не можемо чесно пообіцяти таку саму суму напряму. Наш прямий тариф становить ___ грн і включає ___ [назвати лише вимірну відмінність]. Якщо ці додаткові умови вам не потрібні, розуміємо вибір нижчої ціни на OTA. Якщо потрібні — я можу надіслати одне пряме посилання на оформлення.

Чесне «не можемо» краще за вигадані переваги на кшталт «краще ставлення до прямих гостей». Сервіс не повинен залежати від каналу бронювання, якщо готель не заявив прозорих і законних умов тарифу.

5. Розбіжність спричинили податки, збори або валюта

Ми звірили фінальний крок обох бронювань. На першому екрані OTA показано [сума] грн, але після додавання обов’язкового збору [сума] грн остаточна сума становить [сума] грн. На нашому сайті фінальна сума [сума] грн уже містить [податки/збори]. Для точності порівняли обидві пропозиції в [валюта] за курсом або правилом, показаним перед оплатою. Ось короткий розрахунок і пряме посилання. Якщо на вашому фінальному екрані сума інша, надішліть, будь ласка, обрізаний скриншот без імені, номера бронювання та платіжних даних — перевіримо ще раз.

6. Гість уже забронював через OTA

Дякуємо, бронювання через OTA вже підтверджене, тому ми не радимо його скасовувати або створювати дубль. Збережемо чинні умови й перевіримо, чи передбачає платформа процедуру порівняння ціни для вашого бронювання. У Booking.com, наприклад, така процедура залежить від однаковості умов і правил самої платформи. Ось де можна звернутися до її підтримки: [посилання]. З боку готелю ми підтверджуємо, що ваше бронювання №[номер] бачимо / ще не отримали в системі — оберіть правдивий варіант. Якщо хочете, я перевірю статус і відповім одним повідомленням до [час].

Не пропонуйте гостю скасувати чинне OTA-бронювання, щоб «перебронювати дешевше напряму». Умови Booking.com прямо вказують, що можливість і вартість скасування залежать від політики конкретного тарифу; скасування може також позбавити гостя права на їхню процедуру Price Match. Дубль здатен залишити людину з двома списаннями або без номера в момент, коли інвентар оновиться.

Скриншот потрібен для діагностики, але не дає права збирати все, що на ньому є

Для перевірки достатньо бачити об’єкт, тип номера, дати, склад гостей, включення, умови, валюту, фінальну суму, час і ознаку закритого тарифу. Не потрібні повне ім’я, електронна адреса, номер телефону, номер бронювання, QR-код, дані картки, баланс бонусів або інші поїздки.

Просіть гостя обрізати або закрити зайве. Якщо скриншот уже надійшов, не пересилайте його в загальний чат команди. Збережіть лише там, де це потрібно для розгляду, обмежте доступ і строк зберігання. Це практичне застосування принципу мінімізації: стаття 5 GDPR вимагає, щоб персональні дані були адекватними, доречними й обмеженими необхідним для мети.

Внутрішній запис може виглядати так: «14.08, 22:14; Deluxe King; 20–22.09; 2 дорослих; OTA нижче на 1 180 грн; ознака мобільного або закритого тарифу; URL; перевірено 22:21». Цього достатньо для тарифної діагностики. Фото паспорта, картки чи повний екран облікового запису — ні.

Не звинувачуйте OTA — навіть коли причина на її боці

Фраза «платформа демпінгує» може бути неправильною: знижку здатна фінансувати OTA, тариф може бути умовним, а показ — персоналізованим. Booking.com прямо зазначає, що деякі цінові стимули фінансує сама платформа. Google документує допустимі тарифи за пристроєм, країною, мовою та статусом входу. Спочатку встановіть механіку, потім формулюйте висновок.

Так само не треба доводити, що прямий канал «за визначенням має бути дешевшим». У Європейській економічній зоні регуляторне поле справді змінилося: Європейська комісія пояснила дію DMA для Booking.com, за якою готелі можуть пропонувати кращі ціни й умови на власних та інших каналах. Але це можливість, а не обов’язок кожного готелю мати найнижчу пряму ціну в кожну секунду. Застосовність правил залежить від території та договору; ця стаття не замінює юридичної консультації.

Незалежно від юрисдикції, прозорість — добра операційна норма. Принципи CMA для онлайн-бронювання житла радять порівнювати знижки лише «подібне з подібним» і показувати загальну суму з усіма неминучими платежами. Гість не повинен розшифровувати вашу дистрибуцію, щоб зрозуміти власний рахунок.

Майбутнє — не в автоматичній знижці, а в автоматичному доказі

У найближчій моделі готельного вхідного каналу система не сперечатиметься зі скриншотом і не генеруватиме знижку навмання. Вона зможе витягти з дозволеного зображення параметри пропозиції, замаскувати зайві персональні дані, відтворити кошик у прямому модулі, позначити джерело кожної суми й показати працівникові ймовірну причину розбіжності. Але рішення про виняток, компенсацію або зміну тарифної політики залишиться в межах визначених повноважень.

Такий контур має зберігати не лише текст відповіді, а й доказ:

• що саме порівнювали;

• коли й у якому каналі перевірили;

• звідки взято ціну й умови;

• хто схвалив виняток;

• яке рішення запропонували;

• чи прийняв гість наступний крок;

• чи виправили першопричину для наступних гостей.

Не варто стверджувати, що будь-який AI Inbox уже робить усе це без інтеграцій і правил. Мовна модель може допомогти розібрати повідомлення й підготувати чернетку, але актуальна ціна має надходити з тарифного джерела, повноваження — з політики готелю, а остаточна відповідальність — мати власника. Саме про різницю між красивою відповіддю і керованим наступним кроком ми писали у статті «Логіка наступного кроку: як бот має доводити гостя до бронювання».

Перетворіть кожен скриншот на виправлення системи

Після відповіді гостю робота не закінчується. Позначте причину: різні умови, закритий тариф, валюта, податок, кеш, затримка channel manager, помилка прямого сайту або свідома стратегія. Якщо це помилка — створіть завдання власнику тарифу, перевірте інші дати й категорії, а після виправлення повторіть контрольний пошук. Якщо це нормальна відмінність — додайте команді коротке пояснення й затверджений сценарій.

Саме так одиничне повідомлення о 22:14 стає не приводом видати ситуативну знижку, а датчиком якості прямого каналу.

Гість не вимагає від готелю перемогти інтернет. Він просить пояснити дві цифри й не змусити його шкодувати про довіру. Подякуйте. Відтворіть кошик. Назвіть правду. Запропонуйте справедливе рішення. Залиште один крок.

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