Web siteleri

Seyahat sitesi: rezervasyon, fiyatlar ve iptaller

Dinamik fiyatlar, müsaitlik, rezervasyon sistemleriyle entegrasyonlar, saat dilimleri ve para birimleri, iptal kuralları — bir seyahat sitesinin işleyişini belirleyenler.

Seyahat sitesi sıradan bir katalogdan, ürün değil zaman satmasıyla ayrılır. Belirli tarihler için bir oda iki kez satılamaz ve depoya kaldırılamaz. Tüm zorluklar buradan doğar: fiyat değişir, müsaitlik değişir ve iptal kurallarındaki bir hata müşteriyle anlaşmazlığa ve kaybedilmiş paraya dönüşür.

Fiyat ve müsaitlik özellik değil, değişkendir

Online mağazada fiyat ürünün bir özelliğidir. Seyahatte fiyat birkaç değişkenin fonksiyonudur: giriş ve çıkış tarihleri, konaklama süresi, misafir sayısı, tarife, satış kanalı, rezervasyonun ne kadar önceden yapıldığı.

Projede dikkate alınması gereken pratik sonuçlar:

  • Fiyat tek bir sayıyla gösterilemez. Katalogda yön gösterici bir fiyat — "başlayan fiyatlarla" — gösterilir ve seçilen tarihler için kesin fiyat zorunludur. Yön gösterici fiyat ile ödeme adımındaki toplam arasındaki fark, vazgeçmelerin başlıca nedenidir.
  • Minimum konaklama ve giriş kuralları. Minimum gece sayısı, belirli günlerde giriş yasağı, bayramlarda zorunlu dönemler. Bunlar ödemede bildirilmemeli, tarih seçilirken kontrol edilmelidir.
  • Ek ücretler ve vergiler. Konaklama vergisi, temizlik, ek yatak, yemek. Fiyata eklenen her şey, kişi kart bilgilerini girmeden önce hesaplamada görünmelidir.
  • Müsaitlik aralığa bağlıdır. Doluluk dönemin tüm geceleri için kontrol edilir: ortada dolu tek bir gün tüm aralığı müsait olmaktan çıkarır. Takvim bunu açıkça göstermelidir.

Ayrı bir konu tarifelerdir. Aynı oda genellikle birkaç tarifeyle satılır: iade edilmeyen daha ucuz, iptal edilebilir daha pahalı, kahvaltılı ayrı. Müşteri odayı değil, oda ve tarife kombinasyonunu seçer. Sisteme mülk başına tek tarife kurulursa, diğerlerini sonradan eklemek vitrini, sipariş sürecini ve iptal kurallarını yeniden yazdırır.

Rezervasyon sistemleriyle entegrasyonlar

Konaklama veya tur satan hemen herkesin zaten bir yönetim sistemi vardır: otelde PMS, kanal yöneticisi, tur operatörü sistemi, acentede GDS. Bu şemada site genellikle satış kanallarından biridir.

Burada bir model seçmek gerekir:

  1. Site vitrin olarak. Fiyat ve müsaitlik dışarıdan gelir, rezervasyon da oraya gider. Otellerin çoğu böyle çalışır. Risk: senkronizasyon gecikmeleri.
  2. Site gerçeğin kaynağı olarak. Kendi rezervasyon sistemi, diğer kanallar veriyi ondan alır. Daha fazla kontrol, daha fazla sorumluluk ve geliştirme.
  3. Karma şema. Envanterin bir kısmı sitede yönetilir, bir kısmı iş ortaklarından gelir. Bakımı en zor olanıdır.

Model ne olursa olsun, açıkça tasarlanması gereken şeyler vardır:

  • Dış sistem erişilemez olduğunda ne olur. Rezervasyon sessizce kaybolmamalıdır. Ya dürüst bir mesajla engellenir ya da sonradan onaylanacak bir talep olarak kabul edilir.
  • Son oda yarışı. İki kişi aynı anda son boş odayı rezerve ediyor. Rezervasyon süresince geçici bir tutma ve tutma başarısız olursa anlaşılır bir davranış gerekir.
  • Onay. Anında veya talep üzerine. Rezervasyonu bir insan onaylıyorsa müşteri bunu ödemeden sonra değil önce anlamalıdır.
  • Rezervasyon değişikliği. Tarihleri ve misafirleri kim, hangi ana kadar değiştirebilir ve bu sırada fiyata ne olur.

Fazla rezervasyon ayrıca anılmayı hak eder: kanallar arasındaki gecikmelerden doğar. Teknik olarak sık senkronizasyon ve envanter tutmayla azaltılır ama tamamen ortadan kaldırılamaz — gerçekleştiği durum için operasyonel bir senaryo gerekir.

Saat dilimleri ve para birimleri

Hataların özellikle kötü göründüğü iki alan, çünkü paraya ve programa dokunurlar.

Zaman

Kural basittir: giriş ve çıkış tarihi kullanıcının veya sunucunun değil, tesisin saat diliminde yaşar. Başka bir dilimden gece geç saatte rezervasyon yapan müşteri bir günlük kaymayla karşılaşmamalıdır.

Genellikle gözden kaçanlar:

  • Giriş ve çıkış saatleri açıkça ve tesisin yerel saatiyle belirtilir.
  • Ücretsiz iptal son tarihi, tesisin saat dilimindeki bir zaman noktasıdır. Saat dilimi belirtilmeden "girişten bir gün önce" anlaşmazlık doğurur.
  • Turlar ve transferler için başlangıç saati kritiktir: tarayıcıda sessizce dönüştürülmeden, açık bir etiketle yerel saatte gösterilmelidir.
  • Onaylarda ve raporlarda rezervasyon tarihi ayrı bir değerdir; evrensel saatte saklayıp bağlama göre göstermek kullanışlıdır.

Para

  • Hesaplaşma para birimi ile gösterim para birimi farklı şeylerdir. Fiyatı müşterinin para biriminde göstermek mümkündür ama tahsilat satıcının para biriminde yapılır ve bu açıkça söylenmelidir.
  • Kur bir anda sabitlenir. Hangisinde olacağına karar verilmelidir: gösterim, rezervasyon veya ödeme. Ve iadenin doğru hesaplanması için sabitlenen kurun nerede saklandığına.
  • Yuvarlama tek bir kurala göre yapılır. Aksi hâlde hesaplamadaki tutar ile tahsil edilen tutar kuruşlarla ayrışır ve bu destek talebi için yeterlidir.
  • İade güncel kurla değil, ödeme para biriminde ve orijinal tutar üzerinden yapılır.

Gösterim ile ödeme arasında değişebilecek her değer — fiyat, kur, müsaitlik — rezervasyon oluşturulduğu anda sabitlenmeli ve onunla birlikte saklanmalıdır.

İptal kuralları

Belirsizliğin çatışmaya dönüştüğü yer burasıdır. İptal kurallarını yalnızca uygulamak değil, anlaşılır biçimde göstermek de gerekir.

Bir kuralın tarif ettikleri:

  • İptalin hangi ana kadar ücretsiz olduğu — saat dilimi açıkça belirtilerek.
  • Daha geç iptalde ne kesildiği: sabit bir tutar, ilk gecenin ücreti, tüm ödeme.
  • Gelmeme durumunda ne olduğu — genellikle ayrı ve daha katı bir durum.
  • Rezervasyon birkaç oda veya hizmeti kapsıyorsa kısmi iptalin mümkün olup olmadığı.
  • İptal değil değişiklik durumunda iadenin nasıl hesaplandığı.

Teknik taraf da basit değildir. Rezervasyon kısmen ödenmişse — ön ödeme artı girişte bakiye — kural bununla da çalışmalıdır. Ödeme bir ödeme sağlayıcısı üzerinden geçtiyse iade onun sürelerine ve kısıtlarına bağlıdır ve müşteriye bu dürüstçe söylenmelidir.

Faydalı bir arayüz kuralı: iptal edilebilir ve iade edilmeyen tarifeler seçim aşamasında görsel olarak farklı olmalıdır. İade edilmeyen tarife daha ucuzdur ve bazı insanlar okumadan onu seçer. Koşul fark edilir değilse, ardından satıcının resmen haklı olduğu ama müşterinin fiilen kaybedildiği bir anlaşmazlık gelir.

Ödemeden önce ne gösterilmeli

Ödeme düğmesinden önce müşteride tam bir tablo olmalıdır. Onay ekranı bir formalite değil, destek taleplerinin büyük kısmını ortadan kaldıran şeydir.

İçinde olması gerekenler:

  1. Tesis, konaklama türü ve seçilen tarife.
  2. Yerel saat belirtilerek giriş ve çıkış tarihleri ve saatleri.
  3. Fiyatı etkiliyorsa misafir sayısı ve dağılımı.
  4. Tam hesaplama: temel ücret, ek ücretler, vergiler ve harçlar, tek satırda toplam.
  5. Gösterim para biriminden farklıysa tahsilat para birimi ve bu birimdeki tutar.
  6. Genel kurallara bağlantı değil, belirli bir son tarih ve saatle metin olarak iptal koşulları.
  7. Şimdi ne ödendiği ve yerinde ne ödeneceği.
  8. Onay yöntemi — hemen veya kontrolden sonra — ve yanıt süresi.
  9. Gereklilik varsa girişte yanında getirilmesi veya gösterilmesi gerekenler.

Ödemeden sonra müşteri aynı bilgileri ve rezervasyon numarasını içeren bir e-posta alır. Bu e-posta çoğu zaman resepsiyonda göstereceği tek belgeye dönüşür — bu yüzden yalnızca teşekkür değil, adres, tesisin iletişim bilgileri ve iptal koşullarını da içermelidir.

Lansman öncesi kontrol listesi

Bir seyahat projesine başlamadan önce aşağıdakileri yazılı olarak kapatmaya değer:

  1. Fiyatın nelerden oluştuğu ve hangi ek ücretlerin bulunduğu.
  2. Minimum konaklama dahil, tarifelerin ve giriş kurallarının tam listesi.
  3. Müsaitliği hangi sistemin yönettiği ve değişimin hangi modelle çalıştığı.
  4. Dış sistem arızasında ve son yer yarışında sitenin davranışı.
  5. Rezervasyon süresince envanteri tutma mekanizması.
  6. Kurun ve fiyatın nerede sabitlendiği ve iadede nasıl kullanıldığı.
  7. Giriş, çıkış ve iptal son tarihinin hesaplandığı saat dilimi.
  8. İptal, gelmeme ve değişiklik kuralları — müşteriye gösterilebilecek metin olarak.
  9. Onay ekranının ve rezervasyon e-postasının içeriği.

Üçüncü ile beşinci arasındaki maddeler mimariyi belirler ve sonradan neredeyse değiştirilemez. Geri kalanlar, geliştirmeden önce işletmeyle kararlaştırılması gereken koşullardır, yoksa test aşamasında ortaya çıkarlar. Soruların bir kısmı henüz yanıtsızsa, bunları başlangıçta ele almak mantıklıdır — görev tanımıyla birlikte konuşalım.