1. Kurulum akışını netleştirin: mapping + test = kalite
Bu rehberin hedefi “panel adımlarını saymak” değil; canlıya çıkmadan önce hataları yakalayacak bir disiplin kurmaktır. Entegrasyonun kalitesi; mapping doğruluğu, test rezervasyonu matrisi ve ilk 30 gün izleme ritmiyle ölçülür.
2. Booking ve Expedia hesaplarının hazırlanması
Kurulum başlamadan önce, Booking ve Expedia extranette “tanımlarınız” net olmalıdır. Çünkü mapping, tanıma bağlanır; tanım bulanıksa mapping de bulanık olur. Bu hazırlığı doğru yaparsanız, PMS ve channel manager tarafında kararlar hızlanır.
- •Oda tipleri: Resort senaryosunda ana oda + varyasyonlar (manzara, kapasite, konsept) sade tanımlanmalı.
- •Fiyat planları: Refundable / non-refundable / early booking / last minute gibi planlar isimlendirme standardına oturtulmalı.
- •Politikalar: iptal, ön ödeme, minimum konaklama ve paket içerikleri netleştirilmeli.
- •Market/pazar kombinasyonları: örn. Antalya/Belek’te belirli pazarların farklı minimum gece kuralı varsa yazılı hale getirilmeli.
Mini Check: Extranet hazırlık kontrolü
- • Oda tipi isimleri PMS/CM ile uyumlu olacak kadar net mi?
- • Rate plan’lar (refund/non-refund/promosyon) ayrı mı?
- • İptal ve ön ödeme politikaları yazılı mı?
- • Min stay / stop-sell yaklaşımı belirlendi mi?
Ne yapmalıyım? (SXO)
- • Oda tiplerini “satılabilir ürün” mantığıyla sadeleştirin.
- • Rate plan isimlerini standartlaştırın (her kanalda aynı mantık).
- • Politika ve kısıtları bir tabloya döküp ekipçe onaylayın.
3. PMS ve channel manager ayarları: bağlantı ve roller
Bu aşamada iki kritik karar vardır: (1) Tek kaynak gerçek neresi? (fiyat/kısıt PMS’te mi, channel manager’da mı?) (2) Kim hangi paneli yönetiyor? (RM, rezervasyon, ön büro, ajans/IT). Genel pratik: PMS operasyonun gerçeği, channel manager dağıtım ve kural motoru olur. Önemli olan “iki yerde birden kural yazmamak”tır.
Bağlantı kurulumu için minimum set
- •PMS ↔ Channel manager API/connector aktivasyonu
- •Kanal listesi: Booking + Expedia (ve varsa diğerleri)
- •Güncelleme frekansı/latency beklentisi (dakika seviyesinde)
Mini Check: Tek panel disiplini
- • Fiyat/kısıt değişikliği tek panelden mi yapılacak?
- • Oda müsaitliği (inventory) hangi sistemden güncellenecek?
- • Güncelleme gecikmesi ölçülecek mi? (go-live KPI)
Ne yapmalıyım?
- • “Kim, neyi, nereden yönetir?” dokümanını bir sayfaya yazın.
- • PMS’i operasyon; CM’i dağıtım/kural motoru olarak konumlandırın.
- • Go-live öncesi latency ölçüm hedefi belirleyin.
4. Room & rate mapping: adım adım kurulum listesi
Booking ve Expedia entegrasyonu nasıl yapılır? (5–7 adım)
- Oda tiplerini (RoomType) eşleştir: PMS/CM’deki oda tiplerini OTA’daki oda karşılıklarına bağla.
- Fiyat planlarını (RatePlan) eşleştir: BAR, refundable, non-refundable, promosyon planlarını OTA rate’lerine bağla.
- Kısıt setini tanımla: min stay, stop-sell, CTA/CTD gibi restriction’ların hangi kanallara nasıl dağıtılacağını belirle.
- Vergi/komisyon mantığını doğrula: net/brüt fiyat yaklaşımı ve dahil/harici kalemleri kontrol et.
- Envanter güncelleme kuralını kilitle: satılabilir oda mantığı, allotment ve kapama prosedürü net olsun.
- Örnek kombinasyonlarla “mapping audit” yap: her oda tipi × her rate plan için hızlı doğrulama tablosu oluştur.
- Test rezervasyonu aşamasına geç: canlıya çıkmadan tüm kritik senaryoları koş.
İlişkisel anlatım: RoomType → mappedTo → OTA Room, RatePlan → mappedTo → OTA Rate; TestReservation → validates → mapping + restriction + cancellation flow.
| RoomType | RatePlan | Booking test | Expedia test | İptal | Modifikasyon | Not |
|---|---|---|---|---|---|---|
| Oda A | BAR | ✓ | ✓ | ✓ | ✓ | PMS’e düşüş + fiyat doğrulama |
| Oda A | Non-refundable | ✓ | ✓ | ✓ | ✓ | Ön ödeme/ödeme kuralı kontrol |
| Oda B | BAR | ✓ | ✓ | ✓ | ✓ | Kapasite/konsept varyasyonu doğrulama |
| Oda B | Promosyon | ✓ | ✓ | ✓ | ✓ | Parite + kural dağıtımı kontrol |
Mini Check: Mapping doğrulama
- • Her oda tipi OTA’da doğru ürünle eşleşti mi?
- • Her rate plan doğru fiyat mantığıyla mı bağlandı?
- • Restriction’lar kanal bazında tutarlı mı?
Ne yapmalıyım?
- • Mapping’i “oda” ve “fiyat” diye iki ayrı kontrol listesiyle yürütün.
- • Promosyonları çoğaltmak yerine planları sadeleştirin.
- • En az 1 kez “kısıtlar” için kanal bazlı mini test yapın.
5. Test rezervasyonları ve hata senaryoları (kritik bölüm)
Rakip içeriklerin çoğu burada yüzeysel kalır: “test edin” der ama neyi test edeceğinizi söylemez. Fark yaratan bölüm, test rezervasyon matrisiniz ve hata senaryosu prosedürünüz olmalı.
Minimum test seti (her otel için)
- •Test-1: Oda tipi A + Rate plan BAR → rezervasyon → PMS’e düşüş kontrolü
- •Test-2: Oda tipi A + Non-refundable → ödeme/ön ödeme mantığı kontrolü
- •Test-3: Min stay kuralı → OTA’da doğru davranıyor mu?
- •Test-4: Stop-sell → satış kapanıyor mu, ne kadar sürede kapanıyor?
- •Test-5: İptal → OTA iptali PMS’e doğru yansıyor mu?
- •Test-6: Tarih değişikliği / modifikasyon → rate farkı ve müsaitlik güncellemesi doğru mu?
Hata senaryoları (resort gerçekleri)
- •Yanlış fiyat görünüyor → RatePlan mapping/vergiler/rounding
- •Satış kapanmıyor → stop-sell dağıtımı gecikiyor veya yanlış panelden yazılıyor
- •Overbooking riski → inventory güncellemesi/iki panel çatışması
- •İptal akışı bozuk → connector ayarı/rezervasyon status mapping
Mini Check: Test disiplini
- • Her oda × her rate plan kombinasyonu testlendi mi?
- • İptal ve modifikasyon akışı kontrol edildi mi?
- • Stop-sell ve min stay kısıtları doğrulandı mı?
Ne yapmalıyım?
- • Testleri “kombinasyon matrisi” ile planlayın (oda × rate).
- • Hata yakalayınca önce mapping’i, sonra vergileri/kısıtları kontrol edin.
- • Canlıya çıkmadan önce “test raporu” yazılı hale gelsin.
6. Canlıya geçiş ve ilk 30 gün izleme (stabilizasyon planı)
Canlıya geçiş, teknik bir “switch” değil; stabilizasyon sürecidir. Özellikle ilk 7–14 gün, küçük hatalar hızlıca büyüyebilir. Bu yüzden ilk 30 gün için izleme ritmi ve sorumluluk paylaşımı şarttır.
İlk 30 gün izleme KPI seti (pratik)
- •Overbooking olay sayısı (haftalık)
- •Fiyat tutarlılığı kontrolü (spot-check)
- •Güncelleme gecikmesi (latency) gözlemi
- •İptal/modifikasyon akışı doğruluğu
- •Kanal bazlı net ADR (komisyon sonrası perspektif)
Vaka diliyle veri noktası (yumuşatılmış): Doğru yapılmış room & rate mapping ile overbooking ve fiyat yanlışları belirgin şekilde azalır; test süreci atlanan otellerde ise ilk hafta genellikle daha yoğun destek ve düzeltme ihtiyacı doğar.
Mini Check: Go-live sonrası kontrol
- • Haftalık spot fiyat kontrolü yapılıyor mu?
- • İptal/modifikasyon örnekleri loglanıyor mu?
- • Operasyon ekibi “kapanma prosedürünü” biliyor mu?
Ne yapmalıyım?
- • İlk 30 gün için “günlük 10 dk kontrol” ritmi belirleyin.
- • Hata matrisi çıkarıp tekrar eden kök nedenleri kapatın.
- • Ekip eğitimini iç linklerle destekleyin (pms kurulum + kanal yönetimi).
7. Booking & Expedia Kurulum ve Test Checklist’i — PMS & OTA Yönetimi
Booking & Expedia Kurulum ve Test Checklist’i — PMS & OTA Yönetimi (v1.0)
Bu doküman, Booking ve Expedia entegrasyonunu canlıya almadan önce room/rate mapping doğruluğunu ve test rezervasyonu senaryolarını tek sayfada yönetmeniz için tasarlanmıştır. Amaç, go-live sonrası “ilk hafta krizi” yaratabilecek fiyat hatası, kapama kuralı çalışmaması ve iptal akışı problemlerini erken yakalamaktır. Sonuç olarak ekibiniz daha az reaktif destek, daha hızlı stabilizasyon görür.
Kim Kullanır?
RM, rezervasyon müdürü, ön büro lideri ve entegrasyonu yöneten ajans/IT.
Nasıl Kullanılır?
- Oda tipleri + rate plan listesini PMS/CM’den çıkarın.
- Mapping ve test matrisiyle her kombinasyonu doğrulayın.
- 14 günlük sprint planıyla go-live öncesi tüm senaryoları tamamlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Tek kaynak gerçek belirlendi (PMS mi CM mi?)
- ▢ ✅ RoomType listesi sade ve satış mantığıyla uyumlu
- ▢ ✅ RatePlan listesi (BAR/refund/non-refund/promosyon) standardize
- ▢ ✅ Vergi/ücret dahil-hariç mantığı net
- ▢ ✅ Restriction set (min stay/stop-sell/CTA/CTD) yazılı
- ▢ ✅ Booking test seti hazır
- ▢ ✅ Expedia test seti hazır
- ▢ ✅ İptal + modifikasyon akışı doğrulama adımları hazır
- ▢ ✅ Latency gözlem hedefi (dakika) belirlendi
- ▢ ✅ İlk 30 gün izleme KPI seti belirlendi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: Sorunsuz go-live, “mapping + test + izleme” disiplinidir
Booking ve Expedia entegrasyonunda başarı, tek bir ayar ekranına bağlı değildir. Oda ve fiyat planlarının standart tanımı, room/rate mapping doğruluğu, test rezervasyonu disiplini ve ilk 30 gün izleme ritmi birlikte çalıştığında; yanlış fiyat, kapama hatası ve overbooking riski anlamlı şekilde düşer.
Bir Sonraki Adım
Kurulum, mapping ve test sürecini otelinizin oda tiplerine göre hızlandırın.
Sık Sorulan Sorular
Booking ve Expedia entegrasyonu nasıl yapılır?▾
Room ve rate mapping adımları nelerdir?▾
OTA entegrasyonunda test rezervasyonu neden önemlidir?▾
Canlıya alınmadan önce neler test edilmeli?▾
Test süreci atlanırsa ne olur?▾
Resort otellerde en kritik mapping riski nedir?▾
Antalya/Belek gibi destinasyonlarda hangi testler ekstra önemli?▾
İlgili İçerikler