Saha operasyonlarında yalnızca hız yeterli değildir. Verinin doğru anda, doğru kişide ve doğru bağlamda bulunması gerekir. Saha satış temsilcisi müşteri ziyaretindeyken internet çekmeyebilir. Servis teknisyeni bodrum katta çalışırken fotoğraf yükleyemeyebilir. Bölge yöneticisi ise ekiplerin hangi görevde olduğunu 10 dakika gecikmeyle görmek istemez. Tam da bu yüzden saha ekipleri mobil uygulama tasarımı, klasik bir kurumsal uygulama geliştirme işinden ayrılır.

İyi kurgulanmış bir mobil çözüm, görev akışını sadeleştirir, çift veri girişini azaltır ve merkeze daha güvenilir operasyon verisi taşır. Kötü kurgulanmış bir çözüm ise sahadaki personeli ekrana mahkûm eder. Tasarımın omurgasında üç temel konu yer alır: offline çalışma, konum tabanlı görünürlük ve görev yönetimi. Bunlara ek olarak cihaz güvenliği, senkronizasyon mantığı, rol bazlı yetki ve ERP/CRM entegrasyonu da en az arayüz kadar kritiktir.

Bu yazıda saha satış ve servis ekipleri için mobil uygulama tasarımını teknik ve operasyonel açıdan ele alacağız. Amacımız, her işletmeye uyan tek bir şablon önermek değil; gerçek saha koşullarına dayanıklı bir mimari çerçeve sunmak.

1) Saha uygulamasının çekirdeği: 30 saniyede işlem tamamlatan akışlar

Saha personeli masa başında çalışmaz. Uygulamanın kullanıldığı anlar kısadır, kesintilidir ve dikkat dağıtıcı olabilir. Temel görevlerin 30 ila 90 saniye içinde tamamlanabilir olması bu nedenle ciddi bir tasarım hedefidir. Örneğin bir servis teknisyeni için “göreve başla > müşteri doğrula > iş emri fotoğrafı ekle > parça seç > imza al > görevi kapat” akışı, tek ekranda çözülmese bile gereksiz geçişler üretmemelidir.

Saha satış tarafında da tablo benzerdir. Temsilci; rota, ziyaret planı, cari risk durumu, geçmiş sipariş ve kampanya bilgisini tek oturumda görebilmelidir. Müşterinin yanında 7 farklı sekme arasında dolaşmak verim kaybı yaratır. Burada doğru tasarım kararı, her rol için ayrı bir ana ekran kurgulamaktır. Satış temsilcisi ile servis teknisyeninin aynı menü yapısını kullanması çoğu zaman gereksiz yük oluşturur.

Rol bazlı ekran tasarımı neden önemlidir?

Üç farklı kullanıcı düşünelim: teknisyen, bölge satış sorumlusu, operasyon yöneticisi. Bu kullanıcıların ihtiyaç duyduğu ilk bilgi aynı değildir. Teknisyen için açık iş emri sayısı ve SLA süresi kritik olabilir. Satış temsilcisi için gün içi ziyaret planı ve tahsilat riski daha ön plandadır. Yönetici ise ekip bazlı durum özetini görmek ister. Tek bir “genel dashboard” hepsini memnun etmez.

  • Teknisyen ana ekranı: bugünkü görevler, rota, arıza geçmişi, yedek parça durumu
  • Satış ekranı: ziyaret listesi, açık teklif, sipariş, tahsilat notu
  • Yönetici ekranı: ekip konum özeti, geciken görevler, tamamlanma oranı

Bu ayrım yalnızca kullanılabilirlik meselesi değildir. Veri kalitesini de doğrudan etkiler. Personel aradığı bilgiyi 2 dokunuşta bulursa kayıt tamamlama oranı yükselir; zorlanırsa “sonra girerim” davranışı devreye girer.

2) Offline çalışma: internet yokken bile veri kaybetmeyen mimari

Saha uygulamalarında offline yetenek bir opsiyon değil, temel bir ihtiyaçtır. Türkiye'de büyükşehir merkezlerinde bile bina içi kapsama sorunları yaşanırken; depo, şantiye, kırsal servis noktası ya da tesis içi alanlarda bağlantı kesintisi daha sık görülür. Uygulama, ağ yoksa durmamalı; kontrollü biçimde yerelde çalışabilmelidir.

Pratik yaklaşım şudur: kritik verilerin bir kısmı cihazda tutulur, işlemler yerel kuyruğa yazılır, bağlantı geri geldiğinde senkronizasyon yapılır. Ancak her veriyi cihazda saklamak doğru değildir. Müşteri listesi, açık görevler, ürün kataloğunun ilgili bölümü, son 30-90 güne ait işlem geçmişi çevrimdışı erişime açılabilir. Tüm ERP verisini telefona indirmek ise güvenlik ve performans açısından risklidir.

Offline-first senaryoda hangi veriler yerelde tutulmalı?

Somut bir servis senaryosu üzerinden ilerleyelim. Teknisyen sabah 08:30'da uygulamayı açıyor. O gün için 12 iş emri atanmış. Bu iş emirleri, müşteri adresleri, cihaz seri numaraları, daha önce açılmış son 3 arıza kaydı ve gerekli kontrol listesi cihazda önbelleğe alınabilir. Böylece teknisyen 11:10'da internetin olmadığı bir tesise girse bile görevine devam eder.

  • Görev detayları ve durum kodları
  • Müşteri ve lokasyon temel bilgileri
  • Form şablonları, kontrol listeleri, zorunlu alan kuralları
  • Fotoğraf, not, imza ve parça kullanımı kayıtları

Senkronizasyon tarafında en kritik konu çakışma yönetimidir. Aynı kaydı merkezde başka bir kullanıcı da güncellemiş olabilir. Bu noktada “en son yazan kazanır” mantığı her zaman güvenli değildir. Daha sağlıklı yöntem, kayıt bazında sürüm numarası tutmak ve çakışmayı kullanıcıya anlamlı bir şekilde göstermektir.

{
  "taskId": "SRV-10428",
  "version": 12,
  "status": "in_progress",
  "offlineChanges": true,
  "lastSyncedAt": "2026-07-20T09:12:00Z"
}

Bu tür bir yapı, mobil istemcinin hangi kaydın güncel olduğunu anlamasını kolaylaştırır. Ayrıca fotoğraf ve video gibi büyük dosyalar için arka planda parçalı yükleme tercih edilmelidir. Aksi halde 25 MB'lık tek bir dosya, tüm görevin kapanmasını geciktirebilir.

3) Konum takibi: her an izleme değil, operasyon görünürlüğü

Konum takibi birçok projede yanlış konumlandırılır. Amaç personeli sürekli izlemek değil, operasyon kararlarını daha isabetli verebilmektir. Bu ayrım hem hukuki açıdan hem de kullanıcı kabulü bakımından önemlidir. Uygulama tasarımında konum verisinin “neden toplandığı, ne sıklıkla alındığı, ne kadar süre saklandığı” net biçimde tanımlanmalıdır.

Örneğin servis ekiplerinde konum, görev atamasını optimize etmek için kullanılabilir. Aynı ilçede bulunan ve işini erken bitiren teknisyene yakındaki yeni görev yönlendirilebilir. Satış ekiplerinde ise rota uyumu ve ziyaret doğrulaması için işe yarar. Her 2 saniyede bir GPS verisi toplamak çoğu senaryoda gereksizdir; üstelik pil tüketimini artırır. Bunun yerine olay tabanlı bir model daha mantıklıdır: göreve başlama, müşteri noktasına varış, görev kapanışı, rota sapması gibi anlarda kayıt alınır.

Konum tasarımında dikkat edilmesi gereken teknik sınırlar

Akıllı telefon GPS verisi her zaman kusursuz değildir. Kapalı alan, yüksek bina yoğunluğu ve düşük uydu görünürlüğü nedeniyle hata payı 5 metre ile 50 metre arasında değişebilir. Bu nedenle “müşteri kapısına tam 3 metre yaklaştıysa check-in açılsın” gibi aşırı katı kurallar sahada sorun yaratır. Daha gerçekçi bir geofence yarıçapı, senaryoya göre 50 ila 150 metre bandında kurgulanabilir.

Konum verisinin kullanıcı deneyimine yansıması da sade olmalıdır. Harita, yalnızca görsel olarak etkileyici diye ana ekranı işgal etmemeli. Teknisyen için öncelik rota değilse, harita küçük bir bileşen olarak kalabilir. Yönetici panelinde ise ekip yoğunluğu, gecikme riski ve yakın görev eşleştirmesi daha görünür hale getirilebilir.

4) Görev yönetimi: atama, öncelik, SLA ve kapanış mantığı

Saha ekipleri için mobil uygulama denince çoğu zaman bir görev listesi yapılır ve konu kapanır. Oysa asıl değer, görev yaşam döngüsünün doğru modellenmesinde yatar. “Açık, yolda, başladı, beklemede, parça bekliyor, müşteri erteledi, tamamlandı” gibi durumlar işin gerçeğini yansıtmalıdır. Fazla durum kodu karmaşa yaratır; azı ise raporlamayı bozar. Çoğu operasyon için 6 ila 10 durum kodu pratik bir aralık sağlar.

Atama motoru ilk sürümde manuel başlayabilir. Ancak görev tipi, bölge, beceri seti ve SLA süresi gibi kriterler tanımlanırsa yarı otomatik dağıtım kısa sürede ciddi fayda sağlar. Örnek olarak; klima bakım sertifikası gerektiren iş emirleri yalnızca ilgili yetkinliğe sahip teknisyenlere düşsün. Acil seviye “P1” olan kayıtlar ise bekleyen görevlerin üstüne çıksın.

Görev kapanışında eksik veri bırakmamak

Mobil uygulamanın en kritik anı görev kapanışıdır. Çünkü raporlama, faturalama ve müşteri bilgilendirmesi bu adımdan beslenir. Zorunlu alanlar da burada devreye girmelidir. Ancak her alanı zorunlu yapmak çözüm değildir. Sahada gerçekten gerekli olan kayıtlar zorunlu olmalıdır:

  • Başlama ve bitiş zamanı
  • Yapılan işlem kodu
  • Varsa kullanılan parça veya sarf malzemesi
  • Fotoğraf ya da müşteri onayı

İyi uygulamalarda görev, eksik kritik bilgi varsa kapanmaz; ancak kullanıcıya net bir hata mesajı gösterilir. “Form geçersiz” yerine “Kullanılan parça seçilmedi” gibi açık mesajlar gerekir. Küçük görünen bu detaylar, eğitim maliyetini düşürür.

5) Entegrasyon ve güvenlik: mobil uygulama tek başına değer üretmez

Saha uygulamasının verimli çalışması için arka ofis sistemleriyle konuşması gerekir. En sık karşılaşılan ihtiyaçlar arasında ERP'den cari ve stok bilgisi çekmek, CRM'den müşteri geçmişini görmek, çağrı merkezi kayıtlarını iş emrine bağlamak ve bildirim servisleriyle anlık uyarı göndermek yer alır. API entegrasyonu yoksa saha personeli aynı bilgiyi iki kez girmek zorunda kalır.

Bu noktada çevik ama kontrollü bir entegrasyon katmanı önemlidir. Mobil istemcinin doğrudan ERP veritabanına erişmesi doğru bir yaklaşım değildir. Araya bir API katmanı konur; bu katman kimlik doğrulama, veri filtreleme, loglama ve oran sınırlama görevlerini üstlenir. Örneğin bir satış temsilcisinin yalnızca kendi bölgesindeki müşteri kayıtlarını görmesi, rol bazlı erişim kuralıyla sağlanır.

Cihaz güvenliği ve veri koruma

Sahada kullanılan cihazlar kaybolabilir, çalınabilir ya da ortak kullanılabilir. Bu nedenle temel güvenlik kontrolleri mobil tasarımın en başında planlanmalıdır. Ekran kilidi zorunluluğu, token süre yönetimi, hassas verinin şifreli saklanması ve uzaktan oturum kapatma başlıca gereksinimlerdir. Özellikle offline veri tutulan uygulamalarda bu konu daha da kritiktir.

Ayrıca fotoğraf, imza, konum ve müşteri verisi işlendiği için aydınlatma metinleri, saklama politikası ve yetki matrisinin açık şekilde tanımlanması gerekir. Teknik başarı ile hukuki uyum birlikte ilerlemelidir.

6) Başarılı proje yaklaşımı: 8-12 haftalık pilotla başlamak

Saha ekipleri için mobil uygulama projelerinde en sık yapılan hata, ilk sürümde tüm iş süreçlerini tek pakette çözmeye çalışmaktır. Daha sağlıklı yöntem, dar kapsamlı ama ölçülebilir bir pilotla başlamaktır. Örneğin 1 bölge, 15 teknisyen ve tek bir hizmet tipi üzerinden pilot yapılabilir. Süre, çoğu kurumda 8 ila 12 hafta bandında yönetilebilir; bu süreye analiz, tasarım, geliştirme, test ve canlı prova dahildir.

Pilot aşamada şu metrikler izlenebilir: görev başına ortalama işlem süresi, eksik kapanan kayıt oranı, manuel telefon trafiği, görev atama gecikmesi, çevrimdışı tamamlanan işlem sayısı. Burada kesin sektör ortalamaları vermek doğru olmaz; çünkü ekip yapısı, ürün tipi ve servis yoğunluğu işletmeden işletmeye ciddi biçimde değişir. Yine de kendi baz çizginizi çıkarmak ve pilot sonrasında aynı metriklerle karşılaştırmak güvenilir bir yöntemdir.

Canlıya geçiş sonrasında iş bitmez. Mobil loglar, hata kayıtları, senkronizasyon başarısızlıkları ve kullanıcı davranışı düzenli olarak izlenmelidir. İlk 30 gün içinde gelen geri bildirimler genellikle en değerlisidir. Çünkü sahadaki gerçek kullanım, toplantı odasında öngörülemeyen ayrıntıları hızla ortaya çıkarır.

Özetle, etkili bir saha mobil çözümü yalnızca iyi görünen ekranlardan oluşmaz. Offline dayanıklılık, yerinde konum kullanımı, sağlam görev kurgusu, güvenli entegrasyon ve ölçülebilir pilot yaklaşımı bir araya geldiğinde operasyonel verimlilik anlamlı biçimde artar. Uygulama sahadaki işi kolaylaştırıyor, veri girişini hızlandırıyor ve yönetime daha temiz veri sağlıyorsa amacına hizmet ediyor demektir.