Коли посередник стає стіною
Нещодавно мандрівник забронював рейс IndiGo через платформу AirAsia MOVE. Коли плани змінилися, він попросив скасувати поїздку. Авіакомпанія погодилася. На цьому історія мала б закінчитися. Натомість сама платформа відмовилася обробити скасування, залишивши пасажира в розриві між двома компаніями. Він висловив своє розчарування публічно, назвавши систему марною та безглуздою. Його гнів був емоційним, але він вказував на проблему, яка стосується мільйонів мандрівників, що покладаються на агрегатори для спрощення свого життя.
Цей інцидент — лише дрібний епізод у величезному механізмі онлайн-подорожей, проте він слугує гучним попередженням. Ми завантажуємо ці застосунки, щоб не доводилося маневрувати між сайтами авіакомпаній, платіжними шлюзами та кодами підтвердження. Ми очікуємо, що посередник сприятиме процесу, а не блокуватиме його. Коли платформа не може виконати скасування, яке авіакомпанія вже схвалила, вона не справляється зі своєю єдиною справжньою роботою: надійно передавати інформацію від користувача до постачальника послуг і назад.
Що пішло не так
Деталі цього випадку є простими, і саме це викликає занепокоєння. Пасажир не оскаржував прихований збір і не боровся з лазівками в правилах. Він виконав стандартну дію — скасував рейс — і зіткнувся з помилкою, якої не повинно існувати. IndiGo прийняла скасування. AirAsia MOVE — ні. Результатом стала класична ситуація, в якій програють усі. Мандрівник втратив час і спокій. Платформа втратила довіру.
Такий збій зазвичай стається глибоко в «внутрішніх механізмах», яких мандрівники ніколи не бачать. Онлайн-турагентства та суперзастосунки не зберігають інвентар авіакомпаній на власних серверах. Вони підключаються до авіакомпаній через інтерфейси програмування застосунків, або API, які передають дані туди й назад. Коли ви натискаєте «скасувати», ваш запит іде від телефону до бекенду агрегатора, а потім до системи бронювання авіакомпанії. Авіакомпанія оновлює статус бронювання та надсилає підтвердження. Агрегатор має негайно відобразити цю зміну та обробити ваше повернення коштів або кредитні одиниці на подорож.
Десь у цій ланцюгової реакції AirAsia MOVE заглючила. Можливо, API не зміг отримати оновлений статус із системи IndiGo. Можливо, внутрішня логіка застосунку містила жорстко прописане правило, яке скасувало відповідь авіакомпанії. Можливо, агенти служби підтримки бачили невідповідність на своїх екранах, але не мали прав для примусового виконання скасування. Ми не знаємо точного багу, але ми знаємо результат: людина опинилася в пастці програмного циклу, не маючи змоги скасувати транзакцію, яку всі сторони погодилися скасувати.
Чому довіра руйнується швидше, ніж виправляється код
Мандрівники терплять незграбні інтерфейси. Вони терплять повільне завантаження. Але вони не терплять безпорадності, коли на кону стоять гроші та плани. Скасування — це не легковажна вимога. Зазвичай воно стається через кризу — медичну проблему, сімейну надзвичайну ситуацію або раптові робочі конфлікти. Користувач уже перебуває у стресі. Роль застосунку — зменшити цей стрес, взявши на себе складність бекенду. Коли ж він замість цього створює нову перешкоду, емоційна ціна стає надмірною.
Ось чому публічний вибух емоцій пасажира має значення. Він не скаржився на відсутність балів лояльності чи затримку push-сповіщення. Він назвав платформу марною, тому що в момент, коли вона була йому потрібна найбільше, вона активно блокувала законний запит. Довіра до цифрових сервісів будується на переконанні, що система поважатиме ваші наміри, навіть якщо обставини змінюються. Один такий порушений обіцяний принцип завдає більше шкоди, ніж можуть виправити десять успішних бронювань.
Ця проблема також виявляє стратегічне сліпе місце в тому, як будується багато туристичних платформ. Інженерні команди часто вкладають ресурси у фронтенд: швидкий пошук, гарні календарі, оплату в один клік, персоналізовані пропозиції. Саме ці функції стимулюють завантаження. Операції після бронювання — зміни, скасування, повернення коштів — розглядаються як другорядні. Вони отримують старіші API, менше моніторингу та менше резервних варіантів. Але саме на цьому етапі користувачі дізнаються, чи є застосунок справжнім інструментом, чи просто блискучою брошурою.
Що туристичні платформи мають робити правильно
Тут є чіткі уроки для будь-якої компанії, що стоїть між клієнтами та авіакомпаніями.
Зробіть скасування такими ж простими, як і бронювання. Якщо користувач може забронювати місце за три натискання, він повинен мати можливість скасувати це, не блукаючи лабіринтами чат-ботів, прихованих меню та непідтримуваних форм. Процес скасування має бути прозорим, чесним щодо комісій і позбавленим «темних патернів», які змушують мандрівників почуватися винними або заплутують їх, спонукаючи зберігати бронювання, яке вони не можуть використати.
Створюйте механізми ручного керування, які справді працюють. Автоматизація чудова, поки вона не дає збоїв. Коли виникає конфлікт відповіді API або помилка синхронізації, агенти служби підтримки повинні мати повноваження та інтерфейс для втручання. Занадто багато платформ проєктують повністю автоматизовані фортеці без жодних дверей для людського втручання. У результаті агенти змушені читати за сценаріями, нескінченно вибачатися та надсилати запити у «чорні діри». Корисний механізм ручного керування означає, що агент може побачити підтвердження авіакомпанії, зіставити його із заблокованим бронюванням і здійснити скасування в режимі реального часу.
Підтримуйте програмне забезпечення в синхронізації з реальністю авіакомпаній. Потрібно відходити від пакетних оновлень та повільних циклів опитування (polling). Якщо авіакомпанія позначає квиток як такий, що підлягає скасуванню, поверненню коштів або перенесенню, агрегатор має дізнатися про це протягом хвилин, а не годин. Це потребує надійної архітектури webhook, логіки повторних спроб для невдалих з'єднань (handshakes) та процесів звірки (reconciliation), які виявляють невідповідності до того, як їх помітить користувач. Платформа ніколи не повинна дізнаватися про статус власного продукту останньою.
Що мандрівники можуть зробити вже зараз
Поки галузь не усуне ці прогалини, пасажирам потрібно захищати себе самостійно. Якщо ви бронюєте через будь-який сторонній додаток, включаючи такі великі, як AirAsia MOVE, зберігайте документальний слід. Робіть скриншоти номерів підтвердження, правил скасування та будь-якого листування з авіакомпанією. Вивчайте правила самої авіакомпанії перед покупкою; деякі перевізники дозволяють вносити зміни безпосередньо через свій вебсайт навіть для квитків, проданих партнерами. Якщо додаток не працює, звертайтеся безпосередньо до авіакомпанії. Коли публічні дописи стають резонансними, компанії зазвичай реагують швидше, ніж через приватні канали підтримки. А якщо заблокована значна сума коштів, не вагайтеся звертатися до форумів захисту прав споживачів або використовувати механізми чарджбеку (chargeback).
Головний висновок
Клієнтський досвід — це не шар глянцю, який ви наносите після написання коду. Це код, який працює належним чином, коли ситуація стає складною. Платформа бронювання, яка не може скасувати рейс, подібна до автомобіля без задньої передачі. Він може чудово їхати вперед, але рано чи пізно вам знадобиться виїхати назад із паркувального місця.
Мандрівники не просять магії. Вони просять інструменти, які виконують базові команди, не намагаючись ввести їх в оману. Нездатність AirAsia MOVE виконати скасування, яке IndiGo вже прийняла, є нагадуванням про те, що зручність є реальною лише тоді, коли працює весь ланцюжок. Поки туристичні платформи не інвестуватимуть у надійність після здійснення покупки так само масштабно, як у воронки залучення клієнтів, користувачі залишатимуться настороженими. І це правильно.