Tek deneyim, tek veritabanı anlamına gelmez
Otelin misafir uygulaması birden fazla sistemden bilgi alabilir. Konaklama durumu PMS’te, restoran müsaitliği rezervasyon sisteminde, sipariş QR platformunda ve açık görevler operasyon ekranında bulunur. Bunların hepsini tek bir veri tabanına taşımak yerine hangi bilginin kaynağının hangisi olduğuna karar vermek gerekir.
Örneğin PMS oda değişikliğini bildirdiğinde mevcut restoran rezervasyonunun yanlış odaya bağlı görünmemesi gerekir. Öte yandan restoranın kapalı olduğu gün PMS tarafından belirlenmez. Bu iki kararın bağımsız olması veri çakışmasını önler.
Kimlik eşleme ve erişim sınırını yazın
Misafirin odayla doğrulanması, otelde konakladığını gösterebilir; ancak bir odada birden fazla kişi, aynı odada art arda farklı konaklamalar ve birden fazla odası olan bir aile senaryolarını ayrı değerlendirin. İşlem kimliğini yalnız oda numarasına bağlamak yeterli olmayabilir.
Misafir oturumu, konaklama bitişi ve bağlı rezervasyon yetkisi için ayrı kurallar hazırlayın. Rezervasyon akışındaki çoklu oda ve rezervasyonu oluşturan kişi ayrımı, tesisin tercih ettiği iş kuralına göre kabul testine alınmalıdır.
Restoran, ürün satışı, ödeme ve operasyon sözleşmesini ayrı test edin
PMS okumalarının güncel kalma süresi, restoran kapasitesi ve rezervasyon oluşturma API yanıtı, QR sipariş konum ve ürün bilgisi, Hospitality görevinin atanması ve misafir arayüzündeki son durum birbirinden ayrı kontrol edilmelidir.
Ek hizmette bir kaynak daha vardır: Experience katalog ve sipariş kaydı. Hangi ürünün hangi varyantı, hangi şube ve kanalda satılabilir, fiyatını hangi sistem belirler, satış anı kopyası nerede saklanır? Pay tarafında başarılı tahsilat, ödeme reddi, mükerrer çağrı ve iade kontrolünü ayrıca yapın. Bir Experience siparişi ile ödeme talebinin her zaman bire bir olduğu varsayımını kurmayın; doğrudan misafir ödemesi ayrı bir ödeme talebi gerektirmeyebilir.
Bağlantılardan biri kesilirse diğer hizmetlerin nasıl davranacağı kararlaştırılmalı: PMS doğrulaması başarısızsa misafiri yeni oturum açmış kabul etmeyin; restoran API yanıt vermiyorsa boş yer varmış gibi göstermeyin; sipariş servisi çalışmıyorsa başarı mesajı üretmeyin.
- Oda değişikliği, erken çıkış, rezervasyon iptali ve konaklama uzatma.
- Aynı restorana eşzamanlı son masa isteği.
- Çoklu oda grup rezervasyonunda sahiplik ve iptal.
- QR siparişte yanlış servis noktası ve ürün tükenmesi.
- Görev devrinde açık talebin kime ait olduğu.
- PMS ağ kesintisi ve sonradan veri uzlaştırması.
Gözlemlenebilirlik için kabul ölçütleri
Her entegrasyon çağrısında güvenli bir işlem referansı, sonuç kodu, ilgili tesis ve zaman damgası tutulmalı; kimlik ve ödeme sırları loglara yazılmamalıdır. Günlük uzlaştırmada "gönderildi" ve "karşı sistemde işlendi" ayrımı korunmalı. Çift işlem üretilip üretilmediğini anlamak için yeniden denemeleri ayrıca gözleyin.
Pilot otelde test sonuçlarını üç sütunla toplayın: misafir ne gördü, çalışan hangi kaydı gördü, ana sistemde işlem oluştu mu? Bir alanın "başarılı" sayılması için üçü birlikte beklenen sonucu vermelidir.
Entegrasyon tablosunda her olayın yalnız başarılı davranışını değil azami veri gecikmesi ve toparlanma yolunu da kaydedin. Örneğin PMS bilgisi iki dakika gecikirse yeni oda numarasının misafir ekranına ne zaman yansıyacağı bilinmelidir. Aynı kaydı yeniden gönderen olaylar çift görev veya rezervasyon oluşturmamalı. Hata türü yanlış konaklama mı, geçici ağ hatası mı ve yetki reddi mi ayrıştırılmalıdır.
Experience, Pay, QR Order ve PMS folyo aynı işlemi paylaşmaz
Experience üzerinden satın alınan bir hizmetin ticari kaydı ile Pay üzerinden alınan para ve Hospitality üzerinde oluşturulan hazırlık görevi ayrı nesnelerdir. QR Order ise servis istasyonu ve servis noktasına bağlı F&B siparişi üretir. Bunların hepsini “otel misafirinin siparişleri” diye tek operasyonel nesnede saklamak, iade ile iptali ve teslim ile tahsilatı birbirine karıştırır.
PMS folyosuna gönderilen bir ücret de doğrudan online tahsilat değildir. Oda değişikliği, check-out ve ödeme sağlayıcısı zaman aşımı gibi durumlar için doğru işlem kimliği ve mutabakat kuralı belirlenmelidir. Her entegrasyon, işlem üzerinde yalnız kendine ait durumu güncellemelidir.
Web ve markalı mobil uygulama için aynı işlem sözleşmesini sınayın
Stay web tarayıcısından veya otel markalı mobil uygulamadan açılsa da restoran rezervasyonunun, Experience siparişinin, Pay tahsilatının, QR Order siparişinin ve Hospitality talebinin kayıt sahibi değişmez. İki kanalda aynı misafir, konaklama ve işlem kimliğinin görünmesini test edin.
Mobil mağaza onayı tek başına uçtan uca entegrasyon testi değildir. Ödeme dönüşü, derin bağlantı, tekrar giriş ve geçici bağlantı kesintilerinde aynı rezervasyon ya da satışın iki kez kaydedilmesini önleyen akışı doğrulayın.
Rezervem’deki gerçek ürün sınırları
Rezervem Stay misafir arayüzü, Manager restoran/masa yönetimi, PMS konaklama kaydı, QR Order sipariş ve Hospitality iç operasyon ürünü olarak ayrılır. Konaklama bilgilerinin Hospitality operasyonuna aktarılması, oteldeki PMS bağlantısının etkinliğine bağlıdır. Bu bağlantı yalnızca sistemlerin teknik olarak uyumlu olmasıyla çalışmaya başlamaz; tesis bazında kurulup test edilmelidir.
Stay üzerinden ek hizmet teklifinde Rezervem Experience ürün kataloğu ve `ExperienceOrder` sipariş kaydının sahibidir; Rezervem Pay ise ödeme/tahsilat katmanıdır. Ön büro ya da departmanın hizmeti teslim etmesi ayrıca planlanır. Katalogdaki her varyantın Stay’de otomatik satışa çıkması, siparişin otomatik PMS folyosuna yazılması veya Hospitality görevi doğması garanti değildir.
Varış öncesi bilgi ve ek hizmet taleplerinin PMS tarafındaki yazma işlemleri, kullanılan entegrasyonun desteklediği işlem türlerine göre değerlendirilir. Görevler için Hospitality, rezervasyonlar için Manager, konaklama için PMS ve misafir deneyimi için Stay açıklamalarını birbirine bağlayın.
