Bayi Ağı CRM'de Nasıl Yönetilir?

Bayi ağı olan bir firmada CRM iki katmanlı kurulur: bir katmanda bayi (size ödeme yapan taraf), diğerinde son kullanıcı (ürünü gerçekten kullanan taraf). Tek katmanlı kurulan CRM'de bayi bir "müşteri" olarak görünür ve son kullanıcı hiç görünmez. Sonuç: cironun kimden geldiğini bilirsiniz, ama neden geldiğini bilmezsiniz — ve bayi değiştiğinde o pazarı sıfırdan öğrenmeniz gerekir.

Bayi ağında CRM neden farklı kurulur?

Çünkü satış iki kez gerçekleşir. Siz bayiye satarsınız (sell-in), bayi son kullanıcıya satar (sell-out). Klasik CRM yalnızca birincisini görür. Bayinin deposunda 3 aylık stok varsa, sizin satış grafiğiniz düşmeye başlar ama pazarda talep aynıdır — ya da tersi: sell-in yükselirken bayi stok şişirmiştir, önümüzdeki çeyrek sipariş gelmeyecektir.

Bu körlüğün pratik maliyeti üretim planıdır. Sell-out verisi olmayan firma, talebi bayinin sipariş ritminden tahmin eder; bu ritim ise bayinin nakit durumuna göre değişir, pazara göre değil.

CRM'de hangi yapı kurulur?

1. Hesap hiyerarşisi: bayi ana hesap, son kullanıcılar ona bağlı alt kayıtlar. Böylece bir bayinin portföyünü tek ekranda görürsünüz.
2. Kayıt tipi alanı: her hesap "bayi" veya "son kullanıcı" olarak işaretlenir. Bu alan olmadan raporların tamamı karışır.
3. Bölge ve yetki: bayi yalnızca kendi kayıtlarını görür; bu, bayi portalı kurmanın ön şartıdır.
4. Fırsat sahipliği: her fırsatta iki alan olur — kaydı getiren bayi ve takip eden sizin bölge sorumlunuz.
5. Proje bazlı kayıt: aynı son kullanıcı için iki bayi teklif veriyorsa, proje tek kayıt olur ve bayiler o kayda bağlanır.

Sell-in ve sell-out nasıl ölçülür?

Sell-in kolaydır, faturanızdan çıkar. Sell-out için bayiden veri almanız gerekir ve bunu zorunluluk olarak değil, karşılıklı fayda olarak kurmanız gerekir. İşe yarayan yaklaşım: bayinin garanti kaydı, kurulum formu veya servis talebi süreçlerini sizin sisteminizden geçirmek. Bayi bir işini kolaylaştırdığı için veriyi verir; siz de son kullanıcıyı görürsünüz.

Ölçülecek üç sayı: aylık sell-in, aylık sell-out ve ikisi arasındaki fark yani tahmini kanal stoğu. Kanal stoğu 2 ayı geçtiyse sipariş yavaşlaması gelecek demektir — bunu çeyrek sonunda değil, 8 hafta önce bilmek istersiniz.

Bayi performansı nasıl ölçülür?

Ciro tek başına yeterli değil, çünkü büyük bölgedeki ortalama bayi, küçük bölgedeki iyi bayiden fazla satar. Dört sayı ile bakın:

• Bölge potansiyeline göre pay: bölgedeki tahmini pazar büyüklüğüne oranı.
• Ürün genişliği: kaç farklı ürün grubu satıyor. Tek ürün satan bayi, rakip geldiğinde en hızlı kaybedilen bayidir.
• Yeni son kullanıcı sayısı: pazar mı büyütüyor, aynı 20 müşteriye mi satıyor.
• Ödeme performansı: ortalama tahsilat günü ve vade aşımı.

Bu dördünü çeyreklik bir tabloya koyup bayileri üç kademeye ayırın: büyütülecek, korunacak, gözden geçirilecek. Kademe, iskonto ve destek bütçesinin dağıtım kuralı olur — "en çok satana en çok iskonto" refleksinden çok daha kârlı bir kurgu.

Lead çakışması nasıl çözülür?

Bu, bayi ağlarının en sık çatışma sebebi. Kural yazılı olmalı ve CRM'de uygulanmalı:

1. Gelen talep önce CRM'de aranır; son kullanıcı zaten bir bayiye bağlıysa talep o bayiye gider.
2. Kayıt yoksa bölge kuralına göre atanır ve kayıt tarihi ile kilitlenir.
3. Bayinin bu talebe 5 iş günü içinde dokunma zorunluluğu olur; dokunmazsa talep serbest kalır.
4. Proje bazlı işlerde "proje kaydı" ilk kaydedene 90 gün öncelik verir.

Dördüncü kural olmadan iki bayi aynı projede fiyat kırar; kaybeden siz olursunuz, çünkü marj iki taraftan da erir.

Bayiye ne raporlanır?

Bayi, kendi verisini görebildiği ölçüde veri üretir. Aylık tek sayfa yeterli: kendi sell-in/sell-out grafiği, bölge ortalamasıyla karşılaştırma, elindeki açık projeler ve bekleyen tahsilat. Bu sayfa bayinin işine yaradığı gün, veri girişi sizin takip etmeniz gereken bir iş olmaktan çıkar.

En sık yapılan hatalar neler?

• Bayiyi ve son kullanıcıyı aynı listede tutmak; 400 kayıtta hangi ciro kimden geliyor ayırt edilemez.
• Sell-out verisini zorla istemek. Karşılığında bir fayda sunulmayan veri talebi hiçbir bayide yürümez.
• Lead kuralını sözlü bırakmak.
• Bayi performansını yalnızca ciroyla ölçmek ve ödeme performansını hesaba katmamak.
• Son kullanıcı ilişkisini tamamen bayiye bırakmak: bayi değişince pazar hafızası da gider.

İki katmanlı yapının zorluğu kurgu değil, veriyi üretmek: hangi projede ne konuşulduğu, son kullanıcının neden o ürünü seçtiği, bayinin hangi engelle karşılaştığı çoğunlukla telefon görüşmelerinde kalır. Closync bu konuşmalardan veriyi kendisi çıkarıp CRM'e yazar; böylece bayi ağı bir sipariş listesi değil, üzerine plan yapılabilen bir pazar görüntüsü olur.