Rezervasyon Yönetimi Nedir? Oteller İçin Çok Kanallı Rezervasyon Akışının Temel Mantığı

Rezervasyon yönetimi nedir ve oteller için neden kritiktir?

Rezervasyon yönetimi; Reservation’ın (rezervasyonun) farklı kaynaklardan (OTA, WebsiteBooking, CallCenterBooking, walk-in) gelip PMSReservation olarak tek kayda dönüştüğü ve her adımın bir Status ile yönetildiği süreçtir. Kritik olmasının nedeni şudur: satış kanalı çeşitlendikçe “aynı odaya iki kez satış”, “yanlış tarih”, “yanlış fiyat planı”, “konuk notunun kaybolması” gibi hatalar artar. Standardize edilmiş bir akış, hatayı azaltırken ekipler arasında “kim, ne zaman, ne yaptı?” sorusunu da netleştirir.

Rezervasyon akışını “tek cümle” ile kurarsak: Talep oluşur → opsiyonlanır → onaylanır → misafir gelir (check-in) → konaklama biter (check-out). Bu adımlar basit görünür; fakat çok kanallı yapıda her adımın kaynağı, doğrulama yöntemi ve sorumlusu değişir. Bu yüzden “akış”ı sadece şema olarak değil; sorumluluk + veri + kontrol kombinasyonu olarak düşünmelisiniz.

1) Talep (Inquiry / Request)

Talep; web formu, telefon, WhatsApp, OTA mesajı veya walk-in ile gelebilir. Bu aşamada amaç “satış” değil; doğru veriyle sonraki adıma geçmektir: tarih, kişi sayısı, oda tipi tercihi, iletişim, fiyat çerçevesi ve özel notlar.

• •Giriş kanalı belli mi? (OTA / web / call / walk-in)
• •Tarih + kişi + oda tipi net mi?
• •İletişim bilgisi doğrulandı mı?
• •Fiyat planı / paket adı işlendi mi?
• •Özel not / kısıt (sigara, çocuk, transfer) kaybolmadı mı?

2) Opsiyon (Option / Hold)

Opsiyon; misafire “şu fiyattan şu odayı şu süre tutuyorum” demektir. En sık hata: opsiyonun süresiz kalması veya opsiyonun “stok”tan düşmemesi. Doğru model: opsiyon süresi tanımlı, otomatik düşen, raporlanabilir olmalı.

3) Onay (Confirmed)

Onay; ödeme, garanti, sözleşme veya OTA’nın kesinleştirmesi ile oluşur. Bu aşamada iki kritik kontrol vardır: 1. Müsaitlik doğru mu? (Availability) 2. Fiyat planı doğru mu? (RatePlan) Onay aşamasında PMSReservation artık “tek doğru kayıt” olmalıdır; tüm ekip aynı kaydı referans alır.

4) Check-in

Check-in; sadece kimlik almak değil, rezervasyonun operasyonla buluştuğu andır. Oda değişikliği, upsell, geç giriş, özel istek gibi detaylar bu aşamada netleşir.

5) Check-out

Check-out; folyo kapanışı ve memnuniyetin son dokunuşudur. Ayrıca veri kalitesi için kritik: no-show/early departure/uzatma gibi istisnaları doğru işlemek, rapor doğruluğunu belirler.

Çok kanallı yapı, farklı kaynaklardan gelen rezervasyonların tek akışta birleşmesi demektir. Buradaki hedef “her kanalı ayrı ayrı yönetmek” değil; kanalları aynı statü ve veri standardına bağlamaktır.

OTA rezervasyonları (OTA → PMS)

OTA tarafı genellikle “onaylı rezervasyon” olarak gelir ve otomatik akışla PMS’e düşer. Riskler: kanalın gönderdiği oda tipi eşlemesi, fiyat planı eşlemesi, iptal/no-show kuralları ve mesaj-not akışı.

Web rezervasyonları (WebsiteBooking → PMS)

Web rezervasyonunda ödeme/garanti akışı daha esnektir; preauth, ön ödeme, kampanya kodu gibi katmanlar devreye girer. Risk: web motoru ile PMS arasında “fiyat/müsaitlik” senkronunun gecikmesi.

Çağrı merkezi rezervasyonları (CallCenterBooking → PMS)

Çağrı merkezi rezervasyonları çoğunlukla manuel girilir; bu da “insan hatası” riskini artırır. Avantajı, doğru bir script ve form ile veri kalitesini yükseltmektir.

Walk-in (Front Desk → PMS)

Walk-in, özellikle sezon yüksekken hızlı karar gerektirir. Risk: PMS’e geç girildiğinde overbooking’e davetiye çıkarır.

OTA, web ve çağrı merkezi rezervasyonları PMS’te nasıl birleştirilir?

Birleştirme mantığı basittir: Kaynak fark etmez; hedef kayıt PMSReservation’dır. Her rezervasyon; “source/channel” alanı ile etiketlenir, aynı statü setini kullanır ve aynı minimum alanları taşır. Böylece raporlarda “hangi rezervasyon nereden geldi?” sorusu saniyeler içinde cevaplanır; operasyon ekipleri aynı ekrana bakar.

PMS tarafında rezervasyon yönetimi iki parçadan oluşur: 1. Rezervasyon kartı (PMSReservation record) 2. Durumlar + kurallar (Status + policy logic)

Rezervasyon kartında hangi bilgiler mutlaka yer almalıdır?

Aşağıdaki alanlar “minimum standart”tır; her PMS farklı görünebilir ama mantık değişmez:

• •Misafir bilgileri: ad-soyad, iletişim, ülke, özel notlar
• •Konaklama bilgileri: giriş/çıkış, gece sayısı, kişi sayısı, oda tipi
• •Kanal bilgisi: OTA / web / call center / walk-in + referans numarası
• •Fiyat planı ve toplam: rate plan, paket, vergi/ücret ayrımı (mümkünse)
• •Garanti/ödeme durumu: ön ödeme, kart garantisi, iade/iptal koşulu
• •Statü: talep/opsiyon/onay/check-in/check-out (+ iptal/no-show)
• •Operasyon notları: transfer, yatak tipi, alerji, VIP, erken giriş/geç çıkış
• •Audit trail: kim oluşturdu, kim değiştirdi, ne zaman? (mümkün olan ölçüde)

AIO notu (entity ilişkisi): Reservation → createdIn → PMSReservation, Reservation → hasStatus → Status, Reservation → hasSource → OTA/WebsiteBooking/CallCenterBooking, PMSReservation → affects → Availability/Inventory, PMSReservation → pricedBy → RatePlan.

Statü sözlüğü: “herkes aynı şeyi mi anlıyor?”

“Opsiyon” bir otelde 2 saat, diğerinde 2 gün olabilir. İşte bu yüzden küçük bir “statü sözlüğü” şarttır: her statünün tanımı, geçiş kuralı, sorumlusu ve rapor etkisi yazılır.

• •Statü sayısı 5–8 aralığında mı (fazla karmaşa yok mu)?
• •Her statünün “giriş koşulu” yazılı mı?
• •Opsiyonun süre kuralı net mi?
• •İptal/no-show statüleri raporda ayrı mı takip ediliyor?
• •Statü değişiklikleri audit trail’de görünür mü?

Hızlı görünürlük: “Rezervasyon yönetiminde ilk 5 temel adım”

1. Kaynak kanalı etiketle
2. Minimum alan setini eksiksiz doldur
3. Statüyü doğru seç (talep/opsiyon/onay…)
4. Rate + availability eşleşmesini kontrol et
5. Gün sonu anormallik kontrolünü çalıştır

GEO bağlamında aynı akış; Antalya resort ile İstanbul city hotel’de farklı baskılar taşır. Antalya/Belek/Side/Kemer/Alanya hattında sezon, grup girişleri, transfer ve paketler öne çıkar. Bodrum’da kısa konaklama ve kanal çeşitliliği artabilir. İstanbul’da iş seyahati, hafta içi–hafta sonu dalgası ve hızlı check-in/out baskısı belirgindir.

Senaryo 1: Antalya / Belek resort oteli (OTA + call center karışık)

• •Misafir OTA’dan rezervasyon yapar (Confirmed).
• •Aynı misafir, oda yükseltme için çağrı merkezini arar (CallCenterBooking).
• •Risk: iki ayrı kayıt açılırsa mükerrerlik ve yanlış oda blokajı oluşur.

Doğru uygulama: OTA rezervasyonunu tek PMSReservation olarak referans al, çağrı merkezinin işlemini “modification/upsell” olarak aynı kayda bağla.

• •Grup/transfer notları kayda işleniyor mu?
• •Paket ve rate plan doğru mu?
• •Değişiklikler tek kayıt üzerinde mi?
• •No-show ve iptal politikası net mi?

Senaryo 2: Side / Kemer bölgesinde web kampanyası (web + ön ödeme)

• •Web’den kampanya kodu ile talep gelir, ön ödeme alınır.
• •PMS’e geç düşen senkron yüzünden OTA’da aynı oda satılabilir.

Doğru uygulama: web motoru–PMS senkronu için “buffer” ve hızlı düşüm kuralı; ayrıca kampanya kontenjanı tanımla.

Senaryo 3: İstanbul city hotel (call center opsiyon → aynı gün check-in)

• •Misafir sabah arar, akşam giriş yapacaktır.
• •Opsiyon süresi çok uzunsa stok yanlış tutulur; çok kısaysa satış kaçar.

Doğru uygulama: city otelde opsiyon SLA’sı (örn. 2–4 saat) ve otomatik düşüm kuralı.

Senaryo 4: Bodrum’da walk-in + OTA çakışması

• •Walk-in misafir gelir, oda ayrılır ama PMS’e geç girilir.
• •Aynı oda OTA’da satılır (overbooking riski).

Doğru uygulama: walk-in kayıtlarının PMS’e anlık girilmesi + “çakışma alarmı” kontrolü.

Çok kanallı rezervasyon yönetimini oturtan otellerde genellikle şu etkiler gözlenir: mükerrer kayıt kaynaklı şikâyetler azalır, resepsiyon “hangi rezervasyon nereden geldi?” sorusuna daha hızlı yanıt verir, iptal/no-show ve fiyat uyuşmazlığı daha erken yakalanır. Bu yazıda kesin rakam iddiası yerine ölçülebilir KPI çerçevesi kurmak daha doğrudur.

Örnek KPI seti (uygulanabilir tablo)

Rakip içeriklerin çoğu rezervasyonu PMS ekran tanıtımı gibi ele alıyor; fakat asıl fark, ekranın arkasındaki iş akışı ve çok kanallı yapının birlikte kurgulanmasıdır. Bu yüzden aşağıdaki üç katmanı birlikte tasarlayın:

1. Süreç katmanı: talep→opsiyon→onay→check-in→check-out (tanım + sorumlu + geçiş kuralı)
2. Veri katmanı: minimum alan seti + source + rate plan + audit trail
3. Kontrol katmanı: çakışma kontrolü + opsiyon süreleri + anormallik raporları