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

Related articles

Translations