Aynı masayı iki sistemde yeniden bulmak zorunda kalmayın
Cuma akşamı kapıda üç grup bekliyor. Karşılama ekibi misafirin rezervasyonunu buluyor, masasına yerleştiriyor. Servis ekibi ise POS ekranında o masa için adisyon açmak zorunda. Sistemler birbirini tanımıyorsa hangi adisyonun hangi ziyaretle ilişkili olduğu servis sonunda ayrı ayrı araştırılır. Özellikle aynı masanın farklı oturumlarda kullanıldığı restoranlarda bu eşleştirme önemlidir.
Sorun yeni bir kasa sistemi kurmak değildir. Rezervasyonun, yerleştirilen masanın ve adisyonun aynı ziyareti tarif etmesini sağlamaktır. Oracle Simphony Cloud entegrasyonunda Rezervem'in çözdüğü temel bağlantı budur.
Check-in sırasında hangi adımlar gerçekleşir?
Misafir geldiğinde ekip Rezervem Manager'da rezervasyonu check-in yapar. Restoranın Simphony Cloud bağlantısı etkinse, ilgili masa ve gelir merkezi (RVC) eşlemesi doğrulanır. Uygun eşleme bulunduğunda Rezervem, o rezervasyonla bağlantılı bir Simphony adisyonu açılmasını sağlar.
Masa henüz atanmadıysa, entegrasyon adisyonu rastgele bir gelir merkezinde açmaz. Desteklenen masa ataması tamamlandığında yeniden denenebilir. Walk-in misafirler için de rezervasyon kaydı, masa ataması ve POS yapılandırmasının birlikte çalışması gerekir. Bu nedenle 'her check-in her koşulda adisyon açar' ifadesi doğru değildir.
Adisyon kapanınca harcama nereye gider?
Misafir yemeklerini seçer, servis gerçekleşir ve hesap Simphony üzerinde kapatılır. Entegrasyon adisyonun gerçek kapanış durumunu doğrular. Ardından desteklenen tutar, ürün kalemleri ve ödeme bilgileri Rezervem'deki ilgili rezervasyona aktarılır. Böylece işletme yalnız misafirin geldiğini değil, o ziyaretin finansal sonucunu da görebilir.
Bu veri, ziyaret ve misafir geçmişiyle birlikte değerlendirilebilir. Ancak açık adisyonun her saniye eksiksiz ve canlı olarak misafir kartına aktarıldığını varsaymamak gerekir. Kapanışla gelen doğrulanmış harcama kaydı ve açık adisyon sorgusu ayrı süreçlerdir.
İptal ve yanlış check-in nasıl ele alınır?
Yoğun serviste misafir yanlışlıkla check-in yapılabilir. Geri alma işleminde Simphony'deki açık adisyon kontrol edilir. Adisyon boşsa ve güvenli iptal koşulları sağlanıyorsa otomatik iptal edilebilir. Ürün veya ödeme bulunan adisyon ise veri kaybını önlemek için otomatik silinmez; ekip müdahalesi gerekebilir.
Bu ayrım önemlidir. Rezervem'in amacı POS'taki ticari kaydı yok saymak değil, rezervasyon operasyonu ile adisyon yaşam döngüsünü güvenli şekilde ilişkilendirmektir.
Rezervem ve Simphony arasında görev paylaşımı
Rezervem Manager rezervasyon, masa planı, geliş durumu ve misafir geçmişini yönetir. Oracle Simphony Cloud ise adisyon, satış kalemi ve POS ödeme kaydını yönetmeye devam eder. Rezervem Pay ile yapılan uygun ön ödeme işlemleri, ayrı yapılandırılmış koşullarla bu adisyona kaydedilebilir.
Canlıya geçişte önce tek restoran alanında doğru masa, gelir merkezi, personel ve ödeme yapılandırmasını test edin. İlk ziyaretten hesap kapanışına kadar aynı kaydın izlendiğini doğrulayın. Simphony Cloud entegrasyon sayfasında doğrulanan kapsamı ve başlangıç koşullarını görebilirsiniz.
