OTA Entegrasyonu Nedir? Booking & Expedia ile Oteliniz Nasıl Çalışır?

OTA entegrasyonu, otelin envanter ve fiyat bilgisinin (ve çoğu zaman kısıtların) Booking.com, Expedia, Agoda gibi kanallara otomatik senkron aktarılmasıdır. Buradaki “entegrasyon” bir defalık bağlantı değil; günlük operasyonun kalbinde çalışan sürekli bir veri akışıdır. Bu akışı daha geniş PMS & OTA yönetimi çerçevesi içinde okumak, teknik bağlantıyı operasyon diliyle eşleştirmenizi kolaylaştırır.

Bu veri akışının sağlıklı çalışması için altyapıda PMS kurulum tarafı temiz olmalı, dağıtım mantığı ise kanal yönetimi disipliniyle birlikte düşünülmelidir. Aksi halde “satış açıldı” gibi görünen durum, arka planda hatalı fiyat veya yanlış müsaitlik anlamına gelebilir.

Neden önemlidir? (Özet etkiler)

• •Overbooking riskini azaltır: aynı oda tipinin birden fazla kanalda çakışmasını önler.
• •Fiyat tutarlılığı sağlar: web / OTA / B2B kanal fiyatları kontrol altına alınır.
• •Operasyon yükünü düşürür: resepsiyon ve rezervasyon ekibi “manuel güncelleme” yerine “kontrol ve optimizasyon” yapar.
• •Gelir yönetimini hızlandırır: sezon, doluluk ve talep değişimlerine daha hızlı tepki verirsiniz.

4–5 maddelik kısa yanıt bloğu

• •OTA entegrasyonu, PMS/channel manager üzerinden rate + inventory bilgisini OTA’lara taşır.
• •“Tek kaynak gerçek” belirlenir: PMS mi yoksa channel manager mı ana yönetim panelidir.
• •OTA’lar gelen rezervasyon/iptali geri gönderir; PMS ve raporlama doğru beslenir.
• •Doğru kurulum, fiyat tutarlılığı + müsaitlik doğruluğu + kısıtların çalışması demektir.
• •Yanlış kurulum, çoğu zaman “görünmez hata” üretir: gelir kaybı ve misafir memnuniyetsizliği.

Mini örnek (resort senaryosu)

Belek’te bir resort düşünün: A oda tipi için son dakika kampanyası açtınız. Eğer kampanya fiyatı Booking’de güncellenip Expedia’da kalırsa, aynı gün içinde iki farklı fiyat algısı oluşur. Bu durum sadece gelir kaybı değil; misafirin “neden farklı?” sorusuyla itibar riskine de dönüşür.

☑ Mini Check : “Entegrasyon var mı, yok mu?”

• •En az bir kanalda fiyat/oda güncellemesi yaptığımda diğer kanal 5–15 dakika içinde güncelleniyor mu?
• •Kısıtlar (min stay / stop sell) her kanalda aynı davranıyor mu?
• •Rezervasyon iptali PMS’e doğru işleniyor mu?

Booking ve Expedia’nın farklı extranet alışkanlıkları olsa da entegrasyon mantığı aynı çekirdeğe oturur: • Oda tipi (room type) • Rate plan (fiyat planı) • Müsaitlik (availability/inventory) • Kısıtlar (restrictions: min stay, CTA, CTD, stop sell) Bu parçaların her biri, PMS veya channel manager’da bir “tanım” olarak yaşar. OTA tarafında da karşılığı vardır. Entegrasyon “tanımlar arası doğru eşleşme” demektir.

En çok yapılan hata: “Oda tipi aynı ya” diyerek, rate plan’ları ve kısıtları eksik eşleştirmek. Sonuç: sistem çalışıyor sanırsınız ama promosyonlar, minimum konaklama veya kapama kuralları bir kanalda farklı davranır.

Kavramsal mantık netleştikten sonra pratikte hangi sırayla ilerleyeceğinizi görmek için Booking & Expedia entegrasyonu kurulum rehberi uygulama tarafını somutlaştırır.

Temel mantığı sadeleştirelim (otelde karar diliyle):

1. Benim “satacağım şey” oda tipi mi, paket mi? (room vs package)
2. Benim “fiyat mantığım” hangi rate plan’larla ilerliyor? (refund / non-refund / early booking)
3. Benim “kural setim” ne? (min stay, stop sell, arrival/departure kapama)
4. Bu tanımlar OTA’da bire bir karşılık buluyor mu?

Mini örnek (Antalya yaz sezonu):

Antalya’da yaz yoğunluğunda 3 gece min stay kuralı koydunuz. Booking’de çalışıyor ama Expedia’da çalışmıyorsa, Expedia’dan 1 gecelik satış alırsınız. Bu, operasyonu bozar (oda planı, housekeeping ritmi) ve gelir yönetimini çarpıtır.

☑ Mini Check : “Rate plan eşleşmesi”

• •Refundable / Non-refundable rate plan’lar ayrı ayrı eşleşti mi?
• •Promosyonlar (EB, last minute) için ayrı plan mı var, aynı plan üzerinde indirim mi?
• •Min stay / stop sell kuralları kanal bazlı tutarlı mı?

Bu noktada fiyat akışını yalnız teknik eşleşme gibi değil, rate parity ve fiyat eşitleme stratejileri perspektifiyle de okumak gerekir. Çünkü doğru mapping, ancak doğru fiyat disipliniyle ticari değere dönüşür.

Bu üçlü aslında bir “dağıtım zinciri”dir. En pratik anlatım şudur: • PMS: Otelin “operasyonel gerçekliği” (check-in/out, oda durumu, misafir kayıtları, konaklama akışı). • Channel Manager: Satış kanallarına “dağıtım ve kural motoru” (rate, inventory, restriction dağıtımı). • OTA: Talebin geldiği vitrin (görünürlük, dönüşüm, rezervasyon, iptal).

AIO gereği ilişkiyi açık edelim: PMS → sends → Rates & Inventory → to Channel Manager → distributes → to OTA. Bazı kurulumlarda fiyat/kısıtlar PMS’ten değil, channel manager’dan yönetilir; PMS sadece rezervasyon “son kayıt” olur. Önemli olan, tek bir yönetim noktası belirleyip çakışmayı önlemektir.

Kritik karar: “Tek kaynak gerçek” neresi?

• •Eğer PMS fiyat/kısıt yönetiminde zayıfsa, channel manager merkez olur.
• •Eğer PMS güçlü RMS/price rules sunuyorsa, PMS merkez olabilir; CM dağıtır.
• •Her iki tarafta da kural yazmak: en yaygın hatadır.

Mini örnek (Side / Kemer operasyonu):

Side’deki otelde resepsiyon PMS’ten oda kapatıyor, pazarlama CM’den kampanya açıyor. Aynı gün iki farklı panelde iki farklı kural yazılırsa, bir OTA’da satış kapanır, diğerinde açık kalır. Bu da “bir kanaldan satış geldi ama aslında oda kapalıydı” gibi kriz üretir.

☑ Mini Check : “Tek kaynak gerçek testi”

• •Fiyat/kısıt değişikliğini tek bir panelden mi yapıyoruz?
• •Aynı kural iki yerde yazılı mı? (PMS + CM)
• •Güncelleme gecikmesini (latency) ölçtük mü? (5–15 dk normal, saatler risk)

Entegrasyonun “kalite standardı” şu iki soruda saklıdır: 1. Fiyat nerede yönetiliyor? (rate rules, promosyonlar, paketler) 2. Envanter nerede güncelleniyor? (availability, allotment, stop-sell)

1) Rate (Fiyat) kuralları – minimum set

• •Rate plan hiyerarşisi: BAR, non-refundable, early booking, last minute…
• •Parite yönetimi: Web/OTA/B2B fiyatlarının kontrol mantığı
• •Komisyon etkisi: OTA komisyonu sonrası net gelire bakış (net ADR)

2) Inventory (Envanter) kuralları – minimum set

• •Oda tipi bazında müsaitlik: “Toplam oda” değil, “satılabilir oda” mantığı
• •Stop-sell disiplini: bakım/operasyon/overbooking riskinde anında kapama
• •Allotment ve serbest satış: B2B allotment’ları OTA’lara taşımamayı netleştirme

3) Restriction (Kısıtlar) – çoğu otelin atladığı bölüm (Competitor gap’i kapatan mini bölüm)

Birçok içerik “oda ve fiyat”ta kalır; fark yaratan kısım kısıtların doğru yönetimidir: • Min stay (minimum konaklama) • CTA/CTD (arrival/departure kapama) • Stop sell (tam kapama) • Close to arrival / close to departure Bu kurallar doğru çalışmadığında, “doluluğu yönetiyorum” zannedersiniz ama kanal bazında dengesiz satış alırsınız.

Key Statistics / Data Point (yumuşatılmış benchmark): Bazı resort otellerde, doğru kurgulanmış OTA entegrasyonu ile online satışların önemli bir kısmının (çoğu benchmark’ta OTA ağırlığının yüksek seyrettiği) senkron ve hatasız yönetilebildiği görülür; kritik olan oranı kovalamak değil, hata maliyetini sıfıra yakınlatmaktır.

Özellikle stok güncellemesi gecikiyor, aynı oda farklı kanallarda çakışıyor veya kapama kuralları tutarsız davranıyorsa overbooking risk yönetimi yaklaşımı devreye girmelidir. Bu içerik, senkron hatasının operasyon krizine nasıl dönüştüğünü daha net gösterir.

☑ Mini Check : “3 katman kuralı”

• •Rate plan’lar sade mi, çoğalmış mı? (gereksiz planlar risk)
• •Inventory güncellemeleri tek yerden mi?
• •Restriction setimiz yazılı mı, kanallarda tutarlı mı?

OTA entegrasyonu “teknik bir kurulum” gibi görünse de gelir tarafında üç net çıktısı vardır:

1) Görünürlük → Dönüşüm etkisi

OTA’larda görünürlük sadece reklamla değil; doğru müsaitlik ve rekabetçi, tutarlı fiyatla da ilgilidir. Yanlış eşleşme yüzünden “kapalı” görünen oda tipi, görünürlüğünüzü düşürür. Bu da daha az tıklama, daha az rezervasyon demektir.

Bu teknik kurgu, günlük ticari karar tarafında otel OTA yönetimi disipliniyle birleşir. Çünkü görünürlük, fiyat, kampanya ve kanal önceliği birlikte yönetilmeden entegrasyonun gelir etkisi tam alınamaz.

2) Operasyon hatası maliyeti (gizli maliyet)

• •Overbooking olduğunda sadece “bir misafir” kaybetmezsiniz; transfer, upgrade, iade, itibar ve personel zamanı dahil katlanarak büyüyen bir maliyet üretirsiniz.
• •Fiyat tutarsızlığında, misafir “aynı oda iki farklı fiyat” gördüğünde güven kırılır.

3) Gelir yönetimi hızı

Doğru entegrasyon, ekibinizin zamanı “manuel güncelleme”den “gelir optimizasyonu”na kaydırır. Özellikle Bodrum, Kemer, Alanya gibi dönemsel talebin sert değiştiği destinasyonlarda hızlı aksiyon, fark yaratır.

Aynı zamanda OTA bağımlılığı ile direct booking dengesi de bu teknik omurgadan etkilenir; bu yüzden kanal karmasının marka ve talep tarafındaki karşılığını otel dijital pazarlama perspektifiyle birlikte değerlendirmek gerekir.

Mini örnek (Bodrum hafta sonu talebi):

Hafta sonu talebi yükseldi; BAR’ı artırdınız. Eğer güncelleme bir kanalda gecikirse, düşük fiyattan satış alır ve “yüksek talep gününde” gelir kaybedersiniz.

☑ Mini Check : “Gelir etkisi ölçüm seti”

• •Kanal bazlı net ADR takibi var mı? (komisyon sonrası)
• •Overbooking / relocations kaydı tutuluyor mu?
• •Fiyat tutarsızlığı şikâyeti izleniyor mu?

Bu yazının hedefi, entegrasyona başlamadan önce “en kritik 10 şeyi” netleştirmek. Aşağıdaki mini kutu, projeyi problemsiz başlatmak için yeterli bir çerçeve sunar.

☑ Mini Check (Final): “Entegrasyona başlamadan önce”

• •PMS sürüm/entegrasyon yetkinliği doğrulandı mı?
• •Channel manager seçimi, OTA sayısı ve ihtiyaçlara göre yapıldı mı?
• •Oda tipleri ve rate plan’lar sadeleştirildi mi?
• •Restriction set (min stay/CTA/CTD/stop sell) yazılı mı?
• •Test senaryoları belirlendi mi (fiyat, stop-sell, iptal, no-show)?
• •Roller net mi: kim PMS, kim CM panelini yönetiyor?
• •İç link planı hazır mı (rehber → detay yazılar)?

Kurulum modelini hizmet tarafında derinleştirmek için OTA entegrasyonu hizmeti sayfasına, uygulama öncesi sık soruları toparlamak için de OTA entegrasyonu hakkında sık sorulan sorular katmanına geçebilirsiniz.