Sanayi işletmeleri için B2B e-ticaret sitesi, ürünleri internete koyup fiyat göstermekten çok daha fazlasıdır. Düzenli çalışılan bayiler, servis firmaları ve proje müşterileri; son tüketiciden farklı fiyat gruplarıyla, farklı sipariş birimleriyle ve çoğu zaman onay gerektiren ticari koşullarla alışveriş yapar. Bu farklar baştan tanımlanmazsa portal açılır ama bayiler yine telefonla sipariş vermeye devam eder.
Bu rehberde İkitelli OSB’de hidrolik bağlantı parçaları üreten bir işletmeyi örnek alarak bayi hesaplarının nasıl kurulacağını, fiyat gruplarının nasıl tanımlanacağını ve teklif ile kesin siparişin nasıl ayrılacağını anlatıyoruz.
Kime, hangi koşulla satış yapacağınızı tanımlayın
İlk adım müşteri gruplarını listelemektir: yıllardır çalıştığınız bayiler, sanayi servisleri, proje bazlı alım yapan firmalar ve yeni başvuran işletmeler. Her grubun ürünleri görme, fiyat öğrenme ve doğrudan sipariş verme ihtiyacı farklıdır. Bazı müşteriler sadece katalogu incelemek isterken bazıları her hafta aynı parçaları tekrar sipariş eder.
İlk yayında hangi modelin çalışacağını netleştirin. Herkese açık katalog, yalnızca onaylı hesaplara gösterilen fiyatlar veya fiyat yerine teklif isteme düğmesi farklı kurallardır. Örnek işletme açılışta katalogu herkese açık tutuyor, fiyatları yalnızca onaylı bayilere gösteriyor ve standart dışı ölçüler için teklif akışı kullanıyor.
Satış temsilcilerinizin rolünü de plana ekleyin. Portalın siparişleri toplaması, tüm ticari kararların otomatik verileceği anlamına gelmez. Özel fiyat onayı, teknik uygunluk kontrolü veya sevkiyat planlaması yine belirlediğiniz kişilerde kalabilir. Bugün bir siparişin telefonda nasıl ilerlediğini adım adım yazın; portalda bu sıranın hangi kısmının değişeceğini o zaman net görürsünüz.
Bayi başvurusunu ve hesap onayını düzenleyin
Bayi başvurusu için gerekli firma bilgilerini (unvan, vergi dairesi ve numarası, faaliyet alanı, yetkili kişi) ve başvuruyu değerlendirecek kişiyi belirleyin. Başvurunun alınması ile hesabın aktif olması farklı aşamalardır. Başvuru incelenirken kullanıcının neleri görebileceğini, eksik bilgi olduğunda nasıl bilgilendirileceğini ve onaylandığında hangi yetkileri alacağını yazın.
Başvuru formunu gerçekten ihtiyaç duyduğunuz bilgilerle sınırlayın; her alanın neden istendiği belli olsun. Firma hesabının güncel tutulması ve artık çalışmadığınız bir bayinin erişiminin kapatılması için de sorumlu atayın.
Mevcut bayileri portala aktaracaksanız önce bir hesap listesi çıkarın. “Yılmaz Hidrolik” ile “Yılmaz Hidrolik San. Ltd.” aynı firma olmayabilir; iç müşteri kodu ve vergi numarası üzerinden eşleştirme yapın. Uzun süredir sipariş vermeyen hesapları ayırın. Aynı firmanın birden fazla şubesi varsa teslimat adresleri ile ticari hesap ilişkisinin nasıl kurulacağını belirleyin. Doğrulanmış bir bayi grubuyla başlamak, yanlış fiyatın veya sipariş geçmişinin başka firmaya bağlanma riskini azaltır.
Firma hesabı ile kullanıcı yetkilerini ayırın
Bir bayi firmasında portalı birden fazla kişi kullanabilir: ürünleri inceleyen teknisyen, sepeti hazırlayan satın alma uzmanı ve siparişi onaylayan yönetici. Her kullanıcının hangi firma hesabına bağlı olduğunu ve hangi işlemleri yapabileceğini ayrı tanımlayın.
| Rol | Yapabildiği işlem | Kontrol edilecek nokta |
|---|---|---|
| Teknik kullanıcı | Katalog ve teknik bilgileri görme | Fiyat görme yetkisi gerekli mi? |
| Satın alma sorumlusu | Sepet ve teklif hazırlama | Sipariş onaylama yetkisi sınırlı mı? |
| Firma yöneticisi | Siparişi onaylama, kullanıcı ekleme | Onay kaydı siparişe bağlanıyor mu? |
| Sizin operasyon ekibiniz | Hazırlık ve sevkiyat takibi | Doğru firma ve adres görünüyor mu? |
Roller işletmeden işletmeye değişir. Demo görüşmesinde yetkili kullanıcının işlemi tamamlayabildiğini ve yetkisiz bir kullanıcının o işleme erişemediğini birlikte görün. Bir alanın ekranda gizlenmesi ile yetki kontrolünün sunucu tarafında uygulanması aynı şey değildir.
Aynı denemeyi farklı firma hesaplarıyla yapın: bir bayinin özel fiyatı, teklif belgesi veya sipariş geçmişi başka bir firmanın hesabından görünmemelidir. Bir çalışan firmadan ayrıldığında erişiminin nasıl kapatılacağı da günlük yönetimin parçası olarak tanımlanmalıdır.
Fiyat gruplarını açık ve öncelikli kurallarla kurun
Her fiyatın hangi müşteri grubuna ve hangi ürün kapsamına ait olduğu net olmalıdır. Bayi seviyesi, sipariş miktarı veya firmaya özel anlaşmaya göre fiyat değişiyorsa her kural için somut bir örnek hazırlayın. Fiyatın hangi sistemden geldiğini ve ne sıklıkla güncellendiğini yazın.
Kurallar çakıştığında hangisinin geçerli olacağını belirleyin. Örneğin “A grubu bayilere %15 indirim” kuralı ile “X firmasına bu üründe net 240 TL” anlaşması aynı ürün için geçerliyse hangisi uygulanacak? Kampanya eklendiğinde önceki fiyatların başka hesaplara yanlışlıkla taşınmadığını ve sipariş kaydının doğru fiyatı sakladığını kontrol edin.
Para birimi, KDV’nin dahil mi hariç mi gösterildiği ve nakliye gibi ek hizmetlerin nasıl fiyatlandırılacağı işletmenizin ticari düzenine göre belirlenmelidir. Döviz bazlı fiyat kullanıyorsanız hangi kurun ve hangi saatte esas alınacağını açıkça yazın.
Fiyat denemesinde aynı ürünü iki farklı bayi grubuyla ve farklı miktarlarla sepete ekleyin. Ekranda görünen fiyat ile sipariş kaydına geçen fiyat aynı olmalıdır. Yanlış hesapta yanlış fiyat görürseniz yalnızca rakamı düzeltmeyin; müşteri grubu ile fiyat kaydı arasındaki ilişkinin neden yanlış kurulduğunu araştırın.
Teknik kataloğu sipariş birimleriyle birlikte kurun
Sanayi ürünlerinde parça kodu, malzeme, ölçü, basınç değeri ve uyumluluk bilgisi satın alma kararını belirler. Bu bilgileri üretim veya kalite kayıtlarınızdan doğrulayarak girin. Görünüşü benzeyen iki parçanın teknik olarak aynı olduğunu varsaymayın; diş tipi veya malzeme farkı ciddi sonuçlar doğurabilir.
Adet, kutu, koli veya set üzerinden satış yapıyorsanız birimleri ayrı ayrı tanımlayın. Örnek işletmede bir rakor modeli 25’li kutularda satılıyor; bayi 3 kutu sipariş ettiğinde depodan 75 adet çıkmalıdır. Stok adet bazında tutulup sipariş kutu bazında alınıyorsa bu dönüşüm sistemde açıkça kurulmalıdır. Aynı ürün hem tekli hem kutulu satılıyorsa iki sunumun aynı stoğu nasıl paylaştığını belirleyin.
Minimum sipariş miktarı ve artış adımı (örneğin yalnızca 25’in katları) gerekiyorsa bunları örnek ürünlerle deneyin. Ürün adına “25’li kutu” yazmak, sistemde birim dönüşümünün kurulduğu anlamına gelmez.
Teklif talebi ile kesin siparişi ayırın
Bir bayinin fiyat sorması veya standart dışı bir ölçü için teklif istemesi, üretim ya da sevkiyat emri vermesiyle aynı şey değildir. Teklif kaydında ürün, miktar, istenen teslim tarihi ve teknik açıklamalar bulunmalıdır. Talebin hangi ekibe düşeceği ve ne kadar sürede cevaplanacağı belirlenmelidir.
Teklifin geçerlilik süresini, onaylanan fiyatı ve kapsamını açıkça yazın. Müşteri miktarı veya ürünü değiştirirse önceki teklifin geçerli kalıp kalmayacağını belirleyin. Teklif siparişe dönüştüğünde hangi teklif sürümüne dayandığı kayıtta görünmelidir.
Ürünün stokta olması, müşterinin projesi için teknik olarak uygun olduğu anlamına gelmez. Gerekli teknik inceleme yapılmadan “uygundur” ifadesi kullanmayın. Teknik onay ve ticari onay farklı kişilerdeyse her adımın sonucu aynı kayda işlenmelidir; böylece müşterinin kabul ettiği sürüm ile operasyon ekibinin hazırladığı sürümün aynı olduğu doğrulanabilir.
Ödeme ve vade koşullarını tanımlayın
Peşin ödeme, havale, kredi kartı veya cari hesap gibi yöntemlerden hangisinin siparişi hazırlığa geçireceğini yazın. Ödemesi bekleyen sipariş ile hazırlanabilir sipariş aynı aşamada gösterilmemelidir. Kullanılacak ödeme sağlayıcısını ve bağlantı kapsamını ayrıca değerlendirin.
Firma bazında kredi limiti veya vade kontrolü gerekiyorsa bu kuralları yetkili muhasebe sorumlularınızla birlikte tanımlayın. Limit bilgisinin hangi sistemden geleceği ve limit aşıldığında siparişi kimin onaylayacağı belli olmalıdır. Bu tür kurallar çoğu zaman projeye özel değerlendirme gerektirir.
Yetkili kişinin izinde olduğu günlerde onay bekleyen siparişlerin ne olacağını da planlayın. Bayi siparişinin hangi aşamada beklediğini portalda görebilmelidir. Onay sürecini tek bir çalışanın kişisel mesajlarına bağlamak, görev devrinde hangi kararın geçerli olduğunu bulmayı zorlaştırır.
Stok ve sevkiyat kararlarını siparişe bağlayın
Hazır stok, tedarikçiden gelecek ürün ve üretilecek ürün için farklı hazırlık süreleri gösterin. Bayiye gösterilen süre gerçek operasyonunuzla örtüşmelidir. Tedarikçinin elinde olduğunu söylediği miktarı kendi deponuzdaymış gibi göstermeyin.
Kısmi sevkiyat veya farklı adreslere gönderim yapıyorsanız her sipariş satırının hangi sevkiyata bağlandığı görünmelidir. Sevkiyat planı değiştiğinde bayi ve operasyon ekibi aynı kaydı görmelidir. İade, hasar ve eksik ürün başvurularını ürün, sevkiyat ve sonuç bilgisiyle ayrı takip edin; kurumsal satış koşullarını sözleşme düzeninizle uyumlu tutun.
ERP ve muhasebe bağlantısında veri yönlerini yazın
Kullandığınız ERP veya muhasebe programını, sürümünü, lisans durumunu ve bağlantı erişimlerini hazırlayın. Ürün, müşteri, fiyat, stok ve sipariş bilgilerinden hangilerinin hangi yönde aktarılacağını tek tek yazın. Program adının teklifte geçmesi, tüm bu aktarımların hazır olduğu anlamına gelmez.
Her bilgi için “ana kaynak” belirleyin. Portalda yazılan detaylı ürün açıklamasının bir sonraki aktarımda ERP’den gelen kısa açıklamayla silinmemesi, fiyatın doğru müşteri grubuna bağlanması ve siparişin doğru cari hesaba gitmesi örneklerle doğrulanmalıdır. Bağlantı kesildiğinde nasıl çalışılacağını ve tekrar gönderilen verinin mevcut kayıtla nasıl eşleşeceğini yazın.
Bağlantı denemesinde müşteri, ürün ve sipariş kodlarını birlikte karşılaştırın. Doğru ürünün yanlış firmaya aktarılması da bir hatadır. Hata bildirimlerinde ilgili kodların bulunması, ekiplerin aynı işlem üzerinde konuşmasını kolaylaştırır.
Bir bayi siparişini baştan sona deneyin
Örnek işletmede onaylı bir bayi belirli ölçüde rakor talep etsin. Kullanıcı kendi firma hesabıyla giriş yapar, parça koduyla ürünü bulur ve kutu birimini seçer. Ekrandaki fiyat ve miktar, depoda hazırlanacak kayıtla karşılaştırılır.
İkinci örnekte standart dışı bir ölçü için teklif istenir. Yetkili kişi fiyatı onayladıktan sonra siparişe dönüşen kaydın aynı ürünü, miktarı ve tutarı koruduğu kontrol edilir. Ardından yetkisiz bir kullanıcının denemesi, miktar değişikliği ve stokta olmayan ürün gibi farklı durumlar sınanır. Her bulgu nedeniyle birlikte kaydedilir; düzeltmeden sonra aynı senaryo tekrar edilir.
İlk kullanıma geçerken satış ekibiniz ve birkaç bayi temsilcisi aynı örnek üzerinden eğitim alabilir. İlk bayi grubundan gelen geri bildirimleri “ürün bulunamadı”, “fiyat sorusu”, “onay gecikmesi” gibi başlıklarla toplayın; yalnızca portaldaki sipariş sayısına bakmak kullanım sorunlarını göstermez.
AveksaSoft ile B2B kapsamınızı netleştirin
AveksaSoft’un Aveksa Start, Aveksa Plus, Aveksa Pro ve Aveksa Kurumsal seçeneklerini değerlendirirken standart mağaza ihtiyaçlarınızı ve B2B’ye özel taleplerinizi ayrı ayrı anlatın. Bayi fiyat grupları, kullanıcı yetkileri, onay akışı, cari hesap ve ERP bağlantısı gibi ihtiyaçların nasıl karşılanacağı güncel teklif ve demo görüşmesinde netleşir; paket adı tüm kurumsal işlevleri kendiliğinden kapsamaz.
Görüşmeye bayi hesap yapınızı ve örnek teklif akışınızı götürün. İlk yayın kapsamını, bağlantı sorumlularını ve kullanıcı eğitimini aynı planda belirleyin; satış ekibinizin uygulayabildiği bir akış, projenin kabul ölçütlerinden biri olmalıdır.
Sık sorulan sorular
B2B sitesi sadece farklı fiyat gösteren bir mağaza mıdır?
Hayır. Hesap onayı, kullanıcı yetkileri, sipariş birimleri, teklif akışı, ödeme ve vade koşulları gibi ek ihtiyaçlar da genellikle gerekir. Kapsam, işletmenizin gerçek sipariş süreci üzerinden belirlenmelidir.
Bir bayinin tüm çalışanları aynı yetkiye sahip olmalı mı?
Görevleri farklıysa yetkileri de farklı olmalıdır. Fiyat görme, sipariş verme ve onaylama yetkileri firma içindeki rollere göre ayrı tanımlanabilir.
Teklif istenmesi kesin sipariş sayılır mı?
Sayılmaz. Teklif, sizin ve müşterinin onayından sonra siparişe dönüşür. Teklifin geçerlilik süresi, onaylanan sürümü ve siparişe dönüşme anı açıkça tanımlanmalıdır.
