Restoran rezervasyon sistemi geçiş kontrol listesi
Restoran rezervasyon sistemini değiştirmek yalnızca bir rezervasyon bileşenini değiştirmek değildir. Gelecekteki rezervasyonlar, misafir kayıtları, masa ve servis kuralları, ödemeler, iptal politikaları, web sitesi düğmeleri, Google işlemleri, ekip alışkanlıkları ve raporlama aynı anda taşınır.
En güvenli geçişin tek bir sorumlusu, tek bir geçiş planı ve rezervasyonun oluşturulabildiği veya değiştirilebildiği her nokta için açık kontrolleri vardır. Bir pazaryerinden ayrılırken, kapsamlı bir misafir platformunu değiştirirken veya manuel araçlardan doğrudan rezervasyon sistemine geçerken bu kontrol listesini kullanın.
Önemli noktalar
- Herkese açık bir rezervasyon bağlantısını değiştirmeden önce gelecekteki rezervasyonları dışa aktarın ve uzlaştırın.
- Depozito, ön ödeme, kart garantisi, hediye kartı, iade ve iptal haklarını ayrı geçiş iş akışları olarak ele alın.
- Müsaitliği yalnızca çalışma saatlerinden değil, gerçek operasyon kurallarından yeniden kurun.
- Web sitesi, Google, sosyal medya, QR, kampanya ve ekip rezervasyonlarını belgelenmiş tek bir kanal envanterinden geçirin.
- Geçişi tamamlandı saymadan önce canlı servisleri gerçek rezervasyon senaryolarıyla doğrulayın.
Geçiş tarihi seçmeden önce
Geçiş dönemini yazılımın kolaylığına göre değil, restoran operasyonuna göre seçin. Bayram, etkinlik, menü değişikliği, teras açılışı, büyük özel rezervasyon veya ekibin dikkatinin zaten yoğun olduğu başka bir dönemden hemen önce yayına çıkmayın.
- Geçişten sorumlu tek kişiyi ve istisnalarda karar verecek yetkiliyi belirleyin.
- Hedef yayına geçiş tarihiyle birlikte bir yedek tarih seçin.
- Kesintiyi kaldıramayacak servisleri listeleyin: yoğun akşam servisi, özel yemek, etkinlik, tadım menüsü ve grup rezervasyonu.
- Eski sistemin yeni rezervasyon kabulünü ne zaman durduracağını ve mevcut rezervasyonların nasıl erişilebilir kalacağını kararlaştırın.
- Her iki sistemde aktif kayıt bulunabilecek uzlaştırma dönemini tanımlayın.
- Yeni bağlantıları yayımlamadan önce ekip eğitimini ve izlenecek ilk haftayı planlayın.
Geçiş tarihi ancak bir kanal değişikliğini kimin durdurabileceği, sürdürebileceği veya geri alabileceği belli olduğunda hazırdır. Bu operasyon kararıdır; teknik bir açma-kapama özelliği değildir.
1. Dışa aktarımları güvenceye alın ve veri sahipliğini tanımlayın
Mevcut sağlayıcıya hangi verilerin, hangi biçimde ve hangi tarihe kadar dışa aktarılabildiğini sorun. Arayüzde görülen her alanın dışa aktarımda yer aldığını veya pazarlama izninin koşulsuz aktarılabildiğini varsaymayın.
- Tarih, saat, kişi sayısı, durum, servis, alan, masa ataması, kaynak ve onay modeliyle gelecekteki rezervasyonlar.
- Sözleşme ve yürürlükteki kurallar izin verdiği ölçüde misafir iletişim bilgileri, notlar, tercihler, etiketler, erişilebilirlik ihtiyaçları, beslenme bilgileri ve ziyaret geçmişi.
- Açıklamasız tek bir evet-hayır alanı yerine kaynak, kapsam, dil ve zaman damgasıyla pazarlama izinleri.
- Daha sonra misafir sorularını yanıtlamak için gereken iptal, gelmeme, iade, itiraz ve ödeme referansları.
- Deneyim, menü, alan, masa, vardiya, servis temposu, süre, kapalı zaman ve kişi sayısı yapılandırması.
- Eski panel kapandıktan sonra finansal uzlaştırma, kaynak analizi ve geçmiş karşılaştırma için gereken raporlar.
Orijinal dışa aktarımı salt okunur saklayın, ne zaman oluşturulduğunu kaydedin ve temizlik için bir çalışma kopyası kullanın. İçe aktarımdan önce ve sonra gelecekteki rezervasyonları servis tarihi ve duruma göre sayın. Bir dosyanın açılması geçişin doğrulandığı anlamına gelmez; restoranın servis vereceği kayıtların mevcut ve anlaşılır olması gerekir.
2. Gelecek rezervasyonları, ödemeleri ve misafir taahhütlerini koruyun
Gelecekteki rezervasyonlar misafire verilmiş sözlerdir. Yeni sistem yeni rezervasyonlarda farklı politikalar kullansa bile her rezervasyon onaylandığında geçerli olan metni ve ticari durumu koruyun.
| Taahhüt | Geçiş kontrolü | Misafir sonucu |
|---|---|---|
| Standart rezervasyon | Durum, tarih, saat, kişi sayısı, servis, alan, kaynak, notlar ve değişiklik geçmişi korunur. | Misafir restoranın daha önce onayladığı rezervasyona gelir. |
| Depozito veya ön ödeme | Tutar, para birimi, ödeme durumu, iade durumu, sağlayıcı referansı ve politika sürümü uzlaştırılabilir kalır. | Misafirden iki kez ödeme istenmez ve ekip bakiyeyi açıklayabilir. |
| Kart garantisi veya provizyon | Ekip eski yetkilendirmenin ya da kayıtlı ödeme anlaşmasının kullanılabilir ve izinli olup olmadığını bilir. | Geçerli politika, ödeme dayanağı ve ekip incelemesi olmadan ücret uygulanmaz. |
| Hediye kartı veya hediye çeki | Verilen değer, kod, bakiye, para birimi, son kullanım tarihi, kullanım geçmişi ve rezervasyon bağlantısı anlaşılır. | Misafir geçerli bakiyeyi manuel tahmin gerektirmeden kullanabilir. |
| Deneyim veya ek seçenek | Seçilen menü, paket, oturma alanı, adet, fiyat, vergi uygulaması ve servis notları rezervasyonla birlikte taşınır. | Mutfak ve salon ekibi yalnızca masa saatini değil, ne satıldığını da görür. |
Bir ödeme aracı güvenli biçimde taşınamıyorsa geçişten önce alternatifi belgeleyin: eski kaydı uzlaştırma için erişilebilir tutun, etkilenen misafirlerle iletişime geçin, yalnızca açık onayla yeniden yetkilendirin veya iade edip taahhüdü yeniden oluşturun. Açığı bir rezervasyon notuna gizlemeyin.
3. Müsaitliği, masaları ve politikaları yeniden kurun
Çalışma saatleri rezervasyona açık envanter değildir. Hangi grubun hangi servisi, ne kadar süreyle, hangi alanda ve hangi onay ile ödeme kuralı altında rezerve edebileceğine karar veren operasyon modelini yeniden oluşturun.
- Gün, saat, süre, rezervasyon aralığı ve önceden bildirim süresine göre servisler ile vardiyalar.
- Alanlar, masalar, masa birleşimleri, kapasite, erişilebilirlik, servis temposu ve masa dönüş süresi.
- Kişi sayısı alt ve üst sınırları, büyük grup akışları ve onay gerektiren envanter.
- Özel günler, tatiller, kapalı dönemler, etkinlikler, bloke saatler ve sezonluk alanlar.
- Her rezervasyon türü için anında onay veya restoran onayı.
- İptal süreleri, gelmeme kuralları, depozito, ön ödeme, isteğe bağlı ön ödeme, kart garantisi, iade ve tolerans süreleri.
- Herkese açık rezervasyon yolculuğunda görünmesi gereken deneyimler, menüler, ek seçenekler, hediye kartları, özel yemek ve oturma seçenekleri.
Sonuç vermesi gereken tarihler ve kişi sayılarıyla, ayrıca sonuç vermemesi gereken kombinasyonlarla müsaitliği test edin. Olumsuz senaryolar önemlidir: fazla satış, eksik kısıtlama ve yanlışlıkla anında onay sorunlarını ortaya çıkarır.
4. Her kanal geçişini planlayın
Herkese açık ve ekip tarafından kullanılan tüm giriş noktalarının tek bir envanterini oluşturun. Yalnızca ana web sitesi düğmesini değil, eski e-postalarda, basılı materyallerde, kampanya sayfalarında ve üçüncü taraf profillerinde saklı bağlantıları da ekleyin.
- Web sitesi üst alanı, gezinme, rezervasyon sayfası, gömülü bileşen, alt alan, iletişim sayfası ve şube sayfaları.
- Google İşletme Profili rezervasyon bağlantıları, Reserve with Google iş ortağı yönlendirmesi ve olası ödeme yönlendirmesi.
- Instagram, Facebook, TikTok, WhatsApp, e-posta imzaları, bültenler ve profil bağlantısı araçları.
- Menüler, vitrinler, otel masaları, basılı kartlar, fişler ve etkinlik materyallerindeki QR kodlar.
- Ücretli reklamlar, organik açılış sayfaları, içerik üreticisi bağlantıları, iş ortağı sayfaları ve kampanya parametreleri.
- Telefon, e-posta, kapıdan gelen misafir, concierge, otel ve ekip rezervasyonu süreçleri.
- Doğrudan geçişten sonra yeni misafir keşfi için aktif kalacak pazaryeri profilleri.
Google ve aramadan doğrudan rezervasyonlar rehberi Google talebinin web sitesiyle aynı canlı kuralları nasıl paylaşması gerektiğini açıklar. Entegrasyonlar sayfası bu misafir yolunun arkasındaki kanal katmanını ele alır.
Kanalları kontrollü bir sırayla güncelleyin, ardından nihai hedefi mobil ve masaüstünde doğrulayın. Her giriş noktası için eski bağlantıyı, yeni bağlantıyı, sorumluyu, değişiklik zamanını ve doğrulama sonucunu kaydedin.
5. Ekibi gerçek servis senaryolarıyla eğitin
Ekip eğitimi yalnızca ürün turunu değil, servis sırasında görülecek durumları kullanmalıdır. Telefonu yanıtlayan, misafiri masaya alan, talepleri onaylayan, ödemeleri uzlaştıran ve şikâyetleri yöneten kişilerle senaryoları çalışın.
- İçe aktarılmış gelecekteki bir rezervasyonu bulup değiştirmek.
- Doğru kaynak ve notlarla telefon veya kapıdan gelen rezervasyonu oluşturmak.
- Onay gerektiren rezervasyon talebini kabul veya reddetmek.
- Ödeme bekliyor, ödendi, iade edilebilir, iade edildi, başarısız ve itirazlı durumlarını tanımak.
- Geç iptal, gelmeme incelemesi, misafir toleransı ve restoran kaynaklı iptal durumlarını yönetmek.
- Hediye kartı, hediye çeki, ek seçenek, deneyim, depozito veya ön ödemeyi uygulamak ya da doğrulamak.
- Google, web sitesi, pazaryeri, kampanya ve ekip rezervasyonlarının nerede göründüğünü açıklamak.
- Eksik rezervasyon, mükerrer kayıt, müsaitlik uyuşmazlığı veya ödeme farkını eskale etmek.
Salon ekibine rezervasyon verileri, müsaitlik, ödemeler, Google yönlendirmesi ve misafir iletişimi için isimlendirilmiş sorumluların yer aldığı kısa bir yayına geçiş referansı verin. Genel bir destek e-posta adresi operasyon planı değildir.
6. Yayından önce ve sonra doğrulayın
Yayından önce kabul testi, bağlantılar değişir değişmez geçiş kontrolü ve ilk canlı hafta boyunca günlük inceleme yapın.
| Doğrulama aşaması | Gerekli kontroller | Tamamlanma kanıtı |
|---|---|---|
| Yayın öncesi | İçe aktarımlar uzlaşır, müsaitlik testleri geçer, politikalar doğru görünür, ödeme yolları çalışır ve ekip senaryoları tamamlar. | Sayımlar, test rezervasyonları, sorumlular ve açık istisnalarla imzalanmış kontrol listesi. |
| Geçiş anı | Herkese açık her bağlantı amaçlanan yerelleştirilmiş rezervasyon yoluna ulaşır ve doğru kaynağı oluşturur. | Mobil ve masaüstü bağlantı kontrolleriyle öncelikli kanallardan başarılı test rezervasyonları. |
| İlk servis | Salon ekibi içe aktarılan ve yeni rezervasyonları bulur, ödeme durumunu anlar, taleplere ve değişikliklere işlem yapar. | Her sorunun bir sorumluya atandığı servis değerlendirmesi. |
| İlk hafta | Rezervasyon hacmi, müsaitlik hataları, kaynak dağılımı, ödeme hataları, iptaller, gelmeme ve misafir soruları her gün incelenir. | Günlük uzlaştırma kaydı ve doğrulanmış düzeltmeler. |
| Stabilizasyon sonrası | Eski bağlantılar kaldırılır, gerekli eski kayıtlar erişilebilir kalır ve ekip yeni sistemi operasyon kaynağı olarak kullanır. | Kalan sözleşme, finans veya veri saklama görevleriyle nihai onay. |
Kopyalanabilir geçiş çalışma planı
Bu iş akışlarını restoranın geçiş takip tablosunda başlık olarak kullanın:
- Sorumluluk ve tarihler: sorumlu kişi, yayına geçiş tarihi, yedek tarih, sağlayıcı iletişimleri ve eskalasyon yolu.
- Veri: dışa aktarım kapsamı, temizlik, eşleme, içe aktarım, kayıt sayıları, istisnalar, saklama ve silme sorumlulukları.
- Rezervasyonlar: gelecek rezervasyonlar, talepler, değişiklikler, iptaller, notlar, deneyimler ve masa atamaları.
- Ödemeler: depozito, ön ödeme, kart garantisi, hediye kartı, iade, itiraz, sağlayıcı referansı ve uzlaştırma.
- Yapılandırma: servisler, vardiyalar, masalar, alanlar, servis temposu, kişi sayıları, özel günler, politikalar, diller ve bildirimler.
- Kanallar: web sitesi, Google, sosyal medya, QR, kampanyalar, pazaryerleri, iş ortakları, telefon, e-posta ve ekip girişi.
- İnsanlar: role göre eğitim, yayına geçiş kapsamı, destek sorumluluğu ve servis değerlendirmeleri.
- Doğrulama: yayın öncesi testler, geçiş kontrolleri, günlük izleme, sorun sahipliği ve nihai onay.
Yaygın geçiş hataları
| Hata | Neden olur? | Önleme |
|---|---|---|
| Herkese açık bağlantılar içe aktarım uzlaşmadan değişir | Görünür yayına geçiş projenin ana kilometre taşı sayılır. | Gelecek rezervasyon sayımlarını ve istisna incelemesini yayın ön koşulu yapın. |
| Yeni takvim yalnızca çalışma saatlerini kopyalar | Müsaitlik; servis, masa, tempo ve kurallar yerine saatlere indirgenir. | Tarih, kişi sayısı, servis ve alana göre olumlu ve olumsuz kombinasyonları test edin. |
| Ödeme durumu nota dönüşür | Para ve rezervasyon verileri ayrı taşınır. | Tutar, para birimi, durum, politika, sağlayıcı referansı, iade ve misafir yükümlülüğünü birlikte uzlaştırın. |
| Google ve web sitesi farklı kurallar kullanır | Kanallar ayrı takvimler olarak yapılandırılır. | Her kanalı aynı canlı müsaitlik ve yaşam döngüsü sahipliğine bağlayın. |
| Ekip yayından sonra eğitilir | Yapılandırmaya odaklanılır, servis senaryolarına değil. | Role göre senaryoları herkese açık geçişten önce zorunlu tamamlayın. |
| Eski sistem çok erken kaybolur | Sözleşme sonu, veri saklama ve operasyon erişimi aynı tarih sayılır. | Salt okunur erişimi, dışa aktarımları, finans kayıtlarını, misafir desteğini ve silme zamanını ayrı belgeleyin. |
SSS
Restoran rezervasyon sistemi geçişi ne kadar sürer?
Evrensel bir süre yoktur. Basit gelecekteki rezervasyonlara sahip ve ödeme almayan tek şube hızlı geçebilir. Birden fazla şube, yüksek rezervasyon hacmi, karmaşık masa ve servis temposu, deneyimler, ödemeler, hediye kartları, Google yönlendirmesi ve pazarlama izinleri daha fazla hazırlık gerektirir. Önce iş akışlarını kapsamlandırın, sonra tarihi belirleyin.
Restoranlar iki sistemi aynı anda çalıştırmalı mı?
Kısa ve kontrollü bir örtüşme mevcut ve yeni rezervasyonları uzlaştırmaya yardımcı olabilir. Ancak iki aktif müsaitlik kaynağı mükerrer kayıt ve kafa karışıklığı yaratabilir. Yeni rezervasyonların hangi sisteme ait olduğunu, hangisinin salt okunur veya geçici kaldığını ve her kanalın tam olarak ne zaman değişeceğini belirleyin.
İlk olarak hangi veriler dışa aktarılmalı?
Gelecekteki rezervasyonlarla ve onlara servis vermek için gereken bilgilerle başlayın: misafir iletişimi, tarih, saat, kişi sayısı, durum, servis, alan, notlar, ödeme veya politika durumu ve kaynak. Ardından operasyon, finans ve saklama yükümlülükleri için gereken yapılandırmayı, geçmiş kayıtları, izin kanıtlarını ve raporları güvenceye alın.
Kart bilgileri yeni rezervasyon sistemine taşınabilir mi?
Taşınabildiğini varsaymayın. Kayıtlı ödeme yöntemleri, yetkilendirmeler, kart garantileri ve sağlayıcı belirteçleri; ödeme sağlayıcısı, sözleşme, güvenlik ve onay koşullarına tabidir. Süreklilik sözü vermeden önce izin verilen yolu iki sağlayıcıyla da doğrulayın.
Geçiş ne zaman tamamlanmış sayılır?
Gelecekteki rezervasyonlar uzlaştığında, ekip canlı servisi yönetebildiğinde, her aktif kanal amaçlanan yerelleştirilmiş akışa ulaştığında, ödemeler ve politikalar açıklanabilir kaldığında, öncelikli sorunların sorumluları olduğunda ve gerekli eski kayıtlar doğru biçimde saklandığında veya silindiğinde geçiş tamamlanmıştır.
Sonraki adım: Yazılım seçiminden önce sorumlulukları belirleyin
Bu kontrol listesini OpenTable alternatifi karşılaştırması, SevenRooms alternatifi karşılaştırması veya en iyi restoran rezervasyon sistemleri rehberi sonrasında kullanın. Ürün seçimi önemlidir; ancak geçişin başarılı olması için veriler, talep, rezervasyon kuralları, ödeme taahhütleri, kanal değişiklikleri ve servis doğrulaması için sorumlular açıkça belirlenmelidir.