Yemeksepeti ve Trendyol gibi platformların büyümesiyle birlikte restoran otomasyonu artık lüks değil zorunluluk. 2026'da öne çıkacak trendler.
Restoran otomasyonu üzerine yazılan yazıların çoğu sektör yüzdeleriyle başlar. Biz başlamayacağız: kaynağını gösteremediğimiz bir oranı yazmak, okuyanı bilgilendirmiyor, sadece cümleyi büyütüyor.
Bunun yerine kendi ürünümüzü geliştirirken ve restoranların panelde gerçekte ne yaptığına bakarken gördüğümüz beş yönelimi anlatacağız. Her başlıkta üç şey var: ne değişiyor, panelde karşılığı nedir ve bunun işe yaraması için işletmenin neyi hazır etmesi gerekiyor. Son bölümde de 2026'da olduğundan fazla konuşulan üç şeyi ayrıca yazdık.
Bir restoran bugün aynı anda birden çok yerden sipariş alıyor: masadan, telefondan, kasadan, QR'dan ve online platformlardan. Her kanalın kendi tableti olduğu düzen artık bir "kurulum tercihi" değil, doğrudan sipariş kaçırma sebebi.
Toplama işinin teknik tarafı iki modele dayanıyor. Bildirim (push) modelinde platform, sipariş oluşunca doğrudan yazılımın sunucusuna haber verir. Sorma (polling) modelinde ise yazılım belirli aralıklarla platforma sorar. RestoranTakibi'nde sorma modeliyle çalışan entegrasyonlar 15 saniyede bir kontrol ediliyor; Delivery Hero (Yemeksepeti) ve Migros Yemek tarafında ise platformun sunucumuza bildirim gönderdiği model kurulu.
Siparişi çekmek kolay kısmıdır. Zor kısmı, siparişin platformdaki durumu ile paneldeki durumunun aynı kalmasıdır. Yalnızca "yeni oluşturuldu" durumundaki siparişleri çeken bir sistem, platform tarafında teslim edilmiş siparişleri panelde sonsuza kadar "hazırlanıyor" olarak bırakır. Bunu kendi sistemimizde yaşadık ve düzelttik: artık platformdan gelen gerçek durum yerele işleniyor ve asılı kalan siparişler için ayrı bir süpürücü çalışıyor.
Kanal birleştirmenin işletme tarafındaki hesabını sipariş platformu komisyonları yazısında, teknik tarafını entegrasyon rehberinde anlattık. Bağlanabilen sistemlerin listesi entegrasyonlar sayfasında.
Mutfak ekranı (KDS) yeni bir fikir değil; 2026'da değişen, ekranın kâğıdı tamamen değil kısmen ikame etmesi. Gerçek mutfaklarda ikisi bir arada çalışıyor: ekran akışı yönetiyor, fiş tabağın yanına gidiyor.
Bu yüzden mutfak ekranını değerlendirirken bakılacak üç şey var:
Ayrıntı: mutfak ekranı programı sayfası ve mutfak ekranı rehberi yazısı.
QR menü artık sadece PDF gösteren bir kare değil; masadan sipariş alan bir kanal. Ama kontrolsüz QR siparişi, işletmede iki gerçek sorun üretiyor: masaya oturmayan birinin sipariş geçmesi ve mutfağa doğrudan düşen siparişin garson tarafından fark edilmemesi.
RestoranTakibi'nde QR sipariş akışı bu yüzden üç modda çalışıyor ve varsayılan mod garson onayı:
| Mod | Sipariş nasıl doğar | Ne zaman tercih edilir |
|---|---|---|
| Garson onayı | Beklemede doğar, garson onaylayınca mutfağa geçer | Servisli restoran, kafe |
| Doğrudan mutfak | Anında mutfağa düşer, masa hemen dolu sayılır | Self servis, hızlı tüketim |
| Yönetici onayı | Yetkili onayına düşer | Kontrolün üstte tutulduğu işletmeler |
Buna ek olarak masa bazında konum kapısı açılabiliyor: QR siparişi ancak belirlenen yarıçap içinden geçilebiliyor (varsayılan 250 metre, 50-5000 metre arasında ayarlanabilir). Bu caydırıcı bir katmandır; asıl güvence garson onayıdır.
QR tarafını kurmak için QR menü nasıl yapılır yazısına ve QR sipariş ve masadan ödeme sayfasına bakabilirsiniz.
2026'nın en çok abartılan başlığı bu. Restoran yazılımlarında yapay zekâ iki farklı şey anlamına gelebiliyor ve aradaki fark, işletme açısından çok büyük:
RestoranTakibi'nde yapay zekâ varsayılan olarak danışman modunda çalışır. Panelde açıkça şöyle yazar: veritabanını değiştirmez, stok, gider veya kasa işlemi yapmaz, sadece nasıl düzeltileceğini söyler. Bunun bilinçli bir tercih olduğunu belirtelim; bir modelin, doğrulamadan stok miktarını değiştirmesi işletme için düzeltilmesi zor hatalar üretir.
Panelin yapay zekâ tarafı, işletmenin verisindeki boşlukları da çıkarıyor: reçetesi bağlanmamış menü ürünleri, alış fiyatı girilmemiş stok kalemleri, minimum stok seviyesi tanımlanmamış ürünler, teslim edilmiş ama stoktan düşmemiş siparişler. Bunlar tahminî yorum değil, sayılabilir eksiklerdir.
Ayrıca günlük operasyon özeti üretiliyor ve bu özet isteğe bağlı olarak bir n8n webhook adresine gönderilebiliyor; yani kendi otomasyon zincirinize bağlayabilirsiniz.
Dürüst bir uyarı: günlük özet e-postalarındaki anomali uyarılarını 2026 Eylül'ünde kendimiz denetledik ve yanlış alarm ürettiklerini gördük. Yeni kaydolmuş, menüsü boş bir hesap her sabah "ciddi satış düşüşü" uyarısı alıyordu. Sebep basitti: eşik yalnız haftalık ortalamaya bakıyordu. Uyarı herkese ve her gün çalarsa kimse bakmaz. Bu tür kapıların düzeltilmesi, modelin kendisinden daha çok iş çıkarıyor.
Ayrıntı: AI restoran asistanı ve AI restoran asistanı, veri analizi ve anlık bildirim yazısı.
Restoran raporlamasının en yaygın hatası ortalamadır. Tek bir unutulmuş sipariş, ortalama hazırlık süresini saatlerce yukarı çeker ve rapor kullanılamaz hale gelir.
2026'da işini ciddiye alan işletmeler üç ölçüme geçiyor:
Buna bir de sektör kıyası ekleniyor: panelde, aynı mutfak tipindeki diğer işletmelerin toplulaştırılmış ortalamalarıyla karşılaştırma yapan bir çevre raporu var. Kıyas ancak yeterli sayıda işletme varsa gösteriliyor; tek bir restoranın verisi başkasının ekranında görünmüyor.
Raporlama yaklaşımının tamamı için restoran raporlama ve analiz yazısına bakabilirsiniz.
Otomasyon, boş bir veritabanının üzerinde çalışmaz. Aşağıdaki tablo, hangi özelliğin hangi veriye bağlı olduğunu gösteriyor. Sağdaki sütun doldurulmadan soldaki özellik "açık" görünse bile anlamlı çıktı üretmez.
| Otomasyon | Panelde karşılığı | Çalışması için gereken veri |
|---|---|---|
| Otomatik stok düşümü | Reçete bağlama, stok hareketi | Menü ürünlerine hammadde reçetesi |
| Ürün kârlılığı | Menü maliyeti, önerilen fiyat | Stok kalemlerinde alış fiyatı |
| Kritik stok uyarısı | Stok panelindeki kritik stok listesi | Minimum ve yeniden sipariş seviyeleri |
| Gerçek kâr | Kârlılık ekranı | Kira, personel, elektrik gibi sabit giderlerin girilmesi |
| Vergi tahmini | Vergi merkezi | KDV oranları, mükellef tipi, bordro ve kira tutarları |
| Çalışma saati kontrolü | Sipariş kabulü | Haftalık çalışma takvimi |
| Kasa farkı | Gün sonu | Her gün sayılan tutarın girilmesi |
Son satır özellikle önemli: çalışma takvimi girilmemiş bir işletmeyi sistem 7/24 açık sayar ve gece de sipariş kabul eder. Bunu kendi kullanıcılarımızda ölçtük, uyarıyı panele taşıdık.
Sesli sipariş. Gürültülü bir salonda, aksanlı ve hızlı konuşan bir müşteriden alınan siparişin doğruluğu, tanıtım videolarındaki kadar yüksek değil. Yanlış alınan siparişin maliyeti, kazandırdığı süreden büyük.
Tam otomatik fiyatlandırma. Talebe göre fiyat değiştiren sistemler teknik olarak mümkün, ama mahalle restoranında müşteri ilişkisini bozar. Bizim yaklaşımımız daha dar ve ölçülebilir: kanal bazlı fiyat (masa ve paket için ayrı fiyat) ile gün/saat aralığına bağlı otomatik indirim. Bunlar işletmenin bilerek kurduğu kurallar, modelin kararı değil.
"Yapay zekâ restoranınızı yönetsin." Yönetmiyor. Veriyi okuyor ve öneriyor. Kararı veren hâlâ işletmeci; ve bu, bir eksiklik değil doğru tasarım.
Hepsini aynı anda kurmaya çalışmak, hiçbirini kurmamakla aynı sonucu veriyor. Önerdiğimiz sıra şu: önce menü ve masa düzenini oturtun, sonra kanalları tek panele toplayın, sonra mutfak ekranını devreye alın, sonra çok satan yirmi ürünün reçetesini bağlayın, en son maliyet ve kârlılık ekranını açın.
Bu sıranın modül karşılıklarını restoran kontrol paneli sayfasında, kurulumun ne kadar sürdüğünü kurulum süresi yazımızda, maliyet tarafını ise restoran maliyet düşürme ipuçları yazısında bulabilirsiniz.
Zorunlu değil ama kanal sayısı arttıkça elle yönetmek gerçekten zorlaşıyor. Tek kanaldan sipariş alan küçük bir işletme defterle idare edebilir. Masadan, telefondan, QR'dan ve en az iki online platformdan sipariş alan bir işletmede ise kaçırılan sipariş ve durum uyuşmazlığı kaçınılmaz hale geliyor.
Push modelinde sipariş oluştuğu anda panele düşer, polling modelinde sorgu aralığı kadar gecikme olur. RestoranTakibi'nde sorma modeliyle çalışan entegrasyonlar 15 saniyede bir kontrol ediliyor; Delivery Hero ve Migros Yemek tarafında platformun sunucumuza bildirim gönderdiği model kurulu.
RestoranTakibi'nde hayır. Yapay zekâ varsayılan olarak danışman modunda çalışır: veritabanını değiştirmez, stok, gider veya kasa işlemi yapmaz, yalnızca durumu yorumlar ve ne yapılması gerektiğini söyler. Bu bilinçli bir tasarım tercihi.
Varsayılan mod garson onayıdır: QR'dan gelen sipariş beklemede doğar, garson onaylayana kadar mutfağa geçmez. Doğrudan mutfak ve yönetici onayı modları da var, ancak bunlar işletmenin bilerek seçmesi gereken modlardır. Ayrıca masa bazında konum kapısı açılabiliyor.
Pratikte kaldırmıyor. Çoğu mutfakta ekran akışı yönetiyor, fiş ise tabağın yanına gidiyor. Bu yüzden otomatik fiş basımı hâlâ önemli; ancak düz tarayıcıda her fiş için yazdırma diyaloğu açıldığından, sessiz basım yalnız kasa uygulaması ya da ağ üzerinden ESC/POS yazıcıyla mümkün.
Tek bir unutulmuş sipariş ortalamayı saatlerce yukarı çeker ve rapor kullanılamaz hale gelir. Doğru ölçüm medyan ve p90'dır: siparişlerin yarısı hangi sürede tamamlandı ve en yavaş yüzde 10'u nerede duruyor. RestoranTakibi'nde süre analizi kabul, mutfak ve servis aşamaları için ayrı hesaplanıyor.
Toplam fire tutarı tek başına aksiyon üretmez. Sebep kırılımı üretir: son kullanma tarihi ağırlıklıysa alım miktarı düşürülür, mutfak hatası ağırlıklıysa eğitim gerekir, tedarikçi kaynaklıysa tedarikçi konuşulur. Serbest metin ise gruplanamaz, çünkü aynı sebep on farklı yazımla girilir.
Hayır, sıralı kurmak daha iyi sonuç veriyor. Önce menü ve masa düzeni, sonra kanalların tek panelde birleştirilmesi, sonra mutfak ekranı, sonra çok satan ürünlerin reçetesi, en son maliyet ve kârlılık. Reçete ve alış fiyatı girilmeden kârlılık ekranı açılırsa boş rakam üretir.
Hayır. Panelde aynı mutfak tipindeki işletmelerin toplulaştırılmış ortalamalarıyla karşılaştırma yapan bir çevre raporu var; kıyas ancak yeterli sayıda işletme varsa gösteriliyor ve tek bir restoranın verisi başka bir işletmenin ekranında görünmüyor.