B2C Odaklı Rezervasyon Platformlarının Teknolojik Altyapısı

Online Seyahat Acenteleri (OTA), API Entegrasyonları, Anlık Müsaitlik Senkronizasyonu ve Kanal Yöneticisi (Channel Manager) Teknolojileri

Online Seyahat Acentesi (OTA) Nedir?

Konaklama, uçuş, transfer ve aktivite ürünlerini son tüketiciye internet üzerinden satan dijital aracı platformlardır. Stoğu üretmezler — tedarikçilerin envanterini toplar, dağıtır ve komisyon karşılığında satarlar.

Booking.com / Expedia — Klasik OTA, doğrudan rezervasyon.
Airbnb / Vrbo — Kısa dönem konaklama pazaryeri.
Trivago / Kayak — Meta-arama (fiyat karşılaştırma) motoru.
GetYourGuide / Viator — Aktivite ve tur OTA'ları.

Rezervasyon Ekosistemi: Roller ve Aktörler

Kanal Yöneticisi (Channel Manager)

Otelin envanterini (oda sayısı, fiyat, satış kuralları) tek bir merkezi panelden onlarca OTA'ya eşzamanlı dağıtan ve OTA'lardan gelen rezervasyonları PMS'e geri yazan ara yazılım katmanıdır.

Tek nokta giriş — fiyat ve müsaitlik tek panelden yönetilir.
Çift yönlü senkron — PMS ↔ CM ↔ OTA arası anlık veri akışı.
Overbooking koruması — son oda satıldığında tüm kanallar kilitlenir.
Kural motoru — minimum konaklama, kapalı tarih, fiyat farklılaştırma.

Anlık Senkronizasyon: A.R.I.

Channel Manager'ın taşıdığı üç temel veri kümesi. Her değişiklik, saniyeler içinde tüm bağlı kanallara push edilir.

A

Availability — Müsaitlik

Hangi tarihlerde, hangi oda tipinde kaç oda satılabilir? Stop-sale ve kapalı tarih bilgileri.

R

Rates — Fiyatlar

Oda tipi × kanal × tarih × kişi sayısı bazında dinamik fiyatlama. Promosyon ve indirim kuralları.

I

Inventory — Envanter

Oda tipi, yatak konfigürasyonu, kahvaltı dahil/hariç gibi ürün varyantları ve restriksiyonlar.

+

Reservation Delivery — Rezervasyon Geri Akışı

OTA'da gelen rezervasyon CM üzerinden PMS'e yazılır; iptal ve değişiklikler de aynı yoldan döner.

API Entegrasyon Modelleri

XML Push / Pull

OpenTravel Alliance (OTA) XML standartı
Booking.com, Expedia EQC tercih ediyor
SOAP üzerinden mesajlaşma yaygın
Ağır yapı, ama olgun ve geri uyumlu
Push: değişiklikte CM gönderir

VS

REST / JSON

Modern OTA'lar (Airbnb, Hostelworld)
HTTP fiili — webhook desteği
Daha hafif, geliştirici dostu
OAuth 2.0 ile yetkilendirme
Webhook ile iki yönlü olay akışı

Channel Manager, her OTA için ayrı bir adapter çalıştırarak bu protokol farklarını soyutlar.

Müsaitlik Senkronizasyon Akışı

Overbooking Riski ve Pooled Inventory

10 odanın ayrı ayrı her kanala "10 müsait" olarak gösterilmesi yerine, Channel Manager tek havuz (pool) üzerinden saymayı yapar. Bir kanaldan satış olunca diğerleri saniyeler içinde günceller.

Allocation modeli — kanala özel kontenjan tahsisi (riskli, az kullanılır).
Pool modeli — tüm kanallar aynı stoktan satar (standart yaklaşım).
Stop-sale tetiği — son oda kalınca otomatik kilitleme.
Yedekli mesajlaşma — push başarısız olursa retry kuyrukları.

Pratik: Müsaitlik Push Mesajı

Channel Manager'ın Booking.com'a göndereceği OTA XML formatında basitleştirilmiş bir OTA_HotelAvailNotifRQ mesajı. Tek bir oda tipinin belirli tarihlerde 5 odaya çıkarıldığını bildirir.

InvCode — oda tipi kimliği.
BookingLimit — o tarih için satışa açık oda sayısı.
Start / End — etkilenen tarih aralığı.

XML — OTA 2003

<OTA_HotelAvailNotifRQ
    xmlns="http://www.opentravel.org/OTA/2003/05"
    TimeStamp="2026-04-21T09:30:00"
    Version="3.0">
  <AvailStatusMessages
      HotelCode="HTL12345">
    <AvailStatusMessage
        BookingLimit="5">
      <StatusApplicationControl
          Start="2026-05-01"
          End="2026-05-07"
          InvCode="DBL-STD"
          RatePlanCode="BAR"/>
      <RestrictionStatus Status="Open"/>
    </AvailStatusMessage>
  </AvailStatusMessages>
</OTA_HotelAvailNotifRQ>

OTA vs Meta-search

OTA — Booking, Airbnb

Rezervasyonu kendi platformunda tamamlar
Ödemeyi alır, müşteri ilişkisi OTA'da
Komisyon: %15–25
Müşteri verisi sınırlı paylaşılır
Kendi sadakat programı var

≠

Meta-search — Trivago, Kayak

Sadece fiyat karşılaştırma yapar
Tıklamayı OTA veya otele yönlendirir
Maliyet: CPC (tıklama başına)
Müşteri verisi hedef siteye gider
Bid yönetimi ile sıralama

Google Hotel Ads ve Tripadvisor da meta-search modelinde çalışır.

OTA Platformunun Katmanlı Mimarisi

Pratik Uygulama: yonetim.seven.tours

Aynı OTA mantığının küçük ölçekli bir tur operatörü için uygulanışı: çoklu kaynak havuzu, tedarikçi atama, çok para birimli cari hesap ve gelecek aşama multi-tenant tedarikçi paneli.

Çoklu Kaynak Rezervasyon Havuzu

Tedarikçi Cari Hesap Modeli

Her tedarikçinin kendi para birimi (EUR/USD) tanımlıdır. Müşteriden farklı bir birimde tahsil edilen Rest tutarı, güncel kur ile tedarikçi birimine çevrilir ve cari hareketi olarak işlenir.

Net Fiyat — tedarikçiye ödenecek pas fiyatı (rezervasyon onayında girilir).
Satış Fiyatı — kaynak/domain bazlı; net fiyatın altına düşemez (zarar engeli).
Rest — müşteriden tedarikçinin yerinde tahsil edilen tutar.
Bakiye — Net Fiyat − Rest (tedarikçi birimine çevrilmiş).

Rest Akışı: GYG vs Web Sitesi

Senaryo 1 — GetYourGuide (Ön Ödemeli)

Müşteri ödemeyi GYG platformunda tamamlar
Rest alanı boş kalır
GYG, payout'u Seven Tours'a aktarır
Seven Tours tedarikçiye tam Net Fiyat öder
Cari hareketi: − Net Fiyat (tedarikçi birimi)
Kar = (GYG payout − Net Fiyat) USD'ye dönüştürülür

↔

Senaryo 2 — seven.tours (Tur Günü Öde)

Müşteri tur sabahında tedarikçiye nakit öder
Rest = toplam tutar (Örn: 110 GBP)
Tedarikçi parayı yerinde tahsil eder
Sistem: Net Fiyat − Rest (kur ile çevrilmiş)
Pozitifse → tedarikçi Seven Tours'a borçlu
Negatifse → Seven Tours tedarikçiye borçlu

İki senaryoda da nihai cari, USD ana birime raporlanır; aylık hesaplaşmada netleştirilir.

Aşama 2: Multi-Tenant Tedarikçi Paneli

Komisyon Modeli ve Tenant Cari Hesabı

Multi-tenant aşamada Seven Tours, tedarikçinin satış kanalı olarak işler. Her satışta önceden tanımlı komisyon oranı kesilir; kalan tutar tedarikçinin alacağı olarak supplier_ledger tablosuna işlenir.

Komisyon = Satış × oran (tedarikçi sözleşmesinde tanımlı, %15–25 arası).
Tedarikçi Alacağı = Satış − Komisyon − Tahsil Edilen Rest.
Aylık ekstre tedarikçi panelinde otomatik üretilir.
Çoklu site — bir tedarikçinin ürünü birden fazla domain'de yayınlanabilir; admin onayı ile.

SQL — supplier_ledger

-- Tedarikçi cari hareketi (multi-tenant)
INSERT INTO supplier_ledger (
    tenant_id,        -- tedarikçi (Aşama 2)
    reservation_id,
    direction,        -- 'CREDIT' | 'DEBIT'
    amount_supplier,  -- tedarikçi para birimi
    currency,         -- 'EUR' | 'USD'
    amount_usd,       -- raporlama için
    fx_rate,          -- snapshot kur
    description
)
SELECT
    r.supplier_tenant_id,
    r.id,
    'CREDIT',
    (r.sale_price - r.commission - r.rest_collected_eur),
    s.currency,
    (r.sale_price - r.commission - r.rest_collected_eur)
        * fx.rate_to_usd,
    fx.rate_to_usd,
    'Tur tarihi netleşmesi: ' || r.bilet_no
FROM reservations r
JOIN suppliers s ON s.tenant_id = r.supplier_tenant_id
JOIN fx_rates  fx ON fx.from_ccy = s.currency
                 AND fx.as_of    = r.tour_date;

Multi-Tenant İzolasyon Stratejileri

Database-per-Tenant

Her tedarikçiye ayrı DB
En güçlü izolasyon
Pahalı, ölçeklenmesi zor
Migration zor
10+ tedarikçide elverişsiz

Schema-per-Tenant

Tek DB, ayrı şema
Orta izolasyon
Backup/restore kolay
Cross-tenant rapor zor
100+ tedarikçide şişer

Shared Schema + RLS ✓

Tek DB, tek şema
tenant_id kolonu + RLS
En ekonomik, hızlı geliştirme
Cross-tenant rapor kolay
Seven Tours için seçim

PostgreSQL Row-Level Security ile tenant izolasyonu: CREATE POLICY tenant_isolation ON tours USING (tenant_id = current_setting('app.tenant_id')::int);

Operasyonel Atama: 3 Aşamalı Hiyerarşi

1

Tur Seçimi (Ana Kategori)

Örn: Jeep Safari. Operasyonun temel ürün ailesi belirlenir.

2

Tur Paketi Seçimi (Alt Hizmet)

Örn: Jeep Safari Botlu / Botsuz / Özel. Pakete göre tedarikçi havuzu filtrelenir.

3

Tedarikçi Belirleme (Manuel Karar)

Aynı paketi sunan birden fazla tedarikçi varsa yönetici manuel seçer. Doluluk ve fiyat dengelenir.

4

Otel + Bölge Filtresi

Otel listesi turun coğrafi bölgesiyle sınırlandırılır. Yanlış otel seçimi sistemsel olarak engellenir.

5

Bildirim → Cari Hesap

WhatsApp toplu bildirim gider, kırmızı→yeşil gösterge geçer; supplier_ledger hareketi tetiklenir.

Özet

OTA = Aracı

Stoğu üretmez, dağıtır. Booking, Expedia, Airbnb klasik örnekleridir.

Channel Manager

Onlarca OTA'yı tek panelden yöneten köprü. ARI senkronizasyonunun beyni.

A.R.I.

Availability, Rates, Inventory — sürekli akan üç veri kümesi. Her saniye senkron.

Pooled Inventory

Tüm kanallar tek havuzdan satar. Overbooking riskini minimize eder.

API: XML & REST

Booking/Expedia OTA-XML, modern oyuncular REST/JSON + webhook ile çalışır.

Meta-search ≠ OTA

Trivago, Kayak rezervasyon almaz; tıklamayı OTA'ya CPC ile yönlendirir.