Bir bayi portalının değeri, giriş yaptıktan sonra açılan ekran sayısıyla ölçülmez. Bayinin doğru ürün belgesine ulaşabilmesi, talebinin kimde olduğunu görebilmesi ve merkez ekibin işi izleyebilmesi daha belirleyicidir. Aynı portalda farklı bayiler çalışırken hangi bilginin kimlere açılacağı belirsizse, basit görünen bir geliştirme kısa sürede operasyon sorununa dönüşebilir. Bu nedenle proje, modül listesinden önce yetki ve iş akışı kararlarıyla başlamalıdır.
İyi planlanmış bir web yazılım projesi, kullanıcının yapacağı işi, erişebileceği kayıtları ve işlemin hangi koşulda tamamlanacağını birlikte tanımlar. Bu rehberde bayi rollerini, ürün belgelerini, talep durumlarını, veri erişimini ve teslim testlerini ele alıyoruz. Kullanılan dağıtıcı firma örnekleri varsayımsaldır; gerçek bir müşteri uygulamasını veya elde edilmiş ticari sonucu temsil etmez.
Bayi Portalının Çözeceği Günlük İşi Tanımlayın
Önce bayilerden ve merkez ekipten en sık tekrar eden işleri toplayın. Güncel katalog istemek, teknik belge bulmak, ürün uygunluğu sormak, teklif talebi açmak veya bir başvurunun sonucunu öğrenmek farklı ihtiyaçlardır. Her biri için bugün kullanılan kanalı, gereken bilgileri ve işi sonuçlandıran kişiyi yazın. Portalın ilk sürümünü bu somut görevlerden hareketle kurmak, herkesin farklı anlam yüklediği “bayi yönetimi” ifadesini açıklığa kavuşturur.
Herkese açık kurumsal web sitesi, markayı ve ürünleri tanıtırken bayi portalı tanımlanmış kullanıcıların işlerini yürütür. İki yapının içerik kaynakları ortak olabilir; erişim ve işlem kuralları ayrıca tasarlanmalıdır. Her ürün belgesini giriş arkasına almak da bütün bayi işlemlerini genel iletişim formuna bırakmak da kendiliğinden doğru değildir. Bilginin hedef kitlesine ve ticari sürecin niteliğine göre karar verin.
Yeni iş ortaklarının ilk başvurusu ayrı bir akış olabilir. B2B web tasarımda talep sayfası yapısı, henüz bayi olmayan ziyaretçinin hangi bilgileri vermesi gerektiğini planlamak için tamamlayıcıdır. Başvurunun alınması ile bayi hesabının açılması arasına değerlendirme ve onay adımı koyulacaksa, bu ayrımı kullanıcıya ve merkez ekibe açık biçimde gösterin.
Kullanıcıyı, Bayiyi ve Rolü Ayrı Kavramlar Olarak Kurun
Bir bayi birden fazla çalışanla işlem yapabilir. Aynı çalışan birden fazla şubeyi yönetebilir veya merkezdeki bir satış sorumlusu belirli bayilerden sorumlu olabilir. Bu ilişkileri tek bir kullanıcı adı alanına sıkıştırmak sonraki geliştirmeleri zorlaştırır. Kullanıcı kişiyi, bayi ticari organizasyonu, rol ise kişinin yapabileceği işlemleri tanımlasın. Şube veya bölge gibi ek sınırlar gerekiyorsa bunları da iş modeline açıkça ekleyin.
Varsayımsal bir teknik ekipman dağıtıcısında bayi çalışanı ürün belgelerini inceleyebilir ve kendi bayisi adına talep hazırlayabilir. Bayi yöneticisi aynı bayinin açık taleplerini görebilir; merkez satış sorumlusu atandığı bayilerin taleplerini değerlendirir. İçerik sorumlusu ise ürün belgelerini günceller. Bu örnek bir zorunlu rol şeması değildir. Görevler farklıysa roller de farklılaşmalıdır; amaç kurum unvanlarını doğrudan yazılım yetkisine çevirmek yerine gerçek işlemleri tarif etmektir.
Yetki Tablosunu İşlem ve Kayıt Kapsamıyla Yazın
Yetki tablosunda yalnız “görür” ve “göremez” sütunları bulunması çoğu projede yetersiz kalır. Görüntüleme, oluşturma, düzenleme, onaya gönderme, onaylama, dışa aktarma ve arşivleme ayrı işlemlerdir. Her işlem için hangi kayıtların kapsama girdiğini yazın. Bir kullanıcının kendi taslağını düzenlemesiyle, aynı bayinin başka çalışanının gönderilmiş talebini değiştirmesi aynı izin değildir. Ürün belgelerinde de görüntüleme ile yayımlama birbirinden ayrılmalıdır.
Başlangıç için aşağıdaki görev tanımları üzerinden konuşabilirsiniz. Bir rolün ihtiyacı değiştiğinde bütün yetkileri genişletmek yerine hangi işlem ve kayıt kapsamının değiştiğini belirleyin. “Yönetici” kelimesinin herkes için aynı yetkiyi ifade ettiğini varsaymayın; bayi yöneticisinin başka bayilerin ticari kayıtlarını görmesi gerekmeyebilir.
- Bayi çalışanı: Kendi bayisinin izin verilen ürün belgelerini inceler, talep taslağı oluşturur ve yetkisi varsa gönderir.
- Bayi yöneticisi: Kendi organizasyonundaki tanımlı talepleri izler; kullanıcı ekleme veya onaylama yetkisi ayrıca kararlaştırılır.
- Merkez satış sorumlusu: Kendisine atanmış bayi taleplerini değerlendirir, açıklama ister ve yetkili olduğu durum değişikliklerini yapar.
- Ürün içerik sorumlusu: Belge ve ürün bilgisini günceller; ticari talepleri onaylama yetkisini kendiliğinden kazanmaz.
Bayi Bazındaki Veri Sınırını Her Ekranda Koruyun
İki kişi aynı role sahip olsa bile farklı bayilere ait kayıtlarla çalışabilir. Bu nedenle rol kontrolünün yanında kullanıcının ilgili bayi veya kayıttaki ilişkisi değerlendirilmelidir. Liste ekranı, arama, detay, belge indirme ve dışa aktarma aynı kapsam kararını uygulamalıdır. Örneğin yalnız kendi bayisinin taleplerini görmesi gereken bir çalışan, toplu raporda başka bayilerin bilgilerine ulaşamamalıdır.
OWASP yetkilendirme rehberi, en az yetki, varsayılan olarak erişimi reddetme ve her istekte yetki doğrulama ilkelerini vurgular. Bir düğmeyi arayüzden gizlemek erişim kontrolünün yerine geçmez; karar sunucu tarafında uygulanmalıdır. Proje kabulünde, yetkisiz bir kullanıcının doğrudan kayıt veya dosya adresini açmayı denediğinde de korunmanın sürdüğü doğrulanmalıdır.
Hangi kuralların hazır sistemde karşılandığını, hangilerinin ek geliştirme gerektirdiğini başlangıçta değerlendirin. Özel web yazılım ile hazır sistem karşılaştırması, bu kararı modül sayısının ötesine taşır. Bayi, şube ve merkez ilişkilerinizin desteklenmesi; kapsamın bakım sırasında anlaşılır kalması ve kuralların test edilebilmesi seçimde somut ölçütler olabilir.
Talep Durumlarını ve Geçiş Yetkilerini Belirleyin
Bir teklif talebi için taslak, gönderildi, incelemede, ek bilgi bekleniyor ve sonuçlandı gibi durumlar tanımlanabilir. Ancak bu adlar tek başına iş akışı oluşturmaz. Hangi rolün hangi durumdan hangi duruma geçebileceği, geçişte gereken alanlar ve geri dönüş koşulları da yazılmalıdır. Bayi çalışanının talebini göndermesiyle merkez ekibin ticari onay vermesi ayrı olaylar olarak ele alınmalıdır.
Her durumun kullanıcı açısından anlamı bulunmalıdır. “İşleniyor” ifadesi teknik kuyruğu mu, satış incelemesini mi anlatıyor? Ek bilgi beklendiğinde hangi sorunun cevaplanması gerekiyor? Sonuçlanan talep yeniden açılabilir mi? Bu kararlar başlangıçta verilirse ekipler aynı ekranı farklı biçimde yorumlamaz. Akışın başına ve sonuna odaklanıp aradaki bekleme ve düzeltme adımlarını belirsiz bırakmayın.
Gönderilen Talebin Değişiklik Kuralını Açık Tutun
Varsayımsal dağıtıcı firmada bayi, gönderdiği talebin miktarını sonradan değiştirmek istiyor olsun. Merkez ekip incelemeye başladıysa sessizce eski kaydın üzerine yazmak yerine revizyon veya değişiklik talebi akışı tasarlanabilir. Eski ve yeni bilginin karşılaştırılabilmesi, incelemenin hangi sürüm üzerinden yapıldığının anlaşılmasını sağlar. Aynı kayda eşzamanlı işlem yapıldığında da kullanıcıya güncel durum gösterilmeli; önceki ekranın hâlâ geçerli olduğu varsayılmamalıdır.
Talebi Siparişe Dönüştüren Adımı Ayrıca Tasarlayın
Portalda bir talep oluşturulması, mutlaka ticari sipariş oluştuğu anlamına gelmez. İşletmenin onay, ürün uygunluğu veya başka bir kontrolü varsa bu koşullar tamamlanmadan sonraki aşama başlamamalıdır. Kullanıcının ekranında talep numarası, durum ve beklenen sonraki adım açıkça görünmelidir. Bağlantı sorunu yaşandığında aynı düğmeye yeniden basılması da süreçte ikinci bir iş oluşturma riski açısından değerlendirilmelidir.
ERP veya CRM bağlantısı kurulacaksa veri kaynağı, eşleştirme, tekrar işleme ve hata yönetimi ayrı kapsamdır. CRM ve ERP entegrasyonu planlama rehberi, bu bağlantının teknik kabul koşullarını ayrıntılandırır. Bayi portalında ise kullanıcının gördüğü durumla merkezdeki gerçek iş sonucunun nasıl eşleşeceğini belirleyin. Aktarım bekleyen bir kayıt, tamamlanmış sipariş gibi sunulmamalıdır.
Ürün Belgelerini Sürüm ve Hedef Kitleyle Yönetin
Belge alanında yalnız dosya adı göstermek yerine ürün kodu, belge türü, dil, sürüm ve yayımlanma durumunu birlikte planlayın. Teknik föy, kurulum kılavuzu ve ticari doküman farklı kullanıcı gruplarına açılabilir. Bir dosyanın eski sürümü arşivlendiğinde geçmiş taleple ilişkisi nasıl korunacak, yeni kullanıcıya hangi sürüm gösterilecek ve hatalı belge nasıl geri çekilecek sorularını cevaplayın. Güncelliği belirsiz belgeler, portalın kullanılmasını zorlaştırır.
Belgeyi hazırlayan kişiyle yayımlayan kişi farklı olabilir. Metin ve görsel hazırlama rehberindeki içerik envanteri, burada dosya kaynağı ve onaylı sürümün izlenmesine uyarlanabilir. Portal içeriğinde buna erişim grubu ve ürün ilişkisini ekleyin. “Yeni dosya yüklendi” bilgisinin hangi bayileri ilgilendirdiği böylece belirlenebilir; her güncellemeyi bütün kullanıcılara duyurmak zorunda kalmazsınız.
Dosya Yükleme ve İndirmeyi Aynı Kapsamda Ele Alın
Talebe ek dosya konulacaksa hangi türlerin gerektiğini, boyut sınırını ve dosyanın kime açılacağını kararlaştırın. Kullanıcıya kabul edilen biçimleri yükleme öncesinde gösterin; reddedilen dosyada anlaşılır düzeltme bilgisi verin. Yüklenen dosyanın talep sahibi, merkez sorumlusu ve destek personeli açısından görünürlüğü farklı olabilir. Ek dosyaların genel belge kütüphanesine karışmaması için ilişkilendirme kuralını açık tutun.
OWASP dosya yükleme önerileri, gerekli dosya türlerini sınırlandırmayı, tür doğrulamasını, boyut kontrolünü ve yetkili yüklemeyi birlikte ele alır; tarayıcının bildirdiği dosya türüne tek başına güvenilmemelidir. İndirme tarafında da korunan dosyanın doğrudan adresle herkese açılmaması gerekir. Bu kontrollerin uygulaması ve testleri geliştirmenin parçası olarak teslim kapsamına yazılmalıdır.
Bildirimleri Yetki ve Sorumluluğa Göre Dağıtın
Bildirim tasarımı, her durum değişikliğinde herkese e-posta göndermek değildir. Talebi değerlendirecek kişiye iş ataması, bayiye ek bilgi isteği veya belge sorumlusuna yayın onayı bildirimi farklı amaçlar taşır. Her olay için alıcı rolü, kanal, içerik ve tekrar koşulunu tanımlayın. Mesajın içeriği de alıcının görebileceği bilgiyle sınırlı olmalıdır; hassas ayrıntılar gerekiyorsa kullanıcı yetkili portal ekranına yönlendirilebilir.
Bayi temsilcisi değiştiğinde açık işlerin yeni sorumluya nasıl geçeceğini planlayın. Eski kullanıcıya bildirimlerin sürmesi veya merkezde sahipsiz talepler oluşması operasyonu aksatabilir. Panelde “kimde bekliyor” ve “hangi bilgi eksik” alanları anlaşılır olduğunda destek ekibi de süreci takip edebilir. Yanıt hedefleri işletme tarafından belirlenmeli; yazılıma yalnızca bir süre sayacı eklemek ekiplerin bu süreyi karşılayacağını garanti etmez.
Kullanıcı Yaşam Döngüsünü ve İşlem Geçmişini Unutmayın
Hesap daveti, ilk erişim, rol değişikliği, şube değişikliği ve erişimin kapatılması proje kapsamına dahil edilmelidir. Bir çalışan ayrıldığında hesabı kapatmak geçmiş talepleri sahipsiz veya anlaşılmaz hale getirmemelidir. Açık işin kime devredileceği ve yetki değişikliğinin mevcut oturumlara nasıl yansıyacağı belirlenmelidir. Ortak kullanıcı hesabı yerine kişi bazında çalışma düzeni kurulması, işlemin sorumlusunu takip etmeyi kolaylaştırır.
İşlem geçmişinde hangi olayın, ne zaman, hangi kullanıcı tarafından ve hangi sonuçla gerçekleştiği görülebilmelidir. OWASP uygulama günlüğü rehberi, olay bilgilerinin amaçla uyumlu kaydedilmesini ve parola, erişim anahtarı gibi sırların doğrudan günlüklere yazılmamasını ele alır. İşlem geçmişini görüntüleme yetkisi de tanımlanmalı; teknik kayıtlar, bayi ekranında gelişigüzel açılan bir veri kaynağına dönüşmemelidir.
Gerçek Görevlerle Kullanılabilirlik Kontrolü Yapın
Portal tasarımını ürün listesi ve boş form üzerinden onaylamak yerine kullanıcıya baştan sona bir görev verin. Belirli bir ürünün güncel belgesini bulması, bir talep açması, eksik bilgiyi tamamlaması ve sonucunu izlemesi istenebilir. Menü adlarının anlaşılması, arama sonuçlarının kapsamı ve formdaki hata açıklamaları bu sırada değerlendirilir. Bayinin işini telefon üzerinden yürütmesi bekleniyorsa aynı görev küçük ekranda da tamamlanmalıdır.
Mobil form ve menü kontrol yaklaşımı, bu görev testlerinin ekran boyutuna göre uyarlanmasına yardımcı olur. Portalda buna kullanıcı rolünü de ekleyin. Aynı ekranda farklı yetkilerin bulunması, açıklama veya yönlendirme ihtiyacı doğurabilir. Kullanıcı yetkisiz bir işleme yöneldiğinde karşılaşacağı mesaj, bilgi sızdırmadan ne yapabileceğini anlatmalı; beklenmedik boş sayfayla baş başa bırakılmamalıdır.
Kabul Testlerini Yetki Tablosundan Türetin
Yazılım geliştirmede kalite güvencesi, bayi portalında iş kurallarının gerçekten uygulandığının kanıtlanmasına dayanmalıdır. Test ortamında farklı bayilere bağlı temsili hesaplar kullanın. Yalnız izin verilen işlemlerin başarılı olduğunu görmek yeterli değildir; izin verilmeyen erişim ve geçişlerin de beklenen şekilde engellendiğini kontrol edin. Aşağıdaki senaryolar başlangıç için uyarlanabilir.
- Bayi ayrımı: Bir bayinin kullanıcısı başka bayinin talebini liste, detay, arama veya dışa aktarma üzerinden göremez.
- Durum geçişi: Taslak gönderebilen kullanıcı, merkez onayı gerektiren sonucu kendi başına oluşturamaz.
- Belge kapsamı: Kısıtlı ürün belgesi yetkisiz kullanıcıya doğrudan dosya adresiyle de açılmaz.
- Revizyon: İncelemedeki talep değiştiğinde eski ve yeni bilgi, tanımlanan onay akışına göre değerlendirilir.
- Hesap kapatma: Ayrılan kullanıcının erişimi kaldırılır; açık işler ve geçmiş kayıtlar belirlenen sorumlularla izlenebilir kalır.
- Kesinti: Kullanıcı gönderim sonucunu alamadığında mevcut talep kontrol edilir; aynı iş için gelişigüzel ikinci kayıt oluşturulmaz.
İlk Sürümü Daraltın, Teslim ve Bakımı Yazılılaştırın
İlk sürümde bütün ürünleri, siparişleri, kampanyaları ve raporları aynı anda açmak zorunda değilsiniz. Belge erişimi ve talep takibi gibi seçilmiş işlerle başlayıp pilot bayilerle görev testleri yapılabilir. Hangi kayıtların taşınacağı, test verilerinin nasıl ayrılacağı ve geri bildirimlerin kim tarafından önceliklendirileceği belirlenmelidir. İlk kapsamın bilinçli daraltılması, önemli yetki ve iş akışı kararlarının ertelenmesi anlamına gelmemelidir.
Takvimde iş birimi onaylarını, içerik hazırlığını ve varsa sağlayıcı bağlantılarını görünür kılın. Web tasarım ve geliştirme teslim planı, bu bağımlılıkları birlikte ele almak için kullanılabilir. Kabul dosyasında rol tablosu, durum geçişleri, veri kaynakları, test sonuçları, eğitim notları ve destek sorumluları bulunsun. Eğitim yalnız yöneticiye değil, bayinin gerçekten yapacağı görevlere göre hazırlanmalıdır.
Bakımda yeni bir rol eklenmesi, mevcut bağlantı hatasının giderilmesi ve yeni rapor geliştirilmesi aynı iş değildir. Site sahipliği ve destek sorumlulukları değerlendirilirken portal erişimleri, yedeklerin geri yükleme sorumlusu ve kullanıcı taleplerinin izleneceği kanal da belirlenebilir. Böylece ilk yayından sonra kimin hangi kararı vereceği belirsiz kalmaz.
Web Tasarım Sistemleri olarak bayi portalı ihtiyacını önce kullanıcı görevleri, kayıt kapsamı ve doğrulanabilir iş sonuçları üzerinden değerlendirmeyi öneriyoruz. Mevcut bayi yapınızı, kullanılan belgeleri ve örnek bir talebin nasıl sonuçlandığını bir araya getirerek bayi portalı projenizi bizimle görüşebilirsiniz. Sağlam başlangıç, bütün ekranları listelemekten önce doğru kişinin doğru kayıt üzerinde doğru işlemi yapacağı düzeni kurmaktır.
Bu makalenin uzunluğu 1825 kelimedir.
Bu makale 2026-10-18 tarihinde yayınlanmıştır.