Bayi yönetim sistemi yaptırmak, bayilerin telefonla verdiği siparişi, sorduğu fiyatı ve öğrenmek istediği bakiyeyi kendi girişleriyle görebildikleri bir portal kurdurmak demektir. Bayi sayınız onlarla ifade ediliyor, sipariş tekrarlı geliyor ve iç ekibinizin günü telefonla geçiyorsa bu yatırım değerlendirilmeye değer. Ancak bayi başına özel anlaşmalarınız yazılı değilse ya da stok ve cari veriniz güvenilir değilse önce o düzeni kurmak gerekir; yoksa portal yalnızca mevcut karışıklığı ekrana taşır.
Kararı netleştirmek için üç soruya bakın: Bayiler sizi en çok ne için arıyor? Fiyat kurallarınız kaç istisna içeriyor? Stok ve cari bilgisi bugün hangi sistemden, ne kadar güncel geliyor? Bu cevaplar projenin büyüklüğünü de, bazen hiç yapılmaması gerektiğini de gösterir. Aşağıda bu soruları üretici ve distribütör gözünden, telefon başındaki gerçek iş üzerinden açıyoruz.
Önce telefonu dinleyin: bir haftalık çağrı dökümü kapsamı yazar
Yazılım firmasıyla konuşmadan önce yapabileceğiniz en ucuz analiz şudur: Sipariş alan ekibin önüne bir sayfa koyun ve bir hafta boyunca gelen her çağrıyı, WhatsApp mesajını ve e-postayı tek bir etiketle işaretletin. Sipariş verme, sipariş değiştirme, fiyat sorma, stok sorma, bakiye sorma, sevkiyat nerede, iade veya hasarlı ürün. Süreyi de kabaca yazdırın. Bir hafta sonra elinizde, hiçbir toplantının çıkaramayacağı bir ihtiyaç listesi olur.
Bu döküm genellikle sürpriz yapar. Yönetim "sipariş portalı" diye düşünürken çağrıların önemli bir kısmının "kamyon çıktı mı?" sorusundan oluştuğu görülebilir. O durumda ilk sürümde gelişmiş kampanya motoru yerine sipariş durumu ve sevk bilgisi ekranı daha çok işe yarar. Tersi de olabilir: bakiye hiç sorulmuyordur, çünkü plasiyer zaten her hafta söylüyordur; o zaman cari ekranını ikinci aşamaya bırakmak mantıklıdır.
Dökümde iki şeye ayrıca bakın. Birincisi, aynı bayinin aynı hafta kaç kez aradığı: Sık arayan küçük bayiler pilot için en iyi adaylardır, çünkü portaldan en çabuk onlar fayda görür. İkincisi, telefonda çözülemeyip geri aramaya kalan çağrılar. "Muhasebeye sorup döneyim" dediğiniz her an, bilginin ekipler arasında bir yerde sıkıştığını gösterir ve sistemin asıl değeri çoğu zaman burada ortaya çıkar.
"Geçen seferkinin aynısı": sipariş ekranı neyi çözmeli?
Bayi, internetten alışveriş yapan bir tüketici gibi davranmaz. Kategorilerde gezmez, ürün fotoğrafına bakmaz. Dükkânındaki rafa bakar, eksik kalanları aklından sayar ve telefonda "geçen seferkinin aynısı, yalnız şu üründen iki koli fazla" der. Telefonun gücü buradadır: Karşıdaki kişi sipariş geçmişini, ürün kısaltmalarını ve bayinin alışkanlığını bilir. Portal bu kolaylığı karşılayamıyorsa bayi birkaç denemeden sonra yine telefona sarılır.
Bu yüzden sipariş ekranında vitrin tasarımından önce şu işlevler konuşulmalıdır: önceki siparişi tek hareketle kopyalama; ürün kodu veya bayinin kullandığı kısa adla hızlı arama; koli, palet veya koli katı zorunluluğu; Excel listesinden toplu yükleme; telefondan rahat kullanım. Depodaki kalfanın veya dükkân sahibinin siparişi çoğu zaman masa başında değil, ayakta verdiğini unutmayın.
Sonra işin zor tarafı gelir: Sipariş verildikten sonra ne olacağı. Stokta olmayan ürün reddedilecek mi, açık sipariş olarak mı bekleyecek? Kısmi sevk yapılıyor mu? Saat kaçtan sonra gelen sipariş ertesi güne kalıyor? Bayi siparişi onaylandıktan sonra değiştirebilecek mi? Bunların her biri küçük görünür ama her birinin arkasında depo, satış ve muhasebe arasında bir kural vardır. Bugün bu kurallar telefondaki kişinin kafasındaysa, yazılım yapılmadan önce yazıya dökülmeleri gerekir.
Stok görünürlüğü de ayrı bir karardır. Bayiye gerçek adedi göstermek zorunda değilsiniz; "var, az, yok" düzeyinde göstermek çoğu ticari ilişkide yeterli olabilir ve rakiplerin adetlerinizi öğrenmesi gibi bir kaygıyı da azaltır. Fakat bu gösterimin arkasındaki stok verisi yanlışsa portal ilk haftadan güven kaybeder: "Var" görünen ürün için sipariş verip eksik sevkiyat alan bayi, bir daha ekrana inanmaz. Kısa süreli rezervasyonun gerekip gerekmediği, yani bayinin sepete aldığı ürünün başkasına satılıp satılamayacağı da aynı konuşmanın parçasıdır.
Fiyat listesi değil, istisna listesi: mal fazlası, kur ve vade
Bir üretici "tek fiyat listemiz var" dediğinde, ikinci soruda genellikle başka bir tablo ortaya çıkar. A grubu bayiye yüzde şu kadar iskonto, Ege bölgesine nakliye dahil, on koli alana bir koli mal fazlası, yıl sonu ciro primi, eski bayiye özel korunmuş fiyat. Bunların hiçbiri yanlış değildir; yıllar içinde pazarlıkla oluşmuştur. Ama bir bayi yönetim sisteminde hepsi ya kurala dönüşmek ya da kaldırılmak zorundadır, çünkü ekran telefondaki kişi gibi "bir bakayım, ne yapabiliriz" diyemez.
Türkiye'ye özgü iki konu bu kısmı daha da zorlaştırır. Birincisi döviz bazlı liste. Hammaddesi ithal olan birçok işletme fiyatı dolar veya euro üzerinden tanımlar; o zaman şu cevaplar gerekir: Hangi kur, günün hangi saatinde, sipariş anında mı sevk anında mı sabitlenecek? İkincisi vade farkı. Otuz gün vadeyle peşin alım arasındaki fark bir kural mı, yoksa satış müdürünün kararı mı? Fiyatların sık güncellendiği dönemlerde bayinin ekranında gördüğü fiyatın ne kadar süre geçerli olduğu da açıkça yazılmalıdır.
Pratik yöntem şudur: Birbirine benzemeyen üç bayinizi seçin (büyük, küçük ve en karmaşık anlaşmaya sahip olan). Üçü için aynı beş ürünün net fiyatını, elle ve adım adım çıkarın. Bu çalışma iki sonuç verir: İstisnaların gerçek sayısı görünür ve yazılım firmasına verebileceğiniz doğrulama örnekleri ortaya çıkar. Sistem kurulduğunda ilk test de budur; ekrandaki sonuç sizin elle bulduğunuzla kuruşu kuruşuna aynı olmalıdır.
Fırsattan da yararlanın: Portal projesi, yıllardır biriken özel anlaşmaları sadeleştirmek için iyi bir bahanedir. Otuz farklı iskonto oranını beş bayi grubuna indirmek hem yazılımı basitleştirir hem de ticari disiplin kazandırır. Satış tarafının itirazı olacaktır; bu görüşmeyi kod yazılmaya başlamadan yapın. Toptan fiyatlandırma tarafında temel ayrımları toptan satış yönetimi rehberimizde ayrıca ele aldık.
Cari ekranı tahsilat tartışmasını bitirmeli, başlatmamalı
Bayinin "borcum ne kadar?" sorusu basit görünür; oysa ekranda görünen rakam muhasebe kayıtlarınızla aynı değilse, sorun çözülmek yerine büyür. Üç konu burada belirleyicidir. Birincisi kaynak: Bakiye ERP veya ön muhasebe programınızdan mı geliyor, portal kendi hesabını mı yapıyor? Doğru cevap neredeyse her zaman tektir: Cari defterin tek sahibi vardır, portal yalnızca onu gösterir. İkincisi güncellik: Bilgi anlık mı, saatlik mi, gece aktarımıyla mı geliyor? Bayi sabah ödeme yapmış, öğlen bakiyesini hâlâ eski görüyorsa ekranda "son güncelleme" zamanı yazmalıdır.
Üçüncüsü çek ve senettir. Türkiye'de bayi ilişkilerinin önemli bir kısmında çek, senet ve vadeli ödeme kullanılır. Vadesi gelmemiş çek bakiyeden düşülmüş sayılacak mı? Risk limiti hesabına nasıl girecek? Karşılıksız çıkan çek nasıl yansıyacak? Muhasebecinizin bu soruları cevaplamasını bekleyin; yazılım firmasına bırakılırsa varsayımla çözülür.
Risk limiti aşımı da bir karar noktasıdır. Limiti geçen bayinin siparişi tamamen engellenebilir, onay beklemeye alınabilir ya da yalnızca uyarıyla geçilebilir. Sert engel, uzun süredir çalıştığınız bir bayiyi cumartesi sabahı ekrana kilitlerse satış ekibiniz bunu haklı olarak şikâyet eder. Çoğu işletme için onay kuyruğu daha yumuşak bir başlangıçtır. Mutabakat, yani dönem sonunda bakiye teyidi portala taşınabilir; ancak resmî geçerliliği ve hukuki sonucunu mali müşavirinizle konuşmadan bunu mevcut süreçlerin yerine koymayın.
Bu tablo teknik görünse de yönetim kararıdır. Kullandığınız sistem Logo, Mikro, Netsis ya da başka bir ürün olabilir; asıl soru, dışarıdan güvenli erişime nasıl izin verdiği, hangi sürümde olduğunuz ve bu erişimin size ek lisans doğurup doğurmadığıdır. Bunu teklif öncesinde mevcut yazılım sağlayıcınıza sorun. Bağlantının mantığını bilmiyorsanız API entegrasyonu yazımız konuşmaya hazırlanmak için yeterlidir.
Üretici ile distribütörün portalı aynı olmaz
"Bayi portalı" tek bir ürün gibi anılır ama işi yapan firmanın konumu ihtiyacı kökten değiştirir. Üretici için asıl soru termindir. Sipariş her zaman stoktan karşılanmaz; üretim planına girer, partiler halinde çıkar ve bayiye verilen tarih değişebilir. Bu nedenle üreticinin portalında sipariş onayı, termin bilgisi ve üretim durumu çoğu zaman stok adedinden daha değerlidir. Özel ölçü, renk veya varyantla çalışan bir mobilya ya da yapı malzemesi üreticisinde ürün seçimi de başlı başına bir yapılandırma ekranı gerektirebilir ve kapsamı ciddi biçimde büyütür.
Distribütörde tablo farklıdır. Ürün çeşidi fazladır, birden çok markayla çalışılır, birkaç depo bulunabilir. Bayi hangi depodan alacağını bilmek ister; marka sözleşmesi gereği bazı ürünleri yalnızca belirli bölgelere satabilirsiniz. Tedarikçinin fiyat güncellemesi bir anda binlerce satırı etkileyebilir, bu yüzden toplu fiyat aktarımı ve ürün verisinin temizliği belirleyici olur. Marjlar genellikle daha dardır; yanlış uygulanmış tek bir iskonto kuralı fark edilmeden birçok siparişe yayılabilir.
İki gerçek bir aradaysa, örneğin kendi ürettiğiniz ürünün yanında ithal ürün de dağıtıyorsanız, ilk sürümde hangisini önceleyeceğinize karar verin. Terminli üretim akışı ile depodan hızlı sevk akışını aynı anda ve aynı derinlikte başlatmak, en sık takılınan kapsam tuzaklarından biridir.
Ana bayi, alt bayi, plasiyer: kim neyi görecek?
İşletme yöneticileri kullanıcı yetkisini genellikle en sona bırakır, oysa bayi yönetiminin "yönetim" kısmı tam burada başlar. Bir bayi tek kullanıcı değildir. Sahibi cariyi ve kârlılığı görmek ister, tezgâhtaki çalışanı yalnızca sipariş girebilmelidir, muhasebecisi ekstreyi indirir. Çok şubeli bir bayide her şube kendi siparişini verirken faturanın merkeze kesilmesi istenebilir. Çalışanın gördüğü ekranda alış fiyatı yer almamalı ki müşterisinin yanında açabilsin.
Sizin tarafınızda da roller vardır. Bölge satış temsilcisi yalnızca kendi bayilerini görmeli, gerekirse bayi adına sipariş girebilmeli ve bu kayıt "temsilci girdi" diye işaretlenmelidir. Ana bayi ve alt bayi yapınız varsa soru daha da derinleşir: Alt bayi sizden mi alıyor, ana bayiden mi? Ana bayi alt bayisinin siparişini görecek mi? Fiyatı kim belirliyor? Hiyerarşi derinleştikçe veri modeli de büyür; bu nedenle bugün gerçekten kullandığınız yapıyı çizin, belki bir gün olur diye düşündüğünüz yapıyı değil.
Plasiyerin kaygısını da açıkça konuşun. Bayi kendi siparişini verdiğinde temsilci primini kaybedeceğini düşünürse, bayiye portalı önermez, hatta arkadan vazgeçirir. Çözüm genellikle basittir: Prim, sipariş hangi kanaldan gelirse gelsin bölgeye yazılır ve temsilcinin zamanı sipariş yazmaktan yeni bayi kazanmaya ve tahsilata kayar. Bu kuralı duyuruyu yapmadan önce netleştirin.
Excel'de kalmak da bir seçenek: yatırımı saatlerle hesaplayın
Yatırım kararını "telefonlar azalır" gibi genel bir umutla değil, kendi dökümünüzle verin. Örnek bir hesap: Günde 40 sipariş çağrısı geliyor, çağrı ve sisteme kayıt birlikte 6 dakika sürüyorsa bu, ekipte günde 240 dakika, yani 4 saat eder. Portal bu işin yalnızca bir kısmını alacaktır; çünkü her bayi geçmeyecek, karmaşık siparişler telefonda kalacaktır. Kendi çağrı sayınız, süreniz ve gerçekçi bir geçiş oranıyla aynı hesabı yapın. Buna yanlış sevkten doğan iade maliyetini ve mesai sonrası gelen siparişlerin kaybolma riskini de düşünün; ancak yazılımın bunları ne ölçüde azaltacağı konusunda kimseye kesin rakam vaat ettirmeyin.
Sonra dört yolu dürüstçe karşılaştırın. Bayi sayısı azsa ve siparişler seyrekse düzenli bir paylaşımlı tablo ve sipariş formu yeterli olabilir; yazılıma para harcamak gereksizdir. Kullandığınız ERP'nin kendi bayi modülü varsa en doğal ilk adım onu denemektir, çünkü veri zaten oradadır. Fiyat ve onay kurallarınız standartsa hazır B2B altyapısı hızlı bir yoldur; bu seçeneği B2B e-ticaret sitesi yaptırmak yazımızda ayrıntılı işledik. Özel geliştirme ise kurallarınız hazır ürünlere sığmadığında ve bu kurallar gerçekten rekabet avantajınız olduğunda anlam kazanır.
Şu durumlarda bu projeye şimdi başlamayın: Ürün kartlarınız dağınıksa ve aynı ürün iki kodla duruyorsa; stok sayımı ile sistem arasındaki fark düzenli olarak büyükse; bayilerle yazılı ticari anlaşmanız yoksa; projenin sahibi olacak, karar verebilen bir kişiyi şirket içinde ayıramıyorsanız. Bunların dördü de yazılımın çözemeyeceği sorunlardır ve önce çözülmeleri, sonraki yatırımın değerini doğrudan artırır.
Teklifler neden birbirini tutmaz? Bedeli büyüten kalemler
Aynı toplantıdan çıkan üç teklif arasında büyük fark görmek şaşırtıcı değildir, çünkü her firma açık kalan soruları kendi varsayımıyla kapatır. Bayi portalının bedeli kaç ekran olduğundan çok, kaç kural ve kaç bağlantı olduğuna göre belirlenir. Bu nedenle sabit bir rakam vermek yanıltıcı olur; fiyat, kapsamınız konuşulduktan sonra ücretsiz görüşmede netleşir. Yine de bedeli büyüten kalemleri önceden bilirseniz görüşmeye hazırlıklı gidersiniz:
- Fiyat kurallarının sayısı: Grup iskontosu ile bayi, ürün, bölge, kur ve vadeye bağlı kuralların tamamını hesaplayan motor aynı iş değildir.
- Entegrasyon derinliği ve yönü: Yalnızca okumak ile siparişi ERP'ye geri yazmak, hata yönetimi dahil, çok farklı işlerdir.
- Ürün verisinin temizliği: Eksik görsel, tutarsız birim ve mükerrer kod temizliği çoğu zaman teklif dışında kalır ve sizden ya da firmadan zaman ister.
- Roller ve onay zincirleri: Şube, temsilci ve ana bayi yapısı arttıkça test edilecek senaryo da katlanır.
- Bildirim kanalları: E-posta ile WhatsApp Business API bildirimleri ayrı kurulum ve mesaj maliyetleri doğurabilir.
- Mobil uygulama: Tarayıcıda telefona uyumlu arayüz çoğu bayi için yeterliyken mağaza uygulaması ayrı bir bakım kalemi açar.
Karşılaştırma için teklifleri toplam rakamla değil, aynı senaryolarla okuyun. Her firmaya aynı üç örnek bayiyi ve aynı beş işlemi verin: tekrar sipariş, limit aşımı, kısmi sevk, iade, kampanyalı fiyat. Her birinin kapsamda olup olmadığını yazılı isteyin. Satır satır bir tablo, "dahil değil" notlarını görünür kılar.
Gizli maliyetler genellikle yayın tarihinden sonra gelir: sunucu ve yedekleme, güvenlik güncellemeleri, ERP sürüm değişince güncellenmesi gereken entegrasyon, yeni bayi eğitimleri, sizin ekibinizin projeye ayırdığı zaman. Bakım kapsamı ve destek saatleri teklifte yazılı olmalıdır. Kaynak kodun ve dokümantasyonun kime ait olduğu da aynı sayfada netleşmelidir, çünkü bu sistem yıllarca iş ortaklarınızla aranızda duracaktır.
e-Fatura, e-İrsaliye, KVKK ve rekabet kuralları
Portalın kendisi genellikle fatura kesen sistem değildir; sipariş portaldan gelir, fatura ve irsaliye mevcut ERP'niz veya özel entegratörünüz üzerinden düzenlenir. Bayi ekranına ise belge bağlantısı veya kopyası yansıtılır. Mükellefiyet durumunuza göre e-Fatura, e-Arşiv veya e-İrsaliye süreçleri farklı işleyebilir ve kurallar zaman içinde değişir; akışı çizerken mali müşavirinizle kontrol edin. Temel kavramları e-Fatura geçiş rehberinde bulabilirsiniz.
Kişisel veri tarafı da küçümsenmemeli. Bayi firması bir tüzel kişi olsa bile kullanıcıları gerçek kişilerdir: ad, telefon, e-posta ve kullanım kayıtları KVKK kapsamında değerlendirilebilir. Şahıs şirketi şeklinde çalışan bayilerde bu veri çok daha doğrudandır. Aydınlatma metni, erişim yetkileri, ayrılan çalışanın hesabının kapatılması, verinin nerede barındırıldığı ve varsa yurt dışı aktarımı hukuk danışmanınızla birlikte planlanmalıdır.
Üçüncü başlık çoğu teklifte hiç geçmez: rekabet hukuku. Bayilerin tüketiciye satış fiyatını sistem üzerinden dayatmak veya bölge dışı satışı otomatik engellemek, ticari olarak mantıklı görünse de hukuken hassas alanlara girebilir. "Tavsiye edilen satış fiyatı" alanı ile zorunlu fiyat arasında önemli bir fark olabilir. Bu tür kuralları yazılıma işlemeden önce avukatınıza danışın.
Bayiler portala kendiliğinden geçmez
Teknik olarak kusursuz bir sistem bile, bayi alışkanlığını değiştirmeden boş kalır. Yıllara yayılan bir ilişkinin telefonda kurulduğunu, satış elemanının bayinin çocuğunun adını bildiğini düşünün; karşısına giriş ekranı koymak ilk başta soğuk gelir. Bu nedenle geçiş bir duyuru değil, aşamalı bir plandır. Telefon hattı da kapanmaz: Karmaşık sipariş, sorunlu teslimat ve yeni ürün konuşması insanla yapılmaya devam eder. Hedef telefonu bitirmek değil, tekrarlı işi telefondan almaktır.
Pilot için beş ila on bayi seçin; biri mutlaka en karmaşık anlaşmaya sahip olan, biri de teknolojiye en mesafeli olan olsun. İlk girişleri telefonda birlikte yapın, açılış fiyatlarını ekrana bakarak doğrulatın. Bakiye farkı çıkarsa bunu toplu duyurudan önce çözün. Bu aşamada gelen şikâyetler, yazılım hatası kadar kural eksikliğini de ortaya çıkarır.
Teşvik tasarımı da işe yarar, ancak dikkatli kullanılmalıdır. Portal üzerinden verilen siparişe öncelikli sevk veya daha geç kesim saati gibi operasyonel avantajlar, çoğu zaman iskontodan daha sağlıklıdır, çünkü marjınızı aşındırmaz. Temsilcinin bayi adına sipariş girmesine geçiş boyunca izin verin ama bunu raporda ayrı izleyin; kanal payını doğru görebilmek için tek ölçütünüz bu olabilir. Hangi bayilerin hiç giriş yapmadığını görmek de temsilcinize net bir ziyaret listesi verir.
Yazılım firmasına ilk görüşmede sorulacaklar
Ekran gösterimi herkese iyi görünür. Farkı, işinizin zor senaryolarını masaya koyduğunuzda görürsünüz. Örnek ekran görüntüsü yerine aşağıdaki soruların cevabını isteyin; cevap "bakarız" ise bunu da not edin.
Bir de sizin vermeniz gereken cevaplar vardır: Çağrı dökümü, üç örnek bayinin net fiyat hesabı, ERP sürümü ve erişim bilgisi, yetki çizelgesi ve projeye vakit ayıracak kişinin adı. Bunlarla gittiğiniz görüşme, "bize bir bayi sistemi lazım" diyerek gittiğiniz görüşmeden çok daha doğru bir teklif üretir.
Welda nasıl yardımcı olabilir, nerede olmaz?
Bayi yönetim sistemi yaptırmak istiyorsanız Welda'nın özel yazılım hizmeti bu işin parçalarını karşılar: işinize özel web uygulaması ve portal geliştirme, muhasebe, ödeme ve e-ticaret sistemleriyle REST ve GraphQL API entegrasyonu, onay ve bildirim otomasyonları, WhatsApp Business API üzerinden sipariş ve bildirim akışları, canlı panolar. Çalışma biçimimiz keşifle başlar: Veri modeli, entegrasyon noktaları ve arayüz akışları kod yazılmadan onayınıza sunulur, geliştirme sürümler halinde teslim edilir. Kaynak kod ve dokümantasyon size aittir; lansman sonrası bakım için hizmet seviyeleri ayrıca kararlaştırılır.
Sınırları da söyleyelim. Hazır bir bayi portalı ürünümüz yok. Welda Stock perakende stok ve satış için, Welda CRM ise klinik ve hasta yönetimi için geliştirildi; ikisi de bayi portalının yerine geçmez. Kendi ürünlerimizi geliştirip canlıda işletmek bize yazılımın günlük işletme yükünü bildirir, fakat bu sizin ERP'nize hazır bağlantımız olduğu anlamına gelmez; bağlantı olanağını sisteminizi inceledikten sonra konuşuruz. Çağrı dökümünüz paylaşımlı tablonun veya ERP modülünüzün yeterli olduğunu gösteriyorsa bunu da açıkça söyleriz.
Bayi yönetim sistemi yaptırmak için özel yazılım sayfamızdan ücretsiz görüşme talep edebilirsiniz. Çağrı dökümünüz ve üç örnek bayiniz yanınızdaysa, kapsam ve fiyat en hızlı bu görüşmede netleşir.
Sık sorulan sorular
Bayi portalı ile B2B e-ticaret sitesi arasındaki fark nedir?
Günlük kullanımda iç içe geçer. B2B e-ticaret daha çok katalog ve sipariş kanalını anlatır; bayi yönetim sistemi ise buna cari, sevkiyat takibi, temsilci rolleri, bayi hiyerarşisi ve raporlamayı ekleyen daha geniş bir yapıyı ifade eder. Teklif alırken isme değil, listelenen işlevlere bakın.
Kaç bayi olunca portal mantıklı olur?
Tek başına bayi sayısı yanıltıcıdır. Az sayıda bayi her gün sipariş veriyorsa portal kendini gösterebilir; çok sayıda bayi ayda bir sipariş veriyorsa basit bir form yetebilir. Çağrı sayısı, tekrar oranı ve hata maliyetine birlikte bakın.
Mevcut ERP programımız kalacak mı?
Genellikle evet. Portal, bayinin gördüğü yüzdür; ERP ise muhasebe ve stokun ana kaynağı olarak kalır. Bağlantının nasıl kurulacağı ERP'nizin sürümüne ve dışarıya sunduğu erişime bağlıdır; bunu kod yazılmadan önce doğrulatın.
Bayiler telefon yerine portalı kullanmak istemezse ne olur?
Bir kısmı uzun süre istemeyebilir ve telefon hattı açık kalmalıdır. Pilot, birlikte yapılan ilk girişler, operasyonel teşvikler ve temsilcinin sürece dahil edilmesi kullanımı artırır. Yine de tamamını taşıyacağı varsayımıyla yatırım hesabı yapmayın.
İlk sürümde neler olmalı?
Çağrı dökümünüzde en çok tekrar eden iki üç iş: çoğu firmada tekrar sipariş, net fiyat görünümü ve sipariş durumu. Kampanya motoru, mobil uygulama ve gelişmiş raporlar kullanım oturduktan sonra planlanabilir.
Bu projenin maliyeti nasıl netleşir?
Fiyat kuralı sayısı, entegrasyon yönü, roller ve bakım kapsamı belli olmadan verilen rakam güvenilir olmaz. Örnek bayilerinizle kapsamı çıkardıktan sonra ücretsiz görüşmede size özel teklif konuşulabilir.