Restoran Yönetim Sistemi: Neyi Kapsar, İhtiyaç Listesi Nasıl Yazılır?

"Restoran yönetim sistemi" diye satılan iki teklifi yan yana koyduğunuzda çoğu zaman aynı şeyi karşılaştırmıyorsunuz. Firmalar terimi geniş kullanıyor. Kimi salondan bordroya uzanan bir paketi böyle adlandırıyor, kimi yalnız sipariş ve ödeme alan bir modülü. Ortak nokta, işletmenin çalışma kayıtlarını tek yerde tutmak. Bu kayıtlar menü, siparişler, masalar, rezervasyonlar ve misafirlerdir. Daha kapsamlı paketlerde stok, personel saatleri ve maliyetler de eklenir. Satın almadan ya da geliştirmeden önce sorulacak soru bu yüzden modülün adı değil. Sistem kayıtlarınızın hangisini tutuyor, hangisini başka bir sisteme bırakıyor? Tutmadığı bir kayıt varsa o kaydın nerede duracağı sözleşmeden önce belli olmalı.

Salon, Mutfak ve Ofis: Sistemin Üç Parçası

Tanımların çoğu işi üç parçaya böler. Salon, misafirin dokunduğu taraftır. Menü, sipariş ve ödeme, masalar, rezervasyonlar ve misafir kayıtları burada durur. Mutfak ve depo tarafında mutfak ekranı, stok sayımı, satın alma ve reçete maliyeti var. Ofis ise personel vardiyasını, bordroyu ve muhasebeyi kapsar.

Firmalar bu parçalara aynı adı vermiyor. Birinin "sipariş yönetimi" dediği ekrana öteki "satış ekranı" diyor, oysa iki ekranın arkasında da aynı sipariş kaydı var. Bu yüzden ihtiyaç listesini modül adlarıyla değil, kayıtlar ve kurallarla yazın. Ekranın adı firmadan firmaya değişir, kayıt değişmez.

Tek Fiyat Değişikliği Menünün Kimde Durduğunu Gösterir

Bir fiyatı değiştirmek için önce POS'u, sonra QR menüyü, sonra paket servis platformundaki listeyi açıyorsanız menünüz üç ayrı yerde duruyor. Üç listeden birinde güncellemeyi atlamak kolaydır ve atlandığında QR menüdeki fiyat ile kasadaki fiyat birbirini tutmaz. Defterdeki rezervasyonlar ve müdürün telefonunda duran misafir numaraları da aynı şekilde dağınık kalır.

Bir sistemin bir kaydı gerçekten tutup tutmadığını görmenin en hızlı yolu bir fiyat değişikliğidir. Yeni fiyatı bir kez girin. Fiyat misafirin menüsünde, paket servis listesinde ve sonraki satış raporunda çıkıyorsa ürün kaydı tek yerde duruyor demektir. Aynı rakamı üç ekrana ayrı ayrı yazmanız gerekiyorsa elinizde üç kopya var. Kopyaları eşit tutmak da her fiyat değişikliğinde birinin hatırlamasına kalır.

30/30/30/10 Kuralıyla Kapsam Kontrolü

30/30/30/10 kuralı ciroyu kabaca bölüştürmek için kullanılan pratik bir ölçü. Cironun yaklaşık %30'u yiyecek ve içeceğe, %30'u personele, %30'u işletmeyi açık tutan diğer giderlere (kira, elektrik, su, doğalgaz, pazarlama, tamir) gider, geriye %10 civarı kâr kalır. Kuralı bir başlangıç bütçesi olarak okuyun. Bir kahve dükkânı ile bir et restoranı ne aynı malı alır ne aynı kadroyla çalışır, bu yüzden gerçek dağılım kuraldan epey uzağa düşebilir.

Yazılım seçerken kural başka bir işe yarar, çünkü dört rakamın her biri ayrı bir kayıttan gelir. Ciro siparişlerden çıkar. Yiyecek maliyetini bilmek için ne aldığınızı, ne saydığınızı ve her tabağın reçetesini bilmeniz gerekir. Fiyatı girilmiş ama reçetesi olmayan bir ürünün tabak maliyeti hesaplanamaz. Personel gideri kaydedilen çalışma saatlerinden ve ücretlerden, işletme giderleri muhasebedeki faturalardan gelir.

Yalnız salon kayıtlarını tutan bir sistem ciroyu raporlar ama üç maliyet kaleminin hiçbirini raporlayamaz. Bu tek başına kusur sayılmaz. Önemli olan, bunu sözleşmeden önce bilmek ve yiyecek, personel ve genel giderlerin hangi sistemden geleceğine o noktada karar vermiş olmak. Yiyecek maliyetinin dayandığı stok sayımları stok devir hızı hesabının da temeli. Sayımların tutulacağı sistemi seçerken bu iki rakamı birlikte düşünün.

Bir Restoranın Yazılımlarını Saydığınızda Çıkan Tablo

Restoranların hangi yazılımları kullandığını gösteren, herkese açık ve tarihli bir sayım bilmiyoruz, o yüzden burada pazar payı vermiyoruz. Kendi işletmenizin yazılımlarını saymak ise mümkün ve karşınıza tek bir sistem değil, yan yana çalışan birkaç araç çıkabilir. Tezgâhta bir POS durur. Paket siparişler platformların kendi tabletlerine düşer, rezervasyonlar ayrı bir araçta ya da kâğıt defterde tutulur, muhasebeci başka bir programla çalışır. Reçete maliyetleri ya da vardiya çizelgesi de bir Excel dosyasında duruyor olabilir.

Araçların dağınık olması tek başına sorun değil. Maliyet ek yerlerinde çıkar, yani birinin bir ekrandan okuduğu rakamı başka bir ekrana elle yazdığı yerlerde. Kendi işletmenizdeki ek yerlerini saymak, başka restoranların ne kullandığını gösteren bir listeden size daha çok şey söyler.

POS Fiyatını Etiketten Değil Aylık Faturadan Hesaplayın

Karşılaştırma sayfasında en ucuz görünen POS çoğu zaman abonelik satırı en düşük olan POS'tur. Aylık faturada ise o satırın yanına başka kalemler de eklenir. Karşılaştırmadan önce sistemin sıradan bir ayda alacağı her kalemi toplayın.

Abonelik genellikle şube ve terminal sayısına göre hesaplanır. Hesabı gerçekten çalıştırdığınız sayıyla yapın.

Ödeme işlem ücreti işlem başına alınır ve satış arttıkça büyür. Tek bir ödeme kuruluşuna bağlı düşük bir abonelik, kuruluşu seçmenize izin veren daha yüksek bir abonelikten pahalıya gelebilir.

Donanım da hesaba girer: terminal, kart okuyucu, mutfak yazıcısı, tablet. Kimi firma donanımı satar, kimi kiralar, kimi kendi cihazınızı kullanmanıza izin verir.

Diğer sistemlerle kurulan bağlantılar ayrı bir kalem. Paket servis, rezervasyon, muhasebe ya da dijital menü entegrasyonu bazen ücretsizdir, bazen her bağlantı için aylık ücret alınır.

Ek kullanıcı, ek şube ve daha yüksek sipariş limiti de sık sık pakete dahil olmaz, eklenti olarak satılır.

Bu toplamı kısa listedeki her firma için kendi gerçek aylarınızdan biriyle ve gerçek sipariş sayınızla çıkarın. Ödemeyi masada alıyorsanız bu işi POS'un mu başka bir aracın mı yapacağına karar vermeden önce QR ödemenin nasıl çalıştığına bakın. Bu seçim işlem ücreti satırını değiştirir.

Misafir Kaydı: Restoran CRM'inin Tutması Gerekenler

Bir CRM, onu besleyen misafir kayıtları kadar işe yarar. Restoranda ise misafirlerin bir kısmı arkasında ad bırakmadan gelip gider. Kapıdan girip nakit ödeyen misafirin sistemde bir kaydı olmaz. Bu yüzden CRM araçlarını karşılaştırmadan önce misafir bilgisinin sisteme hangi noktalardan girebileceğini listeleyin. Çevrimiçi sipariş, rezervasyon, geri bildirim formu, sadakat kaydı ve kullanılan promosyon kodu bu noktaların başında gelir.

Misafir kaydı uzun değildir. İletişim izniyle birlikte ad ve iletişim bilgisi, ziyaret ya da sipariş geçmişi, alerji, oturma tercihi ya da doğum günü gibi rezervasyon notları ve misafirin bıraktığı geri bildirim ile yorumlar yeterlidir.

Bir restoran için en iyi CRM, bu bilgilerin zaten girdiği yerde duran CRM'dir. Sipariş ya da rezervasyonla beslenmeyen bağımsız bir CRM, kampanya ekranları ne kadar iyi olursa olsun büyük ölçüde boş kalır. Geri bildirim formu, çoğu işletmenin hemen kullanabileceği ucuz bir misafir kaydı kaynağı. Misafirin formu sonuna kadar doldurup doldurmayacağında da hangi anket sorularını gönderdiğiniz büyük rol oynar.

En Eksiksiz Tanımlanması Gereken Kayıt: Menü Ürünü

Siparişler, raporlar ve misafirin gördüğü menü aynı ürün kaydından beslenir, bu yüzden en eksiksiz tanımlanması gereken kayıt da o. İhtiyaç listesinde ürün yalnız ad ve fiyat olarak geçiyorsa kurulan sistem misafire bir yemekte kuruyemiş olup olmadığını gösteremez. Kahvaltıyı saat on birde menüden kaldıramaz, hangi porsiyonun sattığını da raporlayamaz. Eksiksiz bir ürün kaydında açıklama ve fotoğraf, her porsiyon için ayrı fiyat, ekstra shot ya da soğansız gibi seçenekler, alerjen ve besin bilgisi, siparişe açık olduğu gün ve saatler bulunur.

Salon ile mutfak da ürün kaydında buluşur. Fiyat menüde ya da POS'ta durur, tabak maliyetini belirleyen reçete ise genellikle başka bir yerde, bir arka ofis yazılımında ya da bir tabloda. İki sistem aynı ürün kaydını paylaşmıyorsa satılanı maliyetiyle eşleştirme işi, birinin her hafta elle doldurduğu bir Excel tablosuna kalır. Firmanın menü ekranına vakit ayırmadan önce bu bağlantıyı sorun.

Personelinizin Zaten Uyguladığı Kurallar

Kayıt, sistemde var olan şeyi tutar: ürün, masa, rezervasyon. Kural ise bir şey olduğunda sistemin ne yapacağını belirler. Birçok restoranda kuralların bir kısmı hiçbir yere yazılmamıştır. Yeni gelen personele ağızdan anlatılır, servisin ortasında hatırlanır. Her kuralı tek satıra yazın: ne olunca, sistem ne yapacak, kuralı kim aşabilir.

Kahvaltı ürünleri saat on birden sonra sipariş edilemez, fiks öğle menüsü yalnız öğle saatlerinde görünür. Minimum sepet tutarının altındaki paket sipariş reddedilir. Misafire söylediğiniz teslimat süresi hazırlık ve yol süresinin toplamıdır. Alkollü içecekte yaş doğrulaması istenir. Bir promosyon kodu paket serviste geçip salonda geçmeyebilir ya da yalnız belli bir tutarın üstünde çalışabilir.

Sonra yetki soruları gelir. Siparişi misafir kendi telefonundan mı gönderir, garson tabletten mi, ikisi de mi? İptal yetkisi kimde ve sipariş mutfakta hangi aşamaya gelince iptal artık mümkün olmaz? Paranın da kendi kuralları var: porsiyon fiyatları, kuver ve servis ücreti, hazır bahşiş oranları, adisyonun nasıl bölüneceği. Servisin ortasında biten bir ürün için de, hesabını ödeyip kalkmayan ve masa devrini geciktiren bir masa için de bir cevabınız olsun.

Bazı kurallarınız büyük ihtimalle incelediğiniz hiçbir yazılıma sığmayacak. Onları ayrı bir listede tutun. Bu kuralları personeliniz uygulamaya devam edecek ve yeni başlayanların en sık takıldığı yer de çoğu zaman onlar olacak.

İhtiyaç Listesini Gerçek Bir Servisten Çıkarmak

Şablona ihtiyacınız yok. Bir servis boyunca yanınızda bir defter taşıyın, mümkünse biri yoğun biri sakin iki servis. Aynı bilginin ikinci kez yazıldığı her anı not edin. Fişten okunup kasaya girilen sipariş, telefonla gelip deftere geçen rezervasyon, tahtada değişip uygulamada eski kalan fiyat bu anlardan. Her not savunabileceğiniz bir ihtiyaç satırıdır, çünkü hepsini kendi gözünüzle gördünüz.

Sonra tek bir siparişi alındığı andan muhasebeye düştüğü ana kadar izleyin ve kaç ayrı yerden geçtiğini sayın. Sayı iki üçü geçiyorsa entegrasyonu listenin en üstüne yazın.

İki konu deftere düşmez. Birincisi mutfağın hızı. Dijital sipariş kanalı misafirin sipariş vermek için beklediği süreyi kısaltabilir ama mutfağı hızlandırmaz. Mutfak yetişemiyorsa bekleme masadan pasa taşınır. İkincisi, her masa siparişini telefondan vermek istemez. Kalabalık gruplar ya da özel gün masaları garson isteyebilir. Restoranınızda çevrimiçi siparişi masa servisinin yerine değil, yanında çalışan bir kanal olarak planlayın.

Sistemi Yazılım Projesi Olarak Tasarlamak

Bu başlığı arayanların bir kısmı sistemi satın almayı değil, bir yazılım projesi olarak geliştirmeyi düşünüyor. Onlar için kayıt ve kural ayrımı tasarımın kendisi. Her kayıt kendi alanları olan bir varlığa dönüşür: menü ürünü, seçenek, sipariş, sipariş satırı, masa, alan, rezervasyon, misafir, personel. Defterdeki her kural da bir doğrulamaya ya da durum geçişine dönüşür. Mutfak hazırlamaya başladıktan sonra iptal edilemeyen sipariş bunun tipik bir örneği.

Ekranlardan yola çıkan bir projede aynı veriyi iki ayrı yerde saklamak kolaydır, çünkü her ekran kendi verisini ister. Bu yüzden ilk sürüme yalnız menü ürünü, sipariş ve masa varlıklarını alın. Veri modeli baştan doğru kurulduysa reçete ve stok sayımı gibi mutfak tarafı varlıkları salon tarafını yeniden yazmadan sonradan eklenebilir.

Firma Kısa Listesi ve Kurulum Sırası

Bu sistemlerden birini biz geliştiriyoruz, o yüzden diğerlerini sıralamayacağız. Firmaları neyin üstüne kurulduklarına göre ayırmak daha işe yarar. Arka ofis paketleri genellikle stok, satın alma ve muhasebeden yola çıkar. POS merkezli sistemler sipariş ve ödeme üstüne kurulur. Misafire dönük platformların merkezinde menü, sipariş kanalları, web sitesi ve rezervasyon durur. Eksiklerinizin hangi gruba düştüğünü defterdeki notlar gösterir.

Defterde en sık tekrar eden üç çift girişi seçin. Kısa listedeki her firmadan bu üçünü demoda, kendi ekranlarında ve sizin menünüz yüklüyken göstermesini isteyin. Sorunuza bir özellik adıyla cevap veren olursa o ekranı açmasını isteyin.

Kurulumun sırası bellidir, çünkü her adım bir öncekinde girilen bilgiyi okur. Önce menü gelir: ürün ürün porsiyonlar, seçenekler, alerjenler ve siparişe açık saatler. Genellikle en uzun süren adım budur. Ardından masalar ve alanlar, kanallar ve her kanalda hangi menünün görüneceği gelir. Sonra defter kuralları ayarlara taşınır, en son da POS, ödeme kuruluşu ve yazıcı bağlantıları kurulur. Canlıya geçmeden önce sistemden geçmiş bir günü ürün ürün isteyin. Bunun için veriyi dışa aktarıp bir tabloda yeniden kurmanız gerekiyorsa raporlama ihtiyacınız karşılanmamış demektir.

Üretilen içerik en sona kalır, çünkü sistemde zaten bulunan veriyi kopyalar. Temmuz 2026'da FineDine panelinde bir fırın için deneme web sitesi ürettik. Sitenin Popular Items bölümünde örnek menüden gelen T-Bone Steak ve Filet Mignon çıktı, bir fırının sitesinde. İşletme bilgileri boş olduğu için konum yerine de yer tutucu bir metin göründü. Bu bölümleri site tanımı değil, menü ve işletme kayıtları doldurmuştu. Yarım kalmış bir menünün üstüne kurulan çeviri ya da rapor da aynı şekilde o menünün eksiklerini taşır.

FineDine Neyi Tutuyor, Neyi Başka Sisteme Bırakıyor

FineDine salon kayıtlarını ve raporlamayı kapsar. Menu Manager'da bir ürün kaydı açıklamayı, fotoğraf ve videoyu, her porsiyonun fiyatını, seçenekleri, besin ve alerjen bilgisini ve ürünün siparişe açık olduğu gün ve saatleri tutar. Misafirin QR menüsü aynı kaydı alerjen ikonları ve porsiyon fiyatlarıyla gösterir, AI Website Builder da menü bilgisini bu kayıttan çeker. Menünüz fotoğraf, PDF, Excel ya da CSV olarak elinizdeyse Menu Manager yüklenen dosyadan menüyü çıkarabilir. Bu işlem AI kredisi kullanabilir. Kurulumun en uzun adımı da böylece çıkan menüyü ürün ürün kontrol edip düzeltmeye dönüşür.

Masalar kat planında alanlara yerleşir. Her masaya ayrı bir QR kod verilebilir ya da tüm masalar tek kodu paylaşabilir. Kod yalnız menüyü gösterecek ya da sipariş alacak şekilde ayarlanır. Tabletler üç modda çalışır: garsonun elinde, masaya sabit ya da self servis kiosk olarak. Rezervasyonlar kendi ayarları olan ayrı bir bölümde yönetilir. Defter kurallarının bir kısmının karşılığı panelde ayar olarak bulunur. Minimum sipariş tutarı, teslimat ücreti, hazırlık ve yol süresi, yaş doğrulaması, bahşiş oranları, kuver ve servis ücreti ve tek bir kanala ya da minimum tutara bağlanan promosyon kodları bunlardan. Misafir kayıtları siparişlerden, rezervasyonlardan, geri bildirim formlarından ve ürün yorumlarından gelir ve Guests & Engagement altında toplanır.

Raporlama iki katmanlı. Standart raporlar özet, ürün, işletme ve rezervasyon rakamlarını verir. Saatlik güncellenen AI Reports (FineDine IQ) ciroyu, sipariş sayısını ve ortalama adisyonu önceki bir dönemle karşılaştırır, olağan dışı hareketleri işaretler ve fotoğrafı eksik ürünler gibi aksiyonlar önerir. Siparişleriniz FineDine üzerinden geçiyorsa 30/30/30/10 kuralının ciro satırını bu iki katmandan okuyabilirsiniz. POS, ödeme ve yazıcı bağlantıları Marketplace'te listelenir. Önce kendi sisteminizin listede olup olmadığına, sonra bağlantının ücretli olup olmadığına bakın. Bağlantıların bir kısmı ücretsiz, bir kısmı aylık ücretli.

FineDine'da stok, satın alma, reçete maliyeti, vardiya planlama, bordro ya da muhasebe modülü yok. Personel hesaplarına kimin neyi yapabileceğini belirleyen roller atanır ama çalışılan saat kaydedilmez. Yani yiyecek maliyeti, personel gideri ve işletme giderleri başka bir sistemden gelmek zorunda. Bu da ihtiyaç listenize bir satır ekler: o sistem ürün bazında satış bilgisini nereden alacak, FineDine'dan mı, bağladığınız POS'tan mı?