Bayi portalı konsepti

Bağlam: bayi siparişi neden üç kez yazılır?

Bu konseptte ürünlerini bayiler aracılığıyla satan varsayımsal bir üretici ya da dağıtıcıyı düşündük. Böyle kurumlarda sipariş genellikle telefonla ya da e-postayla gelir. Bayi siparişi yazar, satış destek ekibi aynı bilgiyi sipariş sistemine girer, muhasebe ise faturayı keserken bir kez daha yazar. Her aktarımda hata olasılığı doğar. Bayi stok durumunu bilmeden sipariş verir, siparişinin nerede olduğunu öğrenmek için yine telefon açar. Bayi portalı, bu trafiği bayinin kendi ekranına taşır.

Hedef kullanıcılar

• Bayi çalışanı: Sipariş vermek, önceki siparişi tekrarlamak ve teslimat durumunu görmek ister. Portalı her gün kullanmayabilir; bu yüzden ekranlar eğitim gerektirmeyecek kadar açık olmalıdır.
• Bayi sahibi: Cari bakiyesini, açık siparişlerini ve fatura geçmişini görmek ister.
• Satış destek ekibi: Gelen siparişleri onaylar, istisnaları çözer. Telefonla sipariş almak yerine sorunlu siparişlere zaman ayırır.
• Yönetici: Bayi bazında sipariş hacmini ve bekleyen işleri izler.

Bilgi mimarisi

Bayi tarafında menü beş başlıktan oluşur: Ürünler, Sepet, Siparişlerim, Cari hesap ve Duyurular. Yönetim tarafında ise Siparişler, Bayiler, Ürün ve fiyat listeleri ile Raporlar bulunur.

En önemli tasarım kararı tek kaynak ilkesidir. Stok, fiyat ve cari bakiye portalda ayrıca tutulmaz; kurumun mevcut stok ve muhasebe sisteminden gelir. Portal bir gösterim ve sipariş katmanıdır. Böylece “portaldaki fiyat başka, sistemdeki başka” durumu yaşanmaz.

Ekran ekran tasarım kararları

Ürün kataloğu ve hızlı sipariş

Katalog iki biçimde kullanılır. Yeni ürün arayan bayi görselli listeden ilerler. Ne isteyeceğini bilen bayi ise ürün kodunu ve adedi yazarak hızlı sipariş tablosunu doldurur. Her bayi kendi fiyat listesini ve kendisine tanımlı koşulları görür; stokta olmayan ürünün durumu açıkça yazılır.

Sepet ve sipariş onayı

Sepette toplam, teslimat adresi ve varsa bakiye durumu bir arada görünür. Sipariş gönderildiğinde bayi bir sipariş numarası alır ve kayıt satış destek ekibinin ekranına düşer. Kurala uyan siparişler doğrudan işleme alınabilir; sınırı aşanlar onaya kalır.

Siparişlerim

Her siparişin durumu adım adım görünür: alındı, onaylandı, hazırlanıyor, sevk edildi, teslim edildi. Bayi önceki bir siparişi tek düğmeyle sepete kopyalayabilir. Durum değiştiğinde bildirim gider; bayinin sormasına gerek kalmaz.

Yönetici raporları

Yönetim ekranı, bekleyen siparişleri ve bayi bazında özetleri gösterir. Konseptteki sayılar örnek veridir; amaç hangi sorunun hangi ekranda yanıtlandığını göstermektir.

Teknik altyapı

• Entegrasyon: Stok, fiyat ve cari bilgisi kurumun ERP ya da muhasebe yazılımından alınır; onaylanan sipariş aynı sisteme yazılır. Bağlantı yolu (API, zamanlanmış aktarım ya da veritabanı) karşı sistemin imkânlarına göre analizde belirlenir.
• Hata durumu: Karşı sistem yanıt vermediğinde sipariş kaybolmaz; kuyruğa alınır ve bağlantı geldiğinde iletilir.
• Yetki: Her bayi yalnızca kendi verisini görür. Bayi içinde sipariş veren ve yalnızca görüntüleyen kullanıcılar ayrılabilir.
• İşlem kaydı: Kimin, ne zaman, hangi siparişi verdiği ya da değiştirdiği saklanır.
• Erişim: Portal tarayıcıda çalışır ve telefona uyumludur; bayinin bir program kurması gerekmez.

Başarıyı nasıl ölçerdik?

Bu bir konsept çalışmadır ve ölçülmüş bir sonucu yoktur. Gerçek bir uygulamada aşağıdaki hedefleri belirler, portal öncesindeki durumla karşılaştırırdık.

• Siparişlerin ne kadarının portal üzerinden, ne kadarının hâlâ telefon ve e-postayla geldiği.
• Sipariş girişinden kaynaklanan hata ve düzeltme sayısı.
• Sipariş durumu sormak için yapılan aramaların azalması.
• Bir siparişin alınmasından onaylanmasına kadar geçen süre.
• Portalı etkin kullanan bayi sayısı.

Benzer bir kurumda nasıl uygulanır?

İlk adım mevcut sipariş akışını ve bağlanılacak sistemleri incelemektir. Stok ve muhasebe yazılımının dışarıya nasıl veri verdiği, projenin hem süresini hem kapsamını belirleyen ana etkendir; bu yüzden entegrasyon incelemesi tasarımdan önce yapılır. Ardından ekranlar, birkaç bayinin de katıldığı bir prototip denemesinden geçer.

Portal genellikle dar bir kapsamla açılır: katalog, sipariş ve durum takibi. Cari hesap, iade ve kampanya gibi bölümler sonraki sürümlerde eklenir. İlk dönemde portal birkaç bayiyle denenir, geri bildirimle düzeltilir ve sonra tümüne açılır. Yöntemin ayrıntısı kuruma özel uygulamalar sayfasındadır; bayi ilişkilerini satış tarafıyla birleştirmek isteyenler için kurumlara özel CRM sistemleri sayfasına da bakılabilir.

Benzer bir ihtiyacınız varsa kapsamı birlikte konuşalım; yöntemin tamamı için Kuruma Özel Uygulamalar sayfasına bakabilirsiniz.