The pilot sequence
Six phases from operating definition to controlled rollout
Phase 1 of 6
Define operating contract
Before implementation, document the workflow in operational language.
1 of 6
What a pilot must prove
A technical demonstration proves that systems can exchange data. An operational pilot must prove more.
It should show that:
- the source event is reliable
- required identifiers remain attached
- travel requirements are derived correctly
- policy is applied as intended
- eligible bookings execute safely
- exceptions reach the right team
- changes and cancellations are handled
- finance receives usable records
- security and access controls work
- the airline can pause or reverse the rollout
Choose one first outcome
Do not begin with scheduled bookings, IROPS, transport, payments, reconciliation, every crew base, and every supplier at once.
Suitable first outcomes include:
- scheduled crew hotel requirements for one base
- a limited group of stations
- one roster window
- one hotel contract programme
- one type of deadhead workflow
- airline-approved IROPS hotel actions
- reconciliation-ready booking exports
The scope should be large enough to expose real operating conditions but small enough for the airline to investigate every incorrect or ambiguous outcome.
Phase 1: Define the operating contract
Before implementation, document the workflow in operational language.
Answer:
- Which event starts the process?
- Which system owns that event?
- Which data fields are mandatory?
- Which identifiers must persist?
- Which policy rules apply?
- Which outcomes may proceed automatically?
- Which outcomes require review?
- Who owns each exception?
- What record closes the process?
- What would cause the airline to pause the pilot?
Do not allow unresolved ownership questions to become hidden assumptions inside integration code.
Phase 2: Validate data before booking
Run representative source data through validation before enabling supplier actions.
Check:
- crew and employee identifiers
- pairing and duty references
- schedule windows
- dates and time zones
- airport and station codes
- layover requirements
- hotel dates
- deadhead timing
- duplicate records
- late updates
- removed travel
- conflicting source records
A data issue should produce a visible, owned outcome. It should not silently create or remove a booking.
Phase 3: Observe the workflow in parallel
For a defined period, compare the proposed automation with the existing operating process.
During this phase:
- derive the expected travel actions
- do not automatically execute all actions
- compare the result with the team’s actual decision
- investigate differences
- refine data mapping
- refine policy rules
- document recurring exception categories
- confirm that identifiers reach downstream records
The objective is not to prove that the existing process is always correct. It is to understand why the two processes disagree.
Phase 4: Enable controlled execution
Once the airline trusts the source data and action logic, enable booking execution for a narrow group of low-ambiguity cases.
Examples:
- preferred contracted hotel is available
- rate is within the approved threshold
- dates and crew count are complete
- no policy conflict is present
- the action is not under manual override
- the supplier response is unambiguous
Route other cases to review.
Automation coverage should expand because evidence supports it, not because a target percentage was announced before the pilot began.
Phase 5: Test changes, cancellations, and failures
A pilot that tests only successful new bookings is incomplete.
Test:
- schedule revisions
- removed layovers
- date changes
- hotel changes
- deadhead changes
- duplicate submissions
- safe retries
- expired flight options
- supplier timeouts
- unavailable inventory
- price exceptions
- authentication failures
- partial downstream outages
- manual overrides
Every failure should have an expected state, owner, and recovery path.
Phase 6: Validate the finance handoff
The pilot should prove that finance can understand the result without reconstructing the original operation.
Confirm that the record includes:
- airline operational references
- action identifier
- booking identifier
- supplier confirmation
- booked rate
- contract or preferred-rate context where applicable
- status history
- change and cancellation history
- disruption reference where applicable
- export or downstream handoff
This does not require every invoice or folio workflow to be automated in the first phase. It requires the booking record to preserve the evidence later processes will need.
Pilot metrics
Use a balanced scorecard.
Data quality
Data quality
- percentage of source records accepted
- missing-field rate
- duplicate or conflicting record rate
- late-update rate
Operational accuracy
- correctly derived travel requirements
- incorrect or unnecessary actions
- missed actions
- change and cancellation accuracy
Automation quality
- eligible actions completed without intervention
- review-state volume
- failure-state volume
- retry success
- supplier confirmation status
Team impact
- manual touches per requirement
- time spent investigating exceptions
- clarity of ownership
- support escalations
- operator confidence
Finance readiness
- records with complete identifiers
- records with supplier confirmation
- records with rate evidence
- records successfully exported
Do not use one automation percentage as the sole measure of success.
Expansion criteria
Expand only when:
- source data meets the agreed quality threshold
- exceptions reach named owners
- incorrect actions remain within the agreed tolerance
- changes and cancellations work
- security approval is complete
- finance records are usable
- the airline can monitor and pause the workflow
- operations accepts the new process
Pause or rollback criteria
Pause when:
- source data becomes incomplete or unreliable
- duplicate or incorrect bookings exceed tolerance
- unowned exceptions accumulate
- supplier-state visibility is lost
- a security or access issue is identified
- changes and cancellations cannot be trusted
- finance cannot correlate the records
- the operating team no longer understands the current state
Rollback should be designed before go-live. It is not an admission of failure. It is part of production control.
Expand
Pause
Roll back
Common pilot mistakes
Starting too broadly
A large scope hides root causes and overwhelms the people who need to investigate differences.
Measuring API success instead of operational success
A successful response does not prove that the right crew travel action occurred.
Treating exceptions as edge cases
Exceptions are part of the product. The pilot must prove who receives them, what context they see, and how they close the loop.
Excluding finance until later
Incomplete identifiers and booking records are difficult to repair after volume increases.
Automating before data ownership is clear
No amount of integration code resolves two systems publishing conflicting versions of the schedule.
FAQ
How long should a crew travel automation pilot run?
The duration should cover enough schedule changes, supplier outcomes, exceptions, and operational variation to evaluate the workflow. Use evidence and event coverage rather than an arbitrary calendar duration.
Should an airline begin with IROPS?
IROPS can produce high value but also contains more ambiguity and operational pressure. Many airlines may prefer to prove data and exception handling with a bounded scheduled workflow before expanding into disruption execution.
Should every pilot action be booked automatically?
No. Begin with observation and controlled execution. Increase automation only for cases with reliable inputs, clear policy, and predictable outcomes.
Who should participate?
Crew Scheduling, Crew Services, OCC, airline IT, security, finance, procurement, support, and the team responsible for supplier or hotel operations should be represented according to the pilot scope.
What is the most important pilot deliverable?
A shared operating model with proven data, ownership, exception handling, records, and rollout controls is more valuable than a high automation percentage achieved under artificial conditions.
Build the pilot around controlled evidence
Use the readiness checklist to identify unresolved systems, data, policy, finance, and rollout decisions before technical scope is finalized.
Explore airline operations technology