Bayi, şube ve kullanıcı yetkisini ayrı tanımlayın
Backend geliştirme kapsamına yalnızca giriş ekranı değil kayıt düzeyindeki erişim kuralları da dahil olmalıdır. Bayi şirketi, şubesi ve kullanıcı farklı varlıklardır. Bir satın alma kullanıcısı kendi şubesine sipariş verebilirken merkez yöneticisi başka şubeleri görebilir; bu ayrım açıkça yazılmalıdır.
Örnek olarak satış temsilcisi bayi adına taslak hazırlayabilir fakat bayi finans belgesini göremeyebilir. Finans kullanıcısı belge görebilir ancak ürün fiyatını değiştiremez. Ekrandaki butonu gizlemek tek başına sınırı uygulamaz; veri ve işlem isteğinde de yetki kontrol edilmelidir.
Daveti kimin göndereceğini, ayrılan çalışanın erişiminin nasıl kaldırılacağını ve hesap sahibinin nasıl değiştirileceğini belirleyin. Ortak kullanıcı adıyla bütün ekibin işlem yapması sorumluluk izini zayıflatır. Testleri farklı bayi ve şube hesaplarıyla yürütün; yalnızca yönetici hesabında çalışan akış yeterli değildir.
Rol matrisi
Her rol için görebileceği veri ve yapabileceği işlem ayrı yazılsın. Şube ve şirket kapsamı belirtilsin.
Olumsuz test
Bir bayi diğer bayinin fiyatı, siparişi veya belgesine erişememeli. Beklenen ret sonucu kontrollü test hesabıyla doğrulansın.
Hesap yaşam döngüsü
Davet, rol değişikliği ve erişim kaldırma görevlerinin sahibi belli olsun. Ortak hesap yerine izlenebilir kullanıcı modeli kurulsun.
Bayi kataloğunu sipariş verme biçimine göre sınayın
Ürün verisi kalite kontrolü teknik katalogda kod, paket birimi ve gerekli özellikleri doğrulamaya yardımcı olur. Bayi çoğu zaman ürün ilhamı aramak yerine bildiği stok koduyla tekrar sipariş verir. Arama, hızlı sipariş ve kaydedilmiş liste akışları bu davranışa göre denenmelidir.
Örnek bir yedek parça siparişinde ürün kodu benziyor olabilir fakat uyumlu model farklıdır. Teknik belge, alternatif ürün ve paket miktarı açık sunulmalıdır. “Bir adet” ifadesi tek parça mı kutu mu anlamına geliyor? Portal ve ERP aynı birimi kullanmalıdır.
Her bayinin bütün ürünlere erişimi olmayabilir. Bölge, ürün grubu veya onaylı sözleşme kapsamı katalog görünürlüğünü etkiliyorsa bu kural hedef hesapta test edilir. Katalog dışı ürünün bağlantısını bilen kullanıcının yine de sipariş verebildiği bir açık bırakılmamalıdır.
Hızlı sipariş
Gerçekçi bir kod listesiyle arama ve toplu ekleme deneyin. Hatalı veya kapsam dışı satırın açık açıklaması bulunsun.
Teknik bilgi
Belge, ölçü ve paket birimini ürünle doğru eşleştirin. İlgili olmayan belge hızlı siparişi hızlandırmaz; yanlış siparişi kolaylaştırır.
OKUMADAN SONRAKİ ADIMA
Bayi portalınızın ilk siparişini birlikte sınayalım
Bayi rollerini, fiyat örneklerini ve ERP akışını paylaşın. Kritik kabul senaryolarını yayın planına çevirelim.
Fiyat, miktar ve limit kurallarını yazılı örneğe bağlayın
ERP ve mağaza entegrasyonu kontrolü fiyatın hangi kaynaktan geleceğini belirler. Bayi grubu indirimi, sözleşmeye özel fiyat, miktar kademesi ve kampanya birlikte varsa hangi sırayla uygulanacağı yazılmalıdır. Yazılı kural bulunmadan sadece ekranda düşük fiyat görünmesini başarı saymayın.
Örnek bir kontrolde eşik altı ve üstü sipariş miktarı, farklı şube ve kampanya dışı ürün denenir. Paket miktarı değiştiğinde toplamın ve minimum sipariş kuralının doğru hesaplandığını inceleyin. Finans ekibi onaylı kredi veya ödeme koşullarının anlamını belirler; portal bu koşulu uygulamakla sorumludur.
Limit veya hesap durumu sipariş sırasında değişebilir. Eski sekmede açık kalan sepetin güncel kurala göre yeniden kontrol edilmesi gerekir. Müşteri fiyat değişimini anlaşılır şekilde görmeli; sipariş kayıtları hangi fiyat ve onayla işlem yapıldığını gösterebilmelidir.
Teklif, taslak ve kesin siparişi birbirinden ayırın
Web uygulaması geliştirme sırasında durum adları operasyonla birlikte tanımlanmalıdır. Taslak sepet, fiyat talebi, onay bekleyen sipariş ve ERP’ye kabul edilmiş sipariş aynı şey değildir. Kullanıcıya kesin işlem yapılmış izlenimi vermeden mevcut durum açıkça gösterilmelidir.
Örnek bir iş akışında alıcı taslağı oluşturur, şube yöneticisi onaylar ve iç satış ekibi özel fiyatı değerlendirir. Gerçek işletme farklı bir sıra kullanabilir. Her geçişte kimin yetkili olduğu, hangi bilginin değişebileceği ve hangi bildirimin gönderileceği belirlenir.
İptal, kısmi teslimat ve iade talebi için de durumlar test edilir. Siparişin iptal edilmesi ödemeyi, stoğu ve sevkiyatı otomatik olarak aynı anda düzeltmeyebilir. Kullanıcı hangi işin tamamlandığını, hangisinin ekip incelemesinde olduğunu görebilmelidir.
Taslak ve teklif
Henüz kesin sipariş oluşturmayan işlemleri açık adlandırın. Fiyat veya teslimat onayı gerektiğinde bunun sahibi belli olsun.
Onay ve gönderim
Yetkili onay sonrası hedef sistemin kabul kaydını saklayın. Formun gönderilmesi ERP kabulüyle karıştırılmasın.
İstisna
İptal, değişiklik ve iade için ayrı sonuç bekleyin. Finans ve stok etkisini sorumlu ekip doğrulasın.
ERP kabulünü ve hata kurtarmayı prova edin
ERP entegrasyon kontrol listesi bağlantının yalnızca başarılı örnekte değil zaman aşımı ve tekrar gönderimde de sınanmasını sağlar. Aynı sipariş tekrar işlendiğinde ikinci bir kayıt oluşmaması gerekir. Kaynak işlem kimliğiyle hedef kayıt ilişkisi izlenebilir tutulmalıdır.
Ürün kodu bulunamaması, güncel fiyat alınamaması ve ERP’nin geçici olarak yanıt vermemesi farklı hatalardır. Hepsini “tekrar deneyin” mesajına indirgemeyin. Kullanıcıya ne yapabileceği, ekibe hangi kaydın inceleneceği gösterilmelidir. Otomatik tekrarın güvenli olduğu ve insan kararının gerektiği durumlar ayrılır.
Operasyon ekibi hata kuyruğunu okuyup doğru işlemi başlatabilmelidir. Teknik günlüklerde gereksiz müşteri belgesi veya kişisel veri saklanmamalı; gerekli işlem izi yetkili erişimle korunmalıdır. Kabul kanıtında başarılı aktarım yanında en azından seçilmiş hata ve kurtarma örnekleri de bulunsun.
Az sayıda bayiyle pilot, sonra kontrollü genişleme yapın
Teknik liderlik desteği farklı ekiplerin yayın kararını ortak kabul ölçütlerine bağlamaya yardımcı olur. İlk pilotta farklı rol ve sipariş davranışı olan temsilî bayiler seçin. Bu bir müşteri sonucu iddiası değildir; portalın çalışmasını doğrulamak için önerilen bir yayın yaklaşımıdır.
Eğitimde yalnızca ekran turu yapmayın. Bayi bir sipariş oluştursun, onaylayan kişi görevi tamamlasın, operasyon ERP kaydını görsün ve bir hata durumunun kime gideceği anlatılsın. Kullanıcıların ilk soruları arayüz ve işlem adlarının ne kadar açık olduğunu gösterir.
Pilot sonrası aktif kullanım, tamamlanan geçerli sipariş, hata nedenleri ve destek ihtiyacını birlikte değerlendirin. Çok kullanıcı eklemek başarı ölçütü değildir. Teslim belgesi rol matrisi, ticari kural örnekleri, entegrasyon kanıtları, eğitim görevleri ve açık istisna sahiplerini içermelidir.
Pilot kapsamı
Bayileri rol ve işlem çeşitliliğiyle seçin. Kritik kuralı deneyen hesaplar sayıca büyük fakat tek tip gruptan daha yararlıdır.
İşletim devri
Destek, erişim değişikliği ve fiyat hatası için sorumluları açıklayın. Yayın sonrası kararları sahipsiz bırakmayın.
Kontrol listesini al ve kapsamını değerlendir
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Bayi portalı için standart e-ticaret sitesi yeterli mi?
Şirket hesabı, özel fiyat, onay ve ERP ihtiyaçlarıyla karşılaştırılır. Bazı işletmeler standart özelliklerle ilerleyebilir; bazı kurallar uygulama veya özel geliştirme gerektirir. Platform planı ve koşulları doğrulanmalıdır.
Bayiye özel fiyatı kim belirlemeli?
Ticari ve finans sorumluları kaynak kuralı onaylar. Teknik ekip bu kuralın rol, miktar ve tarih gibi durumlarda tutarlı uygulandığını test eder; fiyat stratejisini kendiliğinden değiştirmez.
Yetki kontrolünde sadece menüleri gizlemek yeterli mi?
Hayır. Veri ve işlem isteklerinde de yetki uygulanmalıdır. Kontrollü test hesaplarıyla diğer bayi veya şube kapsamındaki kayıtların erişilemediği doğrulanır.
Sipariş gönderildiğinde hemen kesinleşmiş olur mu?
İş akışına bağlıdır. Onay, fiyat değerlendirmesi veya ERP kabulü gerekiyorsa kullanıcı bu ara durumu görmelidir. Form gönderimi ile hedef sistem kabulü ayrı kanıtlardır.
ERP erişilemezse sipariş kaybolmalı mı?
Kayıt ve hata akışı kapsamda tasarlanmalıdır. Güvenli bekletme, tekrar işleme ve insan müdahalesi kuralları belirlenir. Aynı siparişin iki kez oluşmadığı da test edilmelidir.
Pilot başarısını nasıl değerlendirmeliyiz?
Geçerli siparişin uçtan uca tamamlanması, doğru fiyat ve yetki, hata kurtarma ve kullanıcının destek ihtiyacı birlikte incelenir. Sadece açılan bayi hesabı sayısı işleyişi kanıtlamaz.
KAPSAMI BİRLİKTE BELİRLEYELİM
Bayi portalınızın ilk siparişini birlikte sınayalım
Bayi rollerini, fiyat örneklerini ve ERP akışını paylaşın. Kritik kabul senaryolarını yayın planına çevirelim.
Portal lansmanını görüşün