Travel assistance service request: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
← Older edit
VisualWikitext
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
Stefanseiler (talk | contribs)
Bureaucrats, dev-team, developer, Interface administrators, iroc-team, Suppressors, Administrators, yousee-team
1,381 edits
 
(37 intermediate revisions by the same user not shown)
Line 1: Line 1:
A ''travel assistance service request'' is created by a personal digital and is filed against one or multiple travel service operation centers, which claim responsibility for segments they are responsible for (by carrier assignment).
[[File:TAR standard management flow.png|thumb|standard assistance request flow|634x634px]]A ''travel assistance service request'' holds all information of a '''partient requesting assistance''' on its upcoming journey. Once filed, the [[Travel assistance service operation center digitals|travel assistance service operation centers]] in charge of requested segments will [[Dev:Travel Segment Service Item Claiming|claim responsibility]] for service delivery on segments and will open a travel assistance service request case, which is the leading data entity along the entire process flow from the request to service delivery.  


Each travel assistance service request holds:
== Case standard process flow ==
=== Flowtype A: Regular request ===


* Personal information and documents
# '''Request creation phase''' - the PAX or the travel agent collects all information on his side on a travel assistance service request before submitting it. As third alternative, the operation center enters the request manually after receiving a request over an insecure channel, like email. At the end of this phase, there exists a valid travel assistance service request case
* The planned [[Travel word definitions|itinerary]]
# '''Decision preparation phase''' - the operation center and the passenger collaborate on reaching the point where the request can be confirmed
* Travel assistance services, which are  requested for this [[Travel word definitions|itinerary]]
# '''Service delivery phase''' - the operation center coordinates the service delivery with its delivery partners
* [[Travel Segment Service Items]] - holding the detail information and are used to communicate with the operation centers (oc)
# '''Billing data acquisition phase''' - after ticket data has been entered, the operation center collects KPIs by which it can charge the carriers
* Status Information
** General status on travel assistance request (Header-Status)
** Travel Segment Service item status information


== Status information ==
Specialities:


=== Header status information ===
* '''Rebooking''' - If the flight is rebooked during the service delivery phase (for reasons on PAX or Carrier side), the request is pushed back with all information to the decision preparation phase and needs to reviewed entirely
This status is stored at the travel assistance service request (db) and is only edited by the personal digital, which is the single point of truth where all information come together.
* '''Cancellation''' - if the service delivery is cancelled by the PAX, the refund issues arise and may need communication with the PAX. This is covered in the cancellation phase.
{| class="wikitable"
!Status
!Process status description
|-
|In Preparation
|This SAR has been created, but has not been transmitted to the carriers
|-
|Submitted
|This SAR has been created and has been submitted by the passenger. The request has been sent to the operation centers of the carriers. The request is waiting until all segments have been claimed by authorative operation centers (OCs)
|-
|Processing
|All segments of the SAR itinerary have been claimed by responsible OCs.
|-
|Requires action
|At least one segment-service requires further action. (see service segment status)
|-
|Decided
|All segment-services have been processed and confirmed or rejected
|}


=== Travel Segment Service Item status information ===
=== Flowtype B: General inquiry ===
From the information provided in the system creates a segment service map by multiplying the segments with the requested services. Once the carriers have [[Dev:Travel Segment Service Item Claiming|claimed their segments]], they are responsible on providing to each of the segment service these information:


==== Travel Segment Service Item - General Availability Status ====
# '''Request creation phase'''
Some services are by design not possible. The service segment general availability is then '''false.''' This status is automatically computed by the information provided in the [[App:Travel assistance service administration|travel assistance service administration app]] by each operation center after the segment was claimed.  
# '''General request answering phase''' - the operation center has received no concrete booking, but a general inquiy and can communicate on this request with the travel agent or pax. This phase does not have a structured handling path


==== Travel Segment Service Item - Requirement Status ====
<u>Specialities</u>
Each service segment item may require more information or payment. This is indicated on segment service level.
 
{| class="wikitable"
* '''Transformation''' - the general inquiry can be change to a regular request, if the PAX adds a journey and booking during the inquiry process. In that moment, the decision the process will continue with the decision preparation phase of the regular request.
!Status
== Data domains & Perspectives ==
!Description
A [[Travel assistance service request|travel assistance service requests]] holds these data domains, which are each handled differently due to the ownership and sensitivity of contained information. This results in different perspectives and tools for request processing:
|-
 
|PAX Info required
* [[TASR - Travel agent perspective|Travel agent perspective]] - The travel agent only has proprietary information on grouping of his customers. The case handling acts on behalf of the passengers, so they have the patient's perspective once the enter a specific case
|At least one operator has processed the SAR and came back with one or more questions. Once the PAX provides the info, it goes back to Processing/Partially
* [[TASR - Passenger perspective|Passenger perspective]] - The passenger has to provide the request and required information for getting the approval for its requests.
|-
* [[TASR - Operation center perspective|Operation center perspective]] - The OC recieves information and has to come to the point of approval or rejection of the request. Once this point is received it has to govern the assistance service delivery process and needs to instruct and monitor the partners finally delivering the assistance services
|PAX Payment required
* [[TASR - Delivery partner perspective|Delivery partner perspective]] - The delivery partners receive information from the OC when to delivery which service. They can accept/reject and request or provide more information on service delivery from the OC.
|At least one of the carriers requested a payment.
 
|}
You can read up this article on [[SARA data domains]] for further details.


==== Travel Segment Service Item - Processing Status ====
This shows the processing status of the service segment item by the operation center.
{| class="wikitable"
!Status
!Description
|-
|Processing
|At least one operator has processed the SAR and came back with one or more questions. Once the PAX provides the info, it goes back to Processing/Partially
|-
|Accepted
|The service has accepted and should be possible, but may require payment or other confirmation by a 3rd party. (Looking good)
|-
|Confirmed
|The service is confirmed and will be fulfilled.
|-
|Rejected
|This service segment was rejected due to reasons provided.
|}
== Related articles ==
== Related articles ==
* [[Kordeus.PAX]]
* [[Kordeus.PAX]]
* [[SARA data domains]]
__NOTOC__

Latest revision as of 08:58, 26 June 2025

standard assistance request flow

A travel assistance service request holds all information of a partient requesting assistance on its upcoming journey. Once filed, the travel assistance service operation centers in charge of requested segments will claim responsibility for service delivery on segments and will open a travel assistance service request case, which is the leading data entity along the entire process flow from the request to service delivery.

Case standard process flow

Flowtype A: Regular request

  1. Request creation phase - the PAX or the travel agent collects all information on his side on a travel assistance service request before submitting it. As third alternative, the operation center enters the request manually after receiving a request over an insecure channel, like email. At the end of this phase, there exists a valid travel assistance service request case
  2. Decision preparation phase - the operation center and the passenger collaborate on reaching the point where the request can be confirmed
  3. Service delivery phase - the operation center coordinates the service delivery with its delivery partners
  4. Billing data acquisition phase - after ticket data has been entered, the operation center collects KPIs by which it can charge the carriers

Specialities:

  • Rebooking - If the flight is rebooked during the service delivery phase (for reasons on PAX or Carrier side), the request is pushed back with all information to the decision preparation phase and needs to reviewed entirely
  • Cancellation - if the service delivery is cancelled by the PAX, the refund issues arise and may need communication with the PAX. This is covered in the cancellation phase.

Flowtype B: General inquiry

  1. Request creation phase
  2. General request answering phase - the operation center has received no concrete booking, but a general inquiy and can communicate on this request with the travel agent or pax. This phase does not have a structured handling path

Specialities

  • Transformation - the general inquiry can be change to a regular request, if the PAX adds a journey and booking during the inquiry process. In that moment, the decision the process will continue with the decision preparation phase of the regular request.

Data domains & Perspectives

A travel assistance service requests holds these data domains, which are each handled differently due to the ownership and sensitivity of contained information. This results in different perspectives and tools for request processing:

  • Travel agent perspective - The travel agent only has proprietary information on grouping of his customers. The case handling acts on behalf of the passengers, so they have the patient's perspective once the enter a specific case
  • Passenger perspective - The passenger has to provide the request and required information for getting the approval for its requests.
  • Operation center perspective - The OC recieves information and has to come to the point of approval or rejection of the request. Once this point is received it has to govern the assistance service delivery process and needs to instruct and monitor the partners finally delivering the assistance services
  • Delivery partner perspective - The delivery partners receive information from the OC when to delivery which service. They can accept/reject and request or provide more information on service delivery from the OC.

You can read up this article on SARA data domains for further details.

Related articles

Retrieved from "https://wiki.kordeus.com/index.php?title=Travel_assistance_service_request&oldid=2618"