Saha Satış Mobil Uygulaması Nasıl Planlanır? Sipariş, Fiyat ve ERP Bağlantısı

Saha satış mobil uygulaması; satış temsilcisinin müşteri ziyaretini, güncel ürün ve fiyat bilgisini, sipariş taslağını, iskonto yetkisini ve merkeze aktarım sonucunu mobil cihazdan yönetmesini sağlar. Sağlıklı bir uygulama yalnız “sipariş formunu telefona taşımak” değildir. Müşteriye gösterilen fiyatın kaynağını, çevrimdışı kaydın güncelliğini, siparişin ERP tarafından kabul edilip edilmediğini ve hatanın kime döneceğini açıkça yönetmelidir.

Bu rehber; distribütör, üretici ve toptan satış ekiplerinin saha satış uygulaması kapsamını çıkarması için hazırlanmıştır. Buradaki ziyaret–fiyat–sipariş–ERP kabul modeli ve kabul testi tablosu bu makale için geliştirilen özgün planlama araçlarıdır. Gerçek bir Kumsal Ajans müşterisinin performans sonucu değildir; satış, ciro veya ziyaret artışı garantisi vermez.

Önce saha satış modelini tanımlayın

“Plasiyer uygulaması” farklı operasyonları ifade edebilir. Sipariş toplayan ön satış ekibi ürünü teslim etmez; sıcak satış ekibi araç stoğundan teslimat yapabilir; mağaza ziyaret ekibi sipariş almadan raf, stok ve kampanya kontrolü yapabilir; bazı ekipler tahsilat veya iade de yönetir. Bu işler aynı uygulamada bulunsa bile veri, yetki ve riskleri farklıdır.

İlk analizde aşağıdaki sınırlar yazılmalıdır:

• Temsilci yalnız sipariş taslağı mı oluşturur, bağlayıcı sipariş de verebilir mi?
• Stok merkez depodan mı, bölge deposundan mı, araç stoğundan mı gösterilir?
• Fiyat müşteri, ürün, miktar, sözleşme, kampanya veya ödeme koşuluna göre değişir mi?
• İskonto ve vade istisnasını kim onaylar?
• Tahsilat, iade, teslimat veya belge üretimi aynı kapsamda mı?

Teknik servis ekipleri benzer çevrimdışı altyapıyı kullanabilir; fakat iş emri, parça tüketimi ve servis kabulü farklı bir süreçtir. Bu ayrım için teknik servis mobil uygulaması planlama rehberini inceleyebilirsiniz.

Kumsal dört kapılı saha sipariş modeli

Saha siparişini tek bir “gönderildi” durumu yerine dört ayrı karar kapısında ele alın. Böylece kullanıcı eylemi ile ticari ve teknik kabul birbirine karışmaz.

 

Bu modelde “telefon veriyi gönderdi” ile “ERP siparişi kabul etti” aynı sonuç değildir. Sipariş cihazdan çıkmış, entegrasyon katmanına ulaşmış, fakat kredi limiti veya ürün eşlemesi nedeniyle ERP'de reddedilmiş olabilir. Kullanıcıya son doğrulanmış durum gösterilmelidir.

Müşteri ve ürün verisinin cihazdaki kapsamını sınırlayın

Uygulama her temsilciye bütün müşteri ve ürün verisini indirmemelidir. Bölge, portföy, rol, ürün grubu ve ziyaret planına göre gereken veri kümesi belirlenir. Müşteri adresi, cari durum, sözleşmeli fiyat, ürün kataloğu ve geçmiş sipariş gibi verilerin hangisinin çevrimdışı görüntüleneceği ayrıca seçilir.

Her çevrimdışı kaydın son güncelleme zamanı ve sürümü görünür olmalıdır. “Stokta” veya “fiyat geçerli” mesajı, güncellik bilgisi olmadan yanıltıcı olabilir. Hassas alanlar için cihazda tutmama, yalnız özet tutma veya bağlantı gerektiğinde sorgulama seçenekleri değerlendirilmelidir.

Fiyatı mobil uygulama değil, tanımlı fiyat kaynağı hesaplamalıdır

Müşteri özel fiyatı; fiyat listesi, ürün, miktar, iskonto, sözleşme, kampanya, para birimi, vergi ve geçerlilik tarihinden etkilenebilir. Mobil uygulamanın bu kuralları bağımsız bir kopya hâlinde yürütmesi, merkez ile saha sonucunun ayrışmasına yol açabilir. Önce fiyatın ana sistemi ve uygulamanın çevrimdışı durumda hangi önbelleğe alınmış sonucu kullanabileceği belirlenmelidir.

Microsoft Dynamics 365 fiyat hesaplama belgeleri, fırsat, teklif, sipariş ve fatura kayıtlarında fiyat listesi, birim fiyat, miktar indirimi ve manuel indirimin ayrı bileşenler olarak ele alındığını gösterir. Bu bir ürün önerisi değildir; “ekranda görünen fiyat”ın tek bir sayı değil, izlenebilir bir hesap ve yetki sonucu olması gerektiğine örnektir.

Mobil siparişte en az şu bilgiler saklanmalıdır:

• Fiyat listesi veya fiyat motoru kimliği ve sürümü
• Hesaplama zamanı, para birimi ve geçerlilik aralığı
• Uygulanan iskonto/kampanya ve gerekçesi
• Manuel değişiklik yapan kullanıcı ve yetki sınırı
• Çevrimdışı fiyatın güncellik durumu ve ERP yeniden kontrol sonucu

Çevrimdışı çalışma ekran özelliği değil, veri sözleşmesidir

Çevrimdışı destek, bağlantı yokken ekranın açılmasıyla tamamlanmaz. Hangi verinin cihazda bulunduğu, hangi işlemin çevrimdışı yapılabildiği, kuyruğun nasıl korunduğu, bağlantı gelince hangi sırayla gönderildiği ve çakışmanın nasıl çözüldüğü yazılmalıdır.

Android'in offline-first mimari rehberi, ağ kullanan depolar için yerel ve ağ veri kaynaklarını; yerel kaynaktan okuma, yazma kuyruğu, yeniden deneme ve senkronizasyon stratejilerini ele alır. Her uygulamanın aynı teknolojiyi kullanması gerekmez. Ancak yerel kayıt ile sunucu kaydının farklı zamanlarda değişebileceği kabul edilmelidir.

Saha satışında çakışma örnekleri şunlardır:

• Temsilci çevrimdışıyken fiyat listesi merkezde değişir.
• Aynı müşteri için iki cihaz farklı sipariş taslakları oluşturur.
• Çevrimdışı seçilen ürün bağlantı geldiğinde satışa kapatılmıştır.
• Miktar girilirken stok başka kanaldan tüketilmiştir.
• Temsilci iskonto isterken müşteri kredi limiti değişmiştir.

Bu durumlarda “son yazan kazanır” kuralı her veri için güvenli değildir. Ziyaret notu birleştirilebilir; fiyat, limit veya sipariş satırı ise yeniden doğrulama ve kullanıcı kararı gerektirebilir.

Sipariş kuyruğu ve tekrar gönderim çift kayıt üretmemelidir

Mobil cihaz isteği gönderdikten sonra yanıt alamazsa siparişin ERP'de oluşup oluşmadığı belirsiz kalabilir. Kullanıcının “tekrar gönder” düğmesine basması ikinci sipariş üretmemelidir. Her siparişe cihazda oluşturulan kalıcı bir işlem kimliği verilmeli; entegrasyon ve ERP aynı kimliği tekrar gördüğünde önceki sonucu döndürebilmelidir.

AWS Builders' Library'nin idempotent API rehberi, yeniden denenen işlemlerde istemci tarafından sağlanan benzersiz istek kimliğinin aynı niyeti tanımaya nasıl yardım ettiğini açıklar. Bu davranış hedef sistemde gerçekten uygulanmalı ve test edilmelidir; yalnız mobil kayda rastgele bir alan eklemek yeterli değildir.

Sipariş durumları en az taslak, cihazda bekliyor, iletiliyor, teknik olarak alındı, ERP kabul etti, iş kuralıyla reddedildi ve insan incelemesinde olarak ayrılabilir. Kullanıcı kuyruktaki kaydı silerse denetim izi ve merkezdeki olası kayıt da dikkate alınmalıdır.

Stok ve teslimat vaadi aynı şey değildir

Fiziksel stok, satılabilir miktar, ayrılmış stok, araç stoğu, yoldaki ürün ve müşteri kotası farklı değerlerdir. Uygulamada gösterilecek miktarın tanımı ve güncellenme zamanı açık olmalıdır. Çevrimdışı görüntülenen son bilinen stok, kesin teslimat sözü olarak sunulmamalıdır.

ERP siparişi kabul ederken stoğu yeniden doğrulayabilir, kısmi teslimata izin verebilir veya alternatif depo önerebilir. Temsilci müşteriye hangi bilginin tahmin, hangi bilginin onaylı taahhüt olduğunu görebilmelidir. Stok, fiyat ve sipariş alanlarının ana kaynaklarını birlikte planlamak için e-ticaret–ERP entegrasyonu rehberi tamamlayıcı bir veri sahipliği matrisi sunar.

Konum özelliğini satışın amacıyla sınırlayın

Konum; ziyaret başlangıcını kolaylaştırmak, yakındaki müşteriyi göstermek veya rota desteği vermek için kullanılabilir. Fakat uygulamanın sürekli arka plan takibi yapması teknik bir varsayım olmamalıdır. İş amacı, gerekli doğruluk, saklama süresi, erişim yetkisi ve konum verilmezse uygulanacak alternatif akış önceden tanımlanmalıdır.

Android konum izni rehberi, konum izninin özellik kullanıldığı bağlamda istenmesini ve arka plan izninin ayrı değerlendirilmesini önerir. Yaklaşık konum bazı amaçlar için yeterli olabilir. Çalışan takibi, kişisel veri ve iş hukuku etkileri bulunduğunda ilgili uzman incelemesi ayrıca yapılmalıdır; bu makale hukuki uygunluk görüşü değildir.

Tahsilat ve müşteri finansal bilgileri ayrı risk alanıdır

Cari bakiye görüntüleme, tahsilat kaydı oluşturma ve gerçek ödeme alma aynı işlem değildir. Uygulama ödeme verisini gereksiz yere saklamamalı; sağlayıcı, yetkilendirme, başarısız işlem, iptal/iade, makbuz ve mutabakat akışları ayrı tasarlanmalıdır. Çevrimdışı tahsilat kabulü özellikle finansal ve operasyonel risk değerlendirmesi gerektirir.

Temsilcinin görebileceği kredi limiti, gecikmiş borç veya risk bilgisi rol ve müşteri portföyüyle sınırlandırılmalıdır. Cihaz kaybolduğunda oturum kaldırma, uzaktan erişim kesme ve yerel veriyi geçersiz kılma yöntemleri bulunmalıdır.

Mobil cihazda saklanan veriyi azaltın ve koruyun

Çevrimdışı çalışma yerel veri gerektirir; fakat bütün ERP kaydını telefona taşımayı gerektirmez. Kimlik doğrulama verisi, müşteri finansal bilgisi, fiyat listesi, sipariş ve konum kaydı duyarlılığına göre sınıflandırılmalıdır. Cihaz içi saklama, aktarım, yedekleme, ekran görüntüsü, dışa aktarma ve log politikaları birlikte ele alınır.

OWASP MASVS güvenli saklama kontrolü, uygulamanın bilinçli olarak sakladığı hassas verinin bulunduğu konumdan bağımsız biçimde korunmasını ister. Bu kontrol tek başına güvenli uygulama kanıtı değildir; kimlik doğrulama, yetki, ağ iletişimi, platform kullanımı, gizlilik ve test kapsamı ayrıca değerlendirilmelidir.

İlk sürümde hangi ekranlar gerekir?

Her olası özelliği ilk sürüme koymak yerine temsilcinin günlük görev zincirini tamamlayın:

1. Günlük müşteri/ziyaret listesi: görev, adres, öncelik ve son senkronizasyon.
2. Müşteri özeti: yetkili kapsamda bakiye, limit, geçmiş sipariş ve notlar.
3. Ürün kataloğu: arama, barkod, paket/birim, son bilinen stok ve fiyat sürümü.
4. Sipariş sepeti: miktar, teslimat, iskonto, uyarı ve onay ihtiyacı.
5. Senkronizasyon merkezi: bekleyen, başarısız, kabul edilen ve düzeltilecek kayıtlar.
6. Ziyaret sonucu: sipariş, fırsat, ret nedeni, sonraki görev ve izinli kanıt.

Rota optimizasyonu, tahsilat, iade, araç stoğu, mobil yazıcı, kampanya sunumu veya mağaza denetimi ancak doğrulanmış iş ihtiyacına göre sonraki faza alınmalıdır.

Uçtan uca kabul testleri nasıl yazılır?

Test yalnız başarılı senaryoyu değil; zaman aşımı, kuyruk birikmesi, hatalı veri, yetki kaybı, uygulama kapanması, düşük pil, sürüm güncellemesi ve kısmi ERP kabulünü de kapsamalıdır.

Teklifte ve proje kapsamındakiler nasıl karşılaştırılır?

• Satış modeli, kullanıcı rolleri, müşteri portföyü ve cihaz politikası
• Çevrimdışı görüntülenecek ve yazılacak veri kümeleri
• Fiyat, iskonto, stok, kredi ve teslimat kuralları
• ERP/CRM/PIM/WMS alan eşlemeleri ve ana sistem kararları
• Sipariş kimliği, kuyruk, tekrar, hata ve mutabakat davranışı
• Konum, barkod, kamera, imza, yazıcı ve bildirim izinleri
• Yerel veri güvenliği, oturum, cihaz kaybı ve erişim kaldırma
• Pilot kullanıcılar, kabul testleri, eğitim ve canlı geçiş
• İzleme, destek, sürüm dağıtımı, işletim ve devir sorumlulukları

Başarı ölçümü için ziyaret sayısı tek başına yeterli değildir. ERP tarafından kabul edilen sipariş oranı, fiyat farkı nedeniyle bekleyen kayıtlar, yinelenen sipariş engellemeleri, senkronizasyon kuyruğu yaşı, düzeltme süresi ve temsilcinin görevi tamamlama oranı birlikte izlenebilir. Ölçüm tanımı ve başlangıç değeri proje öncesinde yazılmalıdır.

Sonuç: Mobil ekranı değil, saha ile merkezin sözleşmesini tasarlayın

Saha satış uygulamasının değeri çok sayıda ekran göstermesinden değil; müşteriyi, fiyatı, siparişi ve ERP sonucunu aynı işlem zincirinde güvenilir biçimde bağlamasından gelir. Çevrimdışı kayıt, fiyat güncelliği, tekrar gönderim, konum ve hassas veri konuları sonradan eklenecek ayrıntılar değildir.

İlk kapsamı dört karar kapısı ve kabul testleriyle çıkarın. Saha satış süreciniz, mobil cihaz gereksinimleri ve ERP bağlantısını birlikte değerlendirmek isterseniz Kumsal Ajans mobil uygulama çözümlerini inceleyebilirsiniz.