CRM, İngilizce customer relationship management ifadesinin kısaltması; Türkçe karşılığı müşteri ilişkileri yönetimi ve yazılım tarafında müşteriyle kurulan ilişkinin kaydını tutan sistemi adlandırıyor. Hangi kaydı tutacağına karar verilen yer sektör listesi değil, müşteri ilişkisinin ağırlığının satışın hangi tarafında yaşadığı. Diotek’te ilişki satılacak cihaz belirlenmeden başlıyor, diş kliniğinde ise asıl ilişki tedavi başladıktan sonra yaşıyor.
CRM, müşteri ilişkileri yönetiminin kısaltması
Bir uyarı en başta dursun: aynı kısaltma havacılıkta ekip içi iletişim eğitiminin de adı, o yüzden arama sonuçlarında o alanın sayfaları yan yana çıkabiliyor. Buradan sonrası yazılım anlamını anlatıyor.
Açılımın işaret ettiği şey müşterinin kendisi değil, müşteriyle aranızdaki ilişki. Rehberinizde bir telefon numarası durur; o numaranın sahibiyle geçen ay ne konuşulduğu orada durmaz. Adres defteriyle CRM arasındaki fark da bu: defter kimi arayacağınızı tutar, CRM o müşteriyle ne yapıldığını ve sırada ne olduğunu da tutar.
“Müşteri bilgisi” ifadesi bir yazılımı tarif etmeye yetmiyor, çünkü hangi bilgi olduğunu söylemiyor. Bir CRM’in tuttuğu şey şu soruların cevaplarının zaman içinde birikmiş hâli: kiminle ne konuşuldu, ne istendi, ne yapıldı, bundan sonra ne yapılacak. Kaydın konusu adlandırılmadığı sürece tanım yarım kalıyor.
Bu birikimin bir yüzü geçmişe, bir yüzü ileriye bakıyor. Geçmiş yüzü kolay anlaşılıyor; kayıt tutmak zaten olanı yazmak gibi duruyor. İleri yüzü gözden kaçıyor. Bekleyen iş kaydın üzerinde durmuyorsa kayıt bir arşive dönüşüyor, arşive de günlük işin içinde kimse bakmıyor. Bir CRM’in gerçekten kullanıldığını buradan anlarsınız: ekip sabah kaydı açıyor mu, yoksa akşam kaydı dolduruyor mu?
Kısaltmanın “yönetim” kısmı da boşuna değil. Yönetilen şey ilişkinin kendisi değil, ilişkinin sürmesi için gereken sıra: kim bekliyor, kime dönülecek, hangi işin önünde ne var. Bu sıra bir yerde durmuyorsa en sesli müşteri en hızlı cevabı alıyor.
Tutmadığı şeyi de söylemek gerekiyor. Bir CRM muhasebe defteri değil, stok sayımı değil, üretim planı değil. İlişkiyle ilgisi olmayan bilgiyi içine almak kaydı okunmaz hâle getiriyor. Kapsam sorusu bu yüzden “neyi ekleyelim” değil, “hangi bilgi ilişkiye bağlı” sorusu.
Bir CRM gün içinde ne işe yarıyor
Bir CRM’in gün içindeki işi, soruyu soran kişiyi değiştirmek. Müşteri aradığında cevap veren kişi etrafa “bununla en son ne olmuştu” diye mi soruyor, yoksa kaydı açıp okuyor mu? Yazılımın faydası tam burada ölçülüyor.
Kullanan kişi bir müşteriyi açtığında geçmişi de bekleyen işi de aynı ekranda görüyor. Ne istendiği, ne yapıldığı ve sırada ne olduğu yan yana duruyor. Bilgi, onu hatırlayan kişinin aklında durmuyor. Bu ayrımın bedeli tatilde, yoğun haftada ve ekip değişikliğinde ödeniyor: hatırlayan kişi masada değilse bilgi de masada değil.
Daha sessiz işleyen bir tarafı var. Aynı müşteriyle birden fazla kişi konuştuğunda sıradaki kişi en son ne olduğunu sormak zorunda kalmıyor, çünkü kayıt kişinin altında değil müşterinin altında duruyor. Satış görüşmesini yapan kişiyle işi yürüten kişi aynı değilse bu tek başına fark yaratıyor.
Kaydı üreten kişiyle okuyan kişi de her zaman aynı değil. Sahada çalışan biri kaydı açıyor, ofiste duran biri okuyor; bazen tersi oluyor. Kayıt kimin elinde doğuyorsa sistemin o noktada çalışması gerekiyor, çünkü hiç yazılmamış bir kayıt sonradan okunamıyor.
Bilgi oraya ekibin elle yazdığı notlardan giriyor, bir de işin kendi akışının ürettiği kayıtlardan: randevu, talep, fatura. Aradaki fark önemli. Elle yazılan not yazılmayı unutuluyor; akışın ürettiği kayıt ise işin yapılmasıyla birlikte doğuyor ve kimsenin disiplinine kalmıyor. Bir CRM’in ne kadar güvenilir olduğu, kaydının ne kadarını akışın kendisinin ürettiğine bağlı.
Asıl soru da burada başlıyor. Akışın ürettiği kayıtların hangileri olduğu işletmeden işletmeye değişiyor. Randevu veren bir klinikle keşif yapan bir havalandırma firması aynı ekranlarla yürümüyor, çünkü işleri aynı kayıtları üretmiyor. “CRM nedir” sorusunun cevabı bu noktadan sonra tek bir ürün tarifi olmaktan çıkıyor.
Sorulması gereken soru: ilişki satıştan önce mi, sonra mı yaşıyor
Yazılım ararken alışkanlık sektör adı yazmak oluyor: klinik CRM, servis CRM, emlak CRM. Sektör adı bir ipucu veriyor ama kararı taşımıyor, çünkü aynı sektörde işin ağırlığı farklı yerlerde durabiliyor. Kararı taşıyan soru şu: müşteriyle kurduğunuz ilişkinin ağırlığı satıştan önce mi, satıştan sonra mı yaşıyor?
Diotek’te ilişki, satılacak cihaz belirlenmeden başlıyor. Klima işinde hangi cihazın yeteceğini mekân belirliyor; bu yüzden teklif öncesinde yerin görülmesi gerekiyor. Yani ortada satılmış bir ürün yokken tutulması gereken bir kayıt var ve o kaydı tutan şey bir CRM.
Diş kliniğinde ağırlık öbür tarafa düşüyor. Tedavi tek randevuda bitmiyor. Plan diş diş kuruluyor, seanslar haftalara yayılıyor ve arada değişiyor. Burada ilişkinin asıl kısmı iş başladıktan sonra yaşıyor; CRM’den beklenen şey bir tarih değil, işin neresinde olunduğu.
Aynı kısaltma bu işlerde başka başka sistem demek. Birinde kaydın asıl görevi henüz yapılmamış bir işi tanımlamak, ötekinde yapılmakta olan bir işin nerede kaldığını tutmak. Ekran listeleri birbirine benzese de kaydın konusu aynı değil.
Bu ayrımın karşı durumu da var: ilişkinin ağırlığı her işte belirgin bir tarafa düşmüyor. Perakende bir satışta görüşme kısa, geçmiş de kısa; orada bir CRM’in taşıdığı yük hafif kalıyor. Soruyu sormaya değer kılan şey, satışın bir tarafında konuşmanın haftalara yayılması.
Bu ayrım, talep tiplerinin ayrılması meselesiyle komşu ama aynı şey değil. Bir talebin hangi akışa ait olduğu ve ayrımın veri modelinde nasıl taşındığı randevu ile servis talebi ayrımı üzerine yazdığımız yazının konusu. Buradaki soru daha geride duruyor: kayıt satışa göre hangi tarafta doğuyor?
Kendi işinizde yoklamanın kolay bir yolu var. Müşterinizle en uzun konuşmayı para el değiştirmeden önce mi yapıyorsunuz, sonra mı? Cevap “önce” ise kaydınızın tutması gereken şey bir istek; “sonra” ise bir geçmiş. Cevap tek bir tarafı göstermiyorsa sıralama sorusuna geliyoruz, ki ona aşağıda dönüyoruz.
Satış öncesinde kayıt, henüz var olmayan bir şeyi tutuyor
Satış öncesi kaydın tanımlayıcı özelliği şu: bağlanacağı nesne henüz yok. Ortada bir ürün kodu, bir seri numarası ya da kurulu bir cihaz bulunmuyor. Kayıt yine de açılmak zorunda, çünkü ilişki çoktan başlamış.
Diotek’te siteye gelen kişi henüz hiçbir cihazı işaret etmiyor; talebi, yerin görülmesi için bir tarihten ibaret. Keşif kaydı bir ürüne değil, görülecek yere ve istenen zamana asılıyor; hangi cihazın uyduğu ziyaretin kendisinde belli oluyor. Keşfin kendisi siteye taşınmıyor, taşınamaz da: kapasite ancak yerinde görülerek belirleniyor. Siteden geçen şey yalnız istek. Hangi adımın self servise taşınabileceği ölçüsünü satış öncesi self servis adımlar üzerine yazdığımız yazıda ayrıca açtık.
Bu tarafta kaybolan şey müşteri değil kayıt. Diotek’te istek telefon hattına bağlı değil; hat meşgulken siteye ulaşan ziyaretçi de arkasında yazılı bir iz bırakıyor. Kanal tek olduğunda ilişki hiç başlamadan düşüyor. Satış öncesi tarafta CRM’in ilk işi bu yüzden müşteri kartı tutmak değil, isteği yazıya geçirmek.
Tek seferlik satış yapan bir işte bile tutulacak bir kayıt var. O kayıt müşterinin geçmişi değil, henüz karşılanmamış istek. İsteklerin bir kuyruğu yoksa sıra, gelen çağrının sesine göre kuruluyor.
Calculator Resterm’de aynı taraf başka bir yüzden görünüyor. Girdi bir katalog kodu değil, ısıtılacak işin kendi ihtiyacı; mühendislik hesabını yazılım yapıyor ve uygun elektrikli ısıtıcıyı seçiyor. Ürün adı kaydın girdisi değil çıktısı. Yani ilişki, ürün belirlenmeden önce kayda geçmiş oluyor.
Bunun CRM tarafındaki sonucu açık: Resterm’de proje o projenin müşterisine bağlandığı için müşteri kaydı teklif daha yazılmadan var oluyor. Müşteri kaydı satıştan değil talepten doğuyor. Seçimin sepete, sepetin projeye ve projenin müşteriye nasıl bağlandığını hesap çıktısının teklife dönüşmesi üzerine yazdığımız yazıda anlattık; burada önemli olan zincirin kendisi değil, kaydın doğduğu an.
Satış öncesi kaydın tuttuğu şey kararın kendisi değil, karara giden istek. Bu yüzden bu tarafta kayıt kapanıyor: keşif yapılıyor, teklif veriliyor, istek bir karara dönüşüyor. Kaydın ömrü kısa; ama ömrü boyunca tek başına ayakta durması gerekiyor, çünkü arkasında dayanacağı bir nesne yok.
Satış sonrasında kayıt, elde duran bir şeye asılıyor
Satış sonrası tarafta durum tersine dönüyor. Kaydın bağlanacağı nesne elde var ve kayıt onun altına asılıyor.
Diş kliniği CRM’inde bu nesne belirli bir diş ve o diş için kurulmuş plan. Tedavi planı, hangi işlemin hangi dişe yapılacağını sıralı seanslar hâlinde taşıyor. Plan randevudan bağımsız duruyor, yani takvime bakmadan okunabilen bir kayıt. Randevu ona bağlanıyor, onun yerine geçmiyor.
Kayıt var olan bir şeye asıldığı için zamanla kalınlaşıyor. Seans ekleniyor, plan değişiyor, yapılan işlem yazılıyor. Kliniğin daha önce kullandığı genel amaçlı randevu yazılımı zamanı tutuyordu, planın hangi adımında olunduğunu tutmuyordu. Kayıt vardı, bağ yoktu. Burada önemli olan eksiğin adı: tutulan şey saatti, ilişki değildi.
AlgoKlima’da aynı taraf daha keskin görünüyor. Servis geçmişi müşteri kartına değil cihazın kendisine asılı: garanti durumu, yapılmış bakımlar ve açılmış arıza kayıtları o cihazın altında toplanıyor. Aynı adresteki cihazların dosyaları birbirine karışmıyor. Cihaz el değiştirdiğinde de geçmişi kendisiyle gidiyor; yeni sahibin kartına baştan yazılmıyor. AlgoKlima bizim kendi ürünümüz, yayında ve geliştirilmeye devam ediyor.
Bu tarafta kolay görünen başka bir yol daha var: geçmişi serbest metin alanına yazmak. Not alanı her şeyi kabul ediyor, ama hiçbir şeyi sorgulanabilir hâle getirmiyor. Bir cihazın son bakımının ne zaman yapıldığını not alanından okumak, her seferinde yeniden okumak demek.
Buradaki ders şu: satış sonrası tarafta kayıt her zaman müşteriye asılmıyor. İlişkinin ağırlığını hangi nesne taşıyorsa kayıt o nesneye açılıyor. Sahibi değişince ilişkinin tarafı değişiyor ama kayıt yerinde kalıyor. Kaydı doğrudan müşteriye asmak kolay görünen yol; aynı müşteride birkaç dosya varsa o kolaylık geçmişin karışması olarak geri geliyor.
Satış öncesi kayıt kapanıp bir karara dönüşürken satış sonrası kayıt kapanmıyor. Plan adımı eklendikçe, cihaza servis açıldıkça aynı kaydın altı dolmaya devam ediyor. CRM’in bu taraftan beklediği dayanıklılık bu yüzden farklı: kayıt yıllar sonra da okunabilir kalmak zorunda ve okuyan kişi büyük olasılıkla onu yazan kişi olmayacak.
Kayıt satışa göre nerede doğuyor
Aşağıdaki satırlar kendi işlerimizden. Tabloyu sektör listesi gibi okumak yazının tezini kaybettiriyor; ekseni taşıyan sütun, kayıt açıldığında bağlanacağı şeyin elde olup olmadığını söyleyen sütun.
| İş | İlişkinin ağırlığı satışın hangi tarafında | Kayıt açıldığında bağlanacağı şey elde var mı | Kaydın tutmak zorunda olduğu şey |
|---|---|---|---|
| Diotek | Satıştan önce | Yok: ortada seçilmiş bir cihaz değil, görülmesi gereken bir mekân var | İsteği yazıya geçirmek ve hangi akışa ait olduğunu kendisinin taşıması |
| Calculator Resterm | Satıştan önce | Yok: girdi ürün değil ısıtma ihtiyacı, ürünü hesap seçiyor | Girdinin, hesabın seçtiği ürünün ve müşterinin aynı zincirde kalması |
| Diş kliniği CRM | Satıştan sonra | Var: belirli bir diş ve o diş için kurulmuş sıralı seanslar | Tedavinin hangi adımında olunduğu |
| Pilatesco | Satış anında ve sonrasında | Var: satılmış bir paket, henüz kullanılmamış ders hakkı | Satış anı ile haftalara yayılan kullanımın arasındaki kalan hak |
| AlgoKlima | Satıştan sonra | Var: adrese kurulmuş belirli bir cihaz | Garanti, bakım ve arıza geçmişinin cihazla birlikte kalması |
Satırlar yan yana durduğunda kaydın bağlandığı şey her seferinde farklı çıkıyor: bir mekân, bir ısıtma ihtiyacı, bir diş, satılmış bir paket, kurulu bir cihaz. Ayrımı üreten şey sektör değil, kaydın satışa göre nerede doğduğu. Kliniği servis firmasıyla aynı sütunda buluşturan şey de bu; birbirine hiç benzemeyen işler aynı kayıt davranışını paylaşıyor.
Bağlanacak şeyi soran sütun pratik bir sonuç veriyor. “Yok” yazan satırlarda kaydın ilk görevi isteği kaybetmemek; “var” yazan satırlarda ilk görevi geçmişi doğru nesneye asmak. Kendi işinizi bu sütundan okuyabiliyorsanız, hangi ekranların gerektiğini konuşmaya başlamadan önce elinizde bir cevap var.
Satışın önü ile arkası aynı müşteri kaydında buluşuyor
Buraya kadarki ayrım bir seçim gibi görünebilir: ya önü ya arkası. Öyle değil. Satışın önü ile arkası ayrı sistemler değil, aynı müşteri kaydının farklı kolları.
Pilatesco’da bu en net görünüyor. Paket satıldığı anda fatura çıkıyor; kullanım ise haftalar boyunca takvimden tükeniyor. Satış bir ana ait, kullanım bir aralığa. Farklı zamanlamadaki bu kayıtlar tek müşteri kaydında birleşiyor ve CRM’in tuttuğu şey ne satış belgesi ne takvim; aradaki kalan hak.
Kalan ders hakkı da müşteri kaydının üzerinde taşınıyor; ayrı bir deftere geçilmiyor. Yani satışın arkasındaki kayıt, satışın önündeki işlemden doğuyor. Hangi durumun bakiyeye ne yaptığı ise bir CRM kaydı değil bir kural tanımı; iptalin, gelmemenin ve tamamlanan dersin bakiyeye nasıl işleyeceğini kurulumda yazmak yönetim yazılımları tarafının konusu.
Aynı kayıt üzerinde durmanın pratik faydası raporlamada görünüyor. Satılan ile kullanılanı karşılaştırmak için ay sonunda ayrı defterleri yan yana koymak gerekmiyor; soru zaten aynı kayıttan cevaplanıyor.
Diotek satışın önünde de arkasında da çalışıyor. Siteye gelen talebin bir yüzü satıştan önce duruyor, öteki yüzü montaj sonrası bakım ve arıza. Aynı işletme hem satış öncesi hem satış sonrası kayıt tutmak zorunda. Akışların nasıl ayrıldığı yukarıda linklediğimiz yazının konusu; burada önemli olan satışın önü ile arkasının aynı işletmede birlikte durabilmesi.
Pratikte bu, seçimin tek taraflı olmadığı anlamına geliyor. Ağırlığın hangi tarafta olduğu kurulum sırasını belirliyor, öteki tarafı silmiyor. Önce kurulan taraf daha ayrıntılı çıkıyor; sonra gelen taraf aynı müşteri kaydının üstüne biniyor. Yanlış tarafı seçme korkusu bu yüzden gereğinden büyük: seçilen şey bir sistem değil, bir başlangıç noktası.
CRM kurulurken ilk hangi kayıt tanımlanıyor
Buraya kadarki soru teşhis; bu bölüm yarın ne yapacağınızla ilgili. Bir CRM kurulurken ilk tanımlanan kayıt, ilişkinin ağırlığını taşıyan kayıt oluyor; geri kalanı onun üstüne biniyor.
Diş kliniğinde sıra böyle kuruldu: ilk tanımlanan kayıt tedavi planı oldu, randevu ona sonradan bağlandı. Ters sırada kurulan bir sistemde takvim dolu, plan boş kalıyor. Takvim işin ne zaman yapıldığını biliyor, nerede kaldığını bilmiyor.
AlgoKlima’da ilk tanımlanan kayıt müşteri bile değil. Geçmiş kişiye değil cihaza bağlandığı için sistemin omurgası cihazın kendisi oldu; müşteri o cihazın bugünkü sahibi olarak bağlanıyor. Kural her işte aynı: ilişkinin ağırlığını hangi nesne taşıyorsa kayıt o nesneye açılıyor.
Diotek’te sıra yine değişiyor. Siteden açılan şey satış değil yazılı bir istek; istek kendi akışında operasyona düşüyor ve kayıt telefon notuna bağlı kalmıyor. Satış öncesi ağırlıklı bir işte ilk tanımlanan kayıt talep kaydı oluyor, müşteri kartı onun arkasından geliyor.
Bu kararı yazılımcıya anlatmak ayrı bir beceri. Sistemde bir satırın neye karşılık geldiğini yazmak, ekran listesi çıkarmaktan daha çok işe yarıyor; bunu ihtiyacınızı yazılımcıya nasıl anlatırsınız üzerine yazdığımız yazıda açtık.
Sırada duran soru hazır bir ürünle mi yoksa özel bir yazılımla mı yürüyeceğiniz. Bu yazı o kararı vermiyor. Soruyu hazır CRM mi özel CRM mi başlıklı rehberde karşılıyoruz.
Buradan kazandığınız şey karar değil, karara girerken elinizde duracak soru. Hangi bilginin neyin altında duracağını konuşmak için CRM sayfasındaki maddelere bakabilirsiniz: her madde bir işten geliyor ve hangi kaydın hangi nesneye asıldığını yazıyor.