Çok şubeli ve çok ekipli yapıda CRM nasıl kurgulanır?
Aynı müşteriye iki şubeden iki farklı teklif gitmesin. Sahiplik ve görünürlük modeli, şubeye göre yönlendirme, devir kuralı ve adil şube kıyaslaması nasıl kurulur?
Salı sabahı, üç şubeli bir endüstriyel ekipman firmasının Bursa ofisinde telefon çalıyor. Arayan, bir hafta önce teklif gönderilen gıda fabrikasının satın alma sorumlusu. Elinde iki teklif var: biri Bursa'dan, biri İzmir'den. Aynı makine, iki farklı ürün kodu, iki farklı teslim süresi ve birbirini tutmayan iki iskonto. Hangisinin geçerli olduğunu soruyor. O görüşmede firma fiyatını değil, kendi iç düzensizliğini masaya koymuş oluyor; müşteri de artık makineyi değil, iki teklif arasındaki farkı pazarlık ediyor. Anlaşma sonunda kapanıyor ama üç puan daha düşük bir marjla.
Çok şubeli ya da çok ekipli bir yapıda CRM kurmak, tek ofisli bir kurulumun büyütülmüş hâli değildir; farklı bir problem sınıfıdır. Aşağıda sırayla şunları ele alıyoruz: organizasyon şemasının neden doğrudan CRM'e kopyalanamayacağını, sahiplik ve görünürlük modelinin nasıl seçileceğini, aynı müşteri iki şubeye düştüğünde ne olacağını, pipeline'ın şubelere bölünüp bölünmeyeceğini, hangi alanların zorunlu hâle gelmesi gerektiğini, gelen talebin hangi şubeye yönleneceğini, iki şubenin ortak kapattığı anlaşmanın kime yazılacağını, şube kıyaslamasının nasıl adil kurulacağını ve merkezî standart ile yerel serbestlik arasındaki sınırın nereye çekileceğini.
Organizasyon şeması ile CRM şeması aynı şey değildir
Çok şubeli kurulumların çoğu aynı yerden başlar: birisi insan kaynaklarındaki organizasyon şemasını açar ve onu olduğu gibi sisteme kopyalar. Genel müdür, bölge müdürleri, şube müdürleri, temsilciler. Şema doğru görünür, ama yanlış sorunun cevabıdır. Organizasyon şeması kimin kime rapor verdiğini anlatır; CRM'in ihtiyacı olan şey ise bir kaydın hangi kurallarla birinden diğerine geçtiğidir. Bu iki soru çoğu şirkette aynı cevabı vermez.
Somut bir örnek: bir firmada teknik satış ekibi merkezde oturur ama üç şubenin de büyük projelerine girer. Organizasyon şemasında bu ekip merkeze bağlıdır, hiçbir şubeye değil. CRM'de ise her kayıtta ikinci bir ilgili gibi davranabilmesi gerekir; yoksa merkezdeki mühendis, üzerinde bizzat çalıştığı İzmir fırsatını ekranında göremez. Şemayı olduğu gibi kopyalayan kurulumlarda bu kişi işini yapabilmek için kendi tablosunu açar, ve sistem daha ilk aydan delinir.
Şube, ekip ve bölge üç ayrı kavramdır
Şube fiziksel ve çoğu zaman mali bir birimdir: kendi deposu, kendi kasası, bazen kendi tüzel kişiliği vardır. Ekip bir çalışma birimidir; aynı şubede iki ayrı ekip olabilir, bir ekip iki şubeye yayılabilir. Bölge ise bir pazar tanımıdır ve şubeyle hiç örtüşmek zorunda değildir; Trakya'daki müşterilere İstanbul şubesi bakıyor olabilir. Bu üçünü tek bir alana sıkıştıran kurulumlar ilk yeniden yapılanmada dağılır, çünkü pazar değiştiğinde şube yapısını da değiştirmek zorunda kalırsınız. Üçünü ayrı alanlarda taşımak, bölge ve hesap planlamasını şube yapısına dokunmadan yenileyebilmenizi sağlar.
Kim kimin kaydını görecek?
Bu, çok şubeli kurulumda alınacak en pahalı karardır ve genellikle en aceleye getirileni de budur. Sorunun iki ayrı katmanı var. Sahiplik, kaydın kimin sorumluluğunda olduğudur ve tek bir kişiye bağlanmalıdır; iki sahibi olan fırsat pratikte sahipsiz fırsattır. Görünürlük ise kimin okuyabildiği, kimin değiştirebildiğidir; buradaki cevabın herkes her şeyi ya da kimse kimseninkini biçiminde uçlarda olması gerekmez.
Pratikte dört model kullanılıyor ve seçim, şubeler arasındaki müşteri örtüşmesine göre yapılmalı. Şubelerin müşteri havuzu gerçekten ayrıksa katı ayrım işe yarar ve kimse kimsenin ekranını karıştırmaz. Aynı müşteriye birden fazla şube dokunuyorsa katı ayrım, girişte anlattığımız çifte teklif kazasını üretmekten başka bir şey yapmaz. Karar vermeden önce şunu ölçün: son bir yılda kaç firma iki ayrı şubede kayıtlı açılmış?
| Görünürlük modeli | Ne zaman doğru | Yan etkisi |
|---|---|---|
| Katı ayrım | Şubelerin pazarları hiç kesişmiyor | Ortak müşteride çifte temas |
| Hiyerarşik | Müdür kendi altını görmeli, yanını değil | Yatay iş birliği zayıflar |
| Ortak okuma, ayrık yazma | Aynı müşteriye birden fazla şube dokunuyor | Fiyat bilgisi şubeler arası dolaşır |
| Havuz ve sahiplenme | Talep akışı düzensiz, kapasite değişken | Sahiplenilmeyen kayıt havuzda yaşlanır |
Model seçildikten sonra iş rol tanımına dönüşür: hangi rol hangi nesnede okuma, yazma, silme ve dışa aktarma yetkisine sahip olacak. Dışa aktarma yetkisi neredeyse her zaman ihmal edilir. Şube müdürünün ayrılırken bütün müşteri listesini tek tıkla indirebilmesi, çok şubeli yapıların en sessiz riskidir ve fark edildiğinde geri alınacak bir şey kalmamıştır. Rol ve yetki modelinin nasıl kurulacağını rol ve yetki yönetimi yazısında ayrıntılı anlatıyoruz.
Aynı müşteri iki şubeye birden düştüğünde ne olur?
Girişteki sahne bir kaza değil, kurulum tercihinin doğal sonucudur. Aynı firma iki şubede iki ayrı kayıt olarak açıldığında sistem bunu bir çakışma saymaz, çünkü ona göre ortada iki farklı müşteri vardır. Çözüm, kaydı açma anında benzersiz bir anahtar üzerinden kontrol yapmaktır: vergi numarası, e-posta alan adı veya normalize edilmiş ticari unvan. Anahtar seçilmediği sürece tekilleştirme her zaman geç kalır: ancak birisi elle fark ettiğinde başlar.
İkinci adım, çakışma bulunduğunda ne olacağını önceden yazmaktır. Çoğu KOBİ için en işlevsel kural şudur: firma kaydı tektir ve merkezde durur, fırsatlar ise şubeye bağlanır. Böylece iki şube aynı firmayla paralel çalışabilir, ama ikisi de diğerinin açık fırsatını görür ve teklif göndermeden önce haberdar olur. Kayıt açılışında yapılan kontrolün mantığını ve normalizasyon adımlarını veri kalitesi ve doğrulama yazısında ele aldık; çok şubeli yapıda bu adımlar isteğe bağlı olmaktan çıkar.
Her şubeye ayrı pipeline mı, tek pipeline mı?
Yaygın tavsiye her şubeye kendi pipeline'ını vermektir; böylece her müdür yalnızca kendi ekranına bakar. Çoğu KOBİ için bu tavsiyenin tersi doğrudur. Şubeler aynı işi yapıyorsa pipeline tek olmalı, şube yalnızca bir alan olarak taşınmalıdır. Sebebi basit: aşamalar bölündüğü anda tanımlar da bölünür. Altı ay sonra Bursa'nın 'teklif verildi' aşamasıyla İzmir'inki farklı şeyler anlatır ve iki şubeyi aynı raporda toplayamazsınız.
Ayrı pipeline yalnızca satış süreci gerçekten farklıysa gerekir. Bir şube keşif gerektiren, üç aylık döngüyle ilerleyen proje işleri yapıyorsa, diğeri aynı hafta kapanan tezgâh üstü satış yapıyorsa, tek bir aşama listesi ikisine de yalan söyler. Ölçüt şubenin adı değil, aşamaların çıkış koşullarıdır. İki iş kolunun bir sonraki aşamaya geçme kriterleri aynıysa pipeline da aynı olmalıdır; kriterler farklıysa ayırmakta tereddüt etmeyin.
Aşamaların nasıl tanımlanacağı ve kaç aşamanın yeterli olduğu konusunda pipeline şablonları yazısındaki çerçeve çok şubeli kurulumlarda da birebir geçerli. Tek fark şu: aşama tanımını artık tek bir ekip değil, birkaç şube müdürü birlikte kabul etmek zorunda.
Hangi alanlar zorunlu hâle gelmeli?
Tek ofisli kurulumda zorunlu alan sayısını düşük tutmak doğru bir reflekstir; her zorunlu alan veri girişini yavaşlatır ve benimsenmeyi zorlaştırır. Çok şubeli yapıda birkaç alan bu kuralın istisnasıdır, çünkü onlar olmadan yalnızca raporlama değil, günlük operasyon da çalışmaz.
- Sahip şube: Kaydın hangi şubenin sorumluluğunda olduğu; raporun, hedefin ve yetkinin dayandığı alandır, bu yüzden boş kalmasına asla izin verilmemelidir.
- Kaynak şube: Talebin ilk düştüğü yer; sahip şubeden farklı olabilir ve pazarlama harcamasının hangi şube için çalıştığını yalnızca bu alan gösterir.
- Hizmet veren şube: Teslimat, montaj veya servisi yapan birim; satan şubeyle aynı olmadığında maliyet ile gelir farklı yerlerde birikir ve kârlılık okuması bozulur.
- Sahip temsilci: Tek bir isim; ekip alanı ayrıca tutulabilir ama sorumluluk paylaştırılmamalıdır.
- Geçerli fiyat listesi: Şubeye veya bölgeye göre değişen liste kaydın üzerinde durmalıdır, yoksa teklif hazırlayan kişi hafızasına güvenmek zorunda kalır.
- Ortak hesap işareti: Birden fazla şubenin dokunduğu müşterileri işaretleyen basit bir bayrak; çifte teklifi engelleyen en ucuz mekanizma budur.
- Devir tarihi ve nedeni: Kayıt el değiştirdiğinde ne zaman ve niçin değiştiği; bu alan olmadan hiçbir devir tartışması kapanmaz.
Bu alanların hepsinin elle doldurulması gerekmez, gerekmemelidir de. Sahip şube atamadan, kaynak şube formun veya kanalın kendisinden, fiyat listesi şubeden türetilebilir. Elle bırakılacak tek alan devir nedeni olsun, onu da açılır listeyle üç dört seçeneğe indirin. Serbest metin olarak bırakılan devir nedeni altı ay sonra hiçbir soruya cevap vermez; herkes farklı bir cümle yazar ve toplamı okunamaz.
Gelen talep hangi şubeye gider?
Yönlendirme kuralı, çok şubeli yapının gerçekten test edildiği yerdir. Coğrafya en bilinen kriterdir, ama tek başına yeterli değildir ve bazı işlerde tamamen yanlıştır. Web üzerinden satış yapan bir firmada müşterinin posta kodu, hangi şubenin o ürünü stokta tuttuğundan çok daha az bilgi taşır. Sağlıklı bir kural zinciri genellikle şöyle sıralanır: önce ürün veya hizmet grubu, sonra dil, sonra coğrafya, en sonda kapasite.
Kapasiteyi en sona koymak önemlidir. Sırayla dağıtım baştan uygulanırsa doğru şubenin işini yanlış şube alır, ve müşteri ilk aramada kendisine bakamayacak birine denk gelir. Yönlendirme mantığının temel kurgusunu lead atama kuralları yazısında anlatıyoruz; çok şubeli yapıda eklenen tek katman, kuralın önce şubeyi, sonra kişiyi seçmesidir.
Kural zincirinin sonunda bir yakalayıcı olsun
Hiçbir kurala uymayan talep her zaman gelir: adresi yazılmamış form, tanımsız bir ürün sorusu, beklenmedik dilde bir mesaj. Bu kayıtlar için atanmamış adında bir havuz ve o havuza her gün bakan tek bir sorumlu tanımlayın. Yakalayıcı yoksa bu talepler sistemde durur ama kimsenin ekranında görünmez. Kaybolan lead'lerin büyük kısmı, kimsenin bakmadığı bu boşlukta kaybolur
İki şube tek anlaşma: kredi kime yazılır?
Şubeler arası devir kaçınılmazdır. İstanbul'a düşen talebin fabrikası Konya'dadır; keşfi Konya yapar, sözleşmeyi İstanbul imzalar. Bu anlaşma kimin sayısına yazılır? Cevabı önceden vermezseniz ay sonunda iki müdür aynı rakamı kendi raporuna koyar, toplam ciro şişer ve bunu fark eden ilk kişi finans olur.
İşleyen üç yaklaşım var. Birincisi anlaşmayı tek şubeye yazmak ve diğerine yalnızca aktivite kredisi vermek; kurulumu en kolayı ama katkı büyükse haksız hissettirir. İkincisi yüzde bazlı bölüşüm tanımlamak; kurulumu zahmetli, adalet duygusu en yükseği. Üçüncüsü geliri tek şubeye, kotayı iki şubeye birden yazmak; muhasebe tarafında toplam bozulmaz, motivasyon tarafında kimse kaybetmez. Hangisini seçerseniz seçin, devir anını kaydın üzerinde tarih ve nedeniyle işaretleyin. Devir sırasında bağlamın nasıl aktarılacağını ekip iş birliği yazısında topladık.
Şube kıyaslaması nasıl adil olur?
Çok şubeli yapıda ilk kurulan pano neredeyse her zaman aynıdır: şubeler, ciroya göre sıralı. Bu pano yanlış bir şeyi ölçmez, yanlış bir şeyi ödüllendirir. Pazarı büyük olan şube, ekibi ortalama olsa bile listenin üstünde durur; küçük pazarda olağanüstü iş çıkaran şube en altta görünür. Sonuç bir süre sonra sayısal değil insani olur: alttaki şubenin en iyi insanları ayrılır.
Şubeleri ham ciroya göre sıralayan bir pano, en iyi ekibi değil en iyi pazarı ödüllendirir.
Adil kıyaslama oran metrikleriyle kurulur: dönüşüm oranı, kazanma oranı, ortalama anlaşma büyüklüğü, satış döngüsü süresi ve temsilci başına üretilen pipeline. Bunların yanına potansiyele göre normalize edilmiş bir hedef koyun; şubenin hedefi kendi pazarının büyüklüğünden türemelidir, geçen yılki cirosundan değil. Hedefin nasıl belirleneceğini ve dağıtımın nasıl adil kalacağını satış kotası belirleme yazısında ele alıyoruz.
Bir başka görünmez sorun tanım farkıdır. Bursa aktif fırsat derken son otuz günde dokunulmuş fırsatı, İzmir ise kapanmamış her fırsatı kastediyorsa iki rakam kıyaslanamaz, üstelik ikisi de kendi içinde doğrudur. Şube sayısı üçü geçtiği anda ortak bir metrik sözlüğü yazmak, yeni pano tasarlamaktan daha öncelikli hâle gelir.
Merkezî çekirdek, yerel serbestlik: sınır nereye çekilir?
Her şubeye her şeyi özelleştirme hakkı verirseniz altı ay sonra elinizde dört ayrı sistem olur. Hiçbir şeye izin vermezseniz şubeler sistemi kullanmaz, kendi tablolarına döner. İşleyen ayrım şudur: veri modeli ve aşama tanımları merkezîdir, çalışma biçimi yereldir. Alan adları, zorunlu alanlar, aşamalar ve rapor tanımları merkezden yönetilir; kayıtlı görünümler, pano düzenleri, hatırlatma sıklıkları ve şablon metinler şubeye bırakılır.
Değişiklik talepleri de bir kuyruğa girmelidir. Şube müdürünün doğrudan alan ekleyebildiği kurulumlarda birkaç ay içinde beş farklı bütçe alanı oluşur ve hiçbiri diğeriyle kıyaslanamaz. Talebi önce bir test ortamında denemek, sonra yayına almak en ucuz yoldur; test ortamı ve değişiklik yönetimi yazısı bu akışı anlatıyor. Yapılan değişikliğin kim tarafından ne zaman yapıldığını geriye dönük görebilmek için denetim kaydı da açık olmalı; çok şubeli yapıda bu alanı kim değiştirdi sorusu, tek ofisli yapıya göre çok daha sık sorulur.
Nereden başlamalı, hangi hatalardan kaçınmalı?
En sık görülen üç hata birbirini besler. Birincisi, kurulumu tek bir şubenin ihtiyacına göre yapıp diğerlerine dayatmak; İkincisi, görünürlük kararını erteleyip başlangıçta herkesi her şeye açmak ve altı ay sonra kısıtlama getirmeye çalışmaktır; geri alınan yetki, hiç verilmemiş yetkiden kat kat fazla direnç üretir. Üçüncüsü, şube bilgisini fırsatın kendisine değil yalnızca kullanıcıya bağlamaktır: temsilci şube değiştirdiğinde geçmiş bütün fırsatlar da yeni şubeye taşınır ve geçen yılın raporu bir gecede başkalaşır.
Başlangıç için işleyen sıra şudur: önce iki şubeyle pilot yapın, en az biri merkez olmayan bir şube olsun. Görünürlük modelini ve devir kuralını tek sayfada yazılı hâle getirin, iki hafta boyunca yalnızca bu iki şubeyi çalıştırın ve ortaya çıkan itirazları not edin. İtirazların çoğu yetkiyle değil görünürlükle ilgili çıkarsa modeli doğru yerinden test etmişsiniz demektir. Sonra üçüncü şubeyi ekleyin, ve otomasyon kurallarını ancak bundan sonra yazın; erken yazılan otomasyon yanlış modeli hızlandırmaktan başka işe yaramaz.
Çok şubeli bir yapıda ihtiyacınız olan şey her şubeye ayrı bir sistem değil, aynı veri modeli üzerinde şubeye göre daralan bir görünümdür. Rocketly'de kullanıcı rolleri, kayıt sahipliği, atama kuralları ve şube kırılımlı raporlar aynı kurulumda birlikte çalışıyor; ücretsiz hesap açarak kendi şube ve ekip yapınızı kurup deneyebilirsiniz.