EHT CRM: WhatsApp, reklam ve yapay zekânın tek hatta bağlandığı CRM

Başlangıç durumu

EHT, satışını tamamen WhatsApp üzerinden yapan bir ekip. Hasta bir reklamdan geliyor, danışmana yazıyor, konuşma günlerce sürüyor, sonunda ya geliyor ya gelmiyor.

Bu modelin üç kör noktası vardı ve üçü de birbirini besliyordu.

Konuşma hiçbir yerde yoktu. Danışmanın telefonundaki sohbet, şirketin verisi değil o kişinin verisiydi. Danışman ayrıldığında geçmiş de gidiyordu. İki danışmanın aynı hastaya yazması ya da bir hastanın günlerce cevapsız kalması, kimsenin göremediği bir şeydi.

Reklam panelleri yanlış şeyi optimize ediyordu. Meta ve Google, kendilerine bildirilen olayı en ucuza getirmeye çalışır. Bildirilen olay “form dolduruldu” ise, sistem form dolduran ama hiçbir zaman satın almayan kitleyi bulmakta ustalaşır. Ucuz form getiren kampanya raporda parlıyor, hasta getiren kampanya sönük görünüyordu.

Konuşma kalitesi ölçülmüyordu. Bir danışmanın ne kadar hızlı döndüğü, itirazı nasıl karşıladığı, bir sonraki adımı netleştirip netleştirmediği — bunların hepsi ancak birinin oturup sohbetleri okumasıyla bilinebilirdi. Kimse okumuyordu.

Kararlar

Neden mikroservis

Mikroservis mimarisi varsayılan olarak doğru bir karar değildir; getirdiği dağıtık sistem maliyeti gerçektir. Burada üç somut gerekçeyle seçildi.

Yük profilleri birbirinden çok farklı. Mesajlaşma ağ geçidi kampanya saatlerinde ani ve yüksek webhook trafiği alır; analiz servisi gece toplu iş çalıştırır; yapay zekâ servisi uzun süren ve pahalı çağrılar yapar. Bunları tek süreçte tutmak, en pahalı bileşen için hepsini birden ölçeklemek demekti.

Arıza sınırı gerekiyordu. Model sağlayıcısı yavaşladığında ya da bir reklam API’si kotaya takıldığında WhatsApp mesajlarının akmaya devam etmesi şart. Mesaj gelmemesi doğrudan kaybedilen hasta demek; rapor gecikmesi ise bekleyebilir.

Dış API’lerin ritmi kendine ait. WhatsApp Cloud API, Meta Marketing API ve Google Ads API’nin kendi hız sınırları, kendi kimlik döngüleri ve kendi kırıcı sürüm değişiklikleri var. Her birini kendi servisinde izole etmek, bir sağlayıcının değişikliğinin bütün sistemi durdurmasını engelliyor.

Servisler arası iletişim RabbitMQ üzerinden olay tabanlı. Her servisin kendi PostgreSQL şeması var; ortak veritabanına yazma yok. Bunun bedeli nihai tutarlılık: bir anlaşma kapandığında rapor ekranına yansıması saniyeler alabiliyor. Satış konuşmasının hızıyla kıyaslandığında bu, kabul edilebilir bir gecikme.

Mesajlaşma ağ geçidi

WhatsApp Cloud API webhook’ları tek bir servise düşüyor. Bu servisin tek işi var: mesajı almak, doğrulamak, olaya çevirmek ve yayımlamak.

Dikkat edilmesi gereken ayrıntılar:

• Tekrarlanan teslimat. Meta, aynı webhook’u birden fazla kez gönderebilir. Her mesaj wamid alanıyla tekilleştiriliyor; ikinci teslimat sessizce düşüyor.
• Sıra garantisi yok. Mesajlar geliş sırasında gelmeyebilir. Konuşma zaman çizelgesi webhook sırasına değil, mesajın kendi zaman damgasına göre kuruluyor.
• 24 saat kuralı. Müşteri son mesajından 24 saat sonra serbest metin gönderilemez; yalnızca önceden onaylanmış şablon kullanılabilir. Bu kural sistemin içine gömüldü: pencere kapandığında arayüz serbest metin alanını kapatıp onaylı şablonları öneriyor. Danışmanın bunu ezberlemesi beklenmiyor.
• Şablon yönetimi. Onay bekleyen, onaylanan ve reddedilen şablonlar sistemde takip ediliyor; reddedilen bir şablonun kullanımda kalması engelleniyor.

Danışmanlar tek bir gelen kutusundan çalışıyor: atama, devir, etiketleme, dahili not, aynı anda yazma çakışmasının önlenmesi. Numara artık kişinin telefonunda değil, şirketin sisteminde.

Atıf: asıl mesele

Bu sistemin en çok değer üreten parçası burası.

Zincirin kurulumu şöyle:

1. Tıkla-WhatsApp’a-git reklamları kullanıcıyı doğrudan sohbete düşürür ve ilk mesajla birlikte bir yönlendirme yükü taşır — hangi reklam, hangi kampanya. Bu yük, konuşma açıldığı anda kişi kaydına yazılıyor.
2. Meta lead formları webhook ile geliyor; form kimliği ve kampanya bilgisi aynı kişi kaydına bağlanıyor.
3. Web formları gclid ve UTM parametrelerini taşıyor; aynı kişiye ait telefon numarası normalize edilerek (E.164) mevcut kayıtla eşleştiriliyor.
4. Danışman anlaşmayı kazanıldı olarak işaretlediğinde bir olay yayımlanıyor.
5. Atıf servisi bu olayı yakalayıp çevrimdışı dönüşümü geri yazıyor: Google Ads tarafına gclid ile, Meta tarafına Conversions API üzerinden hash’lenmiş kişi bilgisiyle. Değer alanına form sayısı değil anlaşma tutarı gidiyor.

Bu adımdan sonra reklam algoritmasının optimize ettiği şey değişiyor. Panel artık “500 TL’ye form” değil, “şu kampanya şu kadar anlaşma getirdi” diyor.

Burada verdiğimiz ödün gecikme: anlaşma günler sonra kapanıyor, dönüşüm de o zaman geri yazılıyor. Reklam platformlarının öğrenme döngüsü bu gecikmeyi bir noktaya kadar tolere ediyor. Bunu telafi etmek için ara sinyaller de gönderiliyor — nitelikli görüşme, randevu verildi — böylece algoritma tamamen kör kalmıyor.

Kişisel veri tarafında kural net: Meta’ya ve Google’a giden alanlar istemci tarafında değil sunucuda hash’leniyor, ham telefon ve e-posta hiçbir zaman dışarı çıkmıyor.

Konuşma analizi

Kapanan her konuşma analiz kuyruğuna giriyor. Değerlendirilen şeyler ölçülebilir ve önceden tanımlı:

• İlk yanıt süresi ve konuşma boyunca ortalama dönüş süresi.
• Nitelendirme sorularının sorulup sorulmadığı.
• İtirazın karşılanma biçimi.
• Bir sonraki adımın netleştirilip netleştirilmediği — randevu, tarih, ödeme adımı.
• Duygu seyri ve konuşmanın nerede koptuğu.

Buradaki asıl risk, dil modelinin ürettiği puanın kendi başına ölçüt sayılmasıdır. İki önlem aldık. Birincisi, insan tarafından etiketlenmiş sabit bir değerlendirme kümesi var; model ya da istem değiştiğinde puanlar bu küme üzerinde yeniden ölçülüyor. İkincisi, puanlar danışmanın performans karnesine doğrudan yazılmıyor; düşük puanlı konuşmalar bir insan inceleme kuyruğuna düşüyor. Model burada bir hakem değil, bir filtre.

AI çağrı merkezi ve RAG

Sık sorulan soruların tekrar oranı yüksek: fiyat aralığı, süreç, konaklama, iyileşme takvimi, ödeme seçenekleri. Bunları karşılayan bir katman kurduk.

Bilgi tabanı fiyat listeleri, süreç dokümanları ve klinik politikalarından oluşuyor. Parçalanıp gömülü vektörlere çevriliyor ve pgvector üzerinde tutuluyor. Arama saf vektör araması değil, anahtar kelime aramasıyla birleştirilmiş bir melez; ardından bir yeniden sıralama adımı geliyor. Sebebi pratik: fiyat sorularında model, anlamca yakın ama yanlış paketin satırını getirmeye eğilimli — anahtar kelime bileşeni bunu düzeltiyor.

Cevap üretiminde üç kural var:

1. Kaynaksız cevap yok. Model yalnızca getirilen parçalara dayanarak cevap veriyor; dayanak bulunamazsa cevap vermiyor.
2. Eşik altında insana devir. Güven eşiğinin altındaki her konuşma, kullanıcıya fark ettirilmeden danışmana aktarılıyor. Devir oranı gizlenen bir sayı değil, sistemin ana metriklerinden biri.
3. Tıbbi alan kapalı. Uygunluk, teşhis, ilaç ve sonuç vaadi soruları modele hiç bırakılmıyor; bu konular doğrudan insana gidiyor. Sağlık alanında bir dil modelinin ikna edici biçimde yanlış cevap vermesi, kabul edilebilir bir risk değil.

Sesli tarafta konuşma metne çevriliyor, aynı erişim hattından geçiyor ve cevap sese dönüyor. Metin tarafıyla aynı bilgi tabanını ve aynı devir kurallarını kullanıyor — iki ayrı doğruluk kaynağı tutmuyoruz.

Uygulama

İzlenebilirlik

Dağıtık bir sistemde en pahalı şey, bir isteğin nerede kaybolduğunu bulamamaktır. Bir WhatsApp mesajının webhook’tan gelen kutusuna, oradan atıf servisine kadar izlediği yol tek bir bağıntı kimliğiyle takip ediliyor. Kuyruklarda ölü mektup mekanizması var; işlenemeyen olay silinmiyor, incelenmek üzere bekliyor.

Kimlik ve tekilleştirme

Aynı kişi web formundan, Meta lead formundan ve WhatsApp’tan üç ayrı kayıt olarak girebilir. Telefon numarası E.164 biçimine normalize ediliyor ve birleştirme kuralları buna göre çalışıyor. Yanlış birleştirme, iki kaydı ayrı bırakmaktan daha pahalıdır; bu yüzden şüpheli eşleşmeler otomatik birleştirilmiyor, öneri olarak sunuluyor.

Maliyet

Yapay zekâ katmanı ölçülebilir bir gider kalemi. Konuşma başına belirteç tüketimi servis bazında raporlanıyor; analiz işleri toplu ve daha ucuz modelde, canlı cevaplar daha güçlü modelde çalışıyor. Sık tekrarlanan sorular için üretilen cevaplar önbelleğe alınıyor.

Ölçüm

Bu sayfaya sayı yazmadık. Ölçüm dönemi kapandığında buraya girecek metrikler:

• Kampanya bazında anlaşma başına maliyet — çevrimdışı dönüşüm geri yazımı öncesi ve sonrası.
• İlk yanıt süresinin dağılımı; ortalama değil, uzun kuyruk.
• AI katmanının insana devir oranı ve devir sonrası dönüşüm farkı.
• Değerlendirme kümesi üzerinde cevap doğruluğu — soru sayısı ve değerlendirme yöntemiyle birlikte.
• Konuşma başına yapay zekâ maliyeti ile danışman zamanından kazanılan sürenin karşılaştırması.