Atlas
Built for pricing decisions, not pace reports.
Atlas transforms booking signals into pricing recommendations that balance demand stimulation with yield protection. Instead of simply reporting whether bookings are ahead or behind pace, Atlas evaluates market competitiveness, demand elasticity, seasonality, and seat protection before recommending an inventory action.
Atlas Decision Stack
Velocity Signal:
Booking pace vs proxy curve
Competitor Fare:
Market fare position
Candidate Add Testing:
Evaluate RBD -3 to +3
Own Price Elasticity:
Demand sensitivity
Seasonality Guardrails:
Min/Max RBD
EMSRc Seat Protection:
Bid price logic
Final Upload RBD:
Final recommendation
Core Capabilities
Atlas compares load factor and passenger build against proxy curves using multiple variance windows.
Seven candidate RBD movements are evaluated before recommending the optimal pricing action.
Structured economic decisioning, not just pace tracking.
Atlas operates on a layered decision architecture. At its foundation is a velocity engine – booking pace relative to a proxy curve, combined with recent booking variance. On top of that, Atlas adds economic rigor: competitor fare positioning, candidate fare testing, own-price elasticity, and EMSRc seat protection.
The result is a system that doesn’t just tell you whether a flight is behind pace. It tells you what to do about it – and shows its work.
Layer 1
Establish pace
Atlas measures current load factor and booking build against proxy curves. 14, 7, 3, and 1-day variances establish whether the flight is ahead or behind expected pace, with holiday and peak/off-peak guardrails applied.
Layer 2
Check the market
A competitor fare signal adjusts the velocity recommendation if your fare is materially above or below market, ensuring the RBD recommendation reflects your actual commercial position.
Layer 3
Test each possible move
The Candidate-Add function tests seven RBD movements (-3 to +3), looks up the associated fare for each, and estimates expected demand impact using the operational elasticity coefficient before selecting the optimal move.
Layer 4
Apply seat protection
EMSRc bid-price logic evaluates whether remaining inventory should be protected for higher-value future demand - reducing the buy-down and spiral-down risk that erodes average fares in weakly restricted fare environments.
Upload
Deliver the final RBD
The final upload RBD incorporates seasonality guardrails and any manual analyst override, then posts to the inventory system with a full audit trail of which signals drove the decision.
Built for teams who need to explain their decisions.
Atlas doesn’t bury the reasoning in a single RBD output. Every component is separated, labeled, and available for review – so analysts can engage with the logic, not just accept the recommendation.
When leadership asks why a fare moved, the answer isn’t “the system said so.” It’s pace, competitor position, demand sensitivity, seasonality, or seat protection – whichever factor actually drove the decision.
Component → Purpose
Velocity RBD Add → Measures booking pace
Competitor Fare Adj. → Checks market pricing
Candidate Add Testing → Tests RBD movements
Own Price Elasticity → Estimates demand response
Expected Demand Impact → Projects booking changes
Elasticity Adjustment → Prevents poor fare moves
Seasonality Guardrails → Applies seasonal rules
Final Upload RBD → Final recommendation