Yapay Zekâ ve CRM: 2026'da Ne Çalışıyor, Hangi İddia Demo Süsü?
Bir CRM'de yapay zekânın bugün güvenilir biçimde yaptığı iş, büyük ölçüde metin işidir: uzun bir yazışmayı özetlemek, bir e-posta taslağı çıkarmak, serbest bir notun içinden telefon numarasını çekip alana koymak. Bunun ötesindeki iddiaların bir kısmı doğru, bir kısmı koşullu, bir kısmı da yalnızca demoda çalışır.
Bu yazının tezi bir özellik listesi değil, bir ayıklama ölçütü. Her iddiayı aynı soruya sokacağız: bu özelliğin çıktısı yanlış olduğunda bunu kim, ne zaman ve hangi maliyetle fark eder? Cevabı belli olan özellikler işe yarıyor; cevabı olmayanlar yalnız satış toplantısında iyi görünüyor.
Aşağıda beş iddia tek tek ele alınıyor: metin özetleme ve taslak yazma, kayıt zenginleştirme, tahmin ve skorlama, konuşma analizi, ve "otomatik veri girişi" cümlesinin gerçekte kaç ayrı işi birden anlattığı. Sonda Rapitek CRM'in bu konudaki açık sınırı var.
Yazıdaki mevzuat ve tavsiye bilgileri Ağustos 2026 itibarıyla, kaynağın kendi kamuya açık belgelerine dayanır ve hukuki görüş değildir.
Bir yapay zekâ özelliğinin işe yarayıp yaramadığını tek bir soru söyler: çıktısı yanlış olduğunda bunu kim, ne zaman ve hangi maliyetle fark eder? Cevap "kimse" ise, elinizdeki şey bir yetenek değil bir demo süsüdür.
İçindekiler
Yapay zekâ bir CRM'e tam olarak nereden takılır?
CRM bir kayıt deposudur: alanları, ilişkileri ve tarihçesi olan yapılandırılmış veri. Dil modeli ise yapılandırılmamış metinle çalışır. İkisi arasındaki bağlantı üç noktada kurulur ve bu üç nokta birbirinden çok farklı riskler taşır.
Girdi tarafı serbest metni alana çevirir: gelen e-postadaki firma adını, bütçeyi, tarihi çıkarıp kaydın alanlarına yazmak. Çıktı tarafı kayıttaki veriyi insan diline çevirir: özet, taslak, brifing. Karar tarafı ise geçmiş kayıtlardan bir sayı üretir: skor, olasılık, tahmin.
İlk ikisi dil işidir. Üçüncüsü istatistik işidir ve bir dil modeliyle aynı şey değildir — aynı pazarlama başlığı altında satılsa bile. "Yapay zekâlı CRM" ifadesinin bu kadar geniş kullanılabilmesinin sebebi tam olarak bu karışıklık.
Riski belirleyen şey ise dördüncü bir eksen: çıktı nereye yazılıyor. Ekrana yazılan bir çıktıyı okuyan insan anında eler. Kaydın bir alanına yazılan çıktı ise veri hâline gelir; sonraki her rapor, her filtre ve her segment onu doğru sayar. Aynı model, aynı hata payıyla, iki yerde tamamen farklı sonuç doğurur.
Hangi iddia neyin üstünde duruyor
| İddia | Altındaki gerçek iş | Hangi koşulda anlamsızlaşır |
|---|---|---|
| Yazışma ve görüşme özeti | Uzun serbest metni kısaltmak | Özeti okuyan kişi kaynağa erişemiyorsa |
| E-posta ve teklif taslağı | Bağlamdan yeni metin üretmek | Gönderen okumadan gönderiyorsa |
| Kayıt zenginleştirme | Dış bir kaynaktan alan doldurmak | Kaynağın güncelliği bilinmiyorsa |
| Otomatik veri girişi | Serbest metinden alan çıkarmak | Çıkarılan alan ekranda onaylanmıyorsa |
| Fırsat skorlama ve tahmin | Geçmiş kapanışlardan olasılık üretmek | Kapanmış kayıt sayısı azsa |
| Konuşma analizi | Sesi yazıya çevirip etiketlemek | Türkçe doğruluk oranı ölçülmediyse |
Çalışan taraf: özetleme ve taslak yazma
Bu iki iş bugün çalışıyor ve sebebi modelin zekâsı değil, doğrulama döngüsünün kısalığı. Özeti isteyen kişi onu hemen okur, kaynak metin de yanı başındadır; hata anında ve bedelsiz yakalanır.
Aynı sebep, aynı özelliğin nerede bozulacağını da söyler. Özet otomatik olarak kaydın bir açıklama alanına yazılırsa döngü kopar: onu altı ay sonra okuyan kişi kaynağı görmez, gördüğü şey artık bir veridir.
Kısaltmanın kendine ait bir yan etkisi de var: özet, kaynaktaki çekinceleri düşürmeye eğilimlidir. "Müşteri ilgili ama bütçe onayı henüz çıkmadı" cümlesi üç satırlık bir özette kolayca "müşteri ilgili" hâline gelir; yani özet, iddiayı kaynağından daha güçlü yapabilir. Pratik kural şu: özet bir hatırlatmadır, karar dayanağı değildir. Aşamayı ilerletirken kaynak yazışmaya bakılır.
Taslak yazmada denge yine aynı yerde. Model boş sayfayı doldurur, gönderme kararını insan verir. Taslağın onaysız gönderildiği her akış, bu özelliğin çalıştığı zemini ortadan kaldırır.
Kaynağa bağlı taraf: zenginleştirme ve "otomatik veri girişi"
Kayıt zenginleştirme, boş alanları dış bir kaynaktan doldurmaktır. Buradaki kalite modelin değil kaynağın kalitesidir; model yalnız taşıyıcıdır. Sorulacak soru "yapay zekâ mı kullanıyor" değil, "hangi veri tabanından ve en son ne zaman güncellenmiş bir kayıttan geliyor" olmalı. Türkiye'deki firma verisi için bu ikinci sorunun cevabı çoğu zaman yazılı değildir.
Bir alanın nereden geldiği kayıtta durmuyorsa, yanlış bir unvanı düzeltmek de imkânsızlaşır: siz düzeltirsiniz, bir sonraki zenginleştirme turu geri yazar.
"Otomatik veri girişi" ise tek bir özellik değil. Aynı adla satılan üç ayrı iş var:
- Alan eşleştirme — bir CSV başlığını doğru alana bağlamak. Bu kural işidir, model işi değil.
- Metinden alan çıkarma — e-postadaki telefonu telefon alanına yazmak. Bu gerçekten dil modeli işidir ve onay ekranı ister.
- Etkinlik günlüğü — e-postanın veya aramanın doğru kayda iliştirilmesi. Bu bir entegrasyon işidir; posta kutusuna bağlanmakla çözülür, modelle değil.
Birincisini ölçtük. Salesforce'un müşteri adayı dışa aktarım dosyasında 19 sütun başlığının 19'u doğru alanla eşleşti; HubSpot kişi dışa aktarımında 17 başlığın 13'ü eşleşti ve 2'si yanlış alana bağlandı. Asıl bulgu ikinci satırda: otomatik eşleşme sessizce yanlış olabiliyor. Bu ölçüm birer dışa aktarma dosyası üzerinde, ölçüm tarihinde yapıldı; iki ürünün kalitesi hakkında bir hüküm değildir. Ayrıntısı alan eşleştirme yazısında duruyor.
Bir yapay zekâ iddiasını sınamanın dört sorusu
Çıktı nereye yazılıyor?
Ekrana mı, kaydın alanına mı? Ekrana yazılan çıktıyı okuyan insan anında eler. Alana yazılan çıktı veri olur; sonraki raporlar, filtreler ve segmentler onu doğru sayar. Satıcıya sorun: bu özellik kaydın içine yazıyor mu, yazıyorsa arada bir onay adımı var mı?
Veri nereye gidiyor?
Metin hangi modele, kimin altyapısına, hangi ülkeye gidiyor? Müşteri verisini dış bir modele göndermek bir veri aktarımıdır. Kimin veri sorumlusu, kimin veri işleyen olduğu projenin başında yazılmalı; bu bir ayar değil sözleşme işidir.
Kaç kapanmış kayıtla çalışıyor?
Skorlama ve tahmin geçmiş sonuçlardan öğrenir; hem kazanılan hem kaybedilen örneğe ihtiyaç duyar. Satıcıya tek soru yeter: bu skor anlamlı olsun diye kaç kapanmış fırsat gerekiyor, ve o sayının altında ekranda ne gösteriyor?
Yanlış olduğunda ne oluyor?
Özelliğin hata hâli tarif edilmiş mi? Çıktı geri alınabiliyor mu, kim onaylıyor, düzeltme kayda düşüyor mu? Hata hâli tarif edilmemiş bir özellik, demoda hiç hata yapmayan bir özelliktir.
Veri hacmi isteyen taraf: tahmin ve skorlama
Skor bir olasılık tahminidir ve tahmin geçmiş örneklerden üretilir. Bunun iki koşulu var; ikisi de küçük ekiplerde kolay tutmaz.
Birincisi hacim. Model, ayırt etmesi istenen her sonuç için yeterli örnek görmek zorundadır — yalnız kazanılan işleri değil, kaybedilenleri de. Eşiğin herkese uyan tek bir sayısı yok; ama yönü nettir: ayda birkaç iş kapatan bir ekipte skorun ürettiği fark, tesadüften ayrılamaz.
İkincisi ve daha yaygın olanı dürüstlük. Çoğu ekipte kaybedilen fırsatlar kapatılmaz, açık bırakılır ve kapanış tarihi ötelenir. O zaman modelin gördüğü tarihçe neredeyse yalnız kazanılan işlerden oluşur; kaybetmeyi hiç öğrenemez. Bu bir model sorunu değil, satış hattı hijyeni sorunudur ve modelden önce çözülür.
Üçüncü bir tuzak daha var: skor kendi kendini doğrular. Düşük skorlu fırsat aranmazsa kaybedilir, model de haklı çıkmış görünür. Buna doğrulama denmez, geri besleme döngüsü denir. Skoru sınamanın tek yolu, bir süre skora rağmen aramaktır.
Bir de karar tarafı var. Kişisel Verileri Koruma Kurumu'nun yapay zekâ tavsiye belgesinde, bireylerin kendi görüşleri dikkate alınmaksızın münhasıran otomatik işlemeye dayalı kararlara maruz kalmamasını sağlayacak ürün ve hizmetlerin tasarlanması öneriliyor. Bir skorun kimin aranacağını tek başına belirlediği akış tam olarak bu başlığın altına düşer.
Konuşma analizi: dil duvarı ve KVKK duvarı
Konuşma analizi tek bir iş değil, arka arkaya iki iştir: sesi yazıya çevirmek (transkripsiyon) ve yazıyı etiketlemek (konu, itiraz, ton). İkinci adımın kalitesi tamamen birincisine bağlıdır; yanlış çözülmüş bir cümlenin doğru etiketlenmesi diye bir şey yok.
Birinci adım Türkçede İngilizcedeki kadar rahat değil. Telefon hattının dar bant sesi, sektör terimleri, marka ve kişi adları hata üretir; sayı ve tarih hataları da sık görülür. Buna dair ölçülmüş bir doğruluk oranımız yok, bu yüzden bu yazıda rakam vermiyoruz. Bir satıcı oran veriyorsa sorulacak soru şu: bu oran hangi ses kayıtlarında, hangi hattan ve hangi sektör sözlüğüyle ölçüldü?
İkinci duvar hukuki ve daha keskin. Bir görüşme kaydı hem müşterinin hem çalışanın kişisel verisidir. O kaydı dış bir dil modeline göndermek, veriyi üçüncü bir tarafa aktarmaktır — bir ayar değişikliği değil, hukuki bir işlem. Kurum'un tavsiye belgesi, paydaşların veri sorumlusu mu veri işleyen mi olduğunun projenin başında belirlenmesini ve aradaki hukuki ilişkinin mevzuatla uyumlu hâle getirilmesini öneriyor. Model sağlayıcısı yurt dışındaysa 6698 sayılı Kanun'un yurt dışına aktarım rejimi de devreye girer ve ayrıca belgelendirilir.
Aynı belgede bir ölçülülük başlığı da var: aynı sonuca kişisel veri işlenmeksizin ulaşılabiliyorsa, verinin anonim hâle getirilerek işlenmesi tercih edilmeli. Konuşma analizinde bunun pratik karşılığı, kaydın tamamını değil yalnız gerekli kısmını göndermektir.
Rapitek CRM'de bunun karşılığı ne?
Tek bir şey var ve onu olduğu gibi yazıyoruz: Rapitek CRM bir MCP paketi yayınlıyor. Müşteri kendi yapay zekâ istemcisini CRM'e bağlayıp kayıt okutabiliyor ve yazdırabiliyor.
Cümlenin sınırı da tam burada. Model bizde değil. Ürünün içinde çalışan bir asistan yok; olan şey, sizin seçtiğiniz istemcinin kayıtlara ulaşabildiği bir bağlantı yüzeyi. Bunun üç sonucu var.
Model seçimi sizde. Hangi modeli hangi sağlayıcıyla kullanacağınıza siz karar verirsiniz — ve o modele giden veri bir aktarımdır; sözleşmesi de aydınlatması da sizinle sağlayıcı arasında kurulur, bizim üzerimizden geçmez.
Yetki sizin yetkinizdir. İstemcinin yaptığı her okuma ve yazma, bağlandığı kullanıcının yetkisiyle yapılır. Görmediğiniz bir kaydı istemci de göremez, yazamadığınız bir alana yazamaz.
Araç sayısını yazmıyoruz. Paketin kaç araç taşıdığı sorusunun cevabını bu yazıya koymuyoruz: o sayı bir denetimde fazla güçlü ifade edilmiş bulundu ve henüz kesinleştirilmedi. Kesinleştiğinde burada yazacak.
Bağlantı yüzeyinin altındaki yol yeni değil: aynı veriye REST API üzerinden de ulaşılıyor — OAuth2 ile korunuyor, composite ucu tek istekte 25 alt-istek, toplu uç tek çağrıda 200 kayıt taşıyor. Yapay zekâ istemcisinin eklediği şey yeni bir veri yolu değil, mevcut yolu doğal dille kullanabilmek.
Bizim sınırlarımız
Rapitek CRM'de kutudan çıkan bir yapay zekâ asistanı yok: ürünün içinde çalışan, kayıtlarınızı kendiliğinden özetleyen ya da skorlayan bir model çalıştırmıyoruz.
Altındaki kalemler tek tek şöyle. Fırsat skorlama modelimiz yok. Konuşma analizi ve ses transkripsiyonu özelliğimiz yok. Kayıt zenginleştirme için bağlı bir dış veri kaynağımız yok. Türkçe transkripsiyon doğruluğu için ölçümümüz yok — bu yüzden bu alanda hiçbir rakam vermiyoruz. Ürünün içinde bir model çalıştırmadığımız için, müşteri verisiyle model eğitmek diye bir işimiz de yok.
Ne var: ekrandan alan ve nesne ekleme, görsel iş akışı, REST API ve yukarıdaki MCP paketi. Ölçülmüş hâli şu: 19 kiracı kod yazmadan 277 özel alan tanımladı, bir kiracı 9 özel nesne ekledi. Ürün 183 iş nesnesi taşıyor.
Verinizin nereye gittiği sorusunda da net olalım: yapay zekâ istemcisini siz kuruyorsunuz, dolayısıyla hangi kaydın hangi modele gideceğine de siz karar veriyorsunuz. Bu bir özellik değil, bir sorumluluk dağılımı — ve güvenlik tarafındaki yetki ayarlarınız bu kararın tek gerçek freni.
Yapay zekâ ve CRM hakkında sık sorulan sorular
CRM'de yapay zekâ bugün gerçekten ne yapıyor?
Yapay zekâ CRM'e veri girişini tamamen otomatikleştirir mi?
Fırsat skorlama küçük bir satış ekibinde işe yarar mı?
Müşteri verimi bir yapay zekâ modeline göndermek KVKK açısından ne demek?
Rapitek CRM'in hazır bir yapay zekâ asistanı var mı?
Türkçe görüşme kayıtlarını yapay zekâyla analiz edebilir miyim?
Bir satıcının yapay zekâ iddiasını nasıl sınarım?
İlgili içerikler
- CRM veri göçünde alan eşleştirme — "otomatik veri girişi" iddiasının ölçülmüş hâli.
- Çok kiracılı CRM mimarisi — "verileriniz ayrı tutulur" cümlesi nerede bitiyor.
- Satış hattı (pipeline) nedir? — skorlamanın üstüne kurulduğu aşama yapısı.
- CRM tarihi — yapay zekânın hangi kısıttan sonra CRM'e girdiği.
- Apex nedir? — platformun içine gömülen mantığın neden taşınmadığı.
- Entegrasyonlar — bugün çalışan bağlantılar ve REST API.
Yapay zekâ başlığını değil, kendi sürecinizi konuşalım
Rapitek CRM'i kuran ekip, Salesforce döneminde 200'den fazla kurumsal CRM projesi tamamladı. Ürün yeni, ekip değil: alanları, aşamaları ve raporları biz yapılandırıyoruz, verinizi biz aktarıyoruz, ekibinize Türkçe eğitimi biz veriyoruz.
Keşif görüşmesinde hangi işin otomasyonla, hangisinin modelle çözüleceğini kendi süreçlerinizle ayırıyoruz; kapsam yazılı belirlenir.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
Kaynaklar
Bu yazıdaki mevzuat ve tavsiye bilgileri şu birincil kaynaklara dayanıyor:
