Special Service Requests (SSRs)

Owned by Vanni Sanvincenti
Last updated: 26 Jul 2023 by Mladenka Vukmirovic
3 min read

Overview

Special Service Requests (SSR) are best described as snippets or strings of information in an Airline Reservations System that are formatted for programmatic use and ingestion to describe a service or additional piece of information that is required about the passenger. Initially SSR’s were used for special requests (such as a wheelchair request) at the Airport and are only sent to carriers participating in the Itinerary prior to travel. However, their flexibility has lead them to be used for a variety of purposes over the years and are used to store non service related items, such as email addresses, postal address, GST information, disabled information etc. In the move to distribution over XML using the standards set forth by the Offers and Orders Groups, the notion of a traditional ‘SSR’ as a formatted string does not conform to the transmission standards of today where XML, JSON or other is being used.

This section describes how the SSR information should be modelled and carried through new distribution messages.

The benefit of mapping the SSR information into the model allows for:

  • A standardized way for Sellers to request and receive services

  • A richer model for information to be broadcast and received

  • The ability for a Seller to interact with a carrier using a PSS and SSRs and a Carrier using an Order Management system in the same manor

  • Minimal impact for a Seller if an airline changes their internal service delivery fulfilment.

This section will detail how SSR’s that are used today and how they should be mapped to an XML message for Sellers and interline parties to understand and use. The use of an SSR within the context of an XML message will enable the reconstruction of an SSR on either side. There is no loss of information, but a standardized way to communicate this information across parties.

Categorisation

SSR’s have been broken into multiple categories to best determine their mapping to an XML message. The following categories have been created and used to describe the function of the SSR within Enhanced Distribution.

Service

An SSR will be defined as a Service if it:

  • A SSR that delivers a ‘service on demand’ and which may follow through as a service item in an Order Management system.

  • An SSR that does not require specific information over that of a ServiceDefinition as modelled in the AIDM.

All Service SSR’s will be mapped to a Service Item using the format set forth in Service items Section.

Note

Note that a Service may also require ‘Information’ and has been described so within the Services Section

 

Information

  • A SSR that does not deliver a specific service to the passenger.

  • A SSR that has specific data requirements outside the scope of a ServiceDefinition.

All Information SSR’s will be mapped depending on their attributes in existing elements or added to the Offers or Order Group queues to add missing information. Each implementation will be specific as they require specific information.

Information SSR’s can be further Categorized into the following areas:

  • Offer Related,

  • Payment Related,

  • Passenger Related (Info or Preference).

Obsolete

A SSR that is no longer relevant within Enhanced Distribution (for example a some of the OTHS SSR’s that are used today as a messaging vehicle to call for action from Airlines to Agents).

Airline Own

Airline specific SSR’s will not be mapped within, however the principle for mapping (service / Information etc) should be treated as the same.

Other

SSR's that do not fit in the above categories.