Cloud POS vs Yerel POS vs Hibrit POS: 32 Kritere Karşılaştırma Matrisi (2026)
📋 Özetle
Cloud POS verisini bulutta tutar, çevrimiçi olunca güçlü; yerel POS her şeyi mağazada tutar, kesintide bile çalışır ama merkezden görünmez; hibrit POS ikisinin avantajını birleştirir. Bu makale her birini 32 kritere göre yan yana koyar, Türkiye saha gerçeğine bakar ve son olarak robotPOS'un seçtiği yolu — yerel-first POS + bulut yönetim + akıllı senkron — gerekçeleriyle açıklar.
Tek cümleyle: Yönetim bulutta yaşar, POS yerelde nefes alır, ikisi arasındaki köprü hem hızlı hem de kesinti toleransıyla çalışır.
1 · POS Mimarisi Neden Bu Kadar Kritik?
POS mimarisi, restoran sahibinin gözünde sıkça "teknik bir detay" olarak görülür. Oysa üç senaryoda bu detay, doğrudan günün cirosunu, müşteri deneyimini ve operasyon disiplinini belirler.
Senaryo A — Cuma akşamı, peak saat, internet kesildi
Saat 20:30. Salon dolu, mutfakta sıralı 18 sipariş, kasada üç kart bekleyen müşteri. O an internet 7 dakika gider. Saf bulut POS'unuz varsa: kasa cevap vermez, KOT mutfağa düşmez, müşteri bekler. Yerel-first bir POS ise: hiçbir şey değişmez, yalnızca o 7 dakikalık satış bağlantı geri gelince merkeze akar.
Senaryo B — 12 şubede aynı anda fiyat değişikliği
Ette tedarikçi fiyatı bu sabah arttı. Menü zammını öğleden önce tüm şubelere yansıtmanız gerekiyor. Saf yerel POS'unuz varsa: 12 şubeye telefon, 12 manuel giriş, 12 fırsat hatası. Bulut yönetim katmanı olan bir POS ise: tek ekrandan değişikliği uygular, 12 şubeye saniyeler içinde dağıtır.
Senaryo C — Gece 23:00, food cost neden yükseldi?
Operasyon direktörü merkezden bakıyor, 4 numaralı şubenin food cost'u %38'e çıkmış. Saf yerel POS ise yarına kadar veri gelmez. Bulut yönetimli bir POS ise aynı anda şube müdürünü açar, son 24 saatin sayım hareketlerini gösterir, sebebi 5 dakikada bulur.
Bu üç senaryonun ortak noktası: kasada esneklik + merkezde anlık görünürlük. Klasik tek-tip mimariler bu ikisini bir arada veremez. Hibrit mimari tam burada doğar.
2 · Üç Mimari Tipi: Net Tanımlar
☁️ Cloud POS (Bulut POS)
Tanım: Verisi tamamen bulut sunucuda tutulan, kasanın tarayıcı veya bulut bağımlı uygulama olarak çalıştığı POS modeli.
Doğal seçim: Tek şube + stabil fiber + düşük hacim + minimum donanım yatırımı isteyen yeni cafeler, sanal marka mutfakları.
Açık zayıflık: İnternet kopunca operasyon durur.
🖥️ Yerel POS (On-Premise)
Tanım: Tüm verisi mağaza içinde fiziksel sunucuda tutulan, internetten bağımsız çalışan klasik POS modeli.
Doğal seçim: İnternet altyapısı zayıf lokasyonlar, KVKK kapsamında verisini tamamen lokalde tutmak isteyen istisnai işletmeler.
Açık zayıflık: Çoklu şube konsolidasyonu, merkezi rapor, uzaktan erişim ek altyapı ister.
⚡ Hibrit POS robotPOS yaklaşımı
Tanım: Kasada yerel-first çalışan, yönetim/raporlamayı bulutta tutan, ikisi arasında akıllı senkron köprüsü kuran çift modlu mimari.
Doğal seçim: Türkiye saha gerçeğinde çoğu işletme — fast food, casual dining, fine dining, çoklu şube zincirleri, otel restoranı.
Açık zayıflık: Doğru kurulmazsa "iki sistemi birden ödemek" gibi hissedilebilir; mimari disiplin önemli.
3 · 32 Kriterli Karşılaştırma Matrisi
Her tabloda 4 kriter, 4 sütun: Cloud POS / Yerel POS / Hibrit POS / robotPOS Yaklaşımı. Hücrelerde ✓ uygun, ⚠ kısıtlı, ✗ uygun değil.
3.1 · Operasyonel Süreklilik
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| İnternet kesintisinde davranış | ✗ Durur | ✓ Etkilenmez | ✓ Yereldeyken devam | ✓ Yerel-first, kesinti şeffaf |
| Maks. offline çalışma süresi | 0 dk | Sınırsız | Saatler / günler | Sınırsız (gün boyu) |
| Recovery sonrası senkron | — | Manuel | Otomatik | Otomatik queue-and-forward |
| Veri kaybı riski (RPO) | ⚠ Bağlantıya bağlı | ⚠ Yedeğe bağlı | ✓ Düşük | ✓ Sıfıra yakın (her satış kalıcı) |
Yorum: Türkiye'de "günde 0 dakika kesinti" varsayımı gerçekçi değildir. Mimarinin ilk testi: kesintide ne yapıyor?
3.2 · Performans (Kasa)
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| Sipariş yazma gecikmesi | ⚠ 200-800 ms | ✓ < 100 ms | ✓ < 100 ms | ✓ Yerel-first → < 100 ms |
| Hesap kapatma süresi | ⚠ Bağlantıya bağlı | ✓ Anlık | ✓ Anlık | ✓ Anlık |
| Çoklu kasa eş anlık | ✓ | ✓ LAN üstünden | ✓ | ✓ LAN + bulut |
| Peak yük dayanımı | ⚠ Sunucu yüküne bağlı | ✓ | ✓ | ✓ Yerel cevap, peak'i hisseder |
Yorum: Ticket time'ı düşürmek istiyorsanız, kasa cevabı ağa değil donanıma bağlı olmalıdır.
3.3 · Kurulum & Bakım
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| Kurulum süresi | ✓ Saatler | ⚠ Günler | ✓ 1-2 gün | ✓ 1-2 gün, kalıp şube taşıma |
| Donanım bağımlılığı | ✓ Düşük | ⚠ Yerel sunucu zorunlu | ⚠ Hafif yerel cihaz | ⚠ Tek mini-sunucu yeterli |
| Yazılım güncelleme | ✓ Otomatik bulut | ✗ Manuel her şube | ✓ Bulut + yerel sync | ✓ Merkezden push |
| BT personeli ihtiyacı | ✓ Düşük | ⚠ Orta-yüksek | ✓ Düşük-orta | ✓ Düşük (servis dahil) |
3.4 · Çoklu Şube & Merkez Yönetimi
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| Yeni şube açma süresi | ✓ Saatler | ⚠ Günler-haftalar | ✓ 1 gün | ✓ Şablon-bazlı, hızlı |
| Merkezden menü/fiyat senk | ✓ Anlık | ✗ Manuel | ✓ Anlık | ✓ Bulut yönetimden tek tık |
| Konsolide rapor anındalığı | ✓ Anlık | ✗ Gün sonu | ✓ Sub-second | ✓ Canlıya yakın (Manager Series) |
| Şubeler arası karşılaştırma | ✓ | ⚠ Kompleks | ✓ | ✓ aiR intelligence içinde hazır |
3.5 · Maliyet Yapısı
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| Başlangıç yatırımı | ✓ Düşük | ⚠ Yüksek (sunucu) | ✓ Orta | ✓ Orta, modüler |
| Aylık abonelik | ⚠ Sürekli | ✓ Yok | ⚠ Orta | ⚠ Modül bazlı, esnek |
| Donanım yatırımı | ✓ Minimum | ⚠ Yüksek | ✓ Orta | ✓ Mini-sunucu + kasa |
| 5 yıllık TCO | Orta | Orta-yüksek (bakım) | Orta | Orta (kesinti maliyeti hariç) |
Yorum: "Aylık abonelik" pahalı görünür ama kesintinin maliyetini içine katmaz. Tek bir Cuma akşamı 7 dakikalık kesintinin cirosal etkisi, çoğu zaman yıllık abonelik farkını karşılar.
3.6 · Veri & Güvenlik
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| Yedekleme stratejisi | ✓ Otomatik bulut | ⚠ Manuel | ✓ Çift yönlü | ✓ Yerel + bulut çift kopya |
| KVKK uyumu | ✓ Sağlayıcıya bağlı | ✓ Tam yerel kontrol | ✓ Yapılandırılabilir | ✓ KVKK uyumlu, TR sunucu |
| Çoklu kullanıcı erişim | ✓ Tarayıcıdan | ⚠ VPN gerekir | ✓ Bulut tarafı tarayıcıdan | ✓ Rol bazlı, her cihazdan |
| Audit log derinliği | ✓ | ⚠ Yerel disk | ✓ Birleşik | ✓ Bulut log + erişim izi |
3.7 · Mevzuat Uyumu (Türkiye)
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| GİB e-Fatura akışı | ✓ Hazır | ⚠ Entegratör gerekir | ✓ Hazır | ✓ Resmi entegratörlerle |
| ÖKC senkronizasyonu | ⚠ Bağlantıya bağlı | ✓ Yerel | ✓ Yerel | ✓ Yerel-first ÖKC bağı |
| e-Adisyon | ✓ | ⚠ Yapılandırma | ✓ | ✓ Hazır akış |
| Yemek çeki entegrasyonu | ✓ | ⚠ Sınırlı | ✓ | ✓ Sodexo, Multinet, Setcard, Ticket |
3.8 · Entegrasyon & Genişleme
| Kriter | Cloud | Yerel | Hibrit | robotPOS |
|---|---|---|---|---|
| Aggregator (Yemeksepeti, Getir Yemek, Trendyol Go) | ✓ | ⚠ Tablet sendromu | ✓ Channel manager | ✓ Tek akışta birleşik |
| EFT-POS | ✓ | ✓ | ✓ | ✓ Çoklu banka entegrasyonu |
| Sadakat / CRM | ✓ Bulut | ⚠ Yerel kısıtlı | ✓ | ✓ air Loyalty (bulut) |
| Açık API genişleme | ✓ | ⚠ Sınırlı | ✓ | ✓ Bulut tarafı REST API |
4 · Türkiye Saha Gerçeği
POS mimarisini seçerken kâğıt üstündeki "uptime garantisi" değil, sahadaki gerçekleşen kesinti deseni belirleyici olmalıdır. Türkiye'de yeme-içme sektöründe sıkça karşılaşılan kesinti tipleri:
| Kesinti Tipi | Tipik Süre | Yıllık Sıklık | Saf Bulut POS Etkisi |
|---|---|---|---|
| Fiber kazısı / kesinti | 30 dk - 4 saat | 1-3 kez | Operasyon tam durur |
| Modem / router donanım | 15-60 dk | 3-6 kez | Operasyon tam durur |
| 4G yedek hat tıkanıklığı | 5-15 dk | 10-25 kez | Ciddi yavaşlama / durma |
| Mobil baz istasyonu yoğunluğu (etkinlik) | 1-3 saat | Etkinlik bazlı | Yavaşlama / kesinti |
| Elektrik kesintisi (UPS sonrası) | 10 dk + | 2-5 kez | Tüm sistem durur |
Sayılar kaba sektör ortalamalarıdır; coğrafyaya göre değişir. Önemli olan rakamlar değil, "ne yaparsanız yapın, gün içinde mutlaka bir-iki kesinti olur" gerçeğidir.
5 · robotPOS'un Mimari Tercihi
robotPOS, klasik "cloud mu yerel mi" ikileminde tek tarafı seçmez. Saha gerçeğine ve operasyonun iki farklı doğasına bakıp üç katmanlı bir mimari kurar: yönetim bulutta yaşar, POS yerelde nefes alır, ikisi arasındaki köprü hem hızlı hem de kesinti toleranslıdır.
☁️ Katman 1 — Yönetim & Analitik (tamamen bulut)
Operasyon direktörünün, finans yöneticisinin ve çoklu şube koordinatörünün baktığı her ekran tarayıcıda açılır.
- air Inventory — bulut stok ve reçete
- air Loyalty — bulut sadakat ve CRM
- air-ERP — bulut finans, fatura, tedarik
- Manager Series — Operation, Franchise, Platform, B2B yönetimi
- aiR intelligence — şube analizi, anomali tespiti, talep tahmini
- IQ Asistan — doğal dil ile veri sorgulama
⚡ Katman 2 — Senkron Köprüsü (akıllı, kesinti toleranslı)
Çevrim varken canlıya yakın (sub-second), yokken yerel + sırada bekleyen senk.
- Online: Her satış, her sipariş kalemi, her ödeme — yereldeki kasa cevabı verdikten sonra arka planda buluta sub-second seviyesinde aktarılır.
- Offline: Bağlantı koparsa kasa hiçbir şey hissetmez; satışlar yerel kuyrukta birikir, çakışmasız (idempotent) yapıyla saklanır.
- Recovery: Bağlantı geri gelince biriken işlemler sırayla, otomatik, çift kayıt riski olmadan aktarılır. Merkezdeki rapor, kesintiyi sayısal olarak fark etmez.
🖥️ Katman 3 — Kasa & Operasyon (yerel-first)
Sahanın can damarı — kasa, mutfak, ödeme — her zaman yereldeki sunucudan çalışır.
- air POS — yerel-first kasa yazılımı
- KDS (mutfak ekran sistemi) — LAN üstünden anlık
- EFT-POS entegrasyonu — yerel banka bağı
- KOT yazıcı, müşteri ekranı, çoklu kasa eş zamanlama — hepsi yerel ağ üzerinde
Neden tam olarak böyle?
Dört nedeni var; ne biri ne diğeri tek başına yeterli olur. Mimariyi şekillendiren bu dördünün kesişimidir:
1. Kasada hız — ticket time düşer
Sipariş yazma, hesap kapatma, KOT mutfağa düşme: bunların hiçbirinin internet üstünden bir HTTP cevabını beklemesine gerek yok. Yerel yanıt, gecikmesiz operasyon demektir.
2. Kesintide süreklilik — gün hiç kapanmaz
İnternet bir tedarik kalemidir; gün içinde mutlaka aksar. Yerel-first POS, bu aksamayı bir sistem olayı olmaktan çıkarıp basit bir senk gecikmesine indirger.
3. Merkezde anlık görünürlük — rapor hiç eksik kalmaz
Yönetim bulutta olduğu için her şube her an merkezden görülür. Operasyon direktörünün "şu an ne oluyor?" sorusu, geceyi beklemez.
4. Mevzuat akışı — GİB ve ÖKC kesintisiz
Yerel-first ÖKC bağı sayesinde her satış mali olarak doğru zamanda kayıt altına alınır; e-Fatura/e-Adisyon iletimi bulut tarafından kuyruk üstünden yapılır. Yasal zincir kopmaz.
6 · Hangi İşletmeye Hangi Mimari?
Hiçbir mimari "evrensel doğru" değildir. Aşağıdaki tablo işletme profili × öneriyi özetler.
| İşletme Profili | Önerilen Mimari | Kısa Gerekçe |
|---|---|---|
| Tek şube cafe (50 sandalye altı, fiber stabil) | Cloud POS veya Hibrit | Düşük hacim, basit operasyon; kesinti riski tolere edilebilir. |
| Fast-food zincir (5+ şube) | Hibrit (yerel-first + bulut yönetim) | Peak hız + merkez görünürlük zorunlu. |
| Fine dining (yüksek hizmet, düşük hacim) | Hibrit | Course bazlı servis, bahşiş, masada-ödeme — kesinti kabul edilemez. |
| Food court / havalimanı | Hibrit | Yoğun peak, paylaşılan ağ, çok sayıda EFT-POS — yerel cevap şart. |
| Dark kitchen / sanal marka | Cloud veya Hibrit | Operasyon online-only ama aggregator yoğun; channel manager kritik. |
| Otel restoran (PMS entegrasyonu, çoklu konsept) | Hibrit | PMS/ERP hattı + yerel servis akışı + merkez raporlama. |
7 · Geçiş Senaryoları
Senaryo 1 — Yerelden hibride geçiş
Mevcut yerel POS verisinin (menü, müşteri, sipariş geçmişi) bir defaya mahsus bulut tarafına aktarılması, kasaların yerel-first modda çalışmaya devam etmesi, sadece yönetim katmanının buluta açılmasıyla başlar. Genelde 1-2 hafta içinde çoklu şubede tamamlanır; kasada operasyon kesintisizdir.
Senaryo 2 — Saf bulut POS riskinden çıkış
İlk açıldığında "internet hep iyi olur" varsayımıyla saf bulut POS seçen ve sonra peak saatte iki kez yandığını gören işletmeler için yol: aynı yazılım soyağacında kalan, yerel-first kasa modülünü ekleyen bir hibrit mimariye geçiş. Veri taşınmaz; yalnızca kasa katmanı yereli destekler hale getirilir.
Senaryo 3 — BT ekibi olmayan işletme
Tek-elden hizmet alınması kritik. Yerel sunucu, bulut hesabı, GİB entegratörü, EFT-POS bağları farklı tedarikçilerden geliyorsa kesinti olduğunda kim sorumlu? Tek bir mimari içinde bunların hepsinin tek vendor sorumluluğunda olması, hibrit modelin gizli en büyük faydasıdır.
8 · Sıkça Sorulan Sorular
Cloud POS internet kesilince hiç çalışmaz mı?
Saf bulut POS internet'siz işlevini kaybeder. Bazı bulut POS'lar "limited offline mode" sunar ama bu modlarda hesap kapatma, EFT-POS, KOT akışı tam çalışmaz. Kritik operasyon için saf bulut yerine hibrit/yerel-first öneririz.
Yerel POS'un en büyük dezavantajı nedir?
Çoklu şube konsolidasyonu ve uzaktan görünürlük. Tek şubede yerel POS sorunsuz çalışır; şube sayısı arttıkça merkezden anlık veri görmek için ek altyapı (VPN, replikasyon, veri taşıma) gerekir. Bu yatırım çoğunlukla bulut yönetimden daha pahalıya gelir.
Hibrit POS, "iki sistemi birden ödemek" anlamına mı gelir?
Hayır — eğer doğru tasarlanmış tek bir mimariyse. Yerel kasa katmanı + bulut yönetim katmanı, aynı vendor çatısı altında ve tek lisans yapısında olur. İki ayrı tedarikçiden hibrit kurmaya çalışırsanız maliyet ve karmaşıklık yükselir; tek elden alındığında bütüncüldür.
Çoklu şubeli restoranda merkezden anlık rapor gerçekten mümkün mü?
Evet — bulut yönetim katmanı varsa. Manager Series + aiR intelligence gibi katmanlar, her şubedeki yerel kasanın sub-second seviyesinde buluta yansıttığı veriyle çalışır. "Anlık" pratik olarak birkaç saniye gecikmeli demektir; rapor için yeterlidir.
Saf bulut POS ile hibrit POS arasında müşteri farkı yaratır mı?
Çoğu zaman fark etmez — gün iyi gittikçe. Ama bir kez peak saatte internet koptuğunda saf bulut POS müşteriyi hissedilir biçimde bekletir; hibrit POS hissettirmez. Müşteri "garip bir gün" hatırlamaz; bu, sessiz bir rekabet avantajıdır.
KVKK açısından bulut POS riskli midir?
Türkiye'deki bulut POS sağlayıcıları KVKK uyumlu sözleşmeyle ve TR sunucu seçeneğiyle çalışıyorsa risk yoktur. Önemli olan veri saklama lokasyonu, işleyici sıfatı ve DPA (veri işleme anlaşması) maddeleridir. robotPOS bulut katmanı KVKK uyumludur ve yurt içi sunucularda barınır.
POS değişimi sırasında veri taşıma ne kadar sürer?
Şube başına 1-3 gün arası tipiktir. Menü, reçete, müşteri tabanı, sipariş geçmişi paralel olarak alınır; eğitim devreye girer; sonra "go-live" gecesi geçilir. Çoklu şubede şablon-bazlı kurulum bu süreyi kısaltır.
9 · POS Seçimi Karar Listesi
Kararı vermeden önce bu sekiz soruyu cevaplayın. Cevaplar mimarinizi büyük ölçüde belirler:
- Kesinti toleransı: Cuma akşamı 7 dakikalık internet kesintisi, kasanızı durdurabilir mi? (Hayır → yerel-first şart.)
- Şube sayısı ve büyüme planı: 12 ay içinde kaç şubeniz olacak? (2+ → bulut yönetim şart.)
- Merkez görünürlük ihtiyacı: Operasyon direktörü canlıya yakın rapora bakmak zorunda mı?
- Online sipariş hacmi: Aggregator'lar günlük cironuzun yüzde kaçı? (%30+ → channel manager hayati.)
- BT kapasitesi: İçerideki BT desteğiniz yeterli mi yoksa tek-vendor sorumluluğu mu istiyorsunuz?
- Mevzuat ihtiyacı: e-Fatura, e-Adisyon, ÖKC, yemek çeki entegrasyonları sorunsuz akmalı mı?
- 5 yıllık TCO: Aboneliği değil, kesinti maliyetini de hesaba katın.
- Vendor sürekliliği: Tedarikçi 5 yıl sonra hâlâ sektörde olacak mı? Saha referansları ne diyor?
📚 İlgili Rehberler
- Restoran Teknolojisi Sözlüğü 2026 — 80 Terim (POS, KDS, ÖKC, KOT ve daha fazlasının net tanımları)
- air Series — robotPOS yerel-first POS + bulut yönetim mimarisi
- air-ERP — bulut tabanlı ERP & finans
- aiR intelligence — bulut analitik ve raporlama
- Manager Series — çoklu şube ve franchise yönetim katmanı
- Aggregator (Yemeksepeti, Getir, Trendyol) entegrasyon rehberi
Son güncelleme: 2026. Bu rehber, POS mimarisi alanındaki gelişmelere göre düzenli güncellenir. Eklenmesini istediğiniz bir kriter veya senaryo için iletişim formundan ulaşın.
