Dev:LH MOC Admin-Travel services
The Travel Service Administration module is the central configuration area where all operational services that can be requested for a passenger are defined and managed.
A Travel Service represents a concrete operational action related to a passenger’s journey.
Examples include:
•Wheelchair assistance
•Stretcher transport (STCR)
•Oxygen on board (POXY)
•Escort services
•Ambulance transport to/from airport
•Medical device transport (CPAP/BIPAP)
•Additional seating
•Handling of medical baggage
These services may require:
•Medical approval
•Operational approval
•Ground handling coordination
•Service delivery partner involvement
•Task automation
•Capacity checks
The module defines how a service behaves in the system, including:
•Availability
•Dependencies
•Approval workflows
•Automation rules
•Service visibility
The Travel Service Administration module defines the operational backbone of passenger assistance and medical service handling.
It controls:
•how services appear
•who can request them
•how they trigger other services
•how approvals work
•how operational workflows are automated
Together with:
•SPFT
•Service Delivery Partners
•Travel Partners
this module forms the core system for managing passenger service operations.
Base data
The Base Data section defines the core behavior of a travel service and controls:
•where the service can be used (segment / port / flight / aircraft)
•who can request it
•how it behaves in workflows
•which additional configuration pages become available
A key part of this section is the Service Network Compatibility catalogue, which drives availability logic and UI behavior across the system.
Member Service Requestability
Defines who can request the service:
| Option | Effect |
|---|---|
| Passenger | Available in PAX portal |
| Travel partner | Available or external partners |
| Internal | Only internal users can add |
Service Network Compatibility (Catalogue-Driven Logic)
This section defines system-level characteristics of the service, based on a catalogue configuration.
These values are not manually editable, but are derived from the selected:
•Global Travel Service Binding
•Service Group Key
They determine:
•how the service behaves
•where it can be delivered
•which configuration options are available
Catalogue Flags
The following flags define service capabilities and restrictions:
On Segment Direct PAX Service Delivery
Value (example): No
Meaning:
Defines whether the service can be delivered directly to the passenger during a flight segment.
If Yes:
•Service can be delivered on board
•Enables:
•segment-level availability configuration
•segment-based automation
•Related pages enabled:
•Segment Availability
•Typical examples:
•onboard oxygen
•onboard assistance
If No:
•Service cannot be delivered onboard
•Segment-related configuration is restricted or irrelevant
At-Port Direct PAX Service Delivery
Value (example): Yes
Meaning:
Defines whether the service can be delivered at airport locations (departure, arrival, transfer).
If Yes:
•Service is available at:
•departure airport
•arrival airport
•transfer airport
•Enables:
•At Port Availability page
•port-based restrictions
•Typical examples:
•wheelchair assistance
•ambulance services
•escort services
If No:
•Service cannot be delivered at airport level
•Port configuration is disabled
Describes General Medical Condition
Value (example): No
Meaning:
Defines whether the service represents a medical condition classification rather than an operational service.
If Yes:
•Service is used for:
•classification (e.g., MEDA)
•Enables:
•medical workflows
•Does NOT represent a physical service
If No:
•Service is treated as an operational service
Trip Extra Service
Value (example): No
Meaning:
Defines whether the service applies to the entire journey (trip-level) rather than individual segments.
If Yes:
•Service applies to:
•whole itinerary
•Not tied to:
•specific segments
•Example:
•special handling across entire trip
If No:
•Service is applied per:
•segment or port
Segment Transport Type Service
Value (example): No
Meaning:
Defines whether the service is tied to transport type (air, rail, bus, etc.)
If Yes:
•Service depends on:
•transport type of segment
•Enables:
•transport-specific filtering
If No:
•Service is independent of transport type
Is Info Service
Value (example): No
Meaning:
Defines whether the service is informational only.
If Yes:
•Service:
•does NOT trigger delivery
•does NOT require execution
•Used for:
•displaying information
•No tasks or delivery partners triggered
If No:
•Service is operational and actionable
Service Availability Limitations
Defines where and under which conditions the service can be used.
These settings directly control:
•which configuration pages are visible
•how the service is filtered in workflows
Limited to Used Craft Type on Segment
If enabled:
•Service is restricted to specific aircraft types
•Enables:
•Craft Availability page
•Example:
•stretcher only available on widebody aircraft
If disabled:
•Service available for all aircraft types
Limited Availability by Port
If enabled:
•Service is restricted to selected airports
•Enables:
•At Port Availability page
•Requires:
•At-Port Direct PAX Service Delivery = Yes
If disabled:
•Service available at all ports
Limited Availability by Segment
If enabled:
•Service restricted to specific routes or segments
•Enables:
•Segment Availability page
If disabled:
•Service available across all segments
Limited Availability by Flight Number
If enabled:
•Service limited to specific flight numbers
•Enables:
•Flight Number Availability page
If disabled:
•Service not restricted by flight
Vessel Manipulation Travel Service
If enabled:
•Service involves physical aircraft manipulation
Examples:
•stretcher mounting
•seat removal
•equipment installation
Enables:
•timing logic in:
•Service Tree Creation
•operational preparation tasks
Enforce Mandatory Fields for this Service on Portal
If enabled:
•Passenger or agent must fill required fields before submitting request
Examples:
•medical details
•equipment requirements
If disabled:
•fields remain optional
Dependency Logic
The system behavior depends on combined conditions:
Example 1
At-Port Direct PAX Service Delivery = Yes
AND
Limited Availability by Port = Enabled
➡ Result:
•At Port Availability page becomes visible
•Service can be configured per airport
Example 2
On Segment Direct PAX Service Delivery = Yes
AND
Limited Availability by Segment = Enabled
➡ Result:
•Segment Availability page becomes visible
•Service can be configured per route
Example 3
Limited to Used Craft Type on Segment = Enabled
➡ Result:
•Craft Availability page becomes visible
•Service limited by aircraft
Example 4
Is Info Service = Yes
➡ Result:
•No:
•delivery partner assignment
•operational tasks
•Used only for:
•display / informational purposes
Example 5
Describes General Medical Condition = Yes
➡ Result:
•Service used in:
•medical classification
•Impacts:
•medical approval workflows
•Not treated as operational service
Internal Service Process Flow Type (SPFT)
Defines which workflow logic applies.
Take MEDA as example
Controls:
•approval flows
•task generation
•communication templates
Minimum Connection Times
Defines minimum required time between segments.
Used for:
•operational feasibility checks
•service validation
Insecure Handling Advice Communication
Defines fallback communication channels:
•email recipients
•telex recipients
Used when:
•digital delivery is not available