Ferry Flights

Backoffice path: backoffice/occ/ferry-flights

Available to roles: System Administrator, Administrator; Operations Staff has full access

Overview

Ferry flights are staff-created, non-revenue operations used to move aircraft along specific routes. Unlike automatic repositioning bounties, ferry flights give operations staff full control over routing, timing, pilot assignments, and rewards. They are ideal for planned fleet movements, seasonal repositioning, or situations where the automatic bounty system cannot find a suitable route.

Creating a Ferry Flight

To create a new ferry operation, staff specifies the following:

Field	Description
Aircraft	The aircraft to be ferried.
Description	A public description visible to pilots, explaining the purpose of the ferry (e.g., "Seasonal repositioning to winter hub").
Legs	An explicit route defined as a sequence of airports (departure and arrival for each leg).
Flight numbers	A flight number assigned to each leg of the ferry. Leave it blank to get a random 9xxx number (e.g. 9042); the ATC number defaults to the flight number.
Points per leg	The Points reward a pilot earns for completing each individual leg.
Time window per leg	The maximum time allowed to complete each leg (default: 24 hours).
Notes	Internal staff notes, not visible to pilots.
Pilot assignments	A priority queue of pilots assigned to the ferry. The system works through the queue in order if the primary pilot is unavailable or their window expires.

Defining Legs

Each ferry operation consists of one or more legs. A leg represents a single flight segment from one airport to another. For a multi-stop repositioning (e.g., moving an aircraft from KJFK to KLAX via KORD), you would define two legs:

1. KJFK to KORD
2. KORD to KLAX

Each leg has its own flight number, Points reward, and time window.

Pilot Assignment Queue

Pilots are assigned to a ferry in a priority queue. The first pilot in the queue is the primary assignee. If that pilot's time window expires without completion, the assignment cascades to the next pilot in the queue. This ensures ferry operations are not stalled by a single unavailable pilot.

When a pilot is added to a leg that is currently waiting for a pilot (Assigned status with no active window), and the new pilot is first in the queue, they are automatically given an active window and notified immediately.

Once their window is open, the active pilot books the leg from their ferry page, which creates a ferry booking and moves the leg to In Progress. If the pilot cancels that booking before flying it, the leg returns to Assigned and their window and queue position are kept, so they can book it again while the window lasts.

Once a leg is flown, its queue closes: every pilot still waiting on it is marked Closed and notified that another pilot flew the leg. The leg leaves their upcoming assignments on the ferry page, while staff still see everyone who queued for it.

Aircraft Availability

While a ferry is in progress (activated), its aircraft cannot be booked for any other flight: it is hidden from the booking screens, and bookings made any other way (tours, sequences, the API) are refused with a message that the aircraft is being ferried. This keeps the aircraft where each leg expects it. A pending ferry does not block bookings, so staff can prepare a ferry without taking the aircraft out of service early. Once the ferry is completed or cancelled, the aircraft is bookable again.

Time Window Management

Every 5 minutes, the system checks for expired time windows on active ferry legs. When a window expires:

1. The current pilot's assignment is removed, freeing the slot so the pilot can re-apply later if needed. If the pilot had booked the leg, the booking is removed and the leg goes back to Assigned.
2. The next pilot in the priority queue is activated. If nobody else is queued, the leg waits for staff to add a pilot, whose window opens straight away.
3. Notifications are sent to both the departing and incoming pilots.

Protection for active flights: If a pilot is actively flying a ferry leg and has submitted position reports, the system protects that leg from expiry. The time window is not enforced while the flight is in progress.

Pilot Notifications

Pilots receive notifications at each stage of the ferry lifecycle:

Event	Notification
Assigned	Pilot is notified they have been assigned to a ferry operation.
Window open	Pilot is notified their time window has begun.
Window expired	Pilot is notified their window has expired and the assignment has moved to the next pilot.
Delayed	Pilot is notified of a delay in the ferry operation.
Completed	Pilot is notified the ferry operation (or their leg) has been completed.
Leg closed	Pilots still waiting on a leg are notified that another pilot flew it and its queue has closed.

Leg Completion

Ferry legs are completed at flight submission time, as soon as the pilot's ACARS client submits the flight data. Completion does not wait for the PIREP to be reviewed (approved, warned, or rejected). This ensures ferry operations continue smoothly and the next leg can be activated immediately, since the aircraft has physically moved to its destination.

Diversions

A pilot can declare an alternate on any ferry leg (first, middle, or last), the same way as on a regular flight. The ferry then reshapes itself to get the aircraft back on track. For example, a leg GOBD → SBSJ diverted to SBRF becomes:

Leg	Result
GOBD → SBRF	Completed when the pilot lands at the alternate. Shown as Diverted, planned SBSJ. No points.
SBRF → SBSJ	Added right after the diverted leg, with the same flight numbers, points, and time window. Booked automatically for the same pilot when they land at SBRF, with a fresh window.

Any later legs (SBSJ → …) keep their pilot queues and wait until the aircraft reaches SBSJ. Flying the leg back pays its Points as usual. If the pilot diverts again on the leg back, the same thing happens from there.

A diverted ferry does not create a repositioning bounty for the stranded aircraft: the ferry's own leg brings it back.

Pilots declare diversions in flight (OCC briefing panel or vOCC). When they don't, staff can flag the diversion on the flight while it awaits review. The leg is then shown as diverted and its points are reversed. If the aircraft is still where it landed, the leg back is added and booked the same way. If the aircraft has been booked or flown since, staff sort the rest of the ferry out by hand.

Points and Rewards

Upon completion of a ferry leg, the assigned pilot is awarded Points with the transaction type "ferry". The amount is the per-leg Points value configured when the ferry was created. Points are awarded individually per leg, so a pilot completing multiple legs of the same ferry earns rewards for each. A leg that ended at an alternate earns nothing; its Points are paid on the leg back to the planned arrival.

Managing Legs After Creation

Staff can manage ferry legs after initial creation:

• Edit pending legs — Change airports, flight numbers, distance, points, or window hours for any leg still in Pending status.
• Add new legs — Append additional legs to ferries that are Pending or In Progress. New legs are added at the end of the sequence.
• Remove pending legs — Remove legs that are still in Pending status and have no active pilot assignments. Remaining legs are automatically resequenced.

Monitoring Ferry Operations

The ferry flights page displays all ferry operations with their current status. Staff can:

• View the overall progress of each ferry (how many legs are complete).
• See which pilot is currently assigned to the active leg.
• Monitor time window status for each leg.
• Track the full assignment history, including expired windows and cascaded assignments.
• Create new ferry operations as needed.
• Edit the public description at any time from the expanded ferry view.