Dev:Travel assistance service requests - Process flow

PAX Operations Portal main process

Core process & phases

Each travel assistance service request always follows this process flow pattern:

1. Request definition phase - Passengers (PAX) or their travel agents creates and edits the travel assistance service requests through an instance of a PAX Portal instance. Once the request is completed, the passenger digital contacts the OC digitals with its request.
2. Claim phase - This phase is happening entirely in the backgound and is implemented as part of the . requests is received by one or multiple travel assistance operation centers (OC). It holds a travel itinerary consisting of multiple travel segments and a list of requested travel assistance services. Now each OC can claim responsibility for one or mulitple travel segments of the itinerary. This is done automatically in the background without human interaction.
3. Processing phase - From now on, the travel assistance operation centers (OC) are processing the request within their Travel Assistance Service Management Suite and
   • may request further information from the PAX regarding the segments and services they have claimed responsibility for
   • fetch information from internal systems to see if services can be delivered at all
   • may decide on if the service for one or all segments can be performed or is rejected
   • may request a decision by special staff (e.g. doctors) , if the service can be performed or is rejected
4. Collection phase - Once all information was collected and the service was considered performable, it may require money collection. In this phase the OC facilitates the money collection process. After this is performed the service is granted and the OC is monitoring and perfoming tasks to implement the service.
5. Service delivery phase - During this phase the OC monitors the service delivery and performs actions to make sure that everything works out. The service delivery partner digitals use the PAX service delivery partner portal.

Communication patterns

MT-Message “TAC.TravelAssistanceRequest.Info”

(From Passenger Digital to LH MOC FRA and other MOCs)

TravelAssistanceRequest is created  or updated in MOC Digital!

à Analysing itinerary

·       Number of relevant segments to which this OC is responsible 1

FRA-BEG (LH)

à TAC.TravelAssistanceRequest.ClaimSegmentResponsibility

·       Number of irrelevant segments to which this OC is not responsible 2

BEG-ZRH (LX), ZRH-FRA (LX) à TAC.TravelAssistanceRequest.NameSegmentResponsibleOCDigitals

·       Subjourney detection

1. FRA-BEG

2. BEG-ZRH (LX), ZRH-FRA (LX)

Criterion: disembarkation port == last port of journey || disembarkation port != next segment boarding port ||  layover between disembarkation port and next embarkation time > 24h

·       Embarcation relevant ports à FRA (relevant), BEG (not relevant)

·       Disembarcation relevant ports à  BEG (relevant), FRA (not relevant)

à Create Travel Service Request in LH MOC FRA

à Create local segment based service product entries

·       segment x requested services

·       ditch segments, which do not support this service

à send to PAX Portal message, that service is not supported for this segment

·       For all other create segment-service-requests and associate them with the

Travel Service Request. Set status of segment-service-request to ”created”

à TAC.SegmentServiceRequest.Info

From here the service processing engine takes over on OC Digital side. It uses the

TAC.SegmentServiceRequest.Info to notify the patient on updates of the service segment requests. The patient digital then checks if the full TravelAssistanceRequest status has changed and propagates it to all participating MOCs.  

Related articles

• Kordeus.PAX