Интернет сервисы для бронирования услуг путешественнику становятся все изощреннее.

Один из последних трендов — это единая корзина. Смысл корзины (единой / мульти, читатель может добавить определения исходя из своих предпочтений) простой — создать возможность, для путешественника, бронировать (оплачивать) бронировать, как авиауслуги, так и всяческие не авиа (аренда авто, проживание, трансфер и т.д.), накидывая их, как в интернет магазине, в единую корзину.

Я вам расскажу, про камни о которые спотыкается развитие данных технологий

Для авиаперевозок (технологическом лидере отрасли) все началось примерно 10 лет назад, когда American Airlines пытался продавать с online полный набор услуг; препятствий возникло множество:

• От сопротивления конкурентов — толи 200, толи 300 туристических агентств (с рассказа участника написания петиции) писали жалобу в сенат США (на тему гибели бизнеса туристических агентств);
• Но самое главное, на пути начинания American Airlines встала технологическая неготовность отрасли.

Путь к единой корзине

Год 2014, IATA (международная организация, устанавливающая стандарты в авиации) анонсирует в привычном месте проведения авиафорумов, в отеле Авиастар (там я услышал, впервые в публичном пространстве, данный термин) переход на новый стандарт NDC. И показывает картинку — корзинка, в которую сложены самые разнообразные услуги. Именно так в индустрию путешествий пришла корзина покупателя из e-commerce.

Комментарий: NDC — глобальная инициатива всемирной организации авиации, технологическая основа — переход от использования телеграмм к xml протоколу обмены данных. XML конечно упрощает интеграцию. Но основная цель — это рынок дополнительных услуг, его потенциал $150 млрд в год, а главное — билеты приносят очень маленькую маржу, а дополнительные услуги от 5 % (что уже выше доходности билетов), до 50 %. По словам владельца одного из американских туристических агентств — в их бизнесе авиабилет, это как молоко в супермаркете, денег не приносит, но должно присутствовать на полке, деньги же в другом.

Год 2017, запускаем в Аэрофлоте единую систему дистрибуции товаров для путешественника, с единой корзиной — к авиабилету в корзинку можно положить: проживание, аренду авто, трансфер, Аэроэкспресс, страховки (а так же дополнительные сервисы к каждой из этих базовых услуг).
Год 2018, готовлюсь к презентации на авиафоруме в Казани, делаю картинку, про то, как удобно устроено на сайте Аэрофлот: накидал услуг в корзинку и заплатил одним платежом, и как неудобно в S7, где каждая услуга, это отдельная покупка. Иду на сайт S7, перепровериться, не был на сайт пару месяцев, а там то же самое — можно купить единой корзиной сразу несколько услуг. Пришлось, в качестве плохого примера, использовать сайт Внуково, примерно вот так —



Год 2019, все начали работать по такому же стандарту, проектов завершённых пока немного, но только лично я знаю 4 проекта, которые в работе. Самое крупное — проект построения импортозамещающей GDS (какой не скажу, их две, запрещает всемогущий NDA).

Говоря просто: продажа через единую корзину — тренд. И тот, кто сегодня не научится работать с корзиной, завтра вынужден будет искать другую работу.

И вот тут то мы подошли к интересному — а как реально происходит переход к единой корзине.

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

На первый взгляд все хорошо — GDS переходят на xml, меняют структуры бронирования, проекты плодятся, всё чтобы жить по современному. Есть конечно аутсайдеры, вроде Leonardo PSS (Passenger Service System — это система в которой авиакомпания хранит все свои ресурсы: борта, рейсы, места; а хорошая PSS еще много что имеет), системы свежей, всего 5 лет ей. И тем не менее построенной на допотопных телеграммах, и про изыски NDC совсем не знающей. Это творение наших дней даже выгрузку расписания не умеет выполнять в автоматическом режиме, отгружают в ручную и зачастую кнопку нажать забывают и расписание не приходит, и тут включается ручная процедура созвона.

Но это аутсайдеры, живущие с импортозамещения. В целом… И тут не все хорошо. Этой осенью мне довелось задать вопрос главному технологу большого проекта построения российской системы бронирования (современной, даже с претензией на инновационность), какой подход они собираются использовать — GDS или маркетплейс. И тут напоролся на ответ: что в отрасли все уже есть и не надо тут ничего выдумывать. Первая мысль была: неудачно / не вовремя спросил. Но после нескольких подобных столкновений и после моих безуспешных объяснений, что дают современные подходы (это были столкновения не с одним сотрудником) я осознал глубину закостенелости отрасли.

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

Пример первый — подбор перевозки туда и обратно

Заходим на один из самых распространенных поисковиков — aviasales (простите ребята, я вас уважаю, это не камень в ваш огород) и ищем Москва-Стамбул, туда и обратно. Находим пачку предложений, но ни одно из них нас не удовлетворяет. Тут же мне хочется, как путешественнику, комбинировать перелеты самому. Но не дают. Почему? Очень просто.

Для туда и обратно GDS требует сформировать бронь RT – (round trip ticket) – авиабилет в обе стороны, т. е туда и обратно. Это не всегда возможно. Самый простой пример — вы агентский сайт и у вас несколько источников получения предложений на перелет. И Москва — Стамбул у вас в одном источнике. А Стамбул- Москва, у вас, в другом источнике. GDS говорит- ну что тут поделаешь… Но у нас то корзина маркетплейса и мы формируем нужный нам набор туда и обратно, и создаем две брони с типом OW – (one way ticket) – авиабилет в одну сторону, и присылаем пассажиру 2 маршрут квитанции. Все удобно, платиться одним взмахом.

Соответственно в заказе (для перелета туда и обратно), в нашей системе мы должны сформировать запись в таблицу orders: Заказы. В качестве основного идентификатора у нас используется не традиционный PNR, а order_n — номер заказа. И две записи в таблицу services: Услуги, обе с ссылкой через order_id на orders. В поле type_flight, для заказа, сформированного по правилам GDS, мы ставим признак типа перелета rt, не по правилам ow, в поле PNR в первом случае один идентификатор, во втором другой идентификатор. Тоже самое с ссылками на электронный билет и маршрут квитанцию.

Вот такая нехитрая конструкция позволяет, не нарушая правила отрасли, работать так, как нам нужно.

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

Пример второй — виртуальный интерлайн

Эта технология позволяет комбинировать перелеты различных авиакомпаний даже при отсутствии между ними соглашения и единых тарифов. Комбинировать, в смысле сформировать предложение на перелет, который выполняется с пересадками, т.е. если нет устраивающего вас прямого рейса и нет интересных пересадок, соберите себе предложение сами и получите вариант, который вас устраивает.

В этой схеме имеется засада, а именно обеспечение размещения пассажира при задержке рейса. Кто разместит пассажира, если задержат один из рейсов и кто возместит потери, если пассажир прилети Москва-Лондон, рейс Лондон-Эр-Риад задержат, и пассажир не успеет на рейс Эр-Риад-Джида, авиакомпании знать не знают про все эти стыковки и ничего пассажиру не должны. Но это уже бизнес технологии, а у нас тут ИТ ресурс.

Виртуальный интерлайн особенно интересен для аэропортов, имея подобную систему, можно расширить свою маршрутную сеть, включив перелеты фактически по всему миру. Но и конечно, наш любимый, агентский сайт (или просто агентство).

Перейдем к технической части

Правило — каждое полетное плечо это отдельная услуга, с точки БД, отдельная запись в таблице services. И с точки зрения сервисной модели, это разные услуги, которые могут независимо друг от друга обрабатываться, влияя, в основном сами на себя. И тип перелетов у них ровно тот, что передается в PSS, в основном OW. И PNR у каждого плеча свой. При кейсе, когда мы бронируем стандартный многосегментный перелет, т.е. по интерлайн соглашению, то записи в таблице на каждое плечо, а вот service_id у них общий, т.е. это единая услуга (как и PNR), а записи, ну так мы добиваемся стандартизации + мало ли что мы потом на придумываем на радость путешественнику, нужно атомизировать перелеты, с тем, что бы потом легче манипулировать данными. И не забудьте, в поле segment_number вписать номер полетного сегмента. И соответственно — если комбинировали сами, то билет выпускаем каждому сегменту; если же по интерлайн соглашению выпускаем единый билет, так сказать по количеству уникальных service_id.

Но это только записи в БД. Дальше интереснее, а именно — БАГАЖ, это на самом деле повод для отдельной статьи. Но поскольку тут мы не проектируем, а рассказываем, как про текущий тренд в одном из веточек великого дерева IT-технологий, то с нас хватит сказать, что самое сложное в данном деле — что делать с багажом.

Комментарий: только не в Шарль-де-Голле, тот очень большой, я ровно так опоздал на пересадку, хвала а…, в смысле толстой негритянке, которая меня всучила на борт, прямо на взлетной полосе.

Не вдаваясь в детали, скажем: надо интегрироваться с несколькими системами управления багажом, для обеспечения автоматизированной перегрузки багажа. Но тут опять явно выходим за рамки небольшой статьи. Укажем только, что в ныне действующих системах, после первого полетного сегмента, необходимо будет получить багаж в аэропорту, а потом сдать его снова на следующий сегмент. Что увеличивает минимальное время стыковки (грубо говоря, вам нужен не час на перегрузку багажа, а час на получение + час на сдачу), и вообще не use friendly.

Пример третий — корзина с добавление не авиауслуг

Читайте в следующей статье…