KOBİ'lerde CRM Seçmeden Önce Cevaplanması Gereken Beş Soru

CRM demosunda her özellik yararlı görünebilir. Seçimi netleştiren şey, işletmenin kendi işini ne kadar açık tarif edebildiğidir. Ben ilk görüşmede yazılımdan önce talebin kime ait olduğunu ve sıradaki işi sorarım.

CRM arayan bir işletmenin önünde kısa sürede uzun bir özellik listesi birikiyor. Takvim, otomasyon, raporlar, mesajlaşma, farklı kanallarla bağlantılar… Liste büyüdükçe kararın kolaylaşması bekleniyor. Bazen tam tersi oluyor.

Ben seçim işini biraz daraltmayı tercih ediyorum. Önce işletmenin kendi akışından bir talep ele alınmalı. Bu talep geldiğinde nereye düşüyor, kim üstleniyor ve ne zaman hangi iş yapılıyor? Alınacak programı bu akışın üzerinde görmek, özellikleri yan yana sıralamaktan daha somut bir başlangıç veriyor.

Aşağıdaki sorular belirli bir CRM markası önermek için değil, işletmenin kendi denemesini hazırlaması için.

Bir: Talebin sahibi kim olacak?

“Satış ekibi bakar” cevabı ilk anda yeterli görünebilir. Ama bir talep geldiğinde ekipteki herkes diğerinin ilgilendiğini düşünüyorsa kaydın kime ait olduğu belirsizdir. CRM'de ilk netleştirmek istediğim konu budur.

Talep belirli bir kişiye mi atanacak, ortak kuyruktan mı alınacak? O kişi izinliyken veya başka bir görüşmedeyken yerine kim bakacak? İşletme bu kuralı anlatamıyorsa yazılımın otomatik atama özelliği tek başına karar veremez.

Denemede görev atamayı ve sorumlunun bunu gördüğünü birlikte kontrol edin. Bir yönetici kaydı açtığında kimin ilgilendiğini anlayabiliyor mu? Bunu anlamak için ayrıca mesaj grubuna sorması gerekiyorsa süreç üzerinde biraz daha çalışmak gerekir.

İki: Kayıt üzerinde hangi bilgi gerçekten gerekli?

Bir sisteme çok alan eklemek kolay. O alanları her gün doğru doldurmak daha zor. Ben ilk aşamada, bir sonraki kişinin işe devam etmesini sağlayacak bilgiyi ayırmaya çalışıyorum.

Müşterinin ihtiyacı, geldiği kanal, son konuşmanın özeti ve açık kalan konu çoğu akışta önemli bir başlangıçtır. Gereken alanlar işin türüne göre değişir. Bir servis talebinde gerekli olan bilgi, danışmanlık başvurusunda aynı olmayabilir.

Örnek olarak, deneme için oluşturulmuş kurgusal bir kayda yalnızca “teklif gönderildi” yazıldığını düşünün. Hangi ihtiyaç için teklif verildiği ve müşterinin hangi bilgiyi beklediği yoksa not eksiktir. Kayıt dolu görünür; ama işi devralacak kişiye yeterince yardımcı olmaz.

Eski kayıtları taşırken de aynı ayrımı yapmak gerekir. Aynı kişiye ait tekrarlar ve anlamı belirsiz sütunlar yeni sisteme topluca aktarılırsa eski karışıklık da taşınabilir. Küçük bir örnek dosya üzerinde alan eşleştirmesini görmek isterim.

Verinin dışarı alınmasını da daha seçim aşamasında denemeye eklerim. Bugün kullandığınız programdan ileride ayrılmanız gerekebilir. Kayıtları, notları ve sorumluları anlaşılır bir dosyada alabiliyor musunuz? Bu dosyayı başka bir çalışan açtığında hangi bilginin ne olduğu belli mi? Yalnızca ekranda düzgün görünen bir yapı yeterli olmaz; işletmenin kendi geçmişini anlayabilmesi ve gerektiğinde taşıyabilmesi de önemlidir. Bu kontrolü sona bırakmak yerine küçük deneme dosyasının bir parçası yapmak, seçim sırasında gözden kaçan bir ihtiyacı ortaya çıkarabilir.

Üç: Bir sonraki adım nasıl görünecek?

“Yeni”, “arandı” ve “görüşüldü” gibi durumlar ne olduğunu özetleyebilir. Fakat bundan sonra ne yapılacağını her zaman söylemez. Kaydın bir durumunun yanında açık bir işi de olmalı.

Müşteriye ek bilgi mi gönderilecek, belirli bir tarihte tekrar mı yazılacak, bir başka çalışandan onay mı beklenecek? Sıradaki işin sorumlusu ve kontrol zamanı anlaşılır olmalı. Her kayda aynı aralıkla hatırlatma koymak, bu kararı vermenin yerini tutmaz.

Denemede bir takip işini geciktirin ve ekibin bunu nasıl gördüğüne bakın. Uyarı doğru kişiye mi gidiyor? Tamamlanmamış iş raporda seçilebiliyor mu? Uyarıyı görmek için gün boyunca farklı ekranlar açmak gerekiyorsa kullanım biçimini yeniden değerlendirin.

Müşteri cevap verdiğinde takip dizisinin ne yapacağını da sorun. Yanıt vermiş bir kişiye hâlâ cevap bekleniyormuş gibi mesaj gitmesi, sürecin koşullarının yeterince tarif edilmediğini gösterebilir.

Dört: Ekip bu kaydı günlük işinde kullanabilecek mi?

Bir özelliğin demoda gösterilebilmesiyle ekibin onu günlük işinde kullanabilmesi farklı meseleler. Seçim sırasında işin gerçekten yapılmasını görmek isterim. Masa başındaki yönetici kadar sahadaki çalışanın ihtiyacı da hesaba katılmalı.

Bir çalışan telefondan not ekleyebiliyor mu? Talebi başka birine devrettiğinde geçmiş konuşma korunuyor mu? Ofiste olmayan kişi hangi bilgilere erişebiliyor? Bu soruları gerçek müşteri verileri yerine test kayıtlarıyla denemek mümkün.

Ekip için her alanın ne anlama geldiğini de açıklayın. Birinin “ilgileniyor” dediği durum diğerine göre “henüz aranmadı” ise raporun ortak bir dili yoktur. Kısa bir kullanım kuralı ve örnek kayıt, bu ayrılığı görünür kılar.

Yetkileri de bu çalışma sırasında belirlemek gerekir. Her çalışanın bütün kayıtları görmesi veya silebilmesi şart olmayabilir. Programın sunduğu seçenekleri işletmenin sorumluluk düzeniyle eşleştirin.

Beş: Düzenin çalıştığını nasıl anlayacağız?

Ben raporda yalnızca kaç kayıt açıldığını görmek istemem. Sahipsiz talep var mı, sonraki işi olmayan kayıt var mı, bekleyen konuların nedeni belli mi? Bunlar yöneticinin günlük işine daha yakın sorular.

İlk yanıtın tanımını da netleştirin. Otomatik bir alındı mesajı ile müşterinin sorusunu karşılayan cevap aynı bilgi değildir. Rapor bu iki durumu ayıramıyorsa ekip hızlandığını düşünebilir, müşteri ise hâlâ cevap bekliyor olabilir.

Seçimden önce küçük bir deneme senaryosu yazın. Bir talep oluşturun, sorumluya atayın, görüşme notu ekleyin, başka çalışana devredin ve takip işini kapatın. Sonra yönetici olarak kaydı açıp ne olduğunu anlamaya çalışın.

Bu denemeden sonra hangi özelliğin gerekli olduğu daha açık görünür. Ekibin tarif edemediği bir süreci yazılıma bırakmak yerine, önce birlikte tarif edersiniz. CRM seçiminin işletmeye asıl katkısı da burada başlar: herkesin aynı talep için ne yapacağını bilmesi.