1. PMS ile Web Rezervasyon Sistemi Entegrasyonu Nasıl Çalışır?
Web booking engine ile PMS’in rol dağılımını netleştirmeden yapılan her kurulum, ileride “fiyat karmaşası”, “müsaitlik tutarsızlığı” ve “ödeme hatası” olarak geri döner. En basit çerçeve şudur: PMS genellikle oda envanteri + rate plan + rezervasyon kaydı tarafında merkezdir; booking engine ise kullanıcı deneyimi + arama/filtre + ödeme adımı + front-end satış katmanıdır.
Net cevap bloğu :
PMS–web rezervasyon entegrasyonu; PMS’ten booking engine’e availability ve rate verisinin aktarılması, web üzerinden gelen rezervasyonun ödeme/onay sonrası PMS’e otomatik kayıt olarak düşmesi ve tüm adımların GA4 ile ölçülmesi mantığıyla çalışır.
Web Rezervasyon Motoru ve PMS Arasındaki Rol Dağılımı
- •PMS (back-office “doğruluk kaynağı”): oda tipi, envanter, fiyat planı, kural seti, rezervasyon statüleri
- •Booking engine (front-office “satış motoru”): arama–seçim–checkout, kupon/kampanya uygulaması, ödeme adımı, upsell/cross-sell
- •Bağlantı katmanı: veri eşleştirme (room type / rate plan), senkron frekansı, hata yönetimi (retry/log)
Mini örnek (otel bağlamı): Kemer’de “son dakika” kampanyasıyla web’de indirim gösteriyorsunuz. PMS’te rate plan doğru değilse web’de görünen fiyat ile PMS’e düşen fiyat farklı olabilir; bu hem misafir şikayeti hem muhasebe/raporlama karmaşasıdır. Rol dağılımı net değilse ekip “hangi fiyat doğru?” tartışmasına döner.
Web Booking Engine Mantığı (Direct Booking Entity’si)
Web booking engine aslında bir “mini e-ticaret” akışıdır: ürün = oda + paket + tarih; fiyat = rate plan + kural + promosyon; ödeme = POS/sanal POS; çıktı = rezervasyon kaydı + onay. Burada hedef, Direct Booking entity’sini ölçülebilir hâle getirmek: arama → oda seçimi → ödeme → başarı.
☑ Mini Check
- • PMS mi “tek doğruluk kaynağı”? Yoksa web’de ayrı fiyat mantığı mı var?
- • Oda tipi / rate plan eşleştirmeleri yazılı mı?
- • Rezervasyon statüleri (confirmed/option) net mi?
- • Ödeme başarısız olursa rezervasyon “hold” mu, “iptal” mi?
- • GA4’te funnel event’leri tanımlı mı?
Ne yapmalıyım?
- • 1. Rol dağılımını yazın: PMS neyi yönetir, booking engine neyi yönetir?
- • 2. Oda tipi ve rate plan sözlüğünü standardize edin.
- • 3. “Ödeme başarısız” senaryosunu süreçle netleştirin.
- • 4. GA4 event şemasını kurulumdan önce kararlaştırın.
2. Gerçek Zamanlı Müsaitlik ve Fiyat Gösterimi
Direkt satışın kırıldığı ilk yer “gerçek zamanlılık” algısıdır. Misafir web’de “var” görüyor ama ödeme sonrası “yok” hatası alıyorsa, ikinci şansı çoğu zaman OTA’ya gider. Bu yüzden Availability & Rate akışı bir satış fonksiyonu kadar kritiktir.
Müsaitlik & Fiyat Akışı Nasıl Kurgulanır?
Net cevap bloğu :
Web’de gösterilen fiyat ve müsaitlik, PMS’ten gelen envanter ve rate plan verisiyle senkronize edilmelidir; senkron gecikmesi, timezone farkı ve hız limitleri için limit/hold ve retry mekanizmaları planlanmalıdır.
- •Senkron frekansı: anlık (event-based) ya da periyodik (5–15 dk). Yoğun sezonda periyodik senkron gecikmesi “sahte müsaitlik” riski üretir.
- •Timezone: PMS, booking engine ve ödeme sağlayıcısı aynı timezone mantığında çalışmalı; özellikle gece 00:00 geçişlerinde test yapılmalıdır.
- •API hız limitleri: çok sayıda oda tipi + çok sayıda rate plan + çok tarih = yüksek çağrı; başarısız çağrılar için retry/backoff + log gerekir.
Oda Tipi, Paket ve Promosyonların PMS ile Senkronu
Paket ve promosyonlar burada tuzak yaratır: web’de “%10 indirim + kahvaltı” gösterip PMS’te farklı bir rate plan’a düşürmek, operasyonu bozar. En iyi pratik:
- •PMS’te rate plan mimarisi sade (az ama net)
- •Promosyonlar “tek kural seti” üzerinden yönetilir (kupon/indirim)
- •Booking engine, PMS’ten gelen rate plan’ı doğru etiketleyip UI’de doğru sunar
Mini örnek: Belek’te “2 gece kal 3. gece %50” kampanyası web’de uygulanıyor; PMS’te karşılığı net değilse rezervasyon PMS’e düşerken fiyat parçalanır. Çözüm: kampanyayı PMS rate plan mantığıyla eşleştirip booking engine’de sadece “gösterim ve doğrulama” rolü vermek.
“Fiyat Paritesi” yerine “Fiyat Tutarlılığı”
OTA ile birebir parite hedeflenebilir ama asıl hedef, web içi tutarlılık: web’de görülen fiyat = ödeme sonrası onaylanan fiyat = PMS’e düşen fiyat. Tutarlılık bozulursa, direct booking funnel en pahalı yerden kırılır: ödeme adımı.
☑ Mini Check
- • Senkron frekansı ve tolerans (ör. 5–10 dk) belirlendi mi?
- • Timezone test edildi mi (özellikle gece geçişi)?
- • Rate plan sayısı kontrol altında mı?
- • Kupon/promo PMS karşılığı var mı?
- • “Hold inventory” (kısa süreli blokaj) kuralı var mı?
Ne yapmalıyım?
- • 1. Web’de “tutarlılık” KPI’ı tanımlayın (web fiyatı = PMS fiyatı).
- • 2. Rate plan mimarisini sadeleştirin; kampanyaları standardize edin.
- • 3. Senkron gecikmesi için hold/limit mekanizması planlayın.
- • 4. Timezone + hız limitlerini senaryolarla test edin.
3. Oda Tipi, Paket ve Promosyonların PMS ile Senkronu (mapping derinliği)
Bu bölüm “booking engine ve pms alan eşleştirme” ihtiyacını pratikleştirir. Çünkü çoğu problem, UI’deki alanların PMS’teki alanlara yanlış bağlanmasından çıkar.
Booking Engine–PMS Alan Eşleştirme Mantığı
Eşleştirmeyi üç katmanda düşünün: 1. Ürün katmanı: oda tipi, kapasite, çocuk politikası, manzara vb. 2. Fiyat katmanı: rate plan, iptal politikası, min-stay, promosyon 3. Misafir/ödeme katmanı: kimlik/iletişim alanları, ödeme durumu, onay
| Booking Engine Alanı | PMS Alanı | Not / Risk |
|---|---|---|
| Room Type ID | Room Type Code | Kod bazlı eşleştirme şart |
| Rate Plan | Rate Plan Code | Kampanya/kupon karşılığı net olmalı |
| Availability | Inventory | Senkron gecikmesi için tolerans |
| Guest Email/Phone | Guest Profile | Onay/SMS için kritik |
| Payment Status | Deposit/Guarantee | Ön provizyon/3D farkı |
| Cancellation Policy | Policy Rules | Web’de görünen metin PMS ile tutarlı |
| Special Request | Notes/Comments | Operasyon için görünürlük |
Promosyonlar: Kupon, Kampanya, Paket
- •Kupon: booking engine tarafında “doğrulama + uygulama” olabilir; PMS’e düşen fiyatın muhasebe karşılığı net olmalı.
- •Paket: PMS’te paket rate plan olarak yönetilmesi daha sağlıklı; web sadece paket UI’ı olur.
- •Upsell: (ör. transfer, spa) booking engine’de seçilebilir; PMS’e not/ek hizmet olarak düşürülür veya ayrı satış akışı olur.
☑ Mini Check
- • Eşleştirmeler ID/kod bazlı mı? (isim bazlı değil)
- • Kupon/promo muhasebe karşılığı tanımlı mı?
- • İptal politikası metni PMS ile tutarlı mı?
- • Özel istekler operasyon ekranında görünür mü?
- • “Yanlış alan eşleştirme” için alarm/log var mı?
Ne yapmalıyım?
- • 1. Alan eşleştirme tablosunu dokümante edin ve versiyonlayın.
- • 2. Kupon/paket mantığını PMS rate plan yapısıyla hizalayın.
- • 3. UI metinlerinin (iptal, ödeme) PMS kurallarıyla aynı olmasını sağlayın.
- • 4. Mapping değişikliklerinde test zorunluluğu koyun.
4. Ödeme, Ön Provizyon ve Onay Süreçleri
Direkt satış funnel’ında en pahalı kırılım noktası ödeme adımıdır. Çünkü trafik maliyeti ödenmiştir; misafir oda seçmiştir; burada yaşanan hata doğrudan kayıptır. Ayrıca ödeme akışı PMS ile doğru bağlanmazsa “rezervasyon var mı yok mu?” karmaşası doğar.
Ödeme & Onay Süreçleri Nasıl Çalışır?
Net cevap bloğu :
Ödeme akışı; (1) ödeme denemesi, (2) başarı/başarısızlık, (3) gerekirse ön provizyon, (4) PMS’e rezervasyon kaydı, (5) e-posta/SMS onayı ve (6) iptal/geri ödeme süreçleriyle birlikte tasarlanmalıdır.
- •Sanal POS / ödeme sağlayıcı: 3D secure, taksit, farklı para birimi gibi opsiyonlar
- •Ön provizyon: yüksek sezon riskini azaltır; ancak başarısız provizyon senaryosu açık olmalı
- •Rezervasyon kaydı: ödeme başarısızsa PMS’e “hold/option” düşebilir (Varsayım: 15 dk hold)
- •Onay: e-posta/SMS tetikleyicileri booking engine + PMS tarafında çakışmayacak şekilde tasarlanmalı
Ödeme Başarısızsa Ne Olur? (Hata Yönetimi)
Burada iki yanlış uç vardır: • “Ödeme başarısız olsa da PMS’e kesin rezervasyon düşürmek” → operasyon risk • “Ödeme başarısızsa hiçbir kayıt tutmamak” → müşteri hizmetlerinde iz kaybı En iyi pratik: ödeme başarısızsa kısa süreli hold, log kaydı ve misafire net mesaj. Böylece hem envanter kilitlenmez hem de müşteri yolculuğu izlenebilir.
Onay, E-posta/SMS ve İptal Süreçleri
Onay akışında “tek kaynak” önemlidir: misafir aynı rezervasyon için iki farklı onay alırsa güven zedelenir. Plan: • Booking engine: anlık “başarılı” ekranı + e-posta tetikleyebilir • PMS: rezervasyon kaydı sonrası ikinci bir doğrulama e-postası atabilir • Varsayım (en iyi pratik): tek e-posta kaynağı seçin; diğer sistem sadece event üretip loglasın.
☑ Mini Check
- • Ödeme başarılı/başarısız senaryoları yazılı mı?
- • Ön provizyon kullanılıyorsa süreç ve süre net mi?
- • PMS’e “hold vs confirmed” statüsü net mi?
- • E-posta/SMS tetikleyicileri çakışmıyor mu?
- • Ödeme ve entegrasyon hataları loglanıyor mu?
Ne yapmalıyım?
- • 1. “Başarısız ödeme” için hold + mesaj + log planı kurun.
- • 2. Onay e-postasını tek kaynaktan yönetin; çakışmayı engelleyin.
- • 3. Statü mapping’ini (hold/confirmed/cancelled) netleştirin.
- • 4. Hata yönetimini operasyonun anlayacağı alarmlara bağlayın.
5. Web Rezervasyon Verisini Raporlama ve Optimize Etmek
Entegrasyonun “kâr”a dönüşmesi ölçümle olur. “Direkt rezervasyon daha kârlıdır” genel doğrudur; fakat sizin otelinizde net etkisini görmek için GA4 event’leri ve rezervasyon e-commerce ölçümü doğru tanımlanmalıdır.
GA4 Event Kurgusu: Arama → Oda Seçimi → Ödeme → Başarı
Önerilen event seti (örnek): • search_rooms (tarih/kişi/oda araması) • select_room (oda seçimi) • begin_checkout (checkout başladı) • add_payment_info (ödeme bilgisi girildi) • purchase / reservation_success (rezervasyon başarılı) • reservation_fail (ödeme/entegrasyon hatası) • cancel_reservation (iptal)
Teknik not (sheet): GA4 event’leri (arama, oda seçimi, ödeme, başarı) ve e-commerce/rezervasyon event’lerinin doğru tanımlanması; ödeme sağlayıcısı ve PMS entegrasyonunda hata yönetimi ve loglama yapılması gerekir.
Funnel optimizasyonu: nerede kaybediyorum?
Sağlıklı funnel’ı olan otellerde, OTA payına göre daha kârlı satışların artabildiği ve doğru ölçümle bunun net gelir üzerindeki etkisinin görülebildiği senaryolar vardır (absolut rakam iddiası yerine “senaryo bazlı” değerlendirin). Örneğin Bodrum’da yüksek ADR’lı bir otelde “checkout terk oranı” %X seviyesinde kalıyorsa, ödeme akışındaki sürtünme (3D, hata mesajı, kart reddi) doğrudan gelir kaybı üretir.
Looker Studio / Raporlama ile tek ekran
Internal Link Targets içinde raporlama sayfaları var: • https://dgtlface.com/tr/raporlama/satis-donusum • https://dgtlface.com/tr/raporlama/looker-studio Bu sayfalara güçlü iç link, karar vericinin tek ekranla ilerlemesini sağlar.
☑ Mini Check
- • GA4 event isimleri ve parametreleri dokümante mi?
- • reservation_fail gibi hata event’i var mı?
- • UTM/kanal atıfı doğru mu? (SEO/SEM/Sosyal)
- • Funnel raporu Looker Studio’da tek ekranda mı?
- • “Web fiyatı = PMS fiyatı” tutarlılığı izleniyor mu?
Ne yapmalıyım?
- • 1. GA4 event şemasını kurun ve test edin (sandbox).
- • 2. Hata event’lerini görünür yapın (log + GA4).
- • 3. Funnel raporunu tek ekran kurun (Looker Studio).
- • 4. A/B testleri sadece UI’de değil, ödeme akışında da düşünün.
6. Direkt Satış Funnel Tasarım & Event Takip Şablonunu İndir — Otel / PMS Web Entegrasyonu (v1.0)
Direkt Satış Funnel Tasarım & Event Takip Şablonunu İndir — Otel / PMS Web Entegrasyonu (v1.0)
Bu şablon, PMS–web booking engine entegrasyonu kuran otellerin direkt satış funnel’ını tasarım → ölçüm → optimizasyon üçlüsünde standartlaştırır. GA4 event’lerinin doğru tanımlanması, ödeme/onay adımındaki kayıpların görünür olması ve net gelir etkisinin senaryo bazlı izlenmesi için pratik bir yapı sağlar.
Kim Kullanır?
Sales–Marketing + Revenue + Teknik ekip birlikte (tek dashboard/tek sözlük).
Nasıl Kullanılır?
- Funnel adımlarını ve event sözlüğünü doldurun (arama→oda seçimi→ödeme→başarı).
- GA4’te event’leri kurup test edin; reservation_fail dahil hata event’lerini aktive edin.
- Looker Studio’da funnel raporunu tek ekrana alıp haftalık optimizasyon rutini oluşturun.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Event isimlerini sade ve tutarlı tutun; her adım tek bir event ile temsil edilsin.
- ▢ ✅ “Hata event’i” zorunlu olsun (reservation_fail), aksi hâlde kayıp görünmez.
- ▢ ✅ Para birimi ve değer parametreleri tek formatta olsun.
- ▢ ✅ Booking ID gibi ana anahtar PMS kaydıyla eşleşsin.
- ▢ ✅ Timezone ve tarih formatı tüm sistemlerde aynı olsun.
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Direkt satış kanalını kurmak ve ölçmek isteyen oteller için.
Sık Sorulan Sorular
PMS ile web rezervasyon sistemi entegrasyonu nasıl yapılır?▾
Web’de gösterilen fiyat ve müsaitlik PMS ile nasıl senkronize edilir?▾
Direkt rezervasyon funnel’ı nasıl kurulmalı ve ölçülmeli?▾
Ödeme ve ön provizyon süreçleri PMS ile nasıl çalışır?▾
Booking engine–PMS mapping neden bu kadar kritik?▾
İlgili İçerikler
İlgili Yazılar