Информация в бронировании для связи с пассажиром

©Sergey Nivens Fotolia.com​

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

Эта очень важная тема уже затрагивалась в №3(42) нашего журнала за 2017 год. Мы вновь возвращаемся к коммуникационным форматам в связи с постоянно возникающими у наших читателей дополнительными вопросами, а также актуальными требованиями авиакомпаний.

Бронирование (Passenger Name Record – сокращенно PNR) – это сохраненный в системах бронирования и инвенторных программах авиакомпаний электронный документ, в котором, прежде всего, содержатся данные о пассажире: элемент имени, все зарезервированные перелеты и другие составляющие его путешествия.

В бронирование могут вноситься и другие данные о самом пассажире и о связанных с его путешествием запросами дополнительных услуг.

В каждом PNR, независимо от системы бронирования, должно быть сохранено 5 обязательных элементов. Одним из необходимых элементов является стандартный элемент контактной информации. Как и любой другой обязательный элемент, элемент контакта должен вноситься в бронирование в строго установленном формате.

Например, в ГДС Амадеус он вносится командой:

>AP <Х> <тире> <Адрес & Телефон>

На месте, обозначенном <Х>, может быть проставлена буква (H, B, M, E, A), обозначающая тип внесенного контакта.

Наряду с контактами пассажира очень желательно внести информацию для связи с туристическим агентством, создавшим резервацию, которая обозначается буквой <А>. В любом случае, в PNR должен быть внесен, как минимум, один элемент контакта в формате «АР».

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

Различными документами и постановлениями государств и авиакомпаний предусмотрено внесение некоторой дополнительной информации о пассажирах – называемой APIS («Advance Passenger Information System»). Сюда могут входить: номер и дата выдачи паспорта, сведения о визе, данные об адресе проживания в стране посещения и некоторые другие. Форматы и принципы внесения информации APIS достаточно подробно описаны в наших журналах №06 и №08 за 2010 год.

Резолюцией ИАТА 830d* от 1 января 2014 года рекомендовано внесение в бронирование информации о возможностях контакта с пассажиром в SSR-форматах, с одинаковым успехом читаемых в любой системе бронирования. В соответствии с этой резолюцией туристическое агентство должно (с согласия пассажира) внести в бронирование адрес его электронной почты и номер мобильного телефона.

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

Контактную информацию необходимо сохранять в SSR-форматах по следующим причинам:

• Форматы SSR – единственные форматы в PNR, которые «видны» как во всех системах бронирования, так и всем авиаперевозчикам, независимо от того, в какой АСБ была внесена информация и какую инвенторную систему имеет перевозчик.
• В случае задержек или отмен рейсов, изменении терминалов вылета, контактная информация, внесенная в PNR в формате SSR, позволяет оперативно и эффективно предоставить пассажиру возможные варианты альтернативного авиаперелета.

Контактная информация должна вносится во все системы бронирования в стандартном SSR-формате, который называется IRegular OPerations (IROP) Kontakt Information.

На основании актуальных требований ИАТА в системы бронирования введены 3 новых SSR-кода для внесения IROP-информации.

• SSR CTCE – код для внесения адреса электронной почты пассажира;
• SSR CTCM – код для внесения номера мобильного телефона пассажира;
• SSR CTCR – код, указывающий на то, что пассажир не разрешил вносить свои контакты в бронирование.

Непосредственно вслед за SSR-кодом и последующим разделительным <тире> в команду должна быть внесена определенная персональная информация, набираемая латинскими буквами в установленном формате. Например, информация об адресе электронной почты пассажира

• >SR CTCE–Andreas.Stein//Domain.com

где: Andreas.Stein//Domain.com – е-майл адрес пассажира, где знак «@», наличествующий в е-майл адресе, должен быть заменен на знак, состоящий из двух последовательных слешей («//»).

Другие специальные символы, применяемые в е-майл адресах, заменяются на:

• Нижнее подчеркивание – <_> заменяется на две точки <..>
• Тире – <-> заменяется на точку и слеш <./>

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

Информация о номере мобильного телефона пассажира записывается как сам номер телефона без всяких пробелов и других знаков. Очень желательно указывать международный телефонный код страны, в которой зарегистрирован мобильный номер. Например, для Германии это <0049>.

• >SR CTCM-004917323456789

А если пассажир отказался (не разрешил) вносить информацию в бронирование, то команда выгладит совсем просто:

• >SR CTCR – допускается внесение указанной команды безо всяких дополнительных сведений или с некоторыми уточняющими сведениями.

Например: SR CTCR-REFUSED TO GIVE CTC INFO,
или:  >SR CTCR-PSGR REFUSED TO SHARE DIRECT CTC/ACCEPTED LIMITED AIRLINE RESPONSIBILITY

Как дополнительная опциональная информация отделенная друг от друга слешами, CTC-форматы могут быть дополнены двухбуквенным кодом страны пассажира (например, для Германии <DE>) и номером пассажира в PNR, <Р1>, если в одном PNR забронированы несколько пассажиров. Например:

>SR CTCE-Andreas.Stein//Domain.com/DE/P1
>SR CTCM-00491732345679/DE/P2

Так выглядит бронирование в АСБ Амадеус, включающее все обязательные элементы, два дополнительных элемента контакта в формате АР и оба, предусмотренных резолюцией ИАТА, SSR СТС элемента.

Как видно, набранные команды в самом бронировании несколько изменили свой вид. В SSR-форматах автоматически добавилось обозначение авиакомпании (здесь – SU) и подтверждающий код <НК1>.

Теперь, в случае необходимости, авиакомпания может сообщить пассажиру информацию о переносе или отмене авиаперелетов, использовав сохраненные в PNR данные контакта. Необходимо отметить, что как при автоматическом, так и при мануальном выставлении авиабилетов, роботы (автоматизированные системы) и операторы консолидаторов, как правило, не проверяют наличие или отсутствие элементов контакта в бронированиях. И если у авиакомпаний не возникает необходимость срочно связаться с пассажиром, то отсутствие элементов контакта может остаться незамеченным. Но если при изменениях в расписании с пассажиром не удалось связаться из-за отсутствия элементов контакта, авиакомпании оставляют за собой право выставления виновникам соответствующих штрафов.

Дополнительную информацию к изложенному можно найти в «Amadeus Fares & Pricing User Guide» в Download Center des Amadeus Extranets.

Для помощи операторам, работающим в АСБ Сейбр, приводим список команд для ввода контактных данных пассажира в Сейбре.

Обязательный элемент контакта, который вносится в Амадеус командами <АР> в Сейбр, вносится командой, начинающейся цифрой <9>, например: >9 < номер телефона > <тире> <Х>

Где: «9» – это код для ввода в PNR стандартной информации о контактах. После <тире> на месте обозначенном <Х>, так же как и в ГДС Амадеус, вводится буква (H, B, M, E, A), обозначающая тип внесенного контакта. Все контакты, внесенные командой с кодом <9>, попадают в раздел бронирования, который обозначается «PHONES».

Далее приводим SSR СТС-форматы для внесения контактов в Сейбр:

Информация об адресе электронной почты пассажира:

>3CTCE/<Е-майл адрес пассажира> <тире> <номер пассажира в PNR>
>3CTCE/Peter.Schmidt//GMX.DE-1.1

или с кодом страны:

>3CTCE/<Е-майл адрес> / <код страны> <тире> <номер пассажира в PNR>
>3CTCE/Peter.Schmidt//GMX.DE/DE-1.1

Информация о номере мобильного телефона пассажира:

>3CTCM/<номер моб. телефона> / <код страны> <тире> <номер пасс. в PNR>
>3CTCM/004915269345678/DE-1.2

Информация об отказе пассажира предоставить свои контактные данные

>3CTCR/REFUSED TO GIVE CTC INFO-1.1

Необходимо обратить ваше внимание на то, что в самих вышеприведенных для ввода в Сейбр командах сокращение <SSR> отсутствует. Но после ввода команды, уже в самом бронировании, код <SSR> возникает в строке, описывающей внесенный контакт, и элемент бронирования выглядит точно так же, как и аналогичный элемент SSR в Амдеусе. В Сейбре контакты пассажира, внесенные в бронирование как в SSR-, так и в OSI-форматах, попадают в раздел бронирования, который обозначается «GENERAL FACTS».

А так выглядит бронирование в ГДС Сейбр с общей контактной информацией и персональной информацией пассажира, внесенной в PNR в формате SSR СТС.

Необходимо отметить, что некоторые авиакомпании требуют внесения «IRegular OPerations Kontakt Information» (IROP) в отличие от резолюции ИАТА 830d не в SSR-, а в OSI-форматах.

В связи с этим ниже приводятся форматы для внесения контактной информации в АСБ Сейбр и Амадеус в форматах OSI. Исходя из того, что основные принципы формирования команд в формате OSI практически не отличаются от команд в формате SSR, ниже будут приведены только готовые команды без подробного объяснения составляющих их элементов.

Итак, форматы OSI в АСБ Амадеус и их отображение в бронировании:

>OS SU CTCE – Empfaenger//Domain.com/P1
>OS SU CTCM – 004916012345678/DE/P2
>OS SU CTCR – REFUSED TO GIVE CTC INFO/P3

А в АСБ Сейбр форматы OSI вносятся и отображаются так:

3OSI SU CTCE/PETER.SCHMIDT//GMX.DE/DE-1.1
3OSI SU CTCM/004915269345678/DE-1.1
3OSI SU CTR/REFUSED TO GIVE CTC INFO-1.1

Как видно, при внесении команд в формате OSI, обязательно указывать двухбуквенный код авиакомпании, осуществляющей полет. Для групповых бронирований разрешается вносить  в PNR только е-майл адрес руководителя группы. Если забронированы совместно путешествующие пассажиры одной семьи или небольшой группы, разрешено сохранить контакты только одного взрослого пассажира. К сведению коллег, бронирующих полеты в системах В2В: вносимые вами сведения автоматически преобразуются  в необходимые SSR- или OSI-форматы.

В случае внесения в PNR только телефонного номера агента или иного номера, не принадлежащего пассажиру, ответственность за своевременное информирование пассажира несёт сам агент.

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

***

IATA – International Air Transport Association – Международная ассоциация воздушного транспорта – неправительственная организация, основной механизм для сотрудничества между авиакомпаниями в продвижении безопасных, надежных и экономичных воздушных перевозок в интересах потребителей.

*PARAGRAPH 830D „RESERAVTION PROCEDURES FOR ACCREDITED AGENTS”: ”The Agent should provide contact details on behalf of the passenger by entering in Name Record (PNR) of the passenger’s mobile phone number and e-mail address, while maintaining compliance with all applicable data protection directives and regulations. Contact details should be entered in the PNR in compliance with the Resolutions governing resevations procedures. Memebers and BSP Airlines shall use these contact details exclusively for the purpose of operational notifications and shall not use the contact details for sales and marketing purposes”.