Garson, mutfak, kurye ve yöneticiler aynı restoran içi ses kanalında buluşur. Mikrofon konuşma algılandığında açılır, sessizlikte kapanır.
Yoğun serviste ekip iletişimi ekrana bakmakla çözülmez. Garson masada, mutfak hazırlıkta, kurye yolda, müdür tüm akışı yönetirken bazen tek bir cümle söylemek gerekir: "üç numara çıktı", "dört kişilik masa boşaldı", "dönüyorum, sipariş varsa hazırlayın".
RestoranTakibi paneline bu ihtiyaç için bir operasyon ses kanalı geliştirdik. Bu yazıda kanalın nasıl kurgulandığını, hangi teknik kararların alındığını, neden şu anda panelde kapalı olduğunu ve ekip iletişiminin bugün hangi araçlarla yürüdüğünü anlatıyoruz. Ekranların bağlamı için garson paneli yazısına ve kurye takip programı sayfasına bakabilirsiniz.
Yazının en önemli cümlesi bu. Operasyon ses kanalı geliştirildi, sunucu tarafı yayında, ama panelde kullanıcıya gösterilmiyor. Özellik 2026-08-30'da bilinçli olarak kapatıldı.
Sebebi teknik ve giderilebilir bir eksik: kanal WebRTC ile çalışıyor ve tarayıcılar arası bağlantı kurmak için yalnızca bir STUN sunucusu tanımlı. TURN sunucusu yok. Bu, kâğıt üstünde küçük bir eksik gibi görünür ama pratikte şu anlama gelir: simetrik NAT arkasındaki ya da kurumsal ağ kullanan iki cihaz birbirine bağlanamaz. Yani panelde "Hazır" yazarken restoranların önemli bir kısmında ses hiç gitmez.
Çalışmayan bir özelliği "hazır" göstermek, hiç göstermemekten kötüdür. Kullanıcı düğmeye basar, sessizlik duyar ve yazılıma güveni sarsılır. Bu yüzden kanal, TURN sunucusu kurulup yapılandırılana kadar arayüzden çekildi. Aynı ilkeyi başka konularda da uyguluyoruz — bir özellik ya çalışır ya da orada durmaz.
Kapalı olsa da mimari üzerinde konuşmaya değer, çünkü açıldığında böyle çalışacak.
Ses sunucudan geçmez. Konuşma verisi cihazlar arasında doğrudan taşınır (uçtan uca WebRTC bağlantısı). Sunucunun tek işi bağlantı kurulurken sinyal mesajlarını iletmektir. Bu tercih hem gecikmeyi düşürür hem de restoran içi konuşmanın sunucuda dolaşmasını engeller.
Mikrofon sürekli açık kalmaz. Bileşen mikrofon giriş seviyesini ölçer; belirlenen eşiğin üstüne çıkıldığında ses gönderilmeye başlar, kısa bir sessizlik payından sonra kapanır. Mutfak davlumbazının uğultusunu sürekli yayınlayan bir kanal, ilk gün kapatılırdı.
Kanal restoran bazında izoledir. Sunucudaki oda anahtarı doğrudan restoran kimliğidir. Bir istemci başka bir restoranın kimliğiyle mesaj göndermeye çalışırsa mesaj sessizce düşürülür. Ayrıca bir odada aynı anda bulunabilecek katılımcı sayısı sınırlıdır; sınır dolduğunda yeni katılım isteği kapasite hatasıyla reddedilir.
Bağlantı koptuğunda oda temizlenir. Kullanıcı sekmeyi kapattığında veya bağlantısı düştüğünde sunucu o kişiyi odadan çıkarır ve kalan katılımcılara güncel listeyi yollar. Odada kimse kalmazsa oda tamamen silinir. Bu olmasaydı odalar zamanla "hayalet katılımcılarla" dolardı.
Rol oturumdan gelir. Odaya giren kişi, oturum açtığı hesabın rolüyle görünür — panelde tanımlı on beş personel rolünden biriyle: yönetim, servis, mutfak, kasa, kurye, bar, depo, satın alma, muhasebe ve diğerleri. Rol, personel kimliği ve kurye kimliği istemciden değil sunucudaki oturum bilgisinden alınır. Görünen ad ise uzunluk sınırlı ve temizlenmiş bir metindir; boş gelirse oturumdaki personel adına düşülür.
Ses kanalı kapalıyken restoran sessiz kalmıyor. Panelde gerçek zamanlı çalışan ve bugün canlı olan yollar şunlar:
| İhtiyaç | Bugün çalışan yol | Nerede görünür |
|---|---|---|
| Yeni sipariş duyurusu | Gerçek zamanlı yayın + ısrarlı sesli uyarı + titreşim | Sipariş ekranı, mutfak ekranı, kasa |
| "Bu masa bekliyor" | Masa durum renkleri ve süre eşikleri | Garson paneli, masa ekranı |
| Müşteri masadan hesap istiyor | QR ekranındaki "Ödeme İste" düğmesi, açık talep listesi | Yönetici bildirimleri, operasyon ekranı |
| Sipariş hazır oldu | Durum değişimi anında tüm ekranlara yayılır | Mutfak ekranı → sipariş ve kurye ekranı |
| Kurye atandı | Atama bildirimi, siparişin atandığı personel kuryeye düşer | Kurye paneli |
| Kurye dükkâna dönüyor | Kuryenin tek dokunuşla yönetici bildirimi | Yönetici bildirimleri |
| Tarayıcı kapalıyken haber | Web push aboneliği (kendi sunucumuzdan, VAPID ile) | Telefon / tarayıcı bildirimi |
Tablodaki son satır bilinçli olarak "web push" diyor. Mağazadan indirilen mobil uygulamada da bildirim görürsünüz, ama o bildirimi uygulamanın kendisi hesaplar; yani ekran açık ve bağlıyken düşer. Uzak bildirim altyapısı (FCM/APNs) uygulamada kurulu olmadığı için kapalı uygulamaya haber gitmez. Telefonu cebindeyken haber alması gereken kişi için çalışan tek yol, paneli tarayıcıdan ya da ana ekrana kurulmuş halinden açıp bildirim iznini vermektir. Bildirim kanallarının karşılaştırması Telegram ve bildirim sistemi yazısında.
Bu liste "sesin yerini tutar" demek değil. Ama pratikte restoran içi iletişimin büyük kısmı zaten konuşma değil durum bildirimidir ve durum bildirimi için ekran, ses ve bildirim üçlüsü konuşmadan daha güvenilirdir: kayıt bırakır, gürültüde kaybolmaz, vardiya değişince ortadan kalkmaz.
Yeni sipariş sesi konusunda iki gerçek hata yaşadık ve ikisi de düzeltildi.
Birincisi ses kilidiydi: duvara asılı ekranlarda uyarı hiç çalmıyordu ve kimse sebebini bilmiyordu (ayrıntısı mutfak ekranı rehberinde). Bugün ses kilidi ilk dokunuş ya da tuş vuruşunda kalıcı olarak açılıyor; ayrıca kilit hâlâ kapalıysa arayüz bunu söylüyor, yani sessizlik artık teşhis edilebilir bir durum.
İkincisi: tek bip yetmiyor. Gürültülü mutfakta tek seferlik uyarı kaçar. Yeni sipariş uyarısı artık kullanıcı ekranla ilgilenene kadar belirli aralıklarla tekrar ediyor ve ilk dokunuşta susuyor. Mutfak ekranı tarafının bütünü için mutfak ekranı rehberi yazısına bakabilirsiniz.
Masa ekranındaki renkler, garsonun mutfağa "şu masa ne oldu" diye sormasını gereksiz kılar. Dolu bir masada son siparişten bu yana geçen süre iki eşiğe göre değerlendirilir: birinci eşikte masa "ilgi bekliyor", ikinci eşikte "ikram zamanı" durumuna geçer. Her iki eşik de ayarlardan işletmeye göre değiştirilebilir ve sıfır yazılarak kapatılabilir.
İkram verildiğinde masa işaretlenir ve uyarı susar. Bu ayrıntı önemli: susturma olmasaydı garson aynı masa için aynı uyarıyı akşam boyunca görürdü ve bir süre sonra tüm uyarıları görmezden gelmeye başlardı.
Masadaki QR ekranında bir "Ödeme İste" düğmesi vardır; bu düğme masa bazında açılıp kapatılabilir. Müşteri dokunduğunda talep yöneticilere anlık olarak yayılır ve operasyon ekranındaki açık talepler listesine düşer. Tutar istemciden alınmaz; sunucu masanın açık adisyonundan yeniden hesaplar, açık adisyon yoksa isteği reddeder. Talebi kapatma da ciro görme yetkisine bağlıdır, yani liste herkesin elinde temizlenebilen bir uyarı yığınına dönüşmez.
Sınırı da yazalım: QR ekranında ayrı bir "Garson Çağır" düğmesi yok. Masadan gelen talebi garsonun önüne düşüren mekanizma, QR siparişinin garson onayına düşmesi ve masa süre eşikleridir. Konunun tamamı garson çağrı sistemi nedir yazısında.
Gerçek zamanlı yayının en çok gözden kaçan tarafı hedeflemedir. "Herkese duyur" kolaydır ama işe yaramaz: kurye, mutfağın hazırlık uyarılarını görürse bir hafta içinde tüm bildirimleri kapatır. Sunucu bu yüzden her mesajı süzgeçten geçirir ve dört ayrı hedefleme biçimini destekler.
Tek kişi. Mesajda bir personel kimliği varsa yalnız o kişiye gider. Kurye ataması böyle çalışır: "Sipariş #128 size atandı" bildirimini yalnız atanan kurye görür.
Rol listesi. Mesaj belirli rollere işaretlenmişse yalnız o rollerdeki oturumlar alır. İşletme sahibi ayrı bir rol olarak değerlendirilir.
Yöneticiler. Bazı bildirimler yalnız "sorumlu kişi" grubuna gitmelidir — kuryenin dükkâna dönüş bildirimi buna örnek. Bu grup unvana göre değil yetkiye göre belirlenir: işletme sahibi, müdür ve stok, masa, kurye atama, ciro, rapor, kârlılık veya log yetkilerinden birine sahip personel. Yetkisi olmayan personel bu bildirimleri hiç görmez.
Herkes. Yeni sipariş gibi, restorandaki herkesin görmesi gereken olaylar süzgeçsiz yayılır.
Bunun üstünde bir katman daha var: mesajın içeriği alıcıya göre kırpılır. Personel oturumları için sipariş verisi, o personelin yetkisine göre temizlenerek gönderilir; ciro görme yetkisi olmayan bir garsona giden sipariş bildiriminde para alanları bulunmaz. Bildirimi filtreleyip veriyi olduğu gibi göndermek, filtrelemenin kendisini anlamsız kılardı.
Son bir sınır: bir restoranın aynı anda açık tutabileceği gerçek zamanlı bağlantı sayısı sınırlıdır. Bu, tek bir işletmenin sekme çoğaltarak tüm gerçek zamanlı kapasiteyi tüketmesini engeller.
TURN sunucusu kurulduğunda kanal aynı mimariyle geri açılacak. Beklenen kullanım şu:
Ses kanalının çözmeyeceği şey ise kayıt tutmaktır. Konuşma iz bırakmaz; kim ne söyledi, ne zaman söyledi sorularının cevabı yoktur. Bu yüzden ses kanalı açıldığında bile sipariş durumu, iptal, indirim ve görev onayı gibi kayıt gerektiren her şey ekran üzerinden yürümeye devam edecek. Kanıt gerektiren işler için görev takibi modülü zaten ayrı bir akış olarak duruyor.
Ses kanalı beklerken pratik bir çerçeve işe yarar. Restoran içi iletişimi üç kategoriye ayırmak, hangi aracın nerede kullanılacağını netleştirir.
Durum bilgisi — "sipariş geldi", "hazır oldu", "masa boşaldı", "kurye yolda". Bunlar konuşulmaz, görülür. Ekran ve bildirim doğru araçtır; konuşmaya çevrildiğinde kaybolur ve iki kişi aynı anda farklı şey bilir. Panelde bu bilgiler zaten anlık yayılıyor.
Kısa yönlendirme — "üç numarayı önce çıkarın", "şu masaya sen bak". Kısa ömürlü, kayıt gerektirmeyen, hızlı olması gereken iletişim. Ses kanalının asıl hedefi burasıdır; bugün bunun yerine yüz yüze konuşma ya da işletmenin kendi mesajlaşma grubu kullanılıyor.
Kayıt gerektiren iş — iptal, indirim, ikram, kasa farkı, görev onayı, stok düzeltme. Bunlar hiçbir koşulda sözle halledilmemeli. Panelde her biri kim yaptı, ne zaman yaptı, öncesi neydi bilgisiyle kayda geçer. Ses kanalı açıldığında da bu kural değişmeyecek.
Ayrı bir mesajlaşma grubu kullanan işletmelerde en sık görülen sorun, üçüncü kategorinin birinci ve ikinciyle karışmasıdır: "şu masaya ikram yaptım" mesajı grup içinde kaybolur, gün sonunda kasa tutmaz ve kimse ne olduğunu hatırlamaz. Bu yüzden ses kanalını, panelin yerine geçen bir araç olarak değil, panelin yanında çalışan bir hız katmanı olarak tasarladık.
Yazılım pazarlamasında en kolay şey, geliştirilmiş ama çalışmayan bir özelliği "var" diye anlatmaktır. Kod tabanında dosya durur, ekran görüntüsü alınır, blog yazısı yazılır. Müşteri satın alır, denemeye kalkar ve olmadığını görür.
Bizim tercihimiz bunun tersi. Bir özellik gerçekten çalışmıyorsa panelden çekilir ve nedeni yazılır. Aynı yaklaşımı entegrasyon tarafında da uyguluyoruz: bir platform modülü kodda hazır olabilir ama işletmede devreye alınması sağlayıcıdan alınacak erişime bağlıysa bunu "canlı" diye anlatmıyoruz. Bu konudaki çerçeve platform API süreci sayfasında ayrıca yazılı.
Gerçek zamanlı altyapının bugün neyi taşıdığını görmek isterseniz gerçek zamanlı restoran operasyonu sayfası, panelin tamamı için restoran kontrol paneli sayfası var.
Hayır. Kanal geliştirildi ve sunucu tarafı yayında, ama panelde kullanıcıya gösterilmiyor. 2026-08-30'da bilinçli olarak kapatıldı; TURN sunucusu kurulup yapılandırılana kadar kapalı kalacak.
Kanal WebRTC ile çalışıyor ve şu anda yalnızca bir STUN sunucusu tanımlı, TURN yok. Simetrik NAT veya kurumsal ağ arkasındaki iki cihaz bu şartlarda birbirine bağlanamıyor. Panelde hazır görünüp pratikte ses gitmemesi, özelliği hiç göstermemekten kötü olduğu için arayüzden çekildi.
Hayır, kanal ses kaydı tutmaz. Tasarımda konuşma verisi cihazlar arasında doğrudan taşınır; sunucunun tek görevi bağlantı kurulurken sinyal mesajlarını iletmektir.
Hayır. Sunucudaki oda anahtarı doğrudan restoran kimliğidir ve farklı bir restoran kimliğiyle gelen mesaj düşürülür. Odaya giren kişi de oturum açtığı hesabın rolüyle görünür; isim istemciden serbest metin olarak alınmaz.
Panelde gerçek zamanlı yayın çalışıyor: yeni sipariş, durum değişimi, kurye ataması, kurye dönüş bildirimi ve masadan gelen ödeme talebi anında ilgili ekranlara düşüyor. Bunun yanında ısrarlı sesli uyarı, titreşim ve web push aboneliği var. Mağazadan indirilen mobil uygulamada bildirim uygulamanın kendi içinde üretilir; uygulama kapalıyken telefona bir şey düşmez, o durumda çalışan yol web push aboneliğidir.
Tekrar bilinçli: gürültülü mutfakta tek bip kaçtığı için uyarı, siz ekranla ilgilenene kadar belirli aralıklarla yinelenir ve ilk dokunuşta susar. Sesin hiç çıkmaması ise ayrı bir durumdur; ekran kurulduktan sonra bir kez uyandırılmadıysa tarayıcı sesi kilitli tutar. Kilit açılmadıysa arayüz bunu ayrıca bildirir.
Evet. Dolu masada son siparişten bu yana geçen süre için iki eşik vardır: ilgi eşiği ve ikram eşiği. İkisi de ayarlardan işletmeye göre değiştirilir; sıfır yazılırsa o eşik kapanır.
Hayır. İptal, indirim, ikram, kasa farkı, görev onayı gibi kayıt gerektiren işler ses kanalı açıldığında da panel üzerinden yürüyecek. Konuşma iz bırakmaz; bu tür işlemlerin kim, ne zaman, ne yaptı bilgisiyle kayda geçmesi gerekir.
Panel özellikleri modül başına ücretlendirilmiyor; işletme 1.000.000 ₺ ciroya kadar ücretsiz kullanıyor, sonrasında aylık 500 ₺ veya 5.000 TL / yıl ile yıllık lisans seçenekleri var. Güncel koşullar fiyatlar sayfasında yazılı.
Hayır, sunucu her mesajı hedefine göre süzer. Kurye ataması yalnız atanan kuryeye, kuryenin dönüş bildirimi yalnız yetkili yönetici grubuna gider; yeni sipariş gibi olaylar ise herkese yayılır. Ayrıca mesajın içeriği alıcının yetkisine göre kırpılır: ciro görme yetkisi olmayan personele giden sipariş bildiriminde para alanları bulunmaz.