Автоматизация возвратов и перебронирований: как турагентству выстроить цифровой процесс

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

Карточка заказа как единица учёта

Чтобы понять, что положено клиенту — возврат, доплата или перебронирование без доплаты, — агентству нужна не заявка на возврат, а состояние заказа: статус (действующий, изменённый, отменённый), правила применённого тарифа, плательщик и тот, кто отвечает за фактическое проведение возврата. Последний пункт важен отдельно. Если агентство — merchant of record, то есть само списывало деньги с карты клиента, отвечать за корректный возврат стоимости билета при отмене или существенном изменении рейса будет оно, а не авиакомпания. Для дополнительных услуг, оформленных отдельно, правила возврата могут не совпадать с правилами по перелёту, и это тоже должно быть видно в карточке заказа, а не выясняться в переписке с клиентом постфактум.

Что уже описано в отраслевых стандартах

Собирать такой процесс с нуля агентству не обязательно: операции для возврата и перебронирования уже описаны в стандартах IATA NDC. Стандарт задаёт обмен данными между авиакомпаниями и продавцами через процессы Offer и Order и предназначен для стандартизации распределения авиапродуктов через разные каналы. Инициатива IATA ONE Order идёт дальше: она заменяет разрозненные записи — PNR, электронный билет, EMD — единым заказом, который используется на всех стадиях, от бронирования до обслуживания и учёта.

Набор возможностей NDC@Scale прямо покрывает сценарий возврата: можно запросить сумму, положенную к возврату по существующему заказу, отменить заказ с возвратом или без возврата, получить текущее состояние заказа и получить уведомление продавца о вынужденных изменениях, включая отмену рейса. Для сценария полной отмены заказа документация IATA описывает последовательность из трёх шагов:

1. получить заказ;
2. запросить сумму к возврату по выбранным элементам заказа;
3. только после этого отправить запрос на отмену.

Сценарий: изменение расписания по инициативе авиакомпании

Практическая логика видна в сценарии обслуживания при изменении расписания, который описывает IATA. Авиакомпания уведомляет продавца об изменении, продавец должен предложить клиенту один из вариантов: принять изменение, оформить новое бронирование или отменить маршрут с возвратом. Тот же стандарт предусматривает передачу данных о доплате или остаточной сумме — агентство получает цифры, достаточные для расчёта, а не только уведомление о том, что рейс изменился.

Добровольно или вынужденно: развилка, от которой зависит всё дальше

Прежде чем что-то считать, процесс должен ответить на один вопрос: кто инициировал изменение. Если сигнал пришёл от авиакомпании или другого поставщика — отмена рейса, существенное изменение расписания, уведомление о вынужденных изменениях через NDC — это одна ветка обработки. Если инициатива исходит от клиента, который просто передумал, — это другая ветка. Именно она определяет, распространяются ли на ситуацию обязательства вроде правила DOT об автоматическом возврате или права выбора в ЕС: правило DOT касается отмены или существенного изменения рейса перевозчиком, а право выбора в ЕС — отмены рейса и случаев, которые правила ЕС приравнивают к отмене. Решение самого пассажира под эти нормы не подпадает.

После того как изменение классифицировано, расчёт суммы опирается на те же операции, что описаны в NDC@Scale и в сценарии полной отмены заказа: запросить сумму, положенную к возврату по конкретным элементам заказа, и затем оформить отмену. Классификация на этом шаге и определяет, какая сумма и какой срок возврата применяются дальше: при вынужденном изменении агентство, выступающее merchant of record по этой покупке, обязано действовать по срокам регулятора, а добровольный отказ клиента такой обязанности не создаёт.

Уведомление клиента и контроль сроков

После того как сумма определена, процесс должен довести дело до конца: сообщить клиенту статус и уложиться в срок. Для авиабилетов на рейсы в США, из США или внутри США срок возврата зависит от способа оплаты:

Эти сроки касаются не только авиакомпании, но и ticket agent — то есть агентства, если оно оформляло операцию. Здесь снова имеет значение статус merchant of record: если деньги с клиента списывало агентство, обязанность вернуть их в срок и в исходной форме оплаты лежит на агентстве, а не перекладывается на авиакомпанию по умолчанию; для дополнительных услуг, оформленных отдельно, эта обязанность у агентства может не возникать даже при статусе merchant of record.

Где автоматизация заканчивается

Даже при наличии стандартов и API возможности автоматизации ограничены тем, что поддерживает конкретный поставщик, GDS или консолидатор. Показательный пример — Self-Service API Amadeus: через Flight Order Management API можно отменить бронирование, пока билет не выписан. Но как только билет выписан, изменения и возвраты по такому бронированию обрабатываются уже не через API, а офлайн, через консолидатора.

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