CRM'de doğru veri modeli nedir?

Doğru model üç varlığı birbirinden ayırır: hesap (firma), kişi (o firmadaki insan) ve fırsat (belirli bir satış girişimi). Bu üçü tek bir "müşteri" tablosunda birleştirildiğinde; aynı firmadan iki kişi iki ayrı müşteri olur, kişi firma değiştirdiğinde geçmiş kaybolur ve aynı firmaya açılan iki teklif birbirini görmez. Modeli sonradan ayırmak, mevcut tüm kayıtların elle yeniden ilişkilendirilmesini gerektirir.

Ek olarak ayrılması gereken kayıtlar

  • Aktivite: görüşme, e-posta, ziyaret. Hem kişiye hem fırsata bağlanabilmelidir.
  • Ürün/hizmet satırı: fırsatın içindeki kalemler; tutar yalnızca başlıkta tutulmamalıdır.
  • Rakip ve kayıp nedeni: kaybedilen fırsatın nedeni seçilebilir bir listeden gelmelidir, serbest metinden değil.
  • İlişki tipi: aynı kişi hem karar verici hem teknik değerlendirici olabilir.

Tekilleştirme kuralını baştan yazın

Mükerrer kayıt, CRM'i kullanılamaz hâle getiren birinci nedendir. Kural setini önceden tanımlayın:

  • Firma için vergi numarası birincil anahtar; yoksa normalize edilmiş unvan + şehir.
  • Kişi için e-posta birincil anahtar; yoksa telefon numarası (uluslararası formata normalize edilerek).
  • Yeni kayıt açılırken benzerlik kontrolü kayıt anında yapılmalı, sonradan raporla değil.
  • Birleştirme (merge) işlemi, hangi kaydın kazandığını alan bazında sorabilmelidir.

İzin yönetimi bir CRM işlevidir

Pazarlama iletişimi gönderiyorsanız, iznin kanal bazında ve tarihli olarak tutulması gerekir: e-posta izni var mı, SMS izni var mı, izin ne zaman ve hangi metinle alındı, ne zaman geri çekildi? İzin kaydı olmayan bir CRM, ticari elektronik ileti gönderiminde doğrudan hukuki risk üretir. Aynı şekilde, izin geri çekildiğinde bunun tüm gönderim listelerine yansıması otomatik olmalıdır.

Satış hunisini ölçülebilir kılmak

Aşamalar, satış temsilcisinin hissine göre değil kanıta göre tanımlanmalıdır. Örneğin "Teklif verildi" aşaması, sistemde bir teklif belgesi varsa geçerlidir. Her aşama için geçiş koşulu yazıldığında şu ölçümler anlamlı hâle gelir: aşama bazlı dönüşüm oranı, aşamada geçen ortalama süre, kaybedilen fırsatların aşama dağılımı ve tahmin doğruluğu (tahmin edilen kapanış ile gerçekleşen fark).

Alan sayısını sınırlamak benimseme oranını artırır

Satış ekibi doldurmadığı sürece CRM veri üretmez. Zorunlu alanları, raporda gerçekten kullanılanlarla sınırlayın. Pratik bir kural: bir alan hiçbir raporda ve hiçbir otomasyonda kullanılmıyorsa zorunlu olmamalıdır. Alan çokluğu, veri kalitesini artırmaz; kayıt açılmamasına yol açar.

ERP ile ilişki

CRM satış öncesini, ERP satış sonrasını yönetir. Sınır, siparişin oluştuğu andır. Fırsat kapandığında sipariş ERP'de açılmalı ve ERP'deki cari kodu CRM hesabına geri yazılmalıdır. İki sistemde ayrı ayrı müşteri kartı yönetmek, kaçınılmaz olarak farklı adres ve unvan verisi üretir. Aktarımın teknik tarafı için API entegrasyonu rehberine bakabilirsiniz.

Sık sorulan sorular

CRM'e geçmiş veriyi taşımalı mıyız?

Açık fırsatları, aktif kişileri ve son iki yılın aktivitelerini taşımak genellikle yeterlidir. Tüm geçmişi taşımak, mükerrer ve güncel olmayan kaydı yeni sisteme kopyalar; temizlik yapılmadan yapılan göç, eski sistemin sorunlarını devralır.

Satış temsilcisi kendi kayıtlarını başkasından gizleyebilmeli mi?

Görünürlük kuralı şirket politikasıdır ve sistemde tanımlanabilir olmalıdır. Ancak tamamen kapalı bir model, temsilci ayrıldığında bilgi kaybına yol açar; en az yönetici seviyesinde tam görünürlük önerilir.

CRM'de otomasyonlar nereden başlamalı?

Hatırlatma ve atama otomasyonlarından. Gelen talebin sorumluya atanması ve yanıtlanmayan talebin süre aşımında yükseltilmesi, en düşük çabayla en görünür faydayı üretir.