CRM

Lead Intelligence

Çok kanallı lead yönlendirme, CRM entegrasyonu ve pazarlama performansını bir araya getiren analiz platformu.

LICRM

Çözülmesi gereken

Farklı kanallardan gelen potansiyel müşterileri uygun satış temsilcisine yönlendirmek ve satış sürecini reklam performansıyla birlikte izlemek.

Uygulanan yaklaşım

Kural tabanlı lead dağıtımı, CRM senkronizasyonu ve ortak filtrelerle çalışan analiz ekranları.

Problem

Farklı kanallardan gelen potansiyel müşterilerin doğru satış temsilcisine aktarılması, müşteri geçmişinin korunması ve sürecin CRM ile tutarlı ilerlemesi gerekiyor. Lead elle dağıtıldığında iki şey birden bozuluyor: aynı kişiyle daha önce görüşen temsilci kaybediliyor ve mesai dışında gelen kayıtlar sahipsiz kalıyor.

Operasyon tarafında ise lead, satış ve kampanya verilerini ayrı ekranlardan birleştirmek yerine birlikte değerlendirebilmek önemli. Reklamın getirdiği kayıt ile o kaydın satışa ne kadar yaklaştığı farklı sistemlerde durduğunda, hangi kampanyanın gerçekten işe yaradığı da söylenemiyor.

Yaklaşım

Lead Intelligence'ı bir dağıtım kuyruğu olarak değil, lead gelir → kapsam belirlenir → temsilci seçilir → CRM'e yazılır → sonuç reklama geri bildirilir zincirinin tamamı olarak ele aldım. Hangi kanaldan gelirse gelsin her kayıt aynı karar hattından geçiyor; ekranlar da bu hattın farklı noktalarına bakan görünümler oluyor.

Lead Dağıtım Akışı

Dağıtım rastgele bir seçim değil, sıralı bir eleme:

  1. Lead sisteme düşüyor ve daha önce kayıt olup olmadığı kontrol ediliyor.
  2. Aynı kişiyle daha önce ilgilenen bir temsilci varsa süreklilik korunuyor.
  3. Kaydın hangi pipeline altında değerlendirileceği belirleniyor; bu bilgi formdan doğrudan gelebiliyor, telefon akışında seçilebiliyor ya da chatbot akışına bağlı olabiliyor.
  4. Kaynak bazlı özel yönlendirme tanımlıysa uygulanıyor: belirli kanallardan gelen kayıtlar belirli temsilcilere veya temsilci gruplarına gidiyor.
  5. Uygunluk filtreleri çalışıyor — aktiflik, vardiya, izin durumu, pipeline yetkisi, günlük lead limiti ve mesai dışı on/off durumu.
  6. Kalan temsilciler arasında ağırlıklı ve dengeli dağıtım yapılıyor.
  7. Kayıt CRM'de oluşturuluyor ve süreç analiz ekranlarına yansıyor.

Karar verilirken kaydın kaynağı, pipeline/operasyon türü, telefon ülke kodu ve sistemdeki geçmişi birlikte değerlendiriliyor.

On/Off ve Mesai Dışı Kurgu

Mesai saatleri dışında ve resmi tatillerde ayrı bir kurgu devreye giriyor. Temsilciler kendilerini bu dönemlerde lead almaya açık hale getirebiliyor; sistem de yalnızca açık ve uygun olan temsilcilere yönlendirme yapıyor.

Kurgunun iki sınırı var: temsilci başına maksimum lead limiti uygulanabiliyor ve izinli ya da uygun olmayan temsilciler otomatik olarak devre dışı kalıyor. Amaç hafta sonu ve gece gelen kayıtların ertesi güne sarkmasını engellemek.

CRM Senkronizasyonu

CRM tarafında kişi, satış fırsatı, pipeline, aşama ve aktivite kayıtları takip ediliyor. Entegrasyon çift yönlü çalışıyor: sistem CRM'e kayıt yazıyor, CRM'de yapılan değişiklikleri de geri alıyor.

Bunun pratik karşılığı şu: satış ekibi kendi alışkın olduğu ekranda çalışmaya devam ediyor, aşama değişikliği yaptığında analiz ekranları da güncelleniyor. Raporlama için ikinci bir veri girişi istenmiyor.

Kampanya Takibi ve Offline Conversion

Reklam tarafında kampanya adı ve kimlik bilgileri, lokasyon hedeflemeleri, kampanyadan gelen kayıtlar ve kampanya bazlı maliyet/performans verileri izleniyor. Kampanya ekranından conversion value tanımlanabiliyor.

Offline conversion, zincirin kapandığı yer: reklamdan gelen bir kayıt CRM içinde değerli bir aşamaya ulaştığında sonuç Google Ads'e geri bildiriliyor.

  1. Kullanıcı reklama tıklıyor ve kayıt sisteme düşüyor.
  2. Satış ekibi kayıtla ilgileniyor.
  3. Kayıt kapora gibi satışa yakın bir aşamaya geliyor.
  4. Bu dönüşüm, kampanya eşleşmesiyle birlikte reklam platformuna gönderiliyor.

Böylece optimizasyon yalnızca form doldurma gibi ilk aksiyona değil, gerçek satış değerine daha yakın bir sinyale göre yapılabiliyor.

Kapora Bildirimi

Ödeme bildirimi geldiğinde akış şöyle ilerliyor: bildirimin gerçekten yeni bir ödeme olup olmadığı kontrol ediliyor, ilgili müşteri ve satış kaydı bulunuyor, CRM'de aşama ve gerekli alanlar güncelleniyor, ödeme aktivite olarak işleniyor ve bildirim/log kayıtları oluşturuluyor.

Mükerrer kontrolü burada kritik: aynı ödemenin iki kez işlenmesi sadece bir kayıt fazlası değil, dönüşüm oranını da bozan bir hata oluyor.

Chatbot, AI ve Çağrı Kaynakları

Sistem yalnızca form ve CRM kayıtlarıyla çalışmıyor. Chatbot akışlarından gelen kayıtların hangi aşamada olduğu, ulaşılabilirlik ve cevap verme durumu izleniyor; sesli AI ve çağrı kaynaklı kayıtlar da aynı hatta giriyor. Çağrı sonrası CRM'e aktivite ekleniyor, gerekiyorsa yeni kişi veya fırsat oluşturuluyor.

Dashboard ve Analiz Modları

Dashboard; lead analizi, yönetici özeti, performans analizi, chatbot analizi, kapora analizi, aylık analiz ve kampanya analizi sekmelerinden oluşuyor. Her sekme kendi filtresini kullanıp ilgili analizi arka uçtan istiyor; hesaplama arayüzde değil, sunucu tarafında yapılıyor.

En belirleyici ayrım iki analiz modu arasında:

  • Anlık analiz kayıtların şu andaki durumuna bakıyor. Bugünün operasyon fotoğrafını veriyor.
  • Seçili dönem analizi kayıtların belirli bir tarihte hangi aşamada olduğunu yeniden kuruyor. "Mayıs ayında gelen kayıtlar ayın 15'inde neredeydi?" sorusunun cevabı bu.

Bu ayrım olmadan aylık değerlendirme yanıltıcı oluyor: geçmiş bir dönemi bugünün aşama dağılımıyla okumak, o dönemde henüz olgunlaşmamış kayıtları başarısız gibi gösteriyor.

Dönüşüm oranı da tek bir tanım üzerinden hesaplanıyor:

text
Lead → Kapora (%) = (Kapora aşamasındaki kayıt / Toplam kayıt) × 100

Kapora sayılan aşamalar tek bir tanımda toplanıyor; toplam sıfırsa oran sıfır kabul ediliyor. Bazı tablolarda aynı mantıkla, ulaşılan kayıt üzerinden ikinci bir oran gösteriliyor.

Ortak Filtre Yapısı

Filtreler ekranlara özel değil, ortak. Tarih aralığı, pipeline, temsilci, kaynak ve kampanya seçimleri sekmeler arasında aynı anlamı taşıyor; ülke ve kaynak gibi alanlar çoklu seçim destekliyor ve sorgu tarafında küme filtresine dönüşüyor.

Kart üzerinden detay açıldığında filtrenin varsayılana dönmesi de bilinçli: başka bir sekmede yapılmış daraltıcı seçimin, tıklanan kartın kapsamını sessizce değiştirmesini engelliyor.

Arka Plan İşleri

Panelde kimse işlem yapmasa da çalışan süreçler var: CRM verilerinin düzenli kontrolü, kuyrukta bekleyen satış kayıtlarının işlenmesi, kampanya bilgilerinin güncellenmesi, offline conversion gönderimleri, günlük/haftalık/aylık mail raporları, on/off listelerinin belirli saatlerde temizlenmesi ve planlı sesli çağrıların işlenmesi.

Bu işler sayesinde sistem açılıp bakılan bir ekran değil, sürekli çalışan bir operasyon motoru gibi davranıyor.

Yetki Yönetimi

Kullanıcının göreceği ekranlar ve yapabileceği işlemler yetki gruplarına bağlı. Yönetici kullanıcılar geniş rapor ve ayar ekranlarına erişirken, satış temsilcileri kendi performanslarına yönelik daha dar bir alan görüyor; kritik ayar işlemleri üst yetki gerektiriyor.

Kullandığım Teknolojiler

Laravel, PHP, MySQL, JavaScript, jQuery, Bootstrap, Vite ve ApexCharts. CRM (Pipedrive) ve reklam platformu entegrasyonları API ve webhook akışlarıyla, tekrarlayan işler zamanlanmış görevlerle yürütülüyor.

Teknik Odak

  • Çok kanallı lead kayıtları ve kural tabanlı, sıralı dağıtım.
  • Müşteri geçmişiyle temsilci sürekliliği.
  • Mesai dışı on/off kurgusu ve günlük limitler.
  • CRM kayıtlarının çift yönlü senkronizasyonu.
  • Kampanya eşleştirme ve offline conversion geri bildirimi.
  • Anlık ve dönemsel analiz modlarının ayrılması.
  • Ekranlar arasında ortak filtre sözleşmesi.
  • Yönetici özetleri, karşılaştırmalar ve rapor dışa aktarımı.

Karşılaştığım Problemler

Zorluk lead'i bir temsilciye yazmak değil, kapsamın belirsiz kaldığı durumları tanımlamaktı:

  • Aynı kişinin farklı kanallardan tekrar gelmesi ve sahipliğin tartışmalı hale gelmesi.
  • Uygunluk kurallarının birbirini iptal etmesi; filtreler arka arkaya uygulandığında geriye hiç temsilci kalmaması.
  • Aynı metriğin iki ekranda farklı çıkması.
  • Geçmiş bir dönemin bugünün aşama dağılımıyla okunması.
  • Mükerrer ödeme bildiriminin dönüşüm oranını şişirmesi.
  • Reklamdan gelen kaydın kampanyayla eşleşmemesi ve geri bildirim zincirinin kopması.

Çözümler

Dağıtım kurallarının sırasını sabitlemek belirleyici oldu: süreklilik, kaynak bazlı yönlendirme ve uygunluk filtreleri hep aynı sırayla çalışıyor, böylece bir kaydın neden o temsilciye gittiği sonradan açıklanabiliyor.

Ortak filtre yapısı, farklı ekranların aynı kapsamı değerlendirmesini sağlıyor. Hesaplama servislerinin ayrılması, analiz mantığının tek bir büyük controller içinde birikmesini önlüyor. Anlık ve dönemsel analizin ayrı tutulması ise geçmiş dönem yorumlarını düzeltti.

Reklam ve CRM verilerinin birlikte ele alınması, lead akışını sonuçlarıyla beraber incelemeyi mümkün kılıyor; mükerrer kontrolü de bu sonuçların şişmesini engelliyor.

Tasarım Notu

Bu projede yönlendirme kuralları kadar, bir rakamın hangi kapsam ve dönem üzerinden hesaplandığının anlaşılması da önemli. İki ekran aynı metrik için farklı sayı gösteriyorsa sorun çoğu zaman hesaplamada değil, kapsamın tanımında oluyor. Bu yüzden ortak filtre yapısını ekranlar arasındaki bir sözleşme gibi ele aldım: aynı filtreyi kullanan her ekran aynı kümeyi değerlendiriyor.

Aynı yaklaşım dağıtım tarafında da geçerli. Kuralların sırası belliyse "bu lead neden bana gelmedi?" sorusu tahmin değil, kontrol listesiyle cevaplanabilir bir soruya dönüşüyor.

Sonraki proje VPM — Vanity Payment Manager

Diğer projeler

Tüm projeler

BİRLİKTE ÇALIŞALIM

Bir fikrin mi var?

Yeni bir proje, iş birliği veya sadece sohbet etmek için.

İletişime Geç