1. Self-Service Rezervasyon Nedir?
Self-service rezervasyon; misafirin rezervasyonunu bir portal/uygulama üzerinden görmesi, temel bilgileri doğrulaması ve belirli işlemleri kendi başına başlatabilmesidir. Bu sadece “online check-in” değildir; rezervasyon yaşam döngüsünün değişiklik tarafına dokunur: tarih kaydırma, oda tipi değişimi, ek hizmet, varış saati, yolcu bilgisi güncelleme gibi.
Self-service rezervasyon neyi değiştirir?
- •Misafir anında görünürlük kazanır (ref no, tarih, koşul, ödeme)
- •Değişiklik “telefon kuyruğu” yerine kural tabanlı akışa döner
- •Operasyon ekipleri için “aynı bilgi” tek kaynağa bağlanır (PMSReservation)
- •İletişim trafiği azalırken, doğru kural tasarımı olmazsa politika ihlali artabilir
Ne yapmalıyım?
- • Self-service kapsamını 3 seviyede tanımla (gör/başlat/yap)
- • Her işlem için “kural seti” yaz (PolicyRules)
- • Portalı PMS’e tek yönde değil, çift yönlü senkron düşün (sync)
- • İlk etapta düşük riskli işlemlerle başla, kapsamı kademeli genişlet
2. 2026’da Misafirin Kendi Rezervasyonunu Yönetmesi
2026’da misafir alışkanlığı net: “Okudum → kontrol ettim → değiştirdim / talep açtım.” Bu yüzden self-service tasarımı, misafirin “ben bunu yapabilir miyim?” sorusuna hızlı cevap vermelidir.
Misafirler hangi işlemleri kendi başına yapabilmeli, hangileri manuel onay gerektirmeli?
Self-service kapsamı işlem riskine göre ayrılmalıdır. Düşük riskli ve doğrulanabilir işlemler otomatik akışa alınabilir; fiyat, iptal, kritik oda tipi veya KVKK açısından hassas alanlara dokunan işlemler ise manuel onaya düşmelidir.
| İşlem | Self-service (Otomatik) | Manuel Onay | Eşik/Not |
|---|---|---|---|
| Varış saati güncelleme | ✅ | düşük risk | |
| İletişim düzeltme | ✅ | doğrulama | |
| Tarih değişikliği | ✅ / ⚠️ | ✅ | kritik günlerde manuel |
| Oda tipi değişimi | ✅ / ⚠️ | ✅ | upgrade manuel |
| Ek hizmet (transfer/spa) | ✅ | müsaitlik kontrol | |
| İptal | ✅ | ceza/iade koşuluna göre |
Self-service (otomatik) uygun işlemler
- •Varış saati güncelleme, iletişim bilgisi düzeltme
- •Ek hizmet talebi (transfer/spa) (müsaitse otomatik onay veya “talep”)
- •Tarih kaydırma sadece belirli pencere ve kuralla (örn. 7+ gün kala)
- •Oda tipi değişikliği sadece eşdeğer/önceden tanımlı alternatifler
Manuel onay gerektiren işlemler
- •İptal (özellikle iade/ceza varsa)
- •Büyük fiyat farkı/kompleks revizyon (kampanya, kurumsal kod, grup)
- •KVKK açısından hassas veri içeren güncellemeler (kimlik/pasaport gibi)
- •Overbooking riski yaratan değişiklikler (kritik gün, kritik oda tipi)
Ne yapmalıyım?
- • Kural motorunu 5–8 basit kural ile başlat (sonra genişlet)
- • “Manuel onay” durumunda SLA belirle (örn. 2 saat içinde dönüş) (Varsayım: operasyon hedefi)
- • Self-service ekranında “geri alma”/iptal talebi için net yol göster
- • Kritik günlerde self-service’i “talep topla” moduna çek (otomatik onay değil)
3. Web/Mobil Uygulama Üzerinden Tarih ve Oda Değişikliği
Tarih ve oda değişikliği, self-service’in en değerli ama en riskli iki alanıdır. Değerli çünkü çağrı merkezi yükünü ciddi azaltır; riskli çünkü fiyat farkı, kısıtlar ve envanter etkisi vardır.
Web/mobilde tarih değişikliği akışı (örnek)
- Misafir yeni tarih aralığını seçer
- Sistem kısıtları kontrol eder (min stay/stop-sell)
- Ücret farkı otomatik hesaplanır (PriceAdjustment)
- Misafir onaylar (kabul/ret)
- PMS’e senkronlanır + change history kaydı oluşur
Oda tipi değişikliği / upgrade akışı (örnek)
- •“Eşdeğer oda değişimi” otomatik olabilir
- •“Upgrade” ise fiyat + değer farkı net gösterilmelidir
- •Kritik gün/oda tipinde manuel onay devreye girebilir
Ne yapmalıyım?
- • Fiyat farkını tek ekranda şeffaf göster (eski–yeni)
- • Misafire “hangi koşul değişti?” bilgisini sade ver
- • İptal penceresi ve ceza kuralını açık yaz (sürpriz olmasın)
- • Kritik günlerde otomatik onay yerine “talep” modunu kullan
4. Self-Service Süreçlerinin PMS ile Entegrasyonu
Self-service’in başarısı, PMSIntegration kalitesine bağlıdır. “Portal değişti ama PMS’e düşmedi” senaryosu, hem misafir hem ekip için güven kırıcıdır.
Self-service değişiklikler PMS’e nasıl yansıtılır?
Değişiklikler PMS’te ReservationChange olarak işlenmeli, tarih/oda/fiyat alanları güncellenirken change history ve “kim yaptı” izi (self-service) tutulmalıdır. Senkron gecikmesi varsa misafire durum net gösterilmeli (“İşleminiz alındı, X dakika içinde güncellenecek”). Ayrıca kanal (OTA/direct/corp) kısıtları ve rate code uyumu kontrol edilmeden otomatik değişiklik tamamlanmamalıdır.
En kritik entegrasyon kontrolleri
- •Rate plan uyumu (PolicyRules)
- •Envanter kilidi / stop-sell
- •Ödeme/penaltı hesabı ve tahsilat akışı
- •Audit trail + loglama
- •İptal/no-show statü disiplini
Ne yapmalıyım?
- • Senkron başarısızlığı için “fallback” oluştur (manual queue)
- • Değişiklik bildirimlerini FO/rezervasyon ekranına düşür
- • Kritik günlerde otomatik değişikliği kısıtla
- • Audit (Blog-16) içine self-service kaynaklı hataları ayrı kategori olarak ekle
5. Operasyon, Gelir ve KVKK Perspektifi
Self-service; operasyonu hızlandırırken gelir ve KVKK risklerini de yeniden tanımlar. Kural seti yoksa “kolaylık” hızlıca “zarar”a dönüşebilir.
Self-service süreçleri çağrı merkezi ve gelir yönetimini nasıl etkiler?
Çağrı merkezinde tekrar eden işlemler azalır; ekip daha karmaşık vakalara odaklanır (overbooking, dispute, grup). Gelir yönetiminde ise kural seti doğruysa güçlü günlerde fiyat korunur, zayıf günlerde kontrollü esneklik sağlanır. En kritik nokta: self-service’in “her şeyi açmak” değil, guardrail ile açmak olduğudur.
KVKK kısa prensipler (operasyonel)
- •Minimum veri: misafirin işini görmeyen veri toplanmaz
- •Hassas veri: portalda güvenli alan + erişim kontrolü
- •Üçüncü kişi: doğrulama olmadan paylaşım yok
- •Loglama: kim, neyi, ne zaman yaptı izlenebilir olmalı
Detaylı uyum için hukuk danışmanı ve teknik KVKK sayfaları referans alınmalıdır.
Ne yapmalıyım?
- • Self-service ile “azalan iş yükünü” QA/koçluk ve zor vakalara kaydır
- • PolicyRules değiştikçe (180 günde bir) portal metinlerini güncelle
- • KVKK için “yapılmaması gerekenler” listesini portal ve ekibe uygula
- • Gelir için: güçlü günlerde kısıt, zayıf günlerde kampanya paketleri hazırla
6. Self-Service’i Devreye Almadan Önce Sorulacak 10 Soru
- Self-service kapsamı nedir? (gör/başlat/yap)
- Hangi işlemler otomatik, hangileri manuel onaylı?
- Kritik gün/oda tipi eşikleri tanımlı mı?
- Ücret farkı ve penaltı otomasyonu nerede çalışıyor?
- İptal/no-show kuralları self-service’te nasıl gösteriliyor?
- PMS senkronu başarısız olursa fallback nedir?
- Değişiklik sonrası misafir ve ekip bildirimi nasıl gidiyor?
- KVKK: hangi veri nerede tutuluyor, kim erişiyor?
- Call center SLA’sı: manuel onaya düşen talepler kaç saatte kapanacak?
- KPI: self-service payı, manuel onay oranı, policy ihlali nasıl ölçülecek?
7. Fark Yaratan Mini Bölüm: Online Check-in Değil, Online Change Management (Competitor Gap)
Rakip içerikler self-service’i çoğu zaman “online check-in” ile sınırlar. 2026 perspektifinde farkı yaratan; rezervasyon değişiklikleri, iptal penceresi, ek hizmet, ücret farkı ve kural otomasyonunu da kapsayan entegre self-service akışıdır. Bu rehber; SelfServicePortal → PolicyRules → PMSIntegration hattını kurarak çağrı merkezi yükünü azaltırken gelir ve KVKK riskini kontrollü yönetmeyi hedefler. (İçerik 180 günde bir güncellenmelidir.)
8. Self-Service Rezervasyon Akış & Kural Tasarım Şablonunu İndir — 2026
Self-Service Rezervasyon Akış & Kural Tasarım Şablonunu İndir — 2026 (v1.0)
Bu şablon, self-service rezervasyon ve değişiklik süreçlerini “otomatik vs manuel onay” sınırlarıyla tasarlamak, ücret farkı/penaltı otomasyonunu kurallara bağlamak ve PMS entegrasyon kontrollerini netleştirmek için hazırlanmıştır. Amaç; çağrı merkezi yükünü azaltırken politika ihlali ve gelir kaybı riskini kontrol altında tutmaktır. KVKK tarafında veri minimizasyonu ve erişim kontrolünü tasarıma gömülü hale getirir.
Kim Kullanır?
Rezervasyon lideri + IT/PMS entegrasyon + revenue + call center.
Nasıl Kullanılır?
- İşlem kapsamını çıkar (misafir neyi görür/başlatır/yapar).
- PolicyRules ile limitleri ve eşikleri tanımla (kritik gün/oda tipi, iptal penceresi, fiyat farkı).
- PMSIntegration kontrol listesini uygula (sync, history, log, fallback).
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Otomatik/manuel sınırlar net
- ▢ ✅ Eşikler yazılı (kritik gün/oda)
- ▢ ✅ Ücret farkı şeffaf ekran
- ▢ ✅ PMS sync + history çalışıyor
- ▢ ✅ KVKK prensipleri tasarımda
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
TEMPLATE – İşlem Kapsamı Matrisi
TEMPLATE – PolicyRules (örnek başlıklar)
- •Kritik gün eşiği: ____
- •Kritik oda tipleri: ____
- •Değişiklik penceresi (check-in’e kaç gün kala): ____
- •Ücret farkı otomasyonu: ____
- •Penaltı kuralı: ____
- •Manuel onay SLA: ____
TEMPLATE – PMSIntegration Kontrol Listesi
- •SelfServiceChange → PMS Reservation sync
- •ChangeHistory “self-service” flag
- •Ödeme/penaltı kaydı (PaymentAdjustment)
- •Bildirim: FO/Rezervasyon (task/alert)
- •Fallback: sync başarısızsa queue + manuel işlem
- •KVKK: minimum veri + erişim log
Bir Sonraki Adım
Limitler, ücret/penaltı kuralları ve PMS entegrasyon guardrail’leriyle self-service’i güvenli biçimde devreye almanıza yardımcı olur.
Sık Sorulan Sorular
2026’da self-service rezervasyon ve değişiklik panelleri nasıl çalışacak?▾
Misafirler hangi işlemleri kendi başına yapabilmeli, hangileri manuel onay gerektirmeli?▾
Self-service değişiklikler PMS’e nasıl yansıtılır?▾
Self-service süreçleri çağrı merkezi ve gelir yönetimini nasıl etkiler?▾
Self-service’te en sık risk nedir?▾
İlgili İçerikler