Bir müşteri teklif formunu dolduruyor. AI asistanınız talebi özetliyor, satış ekibine yönlendirdiğini söylüyor ve ekranda güven veren bir başarı mesajı beliriyor. Ertesi sabah satış temsilcisi CRM’i açtığında kayıt yok. Otomasyon düzgün konuşmuş, fakat iş tamamlanmamış.
Pazarlama ajanslarının AI ile büyürken çözmesi gereken sorulardan biri bu: Bir iş akışının başarılı olduğunu hangi kanıtla söyleyeceğiz? Daha iyi bir model seçmek kadar, teslim edilen sonucun doğru olup olmadığını görebilmek de önem taşıyor. Bu rehber, teklif taleplerini sınıflandırıp CRM’e aktaran temsili bir ajans akışı üzerinden uygulanabilir bir kabul süreci öneriyor.
Kaynak bize ne söylüyor, biz ne ekliyoruz?
Anthropic’in 9 Ocak 2026 tarihli ajan değerlendirme rehberi, sistemin verdiği yanıtla ortamda oluşan gerçek sonucu ayırıyor; değişken çıktılar için tekrarlı denemeleri ve farklı değerlendirme yöntemlerini ele alıyor. Bu bir ürün ekibinin uygulama yazısıdır, hakemli pazarlama deneyi değildir. Eylül ayında yayımlanmış yeni bir haber gibi sunmuyoruz.
Aşağıdaki kabul kartı, senaryo dağılımı, ajans örneği ve teslim planı bizim bu soruna yönelik önerimiz. Kaynağın yöntemini bütün müşteri işlerine aynı eşikle uygulamak yerine, işin sahibiyle kabul koşullarını belirlemeyi esas alıyoruz. Özellikle bir reklam ajansında “iyi çıktı” ifadesi tek başına yeterli değildir: satış ekibinin kullanabileceği, izi sürülebilen ve gerektiğinde düzeltilebilen bir çıktı gerekir.
Önce otomasyonun sözünü tek cümlede yazın
“Lead yönetimini AI ile yapıyoruz” test edilebilir bir tanım değil. Hangi girişin hangi sonuca dönüşeceği belli değilse, ekipler farklı başarı tarifleriyle çalışır. Hesap yöneticisi güzel bir özet beklerken satış ekibi zamanında görev atanmasını, teknik ekip ise bağlantının hata vermemesini başarı sayabilir.
Bu temsili proje için sözümüz şöyle olsun: “Geçerli bir teklif talebi, kaynak bilgisi korunarak tek bir CRM kaydına dönüştürülecek; ilgili ekibe atanacak; belirsiz veya tamamlanamayan işlemler görünür bir inceleme kuyruğuna düşecek.” Yanlış talepleri de zorla satış fırsatına çevirmeyeceğiz. İş başvurusu, mevcut müşterinin destek sorusu ve yeni teklif talebi ayrı iş türleridir.
| Alan | Temsili karar | Kontrol kanıtı |
|---|---|---|
| Girdi | Web formundan gelen teklif talebi | Form kimliği ve alınma zamanı |
| Sonuç | Tek kayıt, doğru ekip, doğru kaynak | CRM kayıt kimliği ve alanları |
| Belirsizlik | Satış mı destek mi anlaşılamıyorsa inceleme | Gerekçe ve sorumlu kişi |
| Hata | Aktarım tamamlanmadıysa başarı mesajı yok | Hata durumu ve yeniden deneme kaydı |
| Sınır | Otomatik fiyat veya indirim sözü verilmez | Çıktı ve işlem geçmişi |
Kabul kartını kodu yazan kişinin tek başına doldurmaması önemli. Satış temsilcisi “doğru ekip” ifadesinin hangi ekip olduğunu açıklamalı; hesap yöneticisi müşteri kaynağını hangi alanda görmek istediğini belirtmeli. Belirsiz bir süreç, teknik olarak çalışsa bile yanlış işi hızlandırabilir.
Cevabı, işlemi ve sonucu ayrı ayrı görün
Bir akışı incelerken üç farklı soruya cevap arayın. Müşteriye ne söylendi? Sistem hangi işlemi denedi? Sonunda iş uygulamasında ne oluştu? Bu ayrımın pratik amacı, hatayı düzeltilecek yere bağlamaktır. Yanlış sınıflandırma ile erişilemeyen CRM aynı çözümü gerektirmez.
Tek talep, üç kontrol noktası
- 01Söylenen
Yanıt, müşterinin talebini ve yapılan işi doğru anlatıyor mu?
- 02Denenen
Doğru sisteme, doğru alanlarla işlem gönderildi mi?
- 03Oluşan
CRM’de beklenen kayıt, atama ve kaynak bilgisi gerçekten var mı?
DijitalPi’nin temsili kabul çerçevesi. Bir kontrolün geçmesi diğerlerinin geçtiğini göstermez.
Örneğin kayıt oluşmuş fakat kampanya kaynağı boş kalmış olabilir. Satış takibi açısından iş kısmen yürür, pazarlama raporu açısından veri kaybolur. Bu yüzden “CRM’e aktarıldı” kontrolü tek başına yeterli değildir. Kaynağı bilinmeyen bir talebe modelin tahmin ettiği bir kampanya adı yazmak da çözüm değildir. Bilinmeyeni görünür tutmak, yanlış bir kesinlik üretmekten daha faydalıdır.
İlk 20 senaryoyu nasıl seçelim?
Başlangıç setini yalnız en kolay taleplerden oluşturmayın. Ekipten, geçmişte elle müdahale gerektiren durumları anlatmasını isteyin. Özel bilgileri kaldırarak veya tamamen kurgusal girdiler kullanarak, işin önemli ayrımlarını koruyan senaryolar hazırlayın. Buradaki 20 sayısı bir başlangıç düzenidir; istatistiksel yeterlilik veya güvenilirlik garantisi değildir.
Önerdiğimiz dağılım beş gruptan oluşuyor: beş açık talep, beş eksik veya karışık talep, dört tekrar veya değişiklik, dört bağlantı/işlem hatası ve iki yetki sınırı. Böylece yalnız modelin anlama becerisini değil, sürecin zor anlarda ne yaptığını da görürüz. Her senaryonun beklenen sonucunu denemeden önce yazın; sonucu gördükten sonra hedefi değiştirerek başarılı ilan etmeyin.
20 senaryolu AI iş akışı test tablosunu indir (CSV)
Dosyada senaryo, temsili girdi, başlangıç koşulu, beklenen sonuç ve kontrol kanıtı hazır. Gerçek sonuç, değerlendirici ve karar alanları boş bırakıldı. Bu alanları kendi denemenizle dolduracaksınız. Dosyayı bir tablo uygulamasında açıp her deneme için ilgili satırı çoğaltabilirsiniz. Model/sürüm, talimat sürümü ve deneme kimliği alanları karşılaştırmanın izini tutar.
Temsili bir hata incelemesi: Aynı talep iki kez geldi
Form yanıtı geç göründüğü için kullanıcı gönder düğmesine yeniden basıyor. İki olayın aynı talebe ait olduğu, akışın koruduğu form gönderim kimliğiyle anlaşılabiliyor. Testte bu iki olayı sırayla, ardından mümkünse birbirine çok yakın zamanda gönderin. Beklenen durum iki ayrı satış fırsatı değil, tanımladığınız tekrar kuralına uygun tek kayıttır.
Burada yalnız e-posta adresine göre birleştirme önermiyoruz. Aynı kişi ertesi hafta başka bir hizmet için gerçekten yeni talep açabilir. Kabul kartında “aynı olayın tekrarı” ile “aynı kişiden yeni ihtiyaç” ayrılmalı. Test tablosunda bu iki durumun ayrı satırları bulunmasının nedeni bu.
Bir hata yakalandığında notu “AI yanlış yaptı” diye kapatmayın. “Aynı gönderim kimliğiyle ikinci olay işlendiğinde yeni fırsat oluştu” şeklinde yazın. Ardından etkiyi ekleyin: iki temsilci aynı kişiyi arayabilir, dönüşüm sayısı şişebilir, raporda yanlış bir başarı algısı oluşabilir. Teknik ekibe verilen görev de böylece somutlaşır: olayın tekrar işlenmesi sırasında hangi kayıt kontrolünün eksik kaldığını araştırmak.
Başarı yüzdesi neyi saklıyor olabilir?
Temsili bir ilk turda 20 senaryodan 18’inin geçtiğini düşünelim. Bu yüzde 90, yalnız bu senaryo setinin o turdaki geçiş oranıdır. Canlı taleplerin yüzde 90’ının doğru işleneceğini göstermez. Ayrıca kalan iki hata, müşteri talebinin sessizce kaybolması ve izinsiz fiyat sözü verilmesi ise sonuç teslim için yeterli olmayabilir.
| Durum | Örnek | Önerilen karar |
|---|---|---|
| Kritik | Yanlış müşteriye kayıt, kayıp talep, yetkisiz işlem | Düzelt ve ilgili senaryoları yeniden dene |
| İşlevsel | Yanlış ekip veya eksik kampanya bilgisi | Etkiyi değerlendir; teslim koşuluna göre karar ver |
| Editoryal | Gereksiz uzun ama doğru bir iç özet | İyileştirme listesine al; iş sonucundan ayrı raporla |
Karşılaştırmada aynı girdileri ve başlangıç durumlarını kullanın. Eski ve yeni sürümü farklı müşteri türleriyle denerseniz, farkın modelden mi örneklerden mi geldiğini ayıramazsınız. Değişken sonuçları görmek için senaryoları tekrar çalıştırın; kaç tekrar yaptığınızı açıkça yazın. Geliştirme sırasında sürekli baktığınız örneklerin yanında, son kontrolde ilk kez kullanılacak ayrı örnekler de tutun.
İnsan devri bir sonuçtur, bekleme odası değil
“İnsan kontrolüne gönder” ifadesinin de bir kabul koşulu olmalı. Talep hangi listede görünecek, kim görecek, ne kadar sürede ele alınması hedeflenecek ve çözüldüğünde sistem bunu nasıl anlayacak? Sadece bir etiket eklemek, işi gerçekten devretmek anlamına gelmeyebilir.
Örneğin satış ve destek ihtiyacını aynı mesajda anlatan kişi için inceleme görevi oluşturulsun. Görevde özgün mesaj, belirsizliğin nedeni ve tamamlanmış işlemler yer alsın. İnsan aynı veriyi yeniden toplamak zorunda kalmasın. Görev atanmamışsa veya listede kimse bakmıyorsa bu da testte başarısız bir devir olarak kaydedilsin. Yanlış otomatik karar yerine doğru devir, bu senaryo için başarılı sonuç olabilir.
Bir haftada uygulanabilecek çalışma planı
İlk gün tek akış ve kabul kartı üzerinde anlaşın. İkinci gün senaryoları satış, hesap yönetimi ve teknik ekip birlikte gözden geçirsin. Üçüncü gün denemeleri test ortamında yürütün; gerçek müşteriye mesaj göndermeden ve canlı kayıtları değiştirmeden sonuç kanıtlarını toplayın. Dördüncü gün hataları etkisine göre ele alın, düzeltilen sürümü aynı koşullarda yeniden kontrol edin.
Beşinci gün teslim görüşmesinde toplam puandan önce kritik hataları, insan devrini ve çözülmemiş durumları konuşun. Bu beş günlük düzen bir planlama örneğidir, her entegrasyonun bir haftada tamamlanacağı sözü değildir. Erişim, veri kalitesi ve iş kuralları belirsizse önce bunları çözmek gerekir.
Teslim dosyasında kabul kartı, kullanılan sürümler, doldurulmuş senaryo tablosu, açık sorunlar ve iş sahibinin kararı bulunsun. Canlıya geçildikten sonra düzeltme süresi, insanın geri çevirdiği kararlar ve sessiz kalan işlemler izlenmeye devam etsin. Model, talimat veya CRM eşleştirmesi değiştiğinde ilgili testleri yeniden çalıştırın. İyi bir otomasyonun değeri, hızlı görünmesinden çok, hangi koşullarda güvenilebileceğinin bilinmesidir.
