Contents
1) Simple Summary
A legacy translator lets you keep flying with your PSS while you move to offer and order management. It sits in the middle, translating between today’s PNR/ticket world and tomorrow’s offer/order world. You can start small, reduce risk, and grow capability without a big‑bang cutover.
Bridge Concept
────────────────────────────────────────────
Channels (Web, App, NDC, GDS)
│
▼
Offer/Order Layer (Offer Engine, OMS)
│
▼
Legacy Translator (Mapping + Rules)
│
▼
PSS (Availability, Fares, PNR, Ticketing)
Goal: decouple retailing speed from legacy constraints, while staying safe on accounting, interline, and regulatory needs.
2) Why Now
- Retail expectations are higher: people want clear products, bundles, and consistent prices.
- Offer and order standards are maturing, making it safer to move.
- You can show value fast: better conversion, new ancillaries, cleaner operations.
3) What a Legacy Translator Does
- Vocabulary: Converts PSS concepts (RBD, PNR, e‑ticket, SSR) into offer and order terms (product attributes, offers, orders, services).
- Compatibility: Keeps partners working (NDC, interline, codeshare) while you modernize.
- Traceability: Maintains audit links between filed fares/taxes and your new offers and orders.
4) Reference Architecture
Reference Architecture (High Level)
────────────────────────────────────────────
[Channels] Web/App | Agency/NDC | Corporate | Call Center
│
▼
[Offer Layer] Context + Pricing + Bundling
│ ▲
│ │ Caches/Signals (availability, demand, tax)
▼ │
[Legacy Translator]
• Contract: APIs + events
• Mapping: RBD/brand → attributes
• Tokens: offer integrity
• Fallbacks: discrete fare when needed
│
▼
[PSS + Legacy Services]
• Availability/Inventory
• Fare/rules via ATPCO
• PNR + Ticketing
• EMD for ancillaries
5) Data Mapping: PSS → Offer/Order
| PSS Field | Offer/Order Concept | Notes |
|---|---|---|
| RBD (Y, B, M) | Attributes (flex, seat, bag) | Map to product features customers understand. |
| PNR | Order | Order holds services; keep PNR link for audit until cutover. |
| E‑ticket | Order item + fulfillment | Use ticket/EMD as fulfillment artifacts during hybrid phase. |
| ATPCO fare/rules | Offer guardrails | Use for legality, combinability, and policy limits. |
| SSR/OSI | Service attributes + notes | Normalize where possible (seats, meals, assistance). |
Mapping Example (Economy Flex)
────────────────────────────────────────────
PSS: RBD = Y, Fare Brand = Flex, AP/MinStay rules
→ Offer: Product = Economy Flex
Attributes = [1 checked bag, free changes, front seat]
Guardrails = from fare rules
→ Order: Items = [Base fare service, Bag service, Seat service]
Fulfillment = Ticket + EMD references
6) Key Flows
- Search/Offer: Translator enriches offers with PSS constraints, maps to attributes, returns a token.
- Book/Order: Token is validated; an order is created; PSS PNR/ticket/EMD is issued behind the scenes.
- Change/After‑sales: Order change request maps back to PSS reissue rules; keep fees and taxes legal.
- Interline: Use anchor fares and fair proration; fall back to filed points if a partner can’t process tokens.
Sequence (Happy Path)
────────────────────────────────────────────
Customer → Search
Offer Engine → Translator → PSS (availability/fare rules)
Translator → Offer (price + brand + attributes + token)
Customer → Book
OMS → Token validate → Translator → PSS (PNR, ticket/EMD)
OMS → Order confirmed (with legacy references)
7) Governance, Risk, Compliance
- Audit trail: Every offer carries method (FILED/DYNAMIC/CONTINUOUS), data versions, and tax table versions.
- Fairness: Avoid sensitive features in pricing signals; review models regularly.
- Tax authority rules: Always call the tax engine; keep a record of versions and overrides.
- SLAs: Token validation and PSS calls must meet strict latency targets to protect conversion.
8) KPIs and Value Tracking
+2–5 pts
Conversion uplift vs. control
↓ 20–40%
Checkout repricing events
~10–25%
Ancillary attach rate increase
< 0.5%
Guardrail breach rate
9) Phased Plan
Phase 1: Translate and Trace
Keep PSS in charge of inventory and tickets. Translator maps brands and attributes, returns tokens, and logs anchors.
Phase 2: Attribute‑First Bundles
Sell by features (flex, bag, seat, priority). Keep legacy references for accounting and interline.
Phase 3: RBD‑light
Hide RBD from channels. Internally map to attribute capacity (e.g., flex seats left).
Phase 4: Order‑Led
Orders become the source of truth; tickets/EMDs persist as fulfillment artifacts or disappear per market rules.
10) Design Patterns and Anti‑Patterns
| Pattern | Why it helps | Notes |
|---|---|---|
| Tokenized offers | Fast checkout, fewer reprices | Short TTL; cryptographically signed |
| Anchor trace | Audit and partner fallback | Store fare ref, rule refs, tax version |
| Attribute capacity | Controls by product, not letters | Backed by PSS inventory early on |
| Feature flags | Safe rollouts and rollbacks | Per route, channel, market |
| Anti‑pattern: Big‑bang cutover | High risk, hard rollback | Prefer phased, with coexistence |
| Anti‑pattern: Hidden discounts | Tax and partner issues | Keep rule‑compliant guardrails |
11) FAQ
Is a legacy translator a permanent solution?
No. It’s a bridge. It buys time and safety while you build confidence in offer and order. Over time, it should get thinner.
Do we need to rewrite our pricing?
Not at once. Start by mapping brands and rules. Then add smarter selection and continuous pricing inside guardrails.
Will partners accept this?
Yes, with fallbacks. Keep anchors for interline. Share tokens with partners who can use them; otherwise offer discrete steps.
12) Checklist
- Define your attribute model (flexibility, seat, bag, priority).
- Map brands and RBDs to those attributes internally.
- Introduce tokenized offers with a short TTL and version tags.
- Track anchors and tax table versions for every offer.
- Set KPIs and feature flags per route and channel.
- Plan phased de‑emphasis of PNR/ticket in favor of orders.