Rezervasyon sistemi neden yalnızca bir form değildir?
Müsaitlik, fiyatlama, oda ve misafir yapıları, ödeme, iptal ve operasyon aynı yaşam döngüsünün parçalarıdır. Sağlam rezervasyon altyapısı bu parçaları tek doğruluk kaynağında birleştirir.
Form, sistemin kendisi değildir
Bir otel web sitesinde giriş tarihi, çıkış tarihi ve kişi sayısı alanlarını göstermek kolaydır. Zor olan, bu sorgunun arkasındaki gerçek operasyonu doğru temsil etmektir. Hangi oda tipinin satılabildiği, hangi fiyat döneminin geçerli olduğu, çocuk yaşlarının fiyatı nasıl etkilediği ve kontenjanın hangi anda tutulacağı aynı karar zincirinin parçalarıdır.
Bu nedenle doğrudan rezervasyon deneyimini yalnızca bir arayüz problemi olarak ele almak kısa sürede sınırına ulaşır. Kullanıcının gördüğü birkaç alanın arkasında fiyat, envanter, misafir, ödeme ve durum yaşam döngüsü birlikte çalışmalıdır.
Müsaitlik ve fiyat aynı bağlamı paylaşmalı
Bir oda müsait görünürken o oda için geçerli fiyat üretilemiyorsa müşteri akışı kırılır. Tersi durumda fiyat göstermek ama gerçek kontenjanı doğrulamamak çifte satış riskine yol açar. Sağlam modelde müsaitlik sorgusu ile fiyatlama aynı tarih, oda, kişi ve kural bağlamından beslenir.
Rytuz Reservation Systems yaklaşımında oda, fiyat dönemi, kişi dağılımı ve rezervasyon durumu birbirinden bağımsız ekranlar değil aynı domain modelinin parçalarıdır. Harici rezervasyon widget'ının da uydurma veri yerine canlı sistem fiyatı ve müsaitliği kullanmasının nedeni budur.
- Tarih ve gece sayısı
- Oda tipi ve kontenjan
- Yetişkin / çocuk dağılımı ve yaş kuralları
- Fiyat dönemi, konsept, kampanya ve indirim
- Ön ödeme ve rezervasyon durumu
Ödeme, değişiklik ve iptal sonradan eklenen modüller değildir
Rezervasyon oluşturulduktan sonra iş bitmez. Tahsilatın hangi kaynaktan geldiği, kalan tutarın ne olduğu, iade gerekip gerekmediği, tarih değişikliğinde fiyatın nasıl yeniden hesaplanacağı ve iptal politikasının hangi koşullarda uygulanacağı rezervasyonun gerçek yaşam döngüsünü belirler.
Bu akışları ayrı ekranlarda tutmak mümkündür; fakat iş kurallarını ayrı ayrı kopyalamak değildir. Rezervasyon değişikliği yapıldığında ödemeyi korumak, kontenjanı eski tarihten bırakıp yeni tarihte tutmak ve işlemi audit edilebilir biçimde kaydetmek tek bir transaction düşüncesi gerektirir.
Doğrudan rezervasyon widget'ı neden aynı çekirdeğe bağlanmalı?
Harici otel sitesindeki widget bağımsız bir mini rezervasyon motoru olmamalıdır. Aksi halde fiyat, müsaitlik ve rezervasyon kuralları iki yerde yaşamaya başlar. Zamanla panelde görünen gerçek ile müşterinin gördüğü gerçek farklılaşır.
Daha güvenli yaklaşım, dış yüzeyin yalnızca kontrollü bir istemci olmasıdır. Widget aynı canlı çekirdekten müsaitlik ve fiyat alır; müşteri bilgileriyle ön rezervasyon oluşturur; operasyon ekibi de aynı kaydı kendi yönetim ekranında görür. Böylece müşteri deneyimi ile arka ofis arasında tek doğruluk kaynağı korunur.