Restoran Mobil Uygulaması: Sipariş, Sadakat, QR Menü

Restoran mobil uygulaması pazaryeri komisyonunu ortadan kaldırmaz; komisyonu zaten sizi tanıyan müşteride ödemeyi bırakmanızı sağlar. 2026 koşullarında anlamlı bir kurulum sipariş, ödeme, sadakat ve POS entegrasyonunu birlikte ister ve aşağıdaki örnek senaryoda ayda 250-650 tekrar sipariş bandında kendini amorti eder.

Bu cümlenin iki yarısı da önemli. Sektör içeriğinin büyük kısmı ilk yarıyı abartıp ikinci yarıyı hiç yazmıyor: "komisyondan kurtul, kendi uygulamanı yap" denir, uygulamanın kendi maliyeti, pazarlama yükü ve kurye problemi atlanır. Oysa bir platform size iki ayrı şey satar — talep ve lojistik. Kendi uygulamanız ikincisini devralabilir, birincisini ancak kısmen devralır.

Bu rehber restoran sahibi gözünden yazıldı: hangi modülün hangi problemi çözdüğü, siparişin mutfağa düşene kadar nerede kırıldığı, sadakat programının hangi kurguda gerçekten tekrar satın alma ürettiği ve bütçenin kalem kalem nereye gittiği.

İçindekiler

• Komisyon Matematiği: Uygulama Ne Zaman Kendini Amorti Eder
• Platform Keşif Kanalı, Uygulama Tekrar Kanalı
• Rekabet Kurulu Kayıtlarında Platform Bağımlılığı
• Sipariş Modülü: Menü, Sepet ve Teslimat Bölgesi
• Ödeme Kurulumu ve Yemek Kartı Gerçeği
• POS Entegrasyonu: Siparişin Mutfağa Düşmesi
• Sadakat Programı: Puan Tiyatrosu mu, Davranış Değişimi mi
• QR Menü, Web Sipariş ve Mobil Uygulama Arasındaki Fark
• Zincir ve Tek Şube Aynı Uygulamayı Kullanmaz
• Örnek Maliyet Çerçevesi ve Kalem Kalem Bütçe
• Yayın Sonrası 90 Gün: Kurulum Değil Dolaşım
• Yayına Almadan Önce 10 Maddelik Kontrol Listesi

Komisyon Matematiği: Uygulama Ne Zaman Kendini Amorti Eder

Komisyon tartışmasının tamamı tek bir soruya indirgenir: 350 TL'lik bir sepetten kasanıza ne kadarı giriyor? Platform oranları sözleşmeye, şehre, kurye modeline ve sipariş hacmine göre değişir; hiçbir platform oranını kamuya açık biçimde yayımlamıyor. 2026 piyasa rehberlerinde aktarılan bantlar, kendi kuryesiyle çalışan restoranlarda yüzde 10-14, platform kuryesi kullanıldığında yüzde 28-38 civarında. Kesin oranı yalnızca kendi sözleşmeniz söyler; bu tabloyu bir kıyas çerçevesi olarak okuyun.

Tablonun söylediği şey şu: en büyük kazanç gel-al ve masada ödeme tarafında. Teslimatlı siparişte kendi kuryenizi çalıştırdığınızda tasarruf ciddi biçimde erir, çünkü platformun yüzde 32'si karşılığında aldığınız şeyin önemli bir kısmı gerçekten kurye.

Amorti hesabını somutlaştıralım. Varsayımlar: ortalama sepet 350 TL, uygulamanın ilk yıl geliştirme bütçesi 450.000 TL, yıllık işletme gideri 60.000 TL, geliştirmeyi 24 aya yayıyoruz. Aylık yük ≈ 23.750 TL.

• Gel-al ağırlıklı kurgu: platformdan kayan her siparişte ~98 TL kalıyor (105 TL komisyon eksi ~7 TL sanal POS). Başabaş ≈ ayda 243 sipariş, yani günde 8.
• Teslimatlı kurgu: sipariş başına net kazanç ~38 TL'ye iniyor. Başabaş ≈ ayda 625 sipariş, yani günde 21.

Bu iki sayı arasındaki üç katlık fark, bir restoran mobil uygulamasının neyi taşıdığına göre kârlı ya da zararlı olduğunu gösteriyor. Teslimatta platformla yarışmak zorsa, uygulamayı önce gel-al, masa siparişi ve sadakat üzerine kurun; teslimatı ikinci fazda açın.

Gerçek hayatta kanallar karışır ve hesap da karışık olur. Günde 60 sipariş alan bir işletme düşünün: 25'i masada, 20'si platform üzerinden teslimat, 15'i telefonla gel-al. Bir restoran mobil uygulaması bu tablonun tamamını değiştirmez; önce telefonla alınan 15 siparişi dijitalleştirir (personel zamanı ve yanlış sipariş kaybını azaltır), sonra platformdaki 20 siparişin tekrar eden kısmını kendi tarafına çeker. İlk aydan sonra platform siparişlerinin yarısı kendi kanalınıza kayarsa, yukarıdaki teslimat senaryosunda ayda 10 sipariş/gün × 38 TL ≈ 11.400 TL net kazanç çıkar — tek başına amorti etmez, ama masa ve gel-al tarafındaki kazançla toplandığında eşiği geçer.

Hesabı kendi sayılarınızla kurmanın tek doğru yolu şu üç girdiyi ölçmek: ayda kaç farklı müşteri ikinci kez sipariş veriyor, ortalama sepetiniz ne, platform oranınız kaç. Kendi varsayımlarınızla oynamak için mobil uygulama maliyet hesaplayıcısını kullanabilirsiniz.

Platform Keşif Kanalı, Uygulama Tekrar Kanalı

Platformdan tamamen çıkma kararı çoğu işletme için yanlış karar. Doğru kurgu şu iş bölümü: platform sizi yeni müşteriye tanıtır, uygulama o müşteriyi ikinci kez getirir.

Rakamlar bu ayrımı destekliyor. ABD'de Ulusal Restoran Birliği'nin 2026 sektör raporuna göre teslimat müşterilerinin yüzde 75'i son altı ayda üçüncü taraf bir platformdan sipariş verdi — ama aynı kişilerin yüzde 56'sı tercih hakkı olsa doğrudan restorandan sipariş etmeyi seçeceğini söylüyor. Aynı rapor daha çarpıcı bir veri veriyor: tüketicilerin yüzde 74'ü restoran sunarsa telefonundaki bir uygulamadan sipariş verip ödeme yapacağını belirtiyor; bu oran 30-45 yaş aralığında yüzde 89'a çıkıyor, 62 yaş üstünde yüzde 54'e iniyor.

Yani talep var ve talebin yönü doğrudan kanaldan yana. Eksik olan şey altyapı. Burada kritik ayrımı yapalım:

• Keşif (yeni müşteri): platform listelemesi, Google aramaları, haritalar, sosyal medya. Bu kanalların maliyeti komisyon ya da reklam bütçesi olarak çıkar.
• Tekrar (mevcut müşteri): uygulama, push bildirim, sadakat bakiyesi, kayıtlı adres ve kayıtlı kart. Bu kanalın marjinal maliyeti neredeyse sıfır.

İkinci gruptaki müşteriyi platformda tutmak, tanıtım için bir kez ödediğiniz bedeli her ay yeniden ödemek demek. Bir restoran mobil uygulamasının asıl işi tam burada: aynı müşteriyi ikinci, beşinci ve yirminci kez komisyonsuz getirmek.

Platformun size vermediği bir şey daha var: müşteri verisi. Platform üzerinden gelen siparişte kim ne sipariş etti, ne sıklıkla geldi, hangi kampanyaya tepki verdi bilgisi büyük ölçüde platformda kalır. Kendi kanalınızda bu verinin sahibi sizsiniz; menü kararlarını, stok planını ve kampanya zamanlamasını buna göre kurabilirsiniz. Veri sahipliği, komisyon tasarrufundan daha az konuşulan ama uzun vadede daha değerli olan kazanç. Aynı mantığı otel tarafında komisyonsuz rezervasyon alan otel web sitesi yazısında ayrıntılandırdık; restoranda değişen tek şey, sepetin küçük ve sıklığın yüksek olması — bu da uygulamayı otelden daha mantıklı hale getiriyor.

Rekabet Kurulu Kayıtlarında Platform Bağımlılığı

Platform bağımlılığı bir his değil, kayda geçmiş bir rekabet sorunu. Rekabet Kurulu'nun 28.01.2021 tarihli ve 21-05/64-28 sayılı kararına konu olan soruşturmada incelenen iddialar şunlar: restoranlara uygulanan fiili münhasırlık, en çok kayrılan müşteri koşulları, zorunlu kampanya katılımı, zorunlu minimum sepet tutarı, listeleme bedeli ve yüksek komisyon oranlarına yönelik aşırı fiyatlama. Soruşturma, ilgili platformun bu uygulamalara son verme taahhüdünün bağlayıcı hale getirilmesiyle kapandı.

Bir yıl sonraki 18.05.2022 tarihli ve 22-23/366-155 sayılı Kurul kararında ise rakip bir platformun şikâyeti reddedildi. O kararın gerekçesi işletmeci açısından okunmaya değer: dosyada tekil restoranlara uygulanan komisyon oranlarının zincir restoranlardakinden belirgin biçimde yüksek olduğu iddiası yer alıyor — oranlar ticari sır olarak gizlenmiş. Karar ayrıca münhasırlık uygulamalarının restoranın birden fazla platformda bulunma (multi-homing) güdüsünü zayıflattığını tartışıyor.

Kurul kararlarının işletmeciye söylediği şey şu: platform sözleşmesi müzakere edilebilir bir metindir ve müzakere ettiğiniz şey yalnızca komisyon oranı değildir. Sözleşmede şu başlıklara bakın: kampanya katılımı zorunlu mu, kampanya indirimini kim finanse ediyor, listeleme veya öne çıkarma bedeli ayrı mı faturalanıyor, komisyon kampanyalı fiyat üzerinden mi yoksa liste fiyatı üzerinden mi hesaplanıyor, ödeme vadesi kaç gün. Ödeme vadesi özellikle kritik: 30 günlük vade, nakit akışı dar bir mutfakta komisyonun kendisi kadar maliyet üretir.

Buradan iki pratik sonuç çıkar. Birincisi, tek şubeli bir işletme olarak muhtemelen pazarlık masasının zayıf tarafındasınız; zincir oranlarını referans alan içerikler sizin tablonuzu yanlış kuruyor. İkincisi, kendi kanalınız bir pazarlık kozudur: sipariş hacminizin bir kısmı kendi uygulamanızdan geliyorsa, sözleşme yenilemesinde oran konuşmanız somut bir dayanağa oturur.

Sipariş Modülü: Menü, Sepet ve Teslimat Bölgesi

Sipariş modülü bir restoran mobil uygulamasının kalbi ve en çok küçümsenen parçası. Menüyü ekrana basmak kolay; menüyü mutfağın gerçekten üretebileceği biçimde ekrana basmak zor.

Dikkat edilmesi gereken yedi nokta:

1. Seçenek ve zorunlu seçim mantığı. "Orta boy pizza + iki malzeme + içecek seçimi" gibi kurgular fiyatı dinamik hesaplar. Bu kuralları sonradan eklemek, baştan tasarlamaktan kat kat pahalı.
2. Stok ve tükenen ürün. Akşam 21.00'de bitmiş olan ürün menüden düşmezse her sipariş bir iptal çağrısına dönüşür.
3. Teslimat bölgesi ve minimum sepet. Poligon bazlı bölge tanımı, mahalle listesinden çok daha az tartışma üretir. Bölge başına ayrı teslimat ücreti ve ayrı minimum sepet tanımlayabilmek gerekir.
4. Hazırlık süresi ve yoğunluk. Mutfak doluysa uygulamanın verdiği süre otomatik uzamalı. Sabit "30-40 dakika" yazan uygulama, ilk yoğun cumartesi akşamında puanını kaybeder.
5. Zamanlı sipariş. Öğle yemeği siparişini saat 10.00'da alıp 12.15'e planlayabilmek, ofis çevresindeki restoranlarda tek başına sadakat üretir.
6. Masa ve gel-al ayrımı. Üç farklı akış var: masada sipariş (QR ile), gel-al ve teslimat. Üçü aynı sepet ekranını paylaşır ama farklı doğrulama kuralları ister.
7. Adres doğruluğu. Harita üzerinden pin, kat ve kapı notu alanları, kayıtlı adresler. Hatalı adres kuryeyi değil marjınızı yakar.

Konum, rota ve teslimat takibi gereksinimlerinin teknik tarafını konum tabanlı uygulama geliştirme yazısında ayrıca ele aldık.

Ödeme Kurulumu ve Yemek Kartı Gerçeği

Ödeme tarafında üç kararı aynı anda vermeniz gerekir: hangi yöntemleri kabul edeceksiniz, parayı kim tahsil edecek ve mağaza komisyonu devreye girer mi.

Yöntem seti. Kayıtlı kart, kapıda nakit, kapıda kart, yemek kartı ve dijital cüzdan. Türkiye'de yemek kartı restoran siparişinde ciddi bir hacim tutuyor ve burada işletme lehine net bir hüküm var: 22 Mayıs 2018 tarihli ve 30428 sayılı Resmî Gazete'de yayımlanan değişiklikle Perakende Ticarette Uygulanacak İlke ve Kurallar Hakkında Yönetmelik'e eklenen 12/A maddesi, yemek kartı kuruluşlarının anlaşmalı işletmelere uygulayacağı komisyon oranını yüzde altı ile sınırlıyor. Aynı madde, "uygulama barındırma, kira, sarf malzemesi, işletim, teknik destek, bakım bedeli ve depozito gibi adlar altında" ek bedel talep edilmesini de yasaklıyor. Maddenin birebir metni Resmî Gazete'de yayımlı. Yemek sipariş platformlarının komisyonu için böyle bir yasal tavan yok — fark tam olarak buradan doğuyor.

Tahsilat modeli. Uygulama içi dijital ürün satmıyorsunuz, fiziksel bir hizmet satıyorsunuz; dolayısıyla mağaza içi satın alma mekanizması yerine sanal POS ile çalışırsınız. Bu ayrımın mağaza kuralları açısından nedenini ödeme entegrasyonu rehberinde, banka ve ödeme kuruluşu oranlarının 2026 tablosunu ise sanal POS komisyon oranları yazısında bulabilirsiniz.

Teslimat ücreti şeffaflığı. Kendi kanalınızda teslimat ücretini gizlemeye çalışmak pahalıya gelir. Müşteri sepet ekranında ürün tutarı, teslimat ücreti ve varsa servis bedelini ayrı ayrı görmezse siparişi terk eder; terk edilen sepet oranı, doğrudan kanalın en büyük sessiz kaybı. Pratik kural: teslimat ücretini menü fiyatına gömmek yerine açık yazın ve belirli bir sepet tutarının üzerinde sıfırlayın — bu, hem sepet büyütür hem de platform fiyatlarıyla karşılaştırmayı sizin lehinize çevirir.

Yasal kurulum. Uygulamadan ön ödemeli sipariş alıyorsanız mesafeli satış mevzuatının ön bilgilendirme ve iptal hükümleri devreye girer; iade ve iptal kurallarınızı, teslimat bölgenizi ve çalışma saatlerinizi uygulama içinde okunur biçimde göstermeniz gerekir. Müşteri adresi, telefonu ve sipariş geçmişi kişisel veridir: saklama süresi, silme akışı ve veri işleme dayanağı yazılımın mimarisine girmeli — KVKK uyumlu yazılım geliştirme yazısı bu katmanı veri modeli düzeyinde anlatıyor.

POS Entegrasyonu: Siparişin Mutfağa Düşmesi

Projelerin en sık kırıldığı yer burası. Uygulama çalışır, ödeme geçer, müşteri mutludur — ama sipariş adisyon sisteminize düşmez. Sonuç: kasiyer siparişi elle giriyor, akşam yoğunlukta sıra karışıyor, ürün eşleşmeleri bozuluyor ve ciro raporu ikiye yarılıyor.

Doğru kurgu iki yönlü bir eşleşmeye dayanır. Menü, ürün ve seçenek ağacı POS tarafındaki kataloğa birebir bağlanır; sipariş ise POS'un sipariş servisine yazılır. Bu modeli adı geçen hazır sistemler de aynı şekilde kuruyor: örneğin bir POS sağlayıcısının Orders API dokümantasyonu siparişi tek merkezde toplama, kataloğu programatik eşleştirme ve kanalları birleştirme çerçevesini açıkça tanımlıyor.

Entegrasyonda cevaplanması gereken sorular:

• POS'unuzun açık bir API'si var mı, yoksa yalnızca dosya aktarımı mı sunuyor?
• Ürün eşleştirmesi ne sıklıkla senkronize olacak? Menü fiyatını POS'tan mı, uygulamadan mı yöneteceksiniz? (Tek doğruluk kaynağı seçin; iki yerden fiyat yönetmek kaçınılmaz olarak tutarsızlık doğurur.)
• Sipariş POS'a yazılamazsa ne olacak? Kuyruk, yeniden deneme ve sesli uyarı tanımlı mı?
• Mutfak ekranı (KDS) ya da yazıcı akışı siparişi hangi formatta bekliyor?
• İade ve iptal POS tarafında da düzeltme üretiyor mu?

Entegrasyon kavramına genel bir giriş arıyorsanız API entegrasyonu yazısı temel terimleri açıklıyor. Pratik tavsiye: bir restoran mobil uygulaması projesinde POS entegrasyonunu ikinci faza bırakmayın. Birinci fazda elle giriş ile yaşayacağınızı düşünürsünüz; gerçekte mutfak ekibi uygulamayı sabote eder, çünkü iş yükünü artırır.

Sadakat Programı: Puan Tiyatrosu mu, Davranış Değişimi mi

Sadakat modülü bir restoran mobil uygulamasının en kolay yazılan, en kötü kurulan parçası. "Her 100 TL'ye 5 puan" tipi bir kurgu teknik olarak iki günde biter ve davranışı hiç değiştirmez.

Sadakatin işe yaradığına dair veri güçlü. Ulusal Restoran Birliği'nin aynı 2026 raporunda, teslimat siparişi veren müşterilerin yüzde 70'i bir sadakat ve ödül programına üye olmasının restoran seçiminde önemli olduğunu söylüyor; gel-al tarafında bu oran yüzde 65. 30-45 yaş grubunda teslimat için oran yüzde 77'ye çıkıyor. İşletmeci tarafında da fark görünür: sınırlı servisli restoranların yüzde 60'ı teknolojinin sadakat programlarına belirgin etkisi olduğunu söylerken, tam servisli restoranlarda bu oran yüzde 33'te kalıyor.

Çalışan kurgular genellikle şu dördünden biri:

• Sıklık odaklı: "Beşinci kahve bizden." Günlük alışkanlık ürünlerinde (kahve, börek, öğle menüsü) en güçlü mekanizma; çünkü ödülü hak etme süresi kısa.
• Sepet büyütme odaklı: belirli eşiği geçen siparişe tatlı veya içecek. Marjı yüksek ürünü ödül yapın, maliyeti düşük olanı değil.
• Zaman kaydırma odaklı: ölü saatlerde çift puan. Mutfağı dengeler, kapasiteyi ücretsiz büyütür.
• Geri kazanma odaklı: 45 gün sipariş vermeyen müşteriye tek kullanımlık teklif. En yüksek getirili ve en az kurulan kurgu.

İki teknik şart: bakiye her ekranda görünmeli ve ödül tek dokunuşla sepete eklenebilmeli. Kullanıcıya kupon kodu ezberletmek sadakat değil sürtünme üretir. Hatırlatma tarafının izin, sıklık ve zamanlama dengesini push bildirim stratejisi yazısında ayrıntılı kurguladık — yemek kategorisinde bildirim saatinin yanlış seçilmesi, uygulamanın silinmesinin bir numaralı sebebi.

QR Menü, Web Sipariş ve Mobil Uygulama Arasındaki Fark

Üçü aynı şey değil ve çoğu işletme yanlış olanı satın alıyor. Problemi doğru adlandırmak bütçenin yarısını kurtarır.

Doğru sıralama genellikle QR menü → web sipariş → restoran mobil uygulaması biçiminde ilerler. Ters sıra, yani henüz tekrar eden müşterisi olmayan bir işletmenin doğrudan uygulamaya girmesi, indirilmeyen bir uygulamaya ödeme yapmak anlamına gelir.

QR menünün bir inceliği var: masada sipariş alma özelliği eklendiğinde bu artık menü değil, sipariş kanalıdır ve POS entegrasyonu ihtiyacı aynen doğar. Bir diğer incelik, QR menünün uygulama yükleme kanalı olarak kullanılabilmesi: masadaki müşteriye bakiye ve ilk sipariş avantajı gösteren bir ekran, reklam bütçesiyle elde edilen kurulumdan kat kat ucuza gelir.

Zincir ve Tek Şube Aynı Uygulamayı Kullanmaz

Tek şubeli bir restoranla sekiz şubeli bir zincirin restoran mobil uygulaması ad olarak aynı, mimari olarak farklıdır. Fark maliyetin de büyük kısmını açıklar.

Tek şube için gerekenler: tek menü, tek teslimat bölgesi, tek kasa, tek çalışma saati. Sadakat bakiyesi tek yerde harcanır. Bu kurgu sade bir arka yüz paneliyle yönetilir.

Çok şube için devreye giren katmanlar: şube seçimi ve en yakın şube mantığı, şube bazlı fiyat farkı, şube bazlı stok ve çalışma saati, siparişin doğru şubeye yönlenmesi, şubeler arası sadakat bakiyesi geçerliliği, franchise sahipleri için ayrı raporlama ve yetki. Her biri ayrı bir ekran ve ayrı bir kural seti.

Pratikte şube sayısı üçü geçtiğinde şu karar düğümü gelir: merkezî menü mü, şube serbestliği mi? Merkezî menü tutarlılık verir ama şubenin yerel kampanya yapmasını engeller. Hibrit kurgu — merkezden kilitli ürün seti, şubeye açık kampanya alanı — en çok çalışan modeldir, ama yetki matrisini baştan tasarlamayı gerektirir. Yetki matrisini sonradan eklemek, kullanıcı rollerini ve tüm yönetim ekranlarını yeniden yazmak anlamına gelir; bu da çok şubeli projelerde en pahalı geriye dönük değişiklik kalemi.

Örnek Maliyet Çerçevesi ve Kalem Kalem Bütçe

Bir restoran mobil uygulaması tek bir kalem değil, yedi ayrı yapım kaleminin toplamı. Aşağıdaki bantlar Master Web'in kendi proje çerçevesinden çıkan gösterge aralıklarıdır; piyasa ortalaması iddiası taşımaz. Kapsam, entegrasyon sayısı ve tasarım derinliği bu aralıkları her iki yöne de kaydırır.

İşletme tarafında yıllık yinelenen kalemler: sunucu ve bildirim altyapısı, geliştirici hesapları, sanal POS sabit ücretleri, bakım ve mağaza uyum güncellemeleri. Bu kalemin büyüklüğünü küçümsememek gerekir; tipik olarak ilk yıl geliştirme bütçesinin yüzde 15-20'si bandında seyreder ve nedenleri mobil uygulama bakım maliyeti yazısında kalem kalem açıklanıyor.

Pazar tarafı bu bütçeyi haklı çıkarabilecek büyüklükte. Deloitte'un "Türkiye Yemek Hizmeti Pazarı" raporuna göre 2021'de 144 milyar TL olan pazarın 2026'da 770 milyar TL'yi aşması bekleniyordu; aynı raporda fast food ve eve servis segmentinin 2023-2026 arasında yaklaşık yüzde 100 büyüyerek 312 milyar TL'ye ulaşması öngörülüyor. Eve servis tarafının pazarın en hızlı büyüyen parçası olması, doğrudan kanalın stratejik değerini artırıyor.

Yayın Sonrası 90 Gün: Kurulum Değil Dolaşım

Uygulama yayınlandığında iş bitmez; asıl iş başlar. Bir restoran mobil uygulamasında başarısızlığın birinci sebebi kötü yazılım değil, indirilmemiş uygulama.

İlk 90 günün üç hedefi var:

Kurulum (1-30. gün). En ucuz kurulum kanalı masanın kendisi: QR kod, kasa ekranı, paket servis poşetine konan kart, kuryeyle giden tek sayfa. İlk sipariş avantajını kurulumun karşılığı olarak konumlandırın. Mevcut müşteri listesine SMS veya e-posta ile duyuru, reklam bütçesinden önce gelir.

İkinci sipariş (30-60. gün). Tek siparişlik kullanıcı değersizdir. Birinci siparişten sonra tetiklenen tek bir hatırlatma ve bakiye bildirimi, ikinci sipariş oranını belirleyen temel mekanizmadır. Burada ölçeceğiniz metrik indirme sayısı değil, ikinci sipariş oranı.

Alışkanlık (60-90. gün). Haftalık aktif kullanıcı, sipariş sıklığı, kanal başına ortalama sepet ve platformdan kayan sipariş yüzdesi. Bu dördü ölçülmüyorsa amorti hesabını yapamazsınız. Hangi metriğin nasıl kurulacağını mobil uygulama analitiği yazısında on metrik üzerinden anlattık.

Kurulum ikna etmenin üç kaldıracı var ve üçü birlikte çalışır: kurulum anındaki somut avantaj (ilk siparişte indirim, hazır bakiye, bedava içecek), kurulumun önerildiği yer (masadaki QR kod ve paket poşetindeki kart, reklamdan kat kat ucuz) ve ikinci siparişteki hız (kayıtlı kart ve kayıtlı adresle sipariş iki dokunuşa düşerse müşteri platforma dönmez). Üçüncüsü en çok ihmal edileni: avantajla indirilen ama yavaş çalışan bir uygulama, ilk haftadan sonra telefonda ölü ikon olarak kalır.

Bir uyarı: ilk aylarda uygulamanın kendi kampanyası platformdaki kampanyadan daha iyi olmalı. Aksi halde müşteri fiyatı karşılaştırır ve komisyonlu kanala geri döner. Doğrudan kanalda ödemediğiniz komisyonun bir kısmını müşteriye aktarmak, uzun vadede en kârlı pazarlama harcamasıdır.

Yayına Almadan Önce 10 Maddelik Kontrol Listesi

1. Menü, seçenek ağacı ve fiyatlar POS'taki katalogla birebir eşleşiyor.
2. Sipariş POS'a düşmezse kuyruğa giriyor, personel sesli uyarı alıyor.
3. Tükenen ürün menüden otomatik düşüyor, geri açılabiliyor.
4. Hazırlık süresi yoğunluğa göre esneyebiliyor.
5. Teslimat bölgeleri harita üzerinde tanımlı, bölge başına ücret ve minimum sepet ayrı.
6. Sanal POS canlı testleri tamam: başarılı ödeme, başarısız ödeme, iade, kısmi iade.
7. Yemek kartı ve kapıda ödeme akışları ayrı test edildi.
8. Sadakat bakiyesi her ekranda görünüyor, ödül tek dokunuşla uygulanıyor.
9. Mesafeli satış ön bilgilendirmesi, iptal-iade kuralları ve aydınlatma metni uygulama içinde erişilebilir.
10. Mağaza red sebepleri gözden geçirildi: hesap silme akışı, izin açıklamaları, test hesabı.

Son madde sandığınızdan daha sık sorun çıkarır; mağaza inceleme süreçlerinin tipik red gerekçelerini uygulama reddi nedenleri yazısında topladık.

Sıkça Sorulan Sorular

Restoran mobil uygulaması yaptırmak platform komisyonundan tamamen kurtarır mı?

Hayır. Bir restoran mobil uygulaması, mevcut ve tekrar eden müşterinizden komisyon ödemeyi bitirir; yeni müşteri keşfi için platform, arama ve haritalar kanalları çalışmaya devam eder. Gerçekçi hedef siparişlerin tamamını değil, tekrar eden kısmını kendi kanalınıza taşımaktır.

Kaç siparişten sonra kendi uygulamam kârlı hale gelir?

Bu rehberdeki örnek senaryoda (350 TL ortalama sepet, 450.000 TL geliştirme, 24 ay amorti) başabaş noktası gel-al ağırlıklı kurguda ayda yaklaşık 243, teslimatlı kurguda ayda yaklaşık 625 sipariş. Kendi sepet ortalamanız ve komisyon oranınızla hesap değişir; teslimat maliyetini mutlaka hesaba katın.

QR menü ile mobil uygulama arasındaki fark nedir?

QR menü basılı menünün yerini alır ve masadaki müşteriye menüyü gösterir; sipariş akışı garsonda kalır. Mobil uygulama ise tekrar satın alma kanalıdır: kayıtlı kart, kayıtlı adres, sadakat bakiyesi ve push bildirim sunar. QR menü günler içinde kurulur, uygulama 8-20 hafta sürer.

POS entegrasyonu olmadan sipariş uygulaması çalışır mı?

Teknik olarak çalışır, operasyonel olarak zorlanır. Siparişi personel elle girer; yoğun saatlerde hata ve gecikme artar, raporlar ikiye bölünür. Deneyimimizde entegrasyonsuz kurulumun en büyük riski mutfak ekibinin uygulamayı benimsememesi ve kanalın sessizce ölmesidir.

Restoran sadakat programı hangi kurguda gerçekten çalışır?

Ödülü hak etme süresi kısa olan kurgular çalışır: sıklık bazlı ödül (beşinci kahve), eşik bazlı ürün hediyesi, ölü saatte çift puan ve 45 gün sipariş vermeyen müşteriye geri kazanma teklifi. Yüzdelik indirim biriktiren karmaşık puan sistemleri genellikle davranışı değiştirmez.

Yemek kartı komisyonu için yasal bir üst sınır var mı?

Evet. Perakende Ticarette Uygulanacak İlke ve Kurallar Hakkında Yönetmelik'in 12/A maddesi, yemek kartı kuruluşlarının anlaşmalı işletmelere uygulayacağı komisyon oranını yüzde altı ile sınırlıyor ve barındırma, kira, teknik destek, bakım gibi adlar altında ek bedel alınmasını yasaklıyor. Yemek sipariş platformlarının komisyonu için benzer bir yasal tavan bulunmuyor.

Tek şubeli bir restoran için uygulama yaptırmak mantıklı mı?

Tekrar eden müşteriniz varsa mantıklı, yoksa erken. Günlük alışkanlık ürünü satan (kahve, öğle menüsü, börek) tek şubeli işletmeler, teslimat ağırlıklı çok şubeli işletmelerden daha hızlı amorti eder; çünkü sıklık yüksek ve kurye maliyeti yok.

Uygulamayı iOS ve Android için ayrı ayrı mı yazdırmak gerekir?

Restoran siparişi için cross-platform yaklaşım (tek kod tabanı, iki mağaza) genellikle yeterlidir; sipariş ve ödeme akışları ağır cihaz donanımı kullanmaz. Native geliştirme, gelişmiş teslimat takibi veya yoğun arka plan konum işleme gibi ihtiyaçlar devreye girdiğinde değerlendirilir. İki mağazaya birlikte çıkmak, tek platformla başlayıp sonra ikinciyi eklemekten de ucuza gelir.

Restoran mobil uygulaması kararı teknoloji kararı değil, kanal kararıdır. Önce şu üç sayıyı masaya koyun: aylık tekrar eden müşteri sayısı, ortalama sepet ve platform komisyon oranınız. Bu üç sayı amorti eşiğinizi söyler; eşiğin altındaysanız QR menü ve web sipariş ile başlamak daha kârlı, üstündeyseniz her ay geciktirdiğiniz karar size komisyon olarak fatura ediliyor.

Kurgunuzu konuşmak, mevcut POS'unuzun entegrasyon olgunluğunu değerlendirmek ve kendi sayılarınızla gerçekçi bir amorti tablosu çıkarmak için mobil uygulama geliştirme hizmetimize göz atabilir, menünüz ve şube yapınızla birlikte bize ulaşabilirsiniz.