1. PMS + OTA + Kanal Yöneticisi Entegrasyonu Nasıl Çalışır?
Bu üçlü sistemi en iyi “boru hattı” (pipeline) gibi düşünün: veri bir yerden çıkar, belirli kurallarla işlenir, doğru hedeflere gider ve geri dönüşleri toplar. Mimariyi doğru kurmak için önce şu kararı netleştirin: Tek doğruluk kaynağı (source of truth) kim? Çoğu otelde bu rol PMS’tedir; bazı yapılarda fiyat/availability dağıtım katmanı olarak channel manager öne çıkar. Buradaki kilit nokta, hangi kararın nerede verildiğini yazılı hale getirmektir.
Veri Akışı (yüksek seviye)
- •PMS (merkez): oda envanteri, rate plan, kural seti, rezervasyon kayıtları
- •Channel Manager (dağıtım): PMS’ten aldığı “rates & availability” verisini OTA’lara dağıtır
- •OTA (kanallar): satış yapar; rezervasyon/iptal/modifikasyon olaylarını geri gönderir
- •Geri dönüş: rezervasyon olayları PMS’te “doğru statü + doğru oda tipi + doğru fiyat planı” ile oluşur
Neden mimari kritik?
Çünkü hataların %80’i “bağlantı yokluğundan” değil, mapping hatası, kural çakışması, sync gecikmesi ve manuel müdahale kaynaklıdır. Örneğin Side’de bir resort’ta “family room” mapping’i yanlışsa, OTA’da satılan oda PMS’te başka oda tipine düşebilir; bu da hem operasyon karmaşası hem misafir memnuniyetsizliği doğurur.
☑ Mini Check
- •Tek doğruluk kaynağı kararı net mi? (PMS mi / channel manager mı?)
- •“Hangi sistem hangi alanı yönetir?” (rate plan, stop-sale, min-stay) yazılı mı?
- •Rezervasyon statü mapping’i tanımlı mı? (confirmed/option/guaranteed)
- •Manuel müdahale yetkileri kısıtlı mı? (OTA paneli “son çare”)
- •Log/uyarı mekanizması ve sorumlusu tanımlı mı?
Ne yapmalıyım?
- • 1. “Karar merkezi”ni belirleyin: fiyat ve envanter nereden yönetilecek?
- • 2. 10 kritik veri alanını listeleyin (oda tipi, rate plan, stop-sale, limit…).
- • 3. Kanallar arası manuel müdahale politikasını yazın (kim, ne zaman, nasıl).
- • 4. Sync gecikmesi ve hata alarmı için basit bir izleme rutini kurun.
2. Entegrasyon Akış Diyagramı ve Veri Yolları
“Veri yolu” dediğimiz şey, hangi bilginin hangi sırayla hareket ettiğidir. Burada iki kritik yol vardır: 1. Outbound (dağıtım): PMS → Channel Manager → OTA’lar 2. Inbound (geri dönüş): OTA → Channel Manager → PMS
Outbound yol: Rates & Availability dağıtımı
Outbound akışın hatasız olması için üç bileşeni birlikte düşünün: • Inventory (envanter): oda tipi bazında satılabilir oda sayısı • Rate Plan (fiyat planı): BAR, non-refundable, paket, üye fiyatı vb. • Kurallar: min-stay, CTA/CTD, stop-sale, release period
Kemer’de “last minute” kampanyası açtığınızı düşünün: eğer rate plan doğru akmıyorsa, OTA’da eski fiyat kalır; parity algısı bozulur. Eğer inventory doğru akmıyorsa, overbooking riski büyür.
Inbound yol: Rezervasyon olayları ve veri bütünlüğü
Inbound akışta en büyük risk, rezervasyonun PMS’e “doğru” düşmemesidir: • yanlış oda tipi → yanlış operasyon planı • yanlış rate plan → yanlış gelir raporu • iptal sonrası stok açılmaması → gereksiz stop-sale
Bu yüzden inbound akış sadece “rezervasyon geldi” kontrolü değil, olay bazlı kontrol ister: rezervasyon, iptal, tarih değişikliği, oda tipi değişikliği, fiyat değişikliği…
“Zaman dilimi” ve “senkron frekansı” gerçeği (teknik ama sade)
API hız limitleri ve senkronizasyon frekansı, özellikle yoğun trafik anlarında kritik olur. Bazı sistemler 5 dakikada bir “batch sync” yapar; bazıları olay bazlı çalışır. Zaman dilimi farkı (timezone) yanlış ayarlanırsa, gece yarısı envanter düşüşleri gecikebilir. Sonuç: OTA’da satılabilir görünen oda, PMS’te aslında kapanmış olabilir.
☑ Mini Check
- •Outbound ve inbound veri yolları şemada çizildi mi?
- •Sync frekansı biliniyor mu? (anlık / 5 dk / 15 dk)
- •Timezone ayarları tüm sistemlerde aynı mı?
- •İptal/modifikasyon olayları test edildi mi?
- •“OTA panelinden manuel düzeltme” son çare kuralı var mı?
Ne yapmalıyım?
- • 1. Outbound ve inbound akışları ayrı ayrı dokümante edin.
- • 2. “Gecikme toleransı” belirleyin (ör. 5–10 dk); aşılırsa alarm üretin.
- • 3. Timezone ve takvim gün değişimi senaryolarını test edin.
- • 4. OTA panel müdahalesini minimize edecek süreç kurgulayın.
3. Oda & Fiyat Mapping’i Nasıl Doğru Kurulur?
Mapping, entegrasyonun “kalp kapakçığı” gibidir: küçük hata tüm sistemi etkiler. Doğru mapping; Room Type ve Rate Plan eşleştirmelerinin hem outbound hem inbound akışta aynı dili konuşmasıdır.
Net cevap bloğu :
Oda ve fiyat mapping’ini doğru kurmak için önce PMS’te oda tiplerini ve rate plan’ları standartlaştırın, sonra channel manager’da birebir eşleyin; rezervasyon/iptal/modifikasyon senaryolarıyla test edip mapping dokümanını versiyonlayın.
1) Room Type mapping: oda tiplerinin standardı
En sık hata: PMS’te “Deluxe Sea View”, channel manager’da “Deluxe SV”, OTA’da “Deluxe Sea” gibi üç farklı ad ve bazen üç farklı kapasite/özellik. Çözüm: • PMS’te oda tipi sözlüğü oluşturun (adı, kapasite, temel özellikler) • channel manager’da birebir eşleyin • OTA’da oda tipi kartlarıyla uyumluluğu kontrol edin
2) Rate Plan mapping: fiyat planlarının disiplini
Rate plan tarafında hatalar daha sinsi olur. Çünkü farklı kurallar devreye girer: • İptal politikası / ön ödeme • minimum konaklama • kampanya ve üyelik fiyatı • ek hizmet (kahvaltı dahil vb.)
Belek gibi yüksek ADR hedefleyen otellerde “paket rate plan” yanlış mapping ile OTA’da yanlış koşulla görünürse, sonradan düzeltmek hem operasyon hem itibar maliyeti doğurur.
3) Versiyonlama ve değişiklik yönetimi
Mapping “bir kere kurulur biter” değildir. Yeni oda tipi, yeni paket, sezon kuralı… Hepsi mapping güncellemesi ister. Bu yüzden mapping dokümanı versiyonlanmalıdır: • v1.0: ilk canlı • v1.1: yeni oda tipi eklendi • v1.2: min-stay kuralı güncellendi
Mapping örnek tablosu (tek tablo – Media Pack)
| PMS Room Type | CM Room Type | OTA Room Type | PMS Rate Plan | CM Rate Plan | Not |
|---|---|---|---|---|---|
| Deluxe Sea View | Deluxe SV | Deluxe Sea View | BAR | BAR | Kapasite/özellik birebir |
| Family Room | Family | Family Room | NRF | Non-Refundable | İptal politikası kontrol |
| Standard | Std | Standard | Package-BB | BB Package | Kahvaltı dahil etiket |
☑ Mini Check
- •Oda tipi sözlüğü PMS’te standardize edildi mi?
- •Rate plan sayısı kontrol altında mı? (gereksiz çoğalma var mı?)
- •Mapping dokümanı versiyonlanıyor mu?
- •Inbound akışta oda tipi/rate plan doğru düşüyor mu?
- •Yeni paket/oda tipi açıldığında mapping güncelleme süreci var mı?
Ne yapmalıyım?
- • 1. Oda tipi ve rate plan envanterini sadeleştirin (standart isimlendirme).
- • 2. Mapping’i dokümante edin ve versiyonlayın.
- • 3. 10 senaryo ile test edin: rezervasyon/iptal/modifikasyon/stop-sale…
- • 4. Her sezon başında mapping sağlık kontrolü yapın.
4. Limit ve Stop-Sale Kuralları Overbooking’i Nasıl Azaltır?
Overbooking tamamen “kötü şans” değildir; çoğu zaman kural seti ve senkron disiplininin sonucudur. Limit, stop-sale ve kontrol mekanizmaları, hatayı yüzdeyle değil “tasarım” ile azaltır: doğru mimaride, hata oluşsa bile etkisi sınırlı kalır.
Net cevap bloğu :
Limit ve stop-sale kuralları; satılabilir envanteri sınırlandırır, belirli koşullarda satışları otomatik kapatır ve gecikmeli senkron gibi risklerde “güvenlik bariyeri” oluşturur; böylece overbooking riski düşer.
Limit türleri (pratik yaklaşım)
- •Hard limit: belirli oda tipinde maksimum satış (kanal bazlı)
- •Soft limit: talebe göre esneyen; ama alarm üreten limit
- •Allotment: belirli kanala ayrılmış kontenjan (dikkatli yönetilmeli)
Stop-sale (stop-sell) ne zaman devreye girer?
- •housekeeping/maintenance nedeniyle oda düşerse
- •grup blokajı (MICE) açılırsa
- •sistem gecikmesi/uyumsuzluk şüphesi varsa (geçici güvenlik)
“Manuel müdahale” tuzağı
OTA panelinden yapılan manuel değişiklikler, mimarinin en büyük düşmanıdır. Çünkü: • PMS’te farklı, OTA’da farklı gerçek oluşur • raporlama tutarsızlaşır • ekipler hangi kaynağa inanacağını şaşırır
Bu yüzden hedef: OTA arayüzünden müdahaleyi en aza indirmek, gerektiğinde de kayıt altına almak.
Key Statistics / Data Point (sheet’e dayalı, senaryo)
Doğru kurulmuş PMS–kanal–OTA mimarisinde, envanter ve fiyat hataları dramatik şekilde azalabilir; manuel iş yükünde ve overbooking kaynaklı maliyetlerde kayda değer düşüş senaryo bazlı gözlenebilir. Bunu ekip içinde “önce/sonra” KPI kartı ile takip etmek, mimarinin gerçek etkisini görünür kılar.
☑ Mini Check
- •Limitler oda tipi ve kanal bazında tanımlı mı?
- •Stop-sale tetikleyicileri yazılı mı? (hangi koşulda kapanır?)
- •OTA panel manuel müdahalesi kısıtlı mı?
- •Gecikmeli sync durumunda “güvenlik modu” var mı?
- •Overbooking olaylarında kök neden analizi yapılıyor mu?
Ne yapmalıyım?
- • 1. Hard limit + stop-sale bariyerlerini kurun (önce güvenlik).
- • 2. Manuel müdahaleyi azaltın; gerekiyorsa loglayın.
- • 3. Overbooking root-cause tablosu oluşturun (problem→kök neden→çözüm).
- • 4. KPI kartıyla iyileşmeyi görünür yapın.
5. Entegrasyon Testleri ve Canlıya Geçiş Planı
Rakip içeriklerin çoğu “entegrasyon nasıl çalışır” der ama test planını somutlamaz. Oysa mimarinin gerçek gücü, canlıya geçmeden önce yaptığınız testler ve canlıda izleme disiplinidir.
Test yaklaşımı: “olay bazlı” düşün
Entegrasyon testlerini 3 katmanda planlayın: 1. Smoke test: bağlantı çalışıyor mu? 2. Senaryo test: rezervasyon/iptal/modifikasyon/stop-sale doğru mu? 3. Dayanıklılık test: yoğun gün/saat, rate limit, gecikme, timezone geçişi
Canlıya geçiş (go-live) planı: pilot + yakın izleme
En iyi pratik: pilot kapsam ile başlamak. • pilot kanal (ör. 1–2 OTA) • pilot oda tipi (en çok satan ama yönetilebilir) • 48–72 saat yakın izleme: log/uyarı + manuel doğrulama
Log ve uyarı sistemi: “hata olduğunda ilk kim görür?”
Log’ları “teknik dosya” gibi değil, operasyonel alarm gibi kurgulayın: • mapping mismatch • stok geri dönmedi (iptal sonrası) • fiyat güncelleme gecikti • rate limit hatası • timezone kayması şüphesi
Teknik not (sheet): API hız limitleri, senkronizasyon frekansı, timezone
• API rate limit: aynı anda çok güncelleme yapılınca bazı çağrılar düşebilir → “retry/backoff” mantığı gerekir. • Sync frekansı: 5–15 dakikalık gecikmeler yoğun günlerde risk yaratır → limit/stop-sale bariyeri ile güvenlik artırın. • Timezone: tüm sistemlerde aynı olmalı; özellikle gece 00:00 geçişleri test edilmelidir.
☑ Mini Check
- •Test senaryoları yazılı ve sorumluları belli mi?
- •Pilot kapsam ve rollback planı var mı?
- •Log/uyarı dashboard’u var mı?
- •Canonical blog URL self-referanslı mı? (teknik SEO notu)
- •/tr/otel/pms-entegrasyonu sayfasına güçlü iç link verildi mi?
Ne yapmalıyım?
- • 1. “Canlıya geçmeden önce 10 test” checklist’ini uygulayın.
- • 2. Pilot + yakın izleme ile riskleri küçük tutun.
- • 3. Log/uyarıları operasyonun anlayacağı şekilde raporlayın.
- • 4. İlk 30 gün “entegrasyon sağlık kontrol” rutini oluşturun (haftalık).
6. PMS–Channel Manager–OTA Mapping & Limit Kontrol Listesini İndir — Otel / PMS Entegrasyonu (v1.0)
PMS–Channel Manager–OTA Mapping & Limit Kontrol Listesini İndir — Otel / PMS Entegrasyonu (v1.0)
Bu asset, PMS–channel manager–OTA entegrasyon mimarisinde en sık kaçırılan mapping, limit ve stop-sale kontrollerini tek sayfada toparlar. Amaç; canlıya geçmeden önce hataları yakalamak, manuel müdahaleyi azaltmak ve overbooking/fiyat tutarsızlığı riskini düşürmektir.
Kim Kullanır?
Revenue lideri + IT sorumlusu + front office operasyon lideri birlikte.
Nasıl Kullanılır?
- Mapping doğrulama checklist’ini doldurun (oda tipi + rate plan).
- Limit/stop-sale bariyerlerini kontrol edin ve test senaryolarını çalıştırın.
- Pilot go-live ile 48–72 saat izleyip KPI kartıyla “önce/sonra” farkını takip edin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Tek doğruluk kaynağı kararı (PMS mi / CM mi?) net
- ▢ ✅ Room Type sözlüğü PMS’te standardize
- ▢ ✅ Rate Plan sayısı kontrol altında (gereksiz çoğalma yok)
- ▢ ✅ Mapping dokümanı v1.0 hazır ve versiyonlanıyor
- ▢ ✅ Limit türleri tanımlı (hard/soft/allotment)
- ▢ ✅ Stop-sale tetikleyicileri yazılı (hangi koşulda kapanır?)
- ▢ ✅ Sync frekansı ve timezone ayarları doğrulandı
- ▢ ✅ OTA panel manuel müdahale politikası var (son çare)
- ▢ ✅ Log/uyarı dashboard’u ve sorumlusu tanımlı
- ▢ ✅ Pilot kapsam + rollback planı hazır
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Mimarinizi netleştirip overbooking ve fiyat karmaşası riskini azaltmak isteyen oteller için.