Restoran Mobil Sipariş Uygulaması Yaptırma: Kapsam, Maliyet ve Büyüme

Kısa cevap: Restoran uygulaması cuma akşamı çalışıyorsa üründür

Restoran mobil sipariş uygulaması yaptırma projesi, dijital bir menü tasarımından ibaret değildir. Müşterinin gördüğü ürünün o şubede gerçekten satılabildiği, seçtiği ekstraların mutfağa anlaşılır düştüğü, ödemenin yalnız kabul edilebilir sipariş için alındığı, hazırlık süresinin gerçek yoğunluğa göre iletildiği ve teslimat sorumluluğunun kaybolmadığı uçtan uca bir satış operasyonudur. En parlak arayüz bile yoğun saatte stok, yazıcı veya ödeme hatasını yönetemiyorsa gelir yerine destek yükü üretir.

Doğrudan sipariş kanalı restoranın müşteri ilişkisini, menü sunumunu ve tekrar sipariş deneyimini kontrol etmesini sağlayabilir. Fakat uygulamayı yayımlamak müşterinin onu kendiliğinden indireceği anlamına gelmez. Paket içi yönlendirme, mağaza içi QR, web trafiği, sadakat ve izinli iletişim gibi edinim mekanikleri ürün planının parçasıdır. Teknoloji teklifi büyüme ve şube operasyonundan kopuk hazırlanırsa indirme sayısı olsa bile kârlı sipariş oluşmayabilir.

Bu rehber tek restoran, bulut mutfak, çok şubeli marka ve birden fazla markayı yöneten gruplar için satın alma niyetine dönük bir kapsam çerçevesidir. Vergi, gıda, tüketici, ödeme ve kişisel veri sorumlulukları işletme modeline göre uzmanlarla doğrulanmalıdır.

Yoğun saat senaryosuyla keşfe başlayın

Normal bir salı öğleden sonrası sistemi fazla zorlamaz. Kapsamı test etmek için cuma 19.30'u hayal edin: bir şubede pizza hamuru bitiyor; başka şube teslimata açık ama gel-al kapalı; POS fiyatı güncellenmiş, uygulama önbelleği eski; mutfak yazıcısının kâğıdı bitmiş; iki ödeme webhook'u geç geliyor; kurye kapasitesi doluyor ve müşteri adresini değiştirmek istiyor. Yönetici hangi ekranda neyi fark eder ve sipariş hangi kurala göre ilerler?

Bu egzersiz beş çekirdek soruyu ortaya çıkarır: Menü gerçeğinin sahibi kim? Sipariş hangi anda kesinleşir? Şube ne kadar sürede kabul etmeli? Hazırlık ve teslim süresini kim günceller? Entegrasyon kesilince güvenli alternatif nedir? Teklifler bu sorulara göre karşılaştırıldığında “kaç ekran var” tartışmasından daha anlamlı sonuç verir.

Menü bir katalog değil, şube bazlı satış sözleşmesidir

Menü modeli kategori ve üründen daha derindir. Boyut, hamur, pişirme, içecek seçimi, çıkarılabilir malzeme, zorunlu/isteğe bağlı ekstra, minimum-maksimum seçim, set menü, alerjen bilgisi, gün/saat uygunluğu ve satış kanalı fiyatı olabilir. Bir ekstra yalnız belirli boyutlarda geçerli olabilir; set içindeki içecek şubeye göre değişebilir. Veri modeli bu ilişkileri açık kurmazsa müşterinin verdiği sipariş mutfakta yorum gerektirir.

Çok şubeli yapıda ürün merkezi tanımlanırken fiyat, stok, görünürlük ve çalışma saatleri şube tarafından farklılaştırılabilir. “Stokta yok” yalnız ürün düzeyinde olmayabilir; bir malzeme tükendiğinde onu kullanan onlarca ürün etkilenir. İlk sürümde reçete-stok entegrasyonu ağırsa şube çalışanına hızlı “tükendi / bugün kapalı” kontrolü verilebilir. Ancak değişikliğin tüm müşteri kanallarına ne kadar sürede yansıdığı ölçülmelidir.

Menü içeriğinin tek kaynağı POS, merkezi yönetim paneli veya ayrı PIM olabilir. İki sistemin aynı alanı değiştirmesi sessiz veri çatışması doğurur. Ürün adı/açıklama/görsel ile muhasebe ürün kodunun farklı sahipleri olabilir; alan bazında kaynak kararı da mümkündür.

Beş rol, tek sipariş gerçeği

Müşteri

Müşteri konum veya adresle hizmet veren şubeyi bulur; teslimat, gel-al ya da masaya sipariş kanalını seçer; menüyü filtreler; ürün seçeneklerini tamamlar; sepet, ücret ve tahmini süreyi görür; ödeme yapar; siparişi takip eder; gerektiğinde destek ve yeniden sipariş akışına geçer. Üyelik zorunluluğu ilk siparişi düşürebilir; misafir ödeme ile sonradan hesap oluşturma seçeneği değerlendirilebilir.

Şube sipariş sorumlusu

Şube yeni siparişi sesli/görsel uyarıyla alır, kapasite ve ürün uygunluğunu kontrol eder, kabul veya gerekçeli ret verir, tahmini hazırlık süresini düzenler ve istisnayı yönetir. Sessize alınmış tablet veya ulaşmayan push nedeniyle siparişin askıda kalmasını önleyen süre aşımı ve merkez alarmı olmalıdır. Bir siparişi kimin kabul ettiği kaydedilir.

Mutfak ve hazırlık istasyonları

Mutfak ekranı veya yazıcı, müşteri uygulamasındaki pazarlama açıklamasını değil üretim için gerekli sade bileşenleri gösterir. Ürünler sıcak, soğuk, bar gibi istasyonlara ayrılabilir; bir siparişin tüm kalemleri hazır olduğunda paketleme tetiklenir. İptal veya değişiklik, üretim başlamışsa farklı yetki ve finans sonucuna sahiptir. KDS ekranında dokunma sırası gerçek mutfak akışına göre saha testiyle belirlenmelidir.

Kurye veya teslimat ortağı

Restoran kendi kuryesini kullanıyorsa atama, teslim alma, rota, müşteri iletişimi ve teslim kanıtı gerekir. Üçüncü taraf ağ kullanılıyorsa sipariş ve kurye durumlarının hangi sistemden geldiği belirlenir. “Hazır” durumu erken basılırsa kurye bekler; geç basılırsa yemek soğur. Hazırlık tahmini ile kurye çağırma politikası birlikte tasarlanır.

Merkez operasyon, pazarlama ve finans

Merkez menü, şube, saat, teslimat bölgesi, ücret, kampanya ve rol yönetir; istisna kuyruğunu ve performansı izler. Pazarlama segment ve kampanya oluşturabilir ama finans kuralını sınırsız değiştirmemelidir. Finans ödeme, iade, şube geliri, promosyon katkısı ve e-belge durumunu uzlaştırır. Aynı yönetici hesabını herkesin paylaşması denetim ve güvenlik açısından kabul edilmemelidir.

Sipariş yaşam döngüsünü ve geri dönüşleri yazın

Örnek durumlar sepet → ödeme başlatıldı → ödeme doğrulandı → şubeye iletildi → kabul edildi → hazırlanıyor → hazır → kuryeye verildi / teslim alınabilir → tamamlandı biçimindedir. Ret, müşteri iptali, şube iptali, ödeme zaman aşımı, kısmi ürün sorunu, iade ve ters ibraz yan dallardır. Kullanıcıya gösterilen metin teknik durum kodundan farklı olabilir; fakat her ekran aynı kaynaktan türemelidir.

Önemli karar, ödemenin ve şube kabulünün sırasıdır. Önce ödeme almak dönüşümü koruyabilir ancak şube reddinde hızlı iade gerektirir. Önce şube kabulü almak müşteriyi bekletebilir ve ödeme sırasında stok değişebilir. Yetkilendirme/tahsilat seçenekleri ödeme kuruluşuyla değerlendirilir. Siparişi “başarılı” sayan an; analitik, fiş/fatura, sadakat puanı ve kurye çağrısını etkilediği için açık tanımlanır.

MVP ve sonraki fazları gelir bağımlılığıyla ayırın

İlk sürümün hedefi “rakipte olan her şey” değil, kontrollü bir bölge ve menüde hatasız sipariş döngüsü olmalıdır. Sadakat stratejisi ürünün ana edinim teziyse basit bir değer önerisi MVP'ye girebilir; ancak on kampanya tipini birden kurmak hem test matrisini hem müşteri desteğini büyütür.

Teknik mimari: sipariş kaybına tolerans yok

Mobil uygulama ve mobil web aynı menü, sepet ve sipariş API'lerini kullanabilir. Yönetim paneli merkez/şube yetkileriyle; KDS veya sipariş tableti gerçek zamanlı sipariş kanalıyla çalışır. Backend kimlik, şube ve hizmet alanı, menü, fiyat/stok, sepet, kampanya, sipariş, ödeme, teslimat, bildirim ve rapor modüllerini net sınırlarla yönetir.

Sepet sunucuda yeniden fiyatlanmalıdır. İstemcinin gönderdiği toplam güvenilir kabul edilmez; şube, kanal, saat, kupon ve ürün uygunluğu ödeme öncesi kontrol edilir. Aynı “sipariş oluştur” isteği ağ yüzünden tekrarlandığında çift sipariş üretmemesi için idempotency uygulanır. Ödeme ve kurye webhook'ları imza, olay kimliği, sıra ve tekrar açısından doğrulanır. Sipariş olayı kalıcı kayda alınmadan yalnız anlık websocket/push gönderimine güvenilmez.

Yoğun saat kapasite testinin merkezidir. Normal ortalamanın yanı sıra belirli dakikada menü okuma, sepet ve ödeme pikleri modellenir. Önbellek statik menüyü hızlandırabilir; fakat fiyat ve stok için bayatlık politikası gerekir. Kritik servislerde izleme; ödeme doğrulama gecikmesi, şubeye iletim, kabul süresi, yazıcı/KDS bağlantısı ve hata kuyruğunu görünür kılmalıdır.

POS, KDS, e-belge, ödeme ve bildirim entegrasyonları

POS entegrasyonunda “API var” cevabı yeterli değildir. Ürün seçenekleri destekleniyor mu? Şube kodları nasıl eşleşiyor? Sipariş oluşturma cevabı kesin mi, asenkron mu? Aynı sipariş tekrar gelirse ne olur? İptal ve iade iki yönlü mü? Test ortamı ile gerçek sürüm aynı mı? API kota ve destek sorumlusu kim? Bu sorular bir teknik ispat çalışmasında erken denenmelidir.

KDS veya yazıcı için istasyon yönlendirmesi, bağlantı kopması, tekrar baskı, iptal işareti ve sipariş numarası test edilir. Yazıcıya gönderildi bilgisini “mutfak gördü” olarak yorumlamak risklidir; mümkünse alındı/işleme başladı sinyali oluşturulur. Entegrasyon yoksa şube tabletinin çevrimdışı/uyarı davranışı ve merkez alarmı güçlendirilir.

E-belge gereksinimi işletmenin mükellefiyet ve kanal yapısına göre mali müşavir ve entegratörle doğrulanır. Geliştirme ekibi güncel şema ve süreçleri resmi GİB e-Belge portalı ile kullanılan özel entegratör dokümanına göre uygular; sabit PDF üretmeyi mevzuat uyumu sanmaz.

Push bildirim sipariş kabulünün tek mekanizması değildir. Firebase Cloud Messaging çapraz platform mesajlaşma sunar, ancak cihaz izinleri ve teslim davranışı göz önünde bulundurulur. Şube ekranında kalıcı bağlantı, düzenli senkron, sesli alarm ve merkez süre aşımı birlikte çalışabilir.

Ödeme güvenliği ve mağaza kuralları

Kart bilgisi restoran uygulaması veya backend loglarında dolaşmamalıdır. Yetkili ödeme sağlayıcısının mobil SDK/hosted form ve token yaklaşımı kapsamı küçültebilir. PCI Security Standards Council standartları kart verisi güvenliği için birincil referanstır; hangi uyum sorumluluğunun işletme ve sağlayıcıda olduğu uzmanlarla belirlenir. Webhook imzası, tutar/para birimi/sipariş eşleşmesi, tekrar işlem ve iade yetkisi ayrıca test edilir.

Fiziksel yiyecek teslimatı ile uygulama içinde tüketilen dijital içerik aynı mağaza ödeme kuralına tabi olmayabilir. Hedef özellikler ve ödeme akışı güncel Apple App Review Guidelines ve Google Play koşulları üzerinden yayın öncesi doğrulanmalıdır. Mağaza hesapları, ödeme hesabı ve üretim sırları müşteri kuruluşunun kontrolünde olmalıdır.

KVKK ve kullanıcı güveni

Adres, telefon, sipariş geçmişi, konum, alerji notu ve pazarlama tercihi farklı amaçlar taşır. Alerji bilgisini serbest not alanına zorlamak yerine ürün içeriği ve açık seçeneklerle risk azaltılabilir; uygulama tıbbi güvence veriyormuş gibi tasarlanmamalıdır. Teslimat için gereken telefonun kampanya mesajına otomatik dönüştürülmesi doğru değildir. Aydınlatma, işleme şartı ve ticari ileti izinleri hukuki danışmanlıkla ayrıştırılır.

Rol bazlı erişim sayesinde şube yalnız kendi siparişini, kurye yalnız atanmış teslimatı, destek yalnız çözüm için gereken alanları görür. Yönetici MFA'sı, cihaz/oturum kapatma, adres ve telefon maskeleme, denetim izi, şifreli aktarım, sır yönetimi, yedek ve geri yükleme testi beklenir. Hata izleme veya analitik sistemine sepet notu ve adres gibi kişisel veriler gelişigüzel gönderilmemelidir. Hesap silme ve veri talebi uygulama/panel sürecine bağlanır.

Maliyet ve süre: menü sayısı tek başına ölçü değildir

Tek şube ve sınırlı menü ile çok marka/çok şube/franchise; farklı ürünlerdir. Maliyet yüzeylerini müşteri mobil uygulaması, mobil web, yönetim paneli, şube tablet/KDS ve kurye uygulaması oluşturur. Ürün seçenek modeli, fiyat/stok senkronu, kampanya motoru, teslimat bölgesi, ödeme, POS, KDS, kurye, e-belge ve CRM bağlantıları eforu değiştirir. Mevcut verinin temizliği ve entegrasyon sağlayıcısının desteği de tahmine dahil edilir.

Ölçek hedefi geliştirme yaklaşımını etkiler: eşzamanlı kullanıcıdan çok kampanya anındaki menü ve ödeme piki önemlidir. Çoklu dil, erişilebilirlik, özel animasyon, fotoğraf işleme, analitik, güvenlik testi ve mağaza optimizasyonu ayrıca kapsamlandırılır. Üçüncü taraf lisans ve kullanım ücretleri aylık sipariş örnekleriyle işletme maliyeti olarak gösterilir.

Takvim keşif ve menü veri modelini, UX/UI, teknik entegrasyon ispatını, geliştirmeyi, test ortamı onaylarını, şube eğitimini, pilotu ve mağaza yayınını ayrı gösterir. POS veya ödeme tarafındaki ticari sözleşme gecikmesi uygulama ekibinin kod yazma hızından bağımsızdır. Teklif, müşteri tarafından sağlanacak menü, fotoğraf, politika, test hesabı ve geri bildirim sürelerini varsayım olarak belirtmelidir.

Sözleşmede adı geçmesi gereken teslimatlar

Ürün kapsamı ve kabul kriterleri; rol/yetki tablosu; sipariş durum diyagramı; menü/seçenek veri modeli; müşteri, şube ve yönetim prototipleri; UI tasarım sistemi; mobil/web/backend kaynak kod depoları; API ve entegrasyon belgeleri; altyapı ve ortam tanımları; otomatik testler; yük ve güvenlik test sonuçları; analitik olay sözlüğü; mağaza paketleri; izleme-uyarı paneli; yedekleme/geri yükleme planı; şube/merkez eğitimleri; bakım ve olay müdahale modeli teslimat listesinde olmalıdır.

Kabul senaryoları gerçek ürün kombinasyonlarıyla yürütülür. Zorunlu ekstra seçilmeden sepete gidilememeli; tükenen malzemeye bağlı ürün satılmamalı; eski istemci fiyatı sunucuda düzeltilmeli; çift dokunuş tek sipariş üretmeli; şube zamanında cevaplamazsa müşteri ve merkez doğru durumu görmeli; iptal mutfağa ve ödemeye ulaşmalı; POS kesintisinde sipariş kaybolmamalı; yetkisiz şube başka şubenin müşterisini açamamalıdır.

KPI panosu: ciro ile operasyon gerçeğini bağlayın

Edinim tarafında uygulama indirme değil, kaynak → menü görüntüleme → ürün ekleme → ödeme başlatma → başarılı ilk sipariş izlenir. Menü araması sonuçsuz kalıyorsa içerik veya stok sorunu olabilir. Sepet terkini ödeme hatası, teslimat ücreti, minimum sepet, slot yokluğu ve arayüz adımlarına göre ayrıştırmak gerekir.

Operasyonda şube kabul süresi, ret ve nedenleri, planlanan/gerçek hazırlık, kurye bekleme, zamanında teslim, yanlış/eksik ürün, iade ve destek oranı ölçülür. Büyümede 30/60/90 günlük tekrar sipariş, siparişler arası süre, sadakat yükümlülüğü, kuponun artımlı etkisi ve kanal bazlı katkı marjı değerlidir. Yalnız brüt sipariş tutarı; indirim, ödeme, kurye ve iade maliyetini saklayabilir.

Her olayın sahibi ve kesin anı tanımlanır. “Sipariş tamamlandı” mutfak hazır olduğunda mı, kurye tesliminde mi gönderiliyor? Kampanya atfı hangi pencereyle yapılıyor? Test siparişleri rapordan nasıl ayrılıyor? Veri sözlüğü olmadan panodaki hassas grafikler yanlış karar üretebilir.

En pahalı hatalar ve önlemleri

• Menü kaynak çatışması: POS ve panel aynı ürünü değiştirir. Alan sahipliği ve senkron yönü belirlenir.
• Şube kapasitesini yok saymak: Sipariş alınır ama üretilemez. Dinamik hazırlık, geçici kanal kapatma ve merkez uyarısı kurulur.
• Push'a güvenmek: Şube cihazı bildirimi kaçırır. Kalıcı sipariş kuyruğu, ses, polling/bağlantı ve SLA alarmı birlikte kullanılır.
• Kampanya kombinasyon patlaması: İndirimler beklenmeyen biçimde üst üste gelir. Öncelik, birleşme, bütçe ve test matrisi yazılır.
• Gizli entegrasyon bağımlılığı: POS güncellemesi siparişleri durdurur. Sürüm izleme, kuyruk ve manuel fallback planlanır.
• Sahte kesin tahmin: Müşteriye 18 dakika denir, şube yoğunluğu bilinmez. Güvenli pencere ve gerçek süre geri beslemesi kullanılır.
• Edinim planının olmaması: Uygulama mağazada bekler. Paket, QR, web ve izinli tekrar iletişim yolculuğu lansman planına eklenir.

Teklif brief'inde bulunması gereken veriler

Marka ve şube yapısını; servis kanallarını; hizmet bölgeleri ve saatlerini; günlük ve zirve sipariş hacmini yazın. Menüden gerçek örnekler verin: varyant, ekstra, set, alerjen, şube fiyatı ve stok kapatma. Müşteri, şube, mutfak, kurye, merkez, pazarlama, destek ve finans rollerinin yetkilerini belirtin.

Sipariş kabul/ret, hazırlık, iptal, iade, eksik ürün, şube değiştirme, planlı sipariş ve destek senaryolarını açıklayın. Ödeme türleri, kupon/sadakat kuralları, teslimat ücreti/minimum sepet, kurye modeli ve e-belge akışını ekleyin. POS/KDS/ERP/CRM/ödeme/kurye sağlayıcılarının isim, doküman ve test erişim durumunu paylaşın. Mevcut menü ve müşteri verisi, hedef KPI, pilot şube, içerik sorumluları ve mağaza hesaplarını da yazın.

Keşiften lansmana önerilen süreç

Birinci aşamada menü ve sipariş “operasyon masası” yapılır; bir yoğun saat siparişi kalem kalem yürütülür. İkinci aşamada müşteri sepeti ile şube/mutfak ekranı aynı prototip testinde bağlanır. Üçüncü aşamada POS veya ödeme gibi en riskli entegrasyon için küçük teknik ispat tamamlanır. Böylece bütçe, bilinmeyen API üzerine kurulmaz.

Geliştirme, tek şubede uçtan uca sipariş; sonra ürün istisnaları ve ödeme; ardından şube/kurye ve kampanya gibi dikey dilimlerle ilerleyebilir. Otomatik testler fiyatlama, kupon, durum geçişi ve yetkiyi korur. Pilot kontrollü şube, menü ve müşteri grubunda gerçek yoğun saati kapsar. Eğitim ve destek masası açılmadan genel lansman yapılmaz. Yayın sonrası ürün kararı dönüşüm kadar mutfak ve kurye KPI'larına dayanır.

Sık sorulan sorular

Uygulama pazaryeri komisyonunu tamamen ortadan kaldırır mı?

Doğrudan kanalın ödeme, kurye, pazarlama, destek ve teknoloji maliyetleri vardır. Kârlılık, pazaryeri komisyonuyla tek kalemde kıyaslanmamalı; müşteri edinme ve tekrar sipariş dahil katkı marjı hesaplanmalıdır. Pazaryeri ve doğrudan kanal birbirini tamamlayabilir.

QR menü ile masadan sipariş aynı projede olabilir mi?

Olabilir; fakat masa, açık hesap, servis çağrısı, mutfak yönlendirmesi ve ödeme akışı paket servisten farklıdır. Aynı menü çekirdeğini paylaşırken sipariş kanalı ve durumları ayrıştırılmalıdır. Masaya sipariş gerçek öncelik değilse ilk sürümü büyütmemelidir.

Farklı şubelerde farklı fiyat gösterilebilir mi?

Evet. Veri modelinde merkezi ürün kimliği ile şube-kanal fiyatı ayrılır. Kullanıcının aktif şubesi değiştiğinde sepet yeniden doğrulanır; sessiz fiyat değişimi yerine açık uyarı verilir. Kampanyanın merkez mi şube mi tarafından finanse edildiği finans kaydına yansır.

Sipariş kabul edilmeden mutfağa yazdırılmalı mı?

İşletme modeline göre değişir. Otomatik kabul güvenilir stok ve kapasite ister; manuel kabul bekleme yaratır. Yazdırma veya KDS'ye düşürme anı, ödeme kesinliği ve iptal maliyeti birlikte kararlaştırılır. Pilot verisi en doğru politikayı gösterir.

Uygulama yayınlandıktan sonra hangi ekip gerekir?

Teknik bakımın yanında menü içeriği, şube eğitimi, müşteri desteği, kampanya, analitik ve entegrasyon operasyonu sahipleri gerekir. Acil sipariş kesintisi ile yeni özellik talebi farklı süreçlerde yönetilmelidir. Sağlayıcı ve işletme sorumluluk matrisi lansman öncesi hazırlanır.

Sonuç: sipariş kanalını müşteri ekranı ve mutfak arasında birlikte kurun

Restoran uygulamasında büyüme, müşteriye daha çok buton vermekten değil; doğru menüyü hızlı göstermenin, şubeye üretilebilir sipariş göndermenin ve tekrar siparişi ölçülebilir biçimde kolaylaştırmanın birleşiminden gelir. Kapsam çalışmasına bir örnek menü, yoğun saat videosu ve son dönemdeki iptal/şikâyet nedenleriyle başlamak teknolojiyi gerçek darboğaza bağlar.

MobiCraft ile görüşmede şube yapınızı, menü örneğinizi ve mevcut POS/kurye akışınızı paylaşabilirsiniz. Müşteri uygulaması, mobil web, şube-mutfak araçları ve merkez panelini aynı sipariş yaşam döngüsü üzerinde planlayıp yatırımınızı aşamalara ayırabiliriz. Restoran sipariş projeniz için görüşme başlatın.