1. OTA entegrasyonu nedir ve neden önemlidir?
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ış doğru tasarlanmadığında “satış açıldı” gibi görünen durum aslında hatalı fiyat, yanlış müsaitlik veya kısıtların çalışmaması 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 (AEO gereği)
- •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?
Ne yapmalıyım?
- • “Tek kaynak gerçek”i belirleyin (PMS mi, channel manager mı?).
- • Oda tipleri ve rate plan’ları için “eşleştirme haritası” çıkarın.
- • 3 temel test senaryosu tanımlayın: fiyat değişimi, stop-sell, iptal.
- • İç bağlantılarla (bilgi derinliği): PMS kurulum ve kanal yönetimi sayfalarını inceleyin.
2. Booking & Expedia entegrasyonunun temel mantığı
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.
Temel mantığı sadeleştirelim (otelde karar diliyle):
- Benim “satacağım şey” oda tipi mi, paket mi? (room vs package)
- Benim “fiyat mantığım” hangi rate plan’larla ilerliyor? (refund / non-refund / early booking)
- Benim “kural setim” ne? (min stay, stop sell, arrival/departure kapama)
- 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ı?
Ne yapmalıyım?
- • Rate plan’ları “listele → sadeleştir → eşleştir” yaklaşımıyla düzenleyin.
- • Promosyonları tek bir yerde yönetmeye karar verin (CM tarafı genelde daha güvenli).
- • “Kanallar arası tutarlılık” için haftalık kontrol ritmi oluşturun.
3. PMS + Channel Manager + OTA üçlüsü nasıl çalışı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)
Ne yapmalıyım?
- • Organizasyonda “kim hangi paneli yönetiyor?” sorusunu yazılı hale getirin.
- • PMS/CM rollerini netleştirin: PMS operasyon, CM dağıtım ve kural motoru.
- • En az 1 kez “uçtan uca test günü” planlayın (fiyat değişimi + stop sell + iptal).
4. Fiyat ve envanter akışının temel kuralları
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.
☑ 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ı?
Ne yapmalıyım?
- • Rate plan’ları sadeleştirip “ana plan + promosyon” yapısına çekin.
- • Envanteri “satılabilir oda” mantığıyla yönetip stop-sell prosedürü yazın.
- • Restriction’ları bir tabloya dökün ve her kanalda test edin (min stay + CTA/CTD).
5. OTA entegrasyonunun otel gelirine etkisi
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.
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.
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?
Ne yapmalıyım?
- • “Net gelir” perspektifiyle kanal raporlaması kurun (komisyon sonrası).
- • Hata maliyetini görünür kılın: overbooking/relocation log’u tutun.
- • Haftalık “kural ve kısıt” denetimiyle görünmez hataları yakalayın.
6. OTA entegrasyonu öncesi kontrol listesi (fark yaratan kapanış bölümü)
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)?
İç link önerileri (Technical SEO notu ile uyumlu): • PMS kurulum: https://dgtlface.com/tr/pms-ota/pms-kurulum • Kanal yönetimi: https://dgtlface.com/tr/pms-ota/kanal-yonetimi • OTA yönetimi: https://dgtlface.com/tr/otel/ota-yonetimi • Silo hub (Varsayım): https://dgtlface.com/tr/pms-ota-yonetimi
7. OTA Entegrasyonu Hata Matrisi (Operasyon + Gelir)
| Hata | Kök Neden | Çözüm | KPI etkisi |
|---|---|---|---|
| Overbooking | Tek kaynak gerçek belirsiz; envanter iki panelden güncelleniyor | Tek yönetim paneli belirle; inventory akışını tekleştir; stop-sell prosedürü yaz | Overbooking oranı düşer; misafir memnuniyeti artar |
| Fiyat tutarsızlığı (kanallar arası) | Rate plan eşleşmesi eksik; promosyon farklı çalışıyor | Rate plan’ları “listele→sadeleştir→eşleştir”; promosyon yönetimini tek yere al | Fiyat tutarlılığı artar; net ADR korunur |
| Stop-sell / restriction çalışmıyor | Restriction set OTA’da karşılık bulmuyor; eksik mapping | Restriction tablosu çıkar; min stay/CTA/CTD/stop-sell test senaryolarını çalıştır | Operasyon stabilitesi artar; iptal/şikâyet azalır |
| İptal/no-show PMS’e yanlış işleniyor | Geri bildirim akışı bozuk; PMS entegrasyon yetkinliği doğrulanmadı | PMS sürüm/entegrasyon kontrolü; uçtan uca iptal/no-show test günü | İptal oranı takibi doğru olur; raporlama kalitesi artar |
| Güncelleme gecikmesi (latency) yüksek | Kanal/PMS servisleri gecikiyor; alarm eşiği yok | Latency ölç; alarm eşikleri belirle; yoğun sezon senaryosu simülasyonu yap | Gelir kaybı azalır; hızlı aksiyon mümkün olur |
8. OTA Entegrasyonu Öncesi Hazırlık Checklist’i — PMS & OTA Yönetimi (v1.0)
OTA Entegrasyonu Öncesi Hazırlık Checklist’i — PMS & OTA Yönetimi (v1.0)
Bu checklist, Booking/Expedia entegrasyonuna başlamadan önce otelin oda tipi–rate plan–kısıt–envanter eşleştirmelerini hızlıca doğrulamanız için hazırlanmıştır. Hedef, canlıya çıkış sonrası ortaya çıkan “görünmez hataları” (fiyat tutarsızlığı, stop-sell çalışmaması, iptal akışı bozukluğu) daha kurulum aşamasında yakalamaktır. Sonuç olarak ekip, entegrasyonu “bağladık” değil, “ölçtük ve doğruladık” seviyesine taşır.
Kim Kullanır?
Rezervasyon müdürü, gelir yöneticisi (RM), ön büro lideri ve entegrasyon tarafında ajans/IT.
Nasıl Kullanılır?
- PMS + channel manager panellerinden oda tipi ve rate plan listesini çıkarın.
- Aşağıdaki checklist ile eşleştirme ve kural setini doğrulayın.
- 14 günlük sprint planıyla testleri tamamlayıp canlıya çıkın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ “Tek kaynak gerçek” seçildi: PMS mi CM mi?
- ▢ ✅ Oda tipleri sade ve net: “satılabilir oda” mantığı hazır
- ▢ ✅ Rate plan’lar temiz: BAR / refundable / non-refundable / promosyonlar
- ▢ ✅ Restriction set yazılı: min stay / CTA / CTD / stop-sell
- ▢ ✅ Kanal bazlı test listesi var: Booking + Expedia + (varsa Agoda vb.)
- ▢ ✅ Rezervasyon iptal/no-show akışı PMS’e doğru işleniyor
- ▢ ✅ Güncelleme gecikmesi ölçüldü (latency)
- ▢ ✅ Raporlama KPI’ları belirlendi (overbooking, net ADR, parity)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Mevcut PMS/CM yapınıza göre riskleri ve hızlı kazanımları 15 dakikada netleştirin.