App:Travel assistance service administration: Difference between revisions

From Kordeus Wiki
Jump to navigation Jump to search
Stefanseiler (talk | contribs)
No edit summary
Stefanseiler (talk | contribs)
No edit summary
 
Line 119: Line 119:
== Related articles ==
== Related articles ==


* [[Special Assistance Request Management Suite (SARA)]]
* [[SARA.Core (Special Assistance Request Management Suite)]]
[[Category:Apps]]
[[Category:Apps]]

Latest revision as of 12:25, 22 June 2025

The travel service administration is split into two parts:

  • Global travel service map - this holds a list of all known travel services known to b-op. It is centrally maintained and acts as standardization between all carriers. This is required to provide global compatibility and to deliver the option for collaboration.
  • Service customization - Each carrier digital, e.g. Lufthansa / LH, may define, where, how and by whome services are delivered and customize services picked from the global travel service map.

This article is about this service process customizations, which is done in this app.

Service type

  • Travel Service Category - This service requires medical approval before confirming the service
  • Icon - The icon used to signal the request on the backend process of OC
  • Color Tag - The signal color of the service request in the backend process of OC

Service availability definition

By picking from a list of global travel service definitions, it becomes generally available to the carrier. Once this is done the customization part starts:

Based on the settings in the global travel service map, a service is either delivered at ports or during travel segments. Still, each carrier may define if the service is

  • generally available - The service is available to all ports/segments or
  • limited available - in this case the carrier wants to define availability per port or per offered segment.
Port limited availability

If limited availability is selected and point of delivery is set to "per port", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:

  • embarcation - This service is to be delivered at embarcation ports.
  • disembarcation - This service is to be delivered at disembarcation ports.
  • transfer (inbound) - This service is to be delivered at transfer ports, where the carrier does the inbound segment
  • transfer (outbound) - This service is to be delivered at transfer ports, where the carrier does the outbound segment

Please note that services can only be delivered, if a service delivery partner is known to the system, which supports this service. Within the delivery partner administration app, the list of supported services at supported ports and the available service providers can be defined.

Segment limited availability

If limited availability is selected and point of delivery is set to "offered segment", the carrier has to define how service availability to the PAX can be determined. In this case PAX availability settings can be:

  • vessel type - Only available if the vessel type supports it. The user can pick from a list of travel devices, which support this service.
  • segment - Only available if the segment supports it. The user can pick from a list of segments, which support this service.

Please note, that both limitations can be active.

Examples for service availability definition

  • Service "Wheelchair". The point of service delivery is "port", as the wheelchair service is delivered at airports. The service availability is set to "generally available", as the carrier knows that each port has to be able to deliver this service due to IATA regulations.
  • Service "STRETCHER". The point of service delivery is "segment" and availability is "travel device and segment".

Service mounting/dismantling task automation

Ports / Service delivery partners

If the service requires work at the travel device, the carrier has to pick

  • mounting/dismantling ports - the ports which are able to do the mounting/dismantling work
  • service delivery partners - for each mounting/dismantling port, the user has to pick a service delivery partner, which performs the mounting/dismantling work at this port

Notification automation

For each service station supporting mounting and dismantling, the admin can define one or multiple mounting/dismantling notification rules. Each mounting/dismantling rule holds these information:

  • Target
    • OC internal - allows the definition of a person or person group
    • service delivery partner - the station performing the mounting/dismantling
  • Time to Delivery (TTD) - how many hours before required mouting/dismantlich, the task shall be created
  • Task template - the travel task template to use for the creation of the task

Examples:

  • Service "STRETCHER", 24 hours before mounting, task template "Mounting task to service station"
  • Service "STRETCHER", 6 hours before dismantling, task template "Mounting task check to MOC"

Task flow & automation

For each service, a list of tasks flow rules has to be created. By these, the system knows when to create tasks and for which party

Event Trigger

Available Triggers:

  • OnSegmentServiceClaim
  • OnSegmentServiceTimeToDelivery - Requires the user to enter a Time To Delivery (TTD) meaning how many hours to a departure or arrival event the task shall be created (embarcation or disembarcation event)
  • OnSegmentServiceFinalApproval
  • OnSegmentServicePartialApproval
  • OnSegmentServiceRejection
  • OnSegmentServicePartialRejection
  • OnServiceCancellation

Used task template

The user has to pick the travel task template to use for creation of this task.

Event Target

Who receives the task / who is responsible for fulfillment. Options are

  • passenger
  • OC internal - allows the definition of a person or person group
  • service delivery partner - allows to either define
    • default service provider - this will pick a service delivery partner, which supports the requested service at the desired port
    • fixed partner - this will always provide this task to a fixed service delivery partner

Applicability / multiplication

When the event target passenger or OC internal is selected, this defines how often this event will be triggered:

  • once per itinerary - this option is not available, if the event target is service delivery partner
  • per port in itinerary
  • per embarcation port in itinerary
  • per disembarcation port in itinerary
  • per service segment item

For service deliery partner the application is always per service segment item.

Event mutiplication restrictions

This allows task to restricted the task execution for service segments or ports by specifying

  • a port limitation list - This list of ports to which this task shall be created. If not specified, all ports defined through port-application are triggering this event
  • segment limitation list - This allows a list of segmenttation rules (e.g. "*" - "FRA": only inbound flights to FRA) on which this task will be created

Examples

  • Rule name "AMBULANCE prenotification"
    • OnSegmentServiceTimeToDelivery: 3 hours
    • Used Task template: "Ambulance required task" (Deadline 1h)
    • Event Target: service delivery partner
    • Applicability/multiplication: per service segment item
    • Event multiplication restrictions: none
  • Service "UK Border Patrol prenotification"
    • OnSegmentServiceTimeToDelivery: 3 hours
    • Used Task template: "UK Border patrol notice"
    • Event Target: service delivery partner
    • Applicability/multiplication: per disembarcation port in itinerary
    • Event multiplication restrictions: Port limitation "LHR"

Related articles