Türkiye Seyahat Dağıtım Ekosistemi Nasıl Çalışır?

Türkiye seyahat dağıtım ekosistemini yalnız OTA listesi olarak okumak yanlış olur. Search ve booking yüzeyine gelen bir hotel, flight veya package offer; çoğu zaman supplier system, connectivity, wholesale/GDS ve retail katmanlarından geçerek oluşur. Doğru mimari, her katmanın hangi state'in source-of-truth'u olduğunu ayrı tutar.

Problem ve neden önemli?

Aynı hotel bir PMS'te, channel manager'da, bedbank'te ve OTA'da farklı ID ile bulunabilir. Aynı flight offer GDS, NDC veya airline direct source'tan gelebilir. Eğer bütün bu identity ve lifecycle'lar tek “provider record” altında flatten edilirse mapping, freshness, attribution ve reconciliation sorunları kaçınılmaz olur.

Mimari akış

Travel Supply
  ↓
PMS / CRS / PSS / Supplier Extranet
  ↓
Connectivity / Channel Manager / GDS / NDC / Bedbank
  ↓
OTA / Marketplace / Metasearch / Tour Operator
  ↓
Booking Engine / Payment / Attribution
  ↓
Reconciliation

Her arrow yalnız transport değildir; identity translation, pricing semantics, availability state ve commercial ownership değişebilir.

Hotel tarafı

Hotel'de PMS operational source olabilir, CRS chain-level inventory/rate orchestration yapabilir, channel manager downstream kanallara ARI ve reservation state taşıyabilir. Bedbank ise contracted/wholesale inventory'yi yeniden dağıtabilir. OTA veya metasearch'e ulaşan offer'ın origin'i bu katmanlardan biri veya bir kombinasyonu olabilir.

Flight tarafı

Flight distribution'da airline PSS/supplier state'i GDS, NDC aggregator veya direct API yoluyla seller'a ulaşabilir. Turkish Airlines TKCONNECT örneği UI, aggregator ve direct NDC API modellerinin aynı supplier altında birlikte bulunabileceğini gösterir.

Package holiday

Tour operator modelinde hotel + flight + transfer gibi component'ler tek package offer'da birleşebilir. Package identity, component identity'lerin basit birleşimi değildir; contract, cancellation ve pricing rule'ları bundle seviyesinde de oluşabilir.

Trade-off'lar

Daha fazla intermediary coverage ve commercial reach sağlar; fakat identity mapping, stale state, reconciliation ve fee/tax normalization karmaşıklığını artırır. Direct connect daha az hop ve daha zengin supplier context sağlayabilir; fakat her supplier için ayrı integration ve operasyon maliyeti yaratır.

Failure mode'lar

• yanlış property/room mapping,
• stale ARI veya availability,
• duplicate hotel,
• source provider kaybı,
• tax/fee normalization hatası,
• supplier timeout sonrası yanlış fallback,
• booking reference ve payment reference eşleşmemesi,
• cancellation state'in downstream'e geç ulaşması.

Observability ve KPI

Layer bazında update lag, mapping coverage, duplicate rate, availability mismatch, price mismatch, timeout/error rate, booking reconciliation drift ve unresolved attribution ölçülmelidir. “Search çalışıyor” tek başına distribution sağlığını göstermez.

Production checklist

• Her offer source/provider provenance taşıyor mu?
• Supplier ID ile canonical ID ayrılmış mı?
• Hotel, room, rate ve package identity ayrı mı?
• GDS/NDC/direct source korunuyor mu?
• Freshness timestamp'leri layer bazında tutuluyor mu?
• Booking/payment/attribution reference'ları ayrılmış mı?
• Reconciliation replay edilebilir mi?
• Fallback stale/partial sonucu açıkça işaretliyor mu?

Türkiye ecosystem hub'ı bu katmanları entity profilleriyle birlikte gösterir; bu rehber ise katmanlar arasındaki teknik sınırın neden korunması gerektiğini açıklar.