Bir restoran yönetim sistemi seçerken önce hangi özelliklere ihtiyacınız olduğunu değil, bugün hangi bilgileri nerede tuttuğunuzu görmek gerekiyor. Menü bir yerde, rezervasyonlar başka bir yerde, siparişler POS'ta, müşteri bilgileri başka bir sistemdeyse aynı bilgiyi tekrar tekrar güncellemek ve kontrol etmek zorunda kalırsınız.
Bu nedenle sistemi değerlendirirken menü, sipariş, masa, rezervasyon, misafir ve personel bilgilerinin nerede tutulacağına bakmak daha kullanışlı. Her biri için iki şeyi netleştirin: ana kayıt hangi sistemde olacak ve diğer sistemler bu bilgiyi oradan okuyabilecek mi? Bu cevaplar, ihtiyaç listenizin temelini oluşturur.
Restoran Yönetim Sistemi Ne Yapar?
Bir fiyatı değiştirdiğinizde ne olduğuna bakalım: sistem çalışıyorsa bu değişiklik bir kez yapılır ve misafirin gördüğü menüde, paket sipariş kanalında ve haftalık raporda aynı anda görünür. Çalışmıyorsa aynı değişiklik üç ayrı yerde yapılır, biri unutulur ve unutulan yer genellikle misafirin baktığı yerdir.
Terim satıcıdan satıcıya değişiyor: kimi hepsi bir arada bir takımı kastediyor, kimi tek bir modülü. Sistemleri karşılaştırırken özellik isimlerinden çok, hangi bilgiyi hangi sistemin tuttuğuna bakmak daha anlamlı.
Kapsam: Sistemin Tuttuğu Kayıtlar
Ürün sayfalarında gördüğünüz modül adları sistemden sisteme değişiyor: birinde "sipariş yönetimi" yazan ekran, diğerinde "satış ekranı" olarak geçiyor. Menü, sipariş, masa ve rezervasyon bilgisini ise hangi sistemi seçerseniz seçin bir yerde tutmanız gerekiyor. İhtiyaç listesini bu bilgiler üzerinden yazdığınızda sistemleri aynı sorularla karşılaştırabiliyorsunuz.
| Kayıt | Ne tutmalı | Sonrasında kim okuyor |
|---|---|---|
| Menü ürünü | Ad, açıklama, fotoğraf, her porsiyon için ayrı fiyat, ek seçenekler, alerjen ve besin bilgisi, sipariş edilebildiği saatler | Misafirin gördüğü menü, site, paket sipariş kanalı, satış raporları |
| Sipariş | Kanal, masa ya da adres, ek seçenekleriyle ürünler, durum, ödeme yöntemi, bahşiş | Mutfak, kasa, muhasebe, raporlar |
| Masa ve alan | Hangi alanda olduğu, kaç kişilik olduğu, kendi kodu mu ortak kod mu, o anki durumu | Oturtma, sipariş, rezervasyon |
| Rezervasyon | Saat, kişi sayısı, öngörülen süre, misafir notu, varsa kapora | Salon planı, misafir kaydı |
| Misafir | İletişim bilgisi, izinler, sipariş geçmişi, geri bildirim ve ürün yorumları | Kampanyalar, segmentasyon, telafi |
| Personel | Rol ve yetkiler, siparişi kimin gönderip kimin iptal edebileceği | Sipariş, raporlar, vardiya devri |
Menü, sipariş kanalları ve raporlar daha sonra bu ürün bilgisini kullanıyor.
İş Kuralları: Gereksinim Listesinin Atlanan Yarısı
Kayıt neyin var olduğunu söylerken kural bir şey olduğunda sistemin ne yapacağını söylüyor; bir şartnameyi dilek listesinden ayıran da bu ikinci kısım.
Bu kuralların çoğu zaten işliyor. Birinin aklında duruyorlar, her yeni personele tek tek anlatılıyorlar ve bugüne kadar hiç yazılmadılar. Hepsini aynı kalıpta yazın: şu olduğunda sistem şunu yapmalı, kim değiştirebilir.
- Zaman. Ürün hangi günlerde ve hangi saatler arasında sipariş edilebilir? Kahvaltı on birde kapanır, öğle menüsü yalnız öğlen vardır.
- Eşikler. Paket siparişte minimum sepet tutarı, teslimat ücreti, hazırlık süresi ve yol süresi. Bu ikisinin toplamı misafire verdiğiniz sözdür.
- Uygunluk. Alkolde yaş doğrulaması, yalnız paket siparişte geçerli bir kupon, belli bir tutarın üstünde açılan indirim.
- Yetki. Siparişi kim gönderebilir, misafir kendi telefonundan mı garson tabletten mi? İptali kim yapabilir ve mutfak akışının neresine kadar?
- Para tarafı: porsiyon fiyatları, kuver ve servis ücreti, bahşiş oranları, hesabın bölünmesi.
- Durum. Misafir iptal ettiğinde ne olur, servis ortasında biten ürün ne olur, ödeme alındıktan sonra masa açık kalır mı?
Yazılımın desteklemediği kurallar personelin hatırlamasına bağlı kalıyor ve servis sırasında hata riski artıyor.
Gereksinim Listesi Tahminle Değil, Salonda Çıkar
Şablona ihtiyacınız yok; birkaç temsili servis boyunca tutulan bir defter yetiyor.
Bu örneklerin her biri ihtiyaç listenize eklenebilecek somut bir problem gösteriyor.
Sonra tek bir siparişin, alındığı andan muhasebeye düştüğü ana kadar kaç ayrı yere uğradığını sayın. Aynı sipariş bilgisi birden fazla sisteme elle taşınıyorsa entegrasyon ihtiyacını öncelikli değerlendirmek gerekiyor.
Sonra şu iki soruyu sorun. Her kayıt için: bugün kim tutuyor, bundan sonra kim tutmalı? Yazdığınız her kural için: yazılım bunu ifade edebiliyor mu, yoksa kural birinin aklında mı kalıyor?
Dijital sipariş salon tarafındaki beklemeyi azaltabiliyor, ancak mutfak kapasitesi aynı kaldığı için toplam hazırlık süresi otomatik olarak kısalmıyor.
QR ile sipariş vermek istemeyen misafirler için personel destekli bir alternatif bırakmak gerekebiliyor.
Entegrasyonların maliyetini de satın alma kararına dahil etmek gerekiyor. Kullandığınız POS, ödeme ve yazıcı sistemlerini desteklenen listeyle karşılaştırın; bazı bağlantılar dahil, bazıları ücretli.
Site, çeviri ve raporlama gibi çıktılar menüdeki mevcut verileri kullanıyor. Bu nedenle temel ürün bilgileri eksikse sonraki çıktılar da eksik ya da yanlış oluyor.
Kurulum Hangi Sırayla Yapılır?
Kurulum sırası önemli, çünkü sonraki adımlar önce oluşturduğunuz bilgileri kullanıyor.
- İşletme bilgileri ve çalışma saatleri. Sonraki adımlar, üretilen çıktılar dahil, burada girdiğiniz bilgileri kullanıyor.
- Menü, kurulumda en fazla hazırlık gerektirebilen bölümlerden biri
- Masalar ve alanlar: hangi masa hangi alanda, kaç kişilik ve kendi kodu olacak mı.
- Kanallar: salon, paket, gel-al, tablet ve her kanalın hangi menüyü göstereceği.
- Kurallar: daha önce belirlediğiniz iş kurallarını mümkün olduğunca sistem ayarlarına taşıyın.
- Entegrasyonlar: POS, ödeme ve yazıcı bağlantıları.
- Raporlar. Canlıya geçmeden önce geçmiş bir günü seçin ve sistemden o günü ürün ürün isteyin. Dışa aktarıp tabloda yeniden kurmanız gerekiyorsa raporlama ihtiyacınız henüz karşılanmıyor demektir.
Site, görsel ve çeviri gibi üretilen çıktılar en sona kalıyor; bunlar yukarıdaki kayıtları kullandığı için erken başlatıldığında çoğu zaman yeniden yapılıyor.
FineDine'da Bu Kararlar Nasıl Veriliyor
Yukarıdaki kararlardan bazıları doğrudan FineDine'da veriliyor.
Bir ürün; açıklamasını ve fotoğrafını, her porsiyon için ayrı fiyatı, ek seçenekleri, besin ve alerjen etiketlerini ve sipariş edilebildiği gün ile saatleri taşıyor. Misafirin gördüğü menü, sipariş kanalları, site ve raporlar aynı kayıttan okuduğu için değişiklik tek yerde yapılıyor. Menünüz zaten fotoğraf, PDF ya da tablo olarak duruyorsa yükleyip bölümleri, ürünleri ve fiyatları çıkartabilirsiniz. Sonrasında sıfırdan yazmak yerine çıkanı düzeltiyorsunuz.
Sipariş kanalları (salon, paket, gel-al, tablet) ve bu kanalların iş kuralları aynı yerden yönetiliyor: minimum sepet tutarı, teslimat ücreti, hazırlık süresi, yaş doğrulaması, bahşiş ve servis ücreti gibi ayarlar kanal bazında tanımlanıyor.
POS, ödeme ve yazıcı entegrasyonları Marketplace'te listeleniyor; hangi bağlantının dahil, hangisinin ücretli olduğu plana göre değişiyor.
Raporlama tarafında özet, ürün ve işletme raporları kullanılabiliyor. Yapay zeka destekli raporlama katmanının kapsamı ise plana göre değişiyor.
Kendi menünüz, masa düzeniniz ve kurallarınız tek sistemde nasıl durur görmek isterseniz bizden demo isteyebilirsiniz.
Restoran Yönetim Sistemi Hakkında Sık Sorulanlar
- Restoran yönetim sistemi ile POS aynı şey mi?
- Aynı şey olmak zorunda değiller. POS'un temel görevi satış ve ödeme akışını yönetmek olsa da modern POS sistemlerinin kapsamı oldukça değişiyor. Burada bakılması gereken şey, menü, sipariş, masa ve müşteri verisinin hangi sistemde ana kayıt olarak tutulduğu.
- Kullandığım POS entegrasyon listesinde yoksa ne olur?
- POS entegrasyonu yoksa sipariş kaydı iki ayrı akışta takip ediliyor ve bazı bilgilerin ikinci kez girilmesi gerekebiliyor. Küçük bir işletmede katlanılabilir, yoğun bir salonda maliyeti artıyor. Engel saymadan önce hangi bilginin gerçekten karşıya geçmesi gerektiğine bakın: bu ihtiyaç muhasebe, stok ve raporlama yapınıza göre değişiyor.
- Küçük bir kafenin buna ihtiyacı var mı?
- Siparişi alan, hazırlayan ve tahsil eden aynı kişiyse ve hiçbir bilgi iki kez yazılmıyorsa kazanç sınırlı kalıyor. Aynı bilgiyi iki farklı yerde tutmaya başladığınızda veya geçmiş satışları bulmak düzenli olarak zaman almaya başladığında böyle bir sistem daha anlamlı hale geliyor.
- Kurulum ne kadar sürer?
- Kurulum süresi menünün büyüklüğüne ve mevcut ürün bilgilerinin ne kadar düzenli olduğuna bağlı. Genellikle en fazla hazırlık isteyen bölüm ürün, fiyat, varyant, görsel ve alerjen bilgilerinin tamamlanması. Mevcut menüyü fotoğraf, PDF ya da tablo olarak yükleyip bölümleri ve ürünleri çıkartabilir, sonra düzeltebilirsiniz.
- Aynı menü birden çok dilde çalışır mı?
- Çalışır, ama pratikte ne demek olduğunu bilmekte fayda var. Çeviri alan alan ilerliyor, yani her ürün adı ve açıklaması ayrı bir iş. Dil başına tamamlanma oranını gösteren ve çevrilmemişleri süzen bir çeviri merkezi bu yükü yönetilebilir tutuyor. Makine çevirisi de bitmiş sonuç değil, düzeltilecek bir ilk tur veriyor. Kaç dille çalışabileceğiniz plana göre değişiyor.
