Restoran mobil uygulaması yaptırmayı düşünüyorsan, muhtemelen halihazırda bir QR menü ya da adisyon programı kullanıyorsun ve bir yerde takılmışsın. Belki komisyonlar canını sıkıyor, belki ikinci şubeyi açtın ve raporlar dağıldı, belki de müşteri listesinin sende olmadığını fark ettin.
Bu yazıda sana uygulama satmaya çalışmayacağım. Çünkü doğrusu şu: restoranların çoğunun kendi mobil uygulamasına ihtiyacı yok. Önce ihtiyacın olup olmadığını netleştirelim, sonra gerçekten varsa nelere dikkat etmen gerektiğini konuşalım.
Restoran mobil uygulaması ne zaman gerekmez?
Türkiye'de restoran yazılımı pazarı doymuş durumda. QR menü, adisyon, kasa, paket servis — hepsinin onlarca sağlayıcısı var ve fiyatları oldukça makul. Aylık birkaç bin liraya menünü dijitalleştiren, masadan sipariş alan, kasanı toplayan bir sistem kurabilirsin.
Şu tabloya uyuyorsan hazır program senin için doğru karardır:
- Tek şuben var ya da şubeler birbirinin kopyası
- İşleyişin standart; sektörün geri kalanından farklı bir akışın yok
- Sipariş hacmin komisyonu can yakacak seviyeye gelmedi
- Müşteriyle ilişkin ağırlıklı olarak mekân içinde kuruluyor
Bu durumdaysan sıfırdan uygulama yaptırmak sana para kaybettirir. Hazır programın maliyeti öngörülebilir, kurulumu bir günde biter, bakımı senin derdin değildir. Bir yazılım stüdyosunun sana "gerek yok" demesi tuhaf gelebilir ama yanlış işi almak iki taraf için de kötü sonuçlanıyor.
Hazır programın tavanı nerede?
Tavan genelde dört yerden birinde görünür. İkisi sende varsa restoran mobil uygulaması konuşulmaya değer hale gelir.
1. Müşteri verisi sende değil
Hazır programda müşteri kaydı, sipariş geçmişi ve iletişim izni sağlayıcının sisteminde durur. Sonucu şu: kime, ne zaman, hangi kampanyayı göndereceğine sen karar veremezsin. Program değiştirdiğinde de o birikim geride kalır.
Bu, işletmenin büyümesiyle birlikte en pahalıya patlayan kısıt. Üç yıllık müşteri geçmişi, yeni açtığın şubenin ilk aylarını taşıyabilecek bir varlıktır — eğer sendeyse.
2. Komisyon matematiği dönmüyor
Pazaryerleri yeni müşteri kazanmak için gerçekten iyi bir kanal. Sorun, sadık müşterinin de orada kalması.
Haftada üç kez aynı yerden sipariş veren bir müşteriyi düşün. O müşteri seni zaten biliyor, menünü biliyor, tekrar tekrar geliyor. Onun her siparişinde aracıya komisyon ödemek, "yeni müşteri kazanma maliyeti" değil, sadece maliyet.
Burada mantıklı hedef pazaryerini terk etmek değil. Kanalları rol ayrımına sokmak: keşif pazaryerinde kalsın, tekrar sipariş senin kanalına geçsin.
3. Şube sayısı arttı
Tek şubede sorunsuz çalışan bir sistem, üçüncü şubede çatırdamaya başlar. Şubeye özel menü, şubeler arası fiyat farkı, ayrı stok, ayrı personel yetkisi ve merkezin hepsini tek ekranda görme ihtiyacı — hazır programların en zorlandığı yer burasıdır.
Zincire dönüşen işletmelerde sistemin baştan çok kiracılı kurgulanması gerekir: her şube kendi menüsü ve raporuyla ayrı bir birim gibi çalışır, merkez tepeden bakar, yeni şube açıldığında sıfırdan kurulum yapılmaz.
4. İşleyişin standart değil
Bazı işletmelerin akışı kalıba girmez. Plaj işletmesinde şezlong numarasına sipariş, otelde oda hesabına aktarım, butik bir mekânda özel rezervasyon kuralları… Hazır program bunları ya hiç yapmaz ya da zorlama bir eklentiyle yapar.
İşin farkı buradaysa, yazılımı işine uydurmak yerine işini yazılıma uydurmaya çalışıyorsun demektir. Uzun vadede bu, en sinsi maliyet kalemi.
QR menü ile restoran mobil uygulaması aynı şey değil
Sık karışan iki şey bunlar ve karışması pahalıya mal oluyor.
QR menü tek seferlik bir sipariş akışıdır. Müşteri masaya oturur, kodu okutur, sipariş verir, kalkar gider. Geriye bir iz kalmaz. Amacı operasyonu hızlandırmaktır ve bu işi iyi yapar.
Mobil uygulama tekrar üzerine kuruludur. Müşteri onu telefonunda taşır, bildirim alır, puan biriktirir, tekrar sipariş verir. Amacı operasyon değil, müşteriyi elde tutmaktır.
Bu ayrım pratik bir sonuç doğuruyor: eğer derdin sadece masadan sipariş almaksa mağazada yayınlanan bir uygulamaya ihtiyacın yok, PWA yeterli — müşteri indirmez, tarayıcıdan çalışır. Ama sadakat ve tekrar sipariş hedefliyorsan uygulamanın telefonda kalması gerekir.
İlk sürümde gerçekten olması gerekenler
Uygulama projelerinin çoğu, ilk sürüme çok fazla şey sığdırmaya çalıştığı için gecikir. Restoran tarafında ilk sürümün taşıması gereken çekirdek aslında kısa:
- Menü yönetimi. Ürün, fiyat, görsel, stok durumu ve gün içi değişiklik. Fiyatı panelden değiştirebilmek, uygulamanın en çok kullanılacak özelliğidir.
- Sipariş akışı. Sepet, not alanı, sipariş durumu ve mutfağa iletim. Durum bildirimi olmayan sipariş, telefonla teyit aramasına dönüşür.
- Ödeme. Online ödeme mi, kapıda mı, ikisi birden mi — bunu baştan netleştirmek gerekir; sonradan eklemek en pahalı değişikliklerden biri.
- Temel raporlama. Günlük ciro, en çok satan ürün, saat bazlı yoğunluk. Üçü de yoksa uygulamayı yönetemezsin.
Rezervasyon, kurye takibi, çoklu şube, kampanya motoru ve entegrasyonlar ikinci sürümün konusu. İlk sürümü küçük tutmak korkaklık değil; gerçek kullanıcıyla test edip yanlış varsayımları ucuza öğrenmenin tek yolu.
Sadakat: indirtmek kolay, ikinci kez açtırmak zor
Restoran uygulamalarında en çok gözden kaçan gerçek bu. Açılış kampanyasıyla uygulamayı indirtirsin, birkaç hafta sonra kullanım düşer ve elinde kimsenin açmadığı bir uygulama kalır.
Sahada işleyen sadakat yapısı neredeyse her zaman sade olanıdır:
- Anlaşılır tek bir mekanik. Müşteri kaç puanla ne kazandığını düşünmeden söyleyebilmeli.
- Yakın vadeli karşılık. "Bir sonraki siparişte geçerli" olan şey, altı ay sonra olgunlaşan bir seviyeden fazla iş görür.
- Az ve doğru zamanlı bildirim. Sabah üçte bildirim atan uygulama silinir. Öğle arasından yarım saat önce atan uygulama sipariş getirir.
Çok seviyeli, rozetli, karmaşık sistemler sunumda etkileyici görünür; sahada kimse takip etmez. Sadeliği baştan seçmek sonradan sadeleştirmekten ucuzdur.
Restoran mobil uygulaması maliyetini belirleyen asıl soru
Fiyat konuşulurken herkes ekran sayısını sorar. Oysa restoran mobil uygulaması projelerinde maliyeti asıl belirleyen tek bir soru var: mevcut kasan entegre olabilir mi?
POS ya da adisyon programının dışa açık bir arayüzü varsa siparişler oraya akar, işler nispeten kolaydır. Yoksa iki yol kalır: ya mutfak ekranı üzerinden bağımsız bir akış kurarsın (daha ucuz ama iki sistemi ayrı yönetirsin), ya da entegrasyon için özel geliştirme yaparsın (daha pahalı ama tek akış).
İkinci belirleyici, sadakatin çekirdekte mi yoksa sonradan mı geleceği. Sonradan eklenen sadakat, kullanıcı ve sipariş modelini yeniden yazmayı gerektirdiği için genelde baştan yapmaktan pahalıya gelir.
Projenin kabaca hangi aralıkta olduğunu görmek istersen fiyat sihirbazından birkaç soruda bir tahmin alabilirsin.
Asıl zorluk yayından sonra başlıyor: personel
Restoran uygulaması projelerinde teknik taraf genelde beklendiği gibi gider. Sahada aksayan şey neredeyse hep aynı: personel eski alışkanlığına döner.
Sebebi de mantıklı. Yoğun bir serviste garson için en hızlı yol, bildiği yoldur. Yeni sistem ona bir saniye bile fazladan yük getiriyorsa, ilk yoğun akşamda kâğıda geri döner ve sistem çift kayıt tutmaya başlar. Bu noktadan sonra raporların da güvenilirliği biter.
Pratikte işe yarayan üç şey var. Birincisi, sistemi personelin işini azaltacak şekilde kurmak — sipariş yazmayı hızlandırmıyorsa benimsenmez. İkincisi, geçişi tek seferde değil tek şubede veya tek vardiyada başlatmak. Üçüncüsü, ilk iki hafta boyunca birinin gerçekten sahada durup takılan yerleri not etmesi.
Bu yüzden yayın gününü projenin bitişi değil, ikinci yarısının başlangıcı olarak planlamak gerekiyor.
Yaptırmadan önce sorulacak beş soru
Teklif alırken bu beşini sor. Cevapları, önündeki firmanın seni ne kadar ciddiye aldığını gösterir.
- Müşteri verisi ve kod kimin adına olacak? Cevap "sizin" değilse devam etme.
- Kasamla entegrasyon mümkün mü, değilse alternatif ne? Net cevap veremiyorsa henüz araştırmamış demektir.
- İkinci şubeyi açtığımda ne olur? Bugün tek şubeliysen bile sor; mimari kararı bugün veriliyor.
- Yayından sonra bakım nasıl işliyor? İşletim sistemi güncellemeleri uygulamayı bozar; bakımsız uygulamanın ömrü kısadır.
- Benzer bir işi canlıda gösterebiliyor musunuz? Anlatılan değil, indirilip açılan bir ürün istemek en hızlı eleme yöntemi.
Kendi ürünümüzden öğrendiklerimiz
Bu yazıdaki şeylerin çoğunu teoriden değil, kendi ürünümüzü kurarken öğrendik. masa, kafe, restoran, bar ve plajlar için geliştirdiğimiz çok kiracılı QR sipariş ve mekân yönetim platformu. Müşteri masadaki kodu okutup sipariş veriyor, sipariş mutfağa WebSocket ile anlık düşüyor, işletme menüden raporlara kadar her şeyi tek panelden yönetiyor.
Orada karşılaştığımız problemler senin de karşılaşacakların: yoğun saatte biriken masalar, mutfakla sözlü iletişimin hataya açık olması, şube bazlı raporun dağılması, modüllerin her işletmede aynı olmaması. Sadakat, rezervasyon ve analitiği ayrı modüller haline getirmemizin sebebi de bu — her mekân aynı şeye ihtiyaç duymuyor.
Özet
Restoran mobil uygulaması yaptırmak bir prestij kararı değil, bir eşik kararı. Hazır programın seni sınırlamadığı sürece en iyi seçenek hazır programdır. Müşteri verisi, komisyon, şube sayısı ve işleyişin standart dışılığı — bu dörtten ikisi sende belirginleştiğinde kendi uygulaman kendini amorti etmeye başlar.
Hangi tarafta olduğundan emin değilsen, restoran mobil uygulama yaptırma sayfasındaki karar kriterlerine bakabilir ya da mevcut durumunu birkaç cümleyle anlatıp ne gerektiğini birlikte netleştirebiliriz. Gerek yoksa bunu da açıkça söylüyoruz.