Bayi Başvuru ve Onboarding Portalı: Belge, Onay ve Hesap Açılışı Rehberi

Bayi başvuru ve onboarding portalı, bir formu dijital ortama taşımaktan ibaret değildir. Adayın kim olduğunu, hangi ticari modele uygun bulunduğunu, hangi belgelerin doğrulandığını, kararı kimin verdiğini ve hesap açılmadan önce hangi koşulların tamamlandığını izlenebilir bir akışa dönüştürür.

Bu rehber satış kanalı, operasyon, finans, hukuk ve BT ekipleri için hazırlanmıştır. Amaç otomatik kabul değil; doğrulanabilir bilgi, ayrıştırılmış yetki ve insan kararıyla çalışan güvenli bir başvuru sistemi tasarlamaktır.

Onboarding neden tek formdan daha büyüktür?

Bir aday iletişim bilgilerini gönderdiğinde henüz bayi olmaz. Faaliyet alanı, bölge, kanal çakışması, ticari yeterlilik, belge geçerliliği, sözleşme ve hesap yetkileri ayrı karar noktalarıdır. Hepsini tek bir “onaylandı” alanına sıkıştırmak eksik başvuruları, belirsiz sorumluluğu ve kontrolsüz hesap açılışını gizler.

NIST’in dijital kimlik kılavuzu kimlik kanıtlamayı çözümleme, kanıtı doğrulama, kişiyi doğrulama ve kayıt adımlarıyla ele alır. Bayi portalı bu standardı birebir uygulamak zorunda değildir; ancak “belge yüklendi” ile “kurum ve yetkili doğrulandı” arasındaki farkı korumalıdır. NIST SP 800-63A risk temelli kimlik kanıtlama sürecini açıklar.

Yedi kapılı bayi kabul modeli

1. Başvuru: Kurum, yetkili, bölge ve faaliyet bilgileri alınır.
2. Uygunluk: Kanal, ürün grubu ve bölge kuralları incelenir.
3. Belge: Gerekli dosyalar tür, sürüm ve geçerlilik tarihiyle doğrulanır.
4. Ticari inceleme: Fiyat grubu, ödeme modeli ve limit kararı verilir.
5. Sözleşme: Doğru metin, doğru taraf ve sürümle kabul edilir.
6. Hesap açılışı: ERP/CRM ve portal kimlikleri kontrollü oluşturulur.
7. İlk sipariş hazırlığı: Kullanıcı, teslimat adresi, fiyat ve yetki test edilir.

Veri modelini başvuru durumundan ayırın

Aday kurum, yetkili kişi, başvuru, belge, inceleme, karar, sözleşme ve açılan hesap ayrı kayıtlar olmalıdır. Böylece bir kurum ikinci bölge için yeniden başvurduğunda kimlik bilgileri kopyalanmaz; yeni başvuru kendi kapsamı ve karar geçmişiyle izlenir.

Her değişiklikte kim, ne zaman, hangi kaynaktan ve hangi gerekçeyle alanı güncellediği tutulmalıdır. Serbest metin notların yanında kontrollü ret, iade ve bekleme nedenleri bulunmalı; ancak adayın görmemesi gereken iç notlar ayrı yetkilendirilmelidir.

Formu koşullu ve tamamlanabilir tasarlayın

İlk ekranda her olası alanı istemek yerine şirket türü, ülke, faaliyet alanı ve kanal seçimine göre gerekli soruları açın. Taslak kaydetme, kaldığı yerden devam etme, belge gereksinimi açıklaması ve tamamlanma listesi sunun. Kullanıcının aynı bilgiyi forma ve belgeye tekrar yazması gerekiyorsa hangi kaynağın esas olduğunu belirtin.

Telefon ve e-posta doğrulaması iletişim kanalını kanıtlar; kişinin şirketi temsil yetkisini tek başına kanıtlamaz. Bu ayrım hem ekranda hem karar kurallarında korunmalıdır.

Belge yüklemeyi güvenli bir işlem olarak ele alın

Dosya uzantısına güvenmeyin. İzin verilen türleri sınırlayın, dosya imzasını kontrol edin, yeniden adlandırın, boyut sınırı uygulayın, zararlı içerik taraması yapın ve dosyaları doğrudan web kökünde tutmayın. OWASP, dosya yüklemede uzantı, içerik türü, imza, ad, boyut, depolama ve yetki kontrollerinin birlikte kullanılmasını önerir. OWASP File Upload Cheat Sheet katmanlı kontrolleri özetler.

Belgeyi salt “var/yok” olarak tutmayın. Belge türü, sahip kurum, dönem, sürüm, yükleyen, doğrulayan, geçerlilik ve reddetme nedeni kaydedilmelidir. Süresi dolan belgenin mevcut hesabı nasıl etkileyeceği de ayrı politika olmalıdır.

Otomasyon kararı desteklesin, sahiplenmesin

Alan biçimi, tekrar eden vergi numarası, eksik belge veya yasaklı dosya türü otomatik kontrol edilebilir. Ticari uygunluk, bölge çakışması veya istisnai limit gibi kararlar ise sorumlu role atanmalıdır. Bir kural başvuruyu durdurduğunda kullanılan kural sürümü ve açıklanabilir neden saklanmalıdır.

Ret kararında gereksiz iç ayrıntı ifşa edilmeden anlaşılır kategori ve gerekiyorsa yeniden başvuru yolu sunulmalıdır. Manuel geçersiz kılma varsa yalnızca yetkili rol kullanabilmeli ve gerekçe zorunlu olmalıdır.

ERP, CRM ve portal hesap açılışını sıralayın

CRM aday kaydı, ERP cari hesabı ve portal kullanıcısı aynı anda başarıyla oluşmayabilir. Her sistem için idempotent istek anahtarı, harici kimlik, durum, yeniden deneme ve insan inceleme kuyruğu tanımlayın. ERP hesabı başarısızken portalın siparişe açılmasını engelleyin.

Fiyat grubu, para birimi, vergi davranışı, teslimat deposu, satış temsilcisi ve kredi koşulu gibi alanlarda hangi sistemin kaynak olduğunu yazılı hale getirin. Benzer alan sahipliği yaklaşımını e-ticaret ve ERP entegrasyonu rehberinde ayrıntılı inceleyebilirsiniz.

Yetkiyi kurum hesabından başlatın

İlk kullanıcı her zaman süresiz yönetici olmamalıdır. Kurum yöneticisi, satın almacı, finans ve depo rolleri için davet, kabul, iptal ve devir kuralları tasarlayın. Ayrılan bir çalışanın erişimini kurum yöneticisinin kapatabilmesi; yönetici kalmadığında ise kontrollü kurtarma akışı bulunması gerekir.

Kabul testleri ve başarı göstergeleri

• Aynı vergi kimliğiyle mükerrer başvuru ve farklı bölge talebi;
• Yanlış uzantılı, büyük, bozuk veya zararlı belge;
• Belge sürümü değişirken devam eden inceleme;
• Bir onaycının izinde veya yetkisinin kaldırılmış olması;
• CRM başarılı, ERP başarısız ve tekrar denenen hesap açılışı;
• Başka kuruma ait başvuru veya belge URL’sine erişim denemesi;
• Mobil cihaz, klavye ve ekran okuyucuyla form tamamlama.

Başvuru sayısı tek başına başarı değildir. Tamamlama oranı, adım başı bekleme süresi, tekrar istenen belge, açıklamasız ret, entegrasyon hatası, ilk giriş ve ilk geçerli siparişe hazırlık gibi göstergeler izlenmelidir. Hedefler gerçek başlangıç verisine göre belirlenmelidir.

Sonuç

Uygulamayı dört teslimata bölün

Keşif ve karar haritası: Mevcut başvuruları, gerçek ret ve iade nedenlerini, belge türlerini, onay sürelerini ve sistem kırılmalarını örnek kayıtlarla inceleyin. Her kapı için girdi, sorumlu, hizmet seviyesi, aday mesajı ve çıkış koşulu yazın. Hukuki gereksinimleri varsaymak yerine ilgili hukuk ve uyum sorumlularına onaylatın.

Pilot ürün: Tek ülke, sınırlı bayi tipi ve az sayıda belgeyle çalışan ilk sürüm kurun. Form, taslak, dosya, inceleme kuyruğu, karar geçmişi ve temel bildirimleri tamamlayın. ERP hesabını otomatik açmak yerine ilk pilotta kontrollü görev üretmek, veri eşlemesini gerçek başvurularla doğrulamayı kolaylaştırabilir.

Entegrasyon ve yetki: Onaylanan alanları CRM ve ERP’ye idempotent işlemlerle aktarın; geri dönen kimlikleri başvuruya bağlayın. Kurum hesabını, ilk kullanıcıyı, rol davetlerini ve siparişe hazırlık kontrolünü ayrı aşamalarda etkinleştirin.

Ölçüm ve genişletme: Pilot tamamlandığında hangi alanların terk edilmeye, hangi belgelerin yeniden istenmesine ve hangi kararların beklemeye yol açtığını inceleyin. Yeni ülke, bayi tipi veya otomasyon kuralını ancak sahip, test ve geri alma planıyla ekleyin.

Teklif kapsamında hangi çıktılar bulunmalı?

• Başvuru, kurum, yetkili, belge, karar, sözleşme ve hesap veri modeli;
• Koşullu form, taslak ve belge gereksinimi matrisi;
• Durum sözlüğü, onay rolleri, eskalasyon ve vekâlet akışları;
• Dosya güvenliği, saklama, silme ve erişim politikaları;
• CRM/ERP alan eşlemesi, hata kuyruğu ve yeniden deneme kuralları;
• Erişilebilirlik, güvenlik, entegrasyon ve sınır durumu testleri;
• Operasyon paneli, denetim kaydı, temel raporlar ve teknik devir dokümanı.

Kapsamı “yapay zekâ belgeleri okur ve bayiyi açar” gibi belirsiz bir vaatle tanımlamayın. Hangi alanın çıkarılacağı, hangi kanıtla karşılaştırılacağı, güven eşiği düştüğünde kimin inceleyeceği ve yanlış sonucun nasıl düzeltileceği yazılı olmalıdır.

Sağlam onboarding; daha hızlı formdan önce daha açık karar, güvenli belge, kontrollü yetki ve geri izlenebilir entegrasyon demektir. Kendi bayi kabul sürecinizi dijitalleştirmek istiyorsanız Kumsal Ajans web yazılım hizmetlerini inceleyebilir; görüşme öncesinde mevcut form, belge listesi, onay rolleri, sözleşme sürümleri ve sistem alanlarını hazırlayabilirsiniz.