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
Service Tree Creation
Defines dependencies and relationships between services.
This allows services to automatically trigger or recommend other services.
Service Ordering
Defines which services should be suggested when another service is requested.
Example:
Requesting STCR (Stretcher) automatically suggests:
•Ambulance transport
•Escort service
•Medical oxygen
Force Option
If enabled, the suggested service is automatically added.
If disabled, the user can accept or reject the suggestion.
Backend Service Dependency
Defines automatic service creation in backend workflows.
Example:
When a Stretcher request is created:
Automatically add:
•Stretcher mounting
•Stretcher dismantling
These services are invisible to the passenger.
Vessel Manipulation Service
Defines services that require preparation work on the aircraft.
Examples:
•stretcher mounting
•equipment installation
•seat removal
Timing Options
Defines when preparation must occur:
| Option | Description |
| Before segment starts | preparation before flighr departure |
| After segment end | post-flight removal |
Port Delivery
The Port Delivery page defines where and how a service is delivered at airport level (ports) and which service delivery partners are responsible.
This page is only relevant when the service is:
•At-Port Direct PAX Service Delivery = Yes (from catalogue)
•AND optionally Limited availability by Port = enabled (from Base Data)
It allows administrators to:
•define at which ports the service is available
•assign responsible delivery partners
•define communication fallback (insecure communication)
•configure capacity restrictions per partner
This page is conditionally available based on Base Data settings
Direct PAX Service Deliverability at Port
Purpose
Defines when during the journey the service is delivered at port level.
Options
Deliverable during embarkation on first segment
•Service delivered at departure airport
•Example:
•wheelchair at check-in
•stretcher boarding preparation
Deliverable during transfer between segments
•Service delivered during transfer at connecting airports
•Example:
•escort during transfer
•medical assistance between flights
Deliverable during disembarkation from last segment
•Service delivered at arrival airport
•Example:
•wheelchair on arrival
•ambulance pick-up
Behavior
•Multiple options can be selected
•Defines when service delivery partners are triggered
•Directly impacts:
•task creation
•partner notifications
•workflow timing
Ports Where Service is Available to PAX
Defines where the service is operationally available and who delivers it.
Global Availability Toggle
Checkbox:
“This service is generally available at all ports”
If ENABLED
•Service is available globally
•Only exceptions (exclusions) are configured below
•Table acts as: restriction list not a whitelist
If DISABLED
•Service is available only at listed ports
Table acts as: explicit allow-list
Add Port Configuration
Fields
Add known port
Select airport (e.g., FRA, GVA)
Add known service delivery partner
Assign delivery partner responsible at that port
Examples: Swissport, Fraport, Handling agents
Unavailable at this port
Marks service as not available at selected port
Used when: global availability is enabled but specific ports must be excluded.
Port Configuration Table
| Column | Description |
|---|---|
| Available at port | Airport code |
| Authorized service delivery partner (defines who is allowed to deliver the service at that port and who will receive tasks and notifications) | Assigned partners |
| Insecure COM (defines fallback communication channel and is used when no digital integration exists or communication must still be ensured) | Fallback communication channels |
| Capacity resriction by partner (defines operational limits such as maximum concurrent services, partner-specific constraints) | Operational limits |