Chatbot Araçları Seçim Rehberi

Chatbot tools seçimi, “hangi bot daha iyi?” sorusundan çok daha fazla şey içerir. Aynı görünen iki araç, işin içine kanal kapsamı, canlı destek devri (handoff), entegrasyonlar, bilgi kaynağı besleme, güvenlik, maliyet modeli ve ekip iş akışları girdiğinde bambaşka sonuçlar üretir. Bir e-ticaret sitesi için dönüşüm odaklı bir bot ile, bir destek ekibinin ticket yükünü azaltacak botun “doğru” tanımı bile farklıdır. Ajansların kurulum hızı ve çoklu müşteri yönetimi gibi dertleri varken, kurumsal ekipler denetim kayıtları ve rol bazlı yetkilendirme ister.

Bu pillar doküman, chatbot tools seçimini bir satın alma kararı olmaktan çıkarıp operasyon tasarımı haline getirmek için yazıldı. E-ticaret yöneticileri, destek ekip liderleri, KOBİ sahipleri, ürün yöneticileri ve ajanslar için; strateji → uygulama → ölçüm katmanında ilerleyen bir çerçeve sunar. Temel kavramlar için ayrıca chatbot nedir ve canlı destekle nasıl çalışır içeriğine de göz atabilirsiniz.

Table of Contents

• İhtiyaç Sınıflandırması
• Araç Kategorileri Haritası
• Kabiliyet Matrisi
• Entegrasyon Yüzeyi
• Bilgi Kaynağı Besleme
• Handoff ve Eskalasyon
• Güvenlik ve Yönetişim
• Maliyet Modeli
• Değerlendirme ve Puanlama
• Kurulum İş Akışı
• İzleme ve İyileştirme Döngüsü

İhtiyaç Sınıflandırması

Chatbot tools seçimini doğru yapan ekiplerin ortak noktası şu: Aracı değil, önce iş hedefini tarif ediyorlar. “WhatsApp botu istiyoruz” bir hedef değil. “WhatsApp üzerinden gelen kargo nerede sorularını %30 daha az ajana düşürmek” hedeftir. Bu bölüm, ihtiyacı sınıflandırıp doğru kategoriye yönlendirmek için bir başlangıç şablonu gibi düşünülmeli.

E ticaret dönüşüm hedefleri

E-ticarette bot, çoğu zaman bir “destek kanalı” değil; satışa giden yolu kısaltan bir akıştır. Dönüşüm hedefi olan ekiplerde ihtiyaçlar genelde şuralarda toplanır:

• Ürün bulma: beden, uyum, stok, alternatif öneri
• Sepet terk: kargo, iade, teslimat süresi, kupon
• Sipariş öncesi güven: ödeme seçenekleri, kapıda ödeme, taksit
• Post-purchase: kargo takibi, adres değişikliği, iptal-iade

Pratik hedef tanımı örnekleri:

• “Ürün sayfasında gelen soruların %60’ını botla yanıtlayıp sepete ekleme oranını etkilemeden canlıya devri azaltmak.”
• “İade politikası sorularında yanlış yanıt riskini sıfıra yakın tutmak; bot sadece onaylı metinle yanıtlasın.”

Bu tip hedeflerde “free-form sohbet”ten çok, kontrollü akış + net CTA daha iyi çalışır. Özellikle ödeme, iade, garanti gibi hassas konularda botun “uydurma” yapması dönüşümü değil, güveni yakar.

Destek ekibi verim hedefleri

Destek ekipleri için botun değeri, “insan yerine cevap vermek” değil; temasları doğru sınıflandırıp doğru yere yönlendirmektir. Burada tipik hedefler:

• Tekrarlayan soruları otomatik çözme (kargo, fatura, şifre)
• İyi bir triage: konu, öncelik, müşteri segmenti
• Ticket başına harcanan süreyi düşürme
• Ajanın bağlam aramakla kaybettiği zamanı azaltma

Ölçülebilir hedef örnekleri:

• “Kargo takip temaslarında bot, sipariş numarası toplayıp durumu göstererek ajan temasını azaltacak.”
• “Handoff olduğunda, bot özeti ve toplanan alanlar (sipariş no, email, konu) ajana aktarılacak; ajan ilk mesaj süresi kısalacak.”

Bu tür hedeflerde canlı destek platformu ile botun birlikte çalışması kritik. Detaylı süreçler için canlı destek kurulumu ve yönetimi rehberi iyi bir tamamlayıcı olur.

Kobi ve ajans kurulum hedefleri

KOBİ ve ajans dünyasında başarı çoğu zaman “mükemmel bot” değil, hızlı kurulum + sürdürülebilir bakım demektir. İhtiyaç şunlara kayar:

• Şablonlarla hızlı kurulum
• Çoklu müşteri/çoklu marka yönetimi (ajans)
• Minimum entegrasyonla değer üretme
• Basit içerik yönetimi (SSS, politikalar)

Ajanslar için ayrıca:

• Müşteri başına workspace/tenant ayrımı
• Yetki devri, faturalama ayrıştırma
• Versiyonlama, yayın onayı

Burada “en güçlü AI” yerine, operasyonel olarak taşınabilir olan kazanır.

Internal operasyon bot hedefleri

Internal bot dediğimiz şey, müşteriye değil ekibe hizmet eder. Örnekler:

• İK: izin politikası, yan haklar, onboarding
• IT: şifre sıfırlama yönlendirmesi, cihaz talepleri
• Satış: fiyat listesi, teklif şablonu, ürün uygunluğu
• Operasyon: prosedürler, SOP, kalite kontrol listeleri

Bu botlarda kritik nokta: erişim kontrolü ve içerik sahipliği. “Herkes her şeye erişsin” yaklaşımı, ilk denetimde sorun çıkarır. Ayrıca bilgi güncelliği iç operasyonlarda daha hızlı eskir; sahiplik net değilse bot iki ayda çöp olur.

Yanlış hedef tanımı örnekleri

Sahada en sık görülen yanlış hedefler:

1. “AI bot kuralım, destek yükü düşsün.”
   • Hangi temas türü? Hangi kanal? Hangi dil? Hangi başarı eşiği?
2. “WhatsApp’ta otomasyon istiyoruz.”
   • Müşteri neyi otomatik yapacak? Sipariş sorgu mu, satış mı, randevu mu?
3. “İnsan gibi konuşsun.”
   • Müşterinin ihtiyacı “insan gibi sohbet” değil, işini çözmek. Bazı yerlerde insan gibi konuşmak risk bile.
4. “Tüm soruları cevaplasın.”
   • Bu hedef, özellikle politika ve hukuki konularda, yanlış yanıt riskini büyütür. Kapsam çizmek şart.

İhtiyaç sınıflandırmasını yapmadan araca bakan ekipler genelde iki ay sonra şunu söylüyor: “Bot var ama kimse kullanmıyor” ya da “kullanıyorlar ama yanlış cevap veriyor”.

Araç Kategorileri Haritası

Chatbot tools dünyası tek bir ürün sınıfı değil. Aynı sayfada “chatbot builder” ile “contact center” yan yana listelenince seçim zorlaşıyor. En sağlıklısı, önce kategoriyi netleştirmek, sonra ürün kıyasına girmek.

Aşağıdaki harita, hangi ihtiyacın hangi sınıfa daha yakın olduğunu anlamak için.

Bot builder sınıfı

Bot builder’lar, akış tasarımı ve hızlı yayın odağıyla gelir. Tipik özellikler:

• Görsel akış tasarımı (no-code)
• Form alanları, koşullar, etiketleme
• Basit entegrasyonlar veya webhook
• Widget yayınlama, embed, temel analitik

Bu sınıf, “web sitesinde lead toplama” veya “SSS akışı” gibi net tanımlı işlerde iyi çalışır.

Örnek ürünler (resmi siteler):

• ChatBot
• Landbot
• Manychat (özellikle sosyal DM tarafında güçlüleşmiş durumda)

Risk: Builder güçlü olsa bile, canlı destek devri ve ajan tarafı zayıf kalabilir. Destek operasyonu hedefliyorsanız bu kritik.

Canlı destek platformu sınıfı

Canlı destek platformları, botu “bir özellik” olarak konumlar. Güçlü oldukları yer:

• Handoff ve ajan deneyimi
• Kuyruklar, atamalar, etiketler
• Sohbet geçmişi, müşteri profili
• Çoklu kanal inbox (ürüne göre değişir)

Bu sınıfta botu; triage, self-servis ve ajanı besleyen bir katman gibi düşünmek daha doğru. Özellikle destek ekipleri için “bot + agent workspace” bütünlüğü belirleyici olur.

Örnekler:

• Intercom
• Zendesk
• Freshdesk

Sosyal DM otomasyonu sınıfı

Instagram DM, Facebook Messenger, WhatsApp gibi kanallarda otomasyon yapan araçlar, genelde pazarlama ve satış akışlarında öne çıkar:

• Anahtar kelime tetikleyicileri
• Story yorumundan DM akışı
• Kampanya, kupon, yönlendirme
• Basit segmentasyon ve yayın

Örnekler:

• Manychat
• Meta Business Suite (sınırlı otomasyon, daha çok yönetim)

Bu sınıfta dikkat: Kanal politikaları, mesaj şablon onayları, WhatsApp ücretlendirme mantığı ürün seçimini etkiler. “Bot iyi” olsa da kanal kısıtları yüzünden hedef boşa düşebilir.

Contact center sınıfı

Contact center çözümleri; ses, chat, email, sosyal kanallar, workforce management gibi daha geniş bir çerçevede gelir. Chatbot burada tek parça.

• Gelişmiş yönlendirme (skill-based routing)
• SLA, QA, kayıt, denetim
• IVR + chat birleşimi (bazı senaryolar)
• Kurumsal güvenlik ve yönetişim

Örnekler:

• Genesys
• NICE CXone
• Five9

Bu sınıf, genelde “sadece chatbot” ihtiyacına ağır gelir. Ama çağrı merkezi ölçeğinde çalışan ekipler için doğru çatı olabilir.

Internal bot sınıfı

Internal botlar Slack, Microsoft Teams gibi ortamlarda yaşar; bilgiye erişim ve süreç otomasyonu yapar.

• Kurumsal arama ve bilgi tabanı
• Yetkilendirme ve grup bazlı erişim
• İş akışı otomasyonu (onay, talep)
• Audit ve veri saklama politikaları

Örnekler:

• Microsoft Copilot
• Slack AI
• Google Agents / Vertex AI (altyapı yaklaşımı)

Burada seçim çoğu zaman “bot aracı” değil, kurumun kimlik yönetimi, doküman ekosistemi ve güvenlik gereksinimleri üzerinden şekillenir.

Kabiliyet Matrisi

Kabiliyet matrisi, ürün demolarında kaybolmayı engeller. Bir tablo açın ve her aracı aynı sorularla değerlendirin. Aşağıdaki başlıklar, pratikte en çok fark yaratanlar.

Kanal kapsamı ve çoklu kanal

“Çoklu kanal” iddiası çoğu zaman muğlak. Şunları netleştirin:

• Web widget var mı? Mobil SDK var mı?
• WhatsApp, Instagram DM, Messenger, Telegram destekliyor mu?
• Email ve ticket ile birleşiyor mu, yoksa ayrı mı?
• Kanallar arası tek müşteri profili var mı?

Özellikle şu test senaryosu çok şey anlatır:

• Müşteri önce Instagram DM’den yazıyor, sonra web chat’e geçiyor. Ajan geçmişi görüyor mu?
  Eğer görmüyorsa, “çoklu kanal” sadece pazarlama cümlesidir.

Kanal seçiminde bir diğer pratik detay: Bazı araçlar aynı kanalı desteklese bile “native” entegrasyonla mı geliyor, yoksa üçüncü parti köprüyle mi? Native olanlar genelde daha stabil, daha az sürprizli.

Analitik ve performans görünümü

Bot kurulduktan sonra asıl iş başlar. Analitik yoksa iyileştirme de yok. Minimum arayın:

• Toplam konuşma, aktif kullanıcı, drop-off
• Çözüm oranı (self-serve) tanımı ve hesaplama yöntemi
• En çok kaçış (fallback) alan intent veya adım
• Handoff oranı ve nedenleri
• Konuşma başına maliyet (özellikle AI kullanımı varsa)

Burada önemli bir ayrım: Bazı ürünler “çözüm”ü, konuşmanın kapanması olarak sayar. Siz ise “sipariş durumu gösterildi” veya “ticket açıldı” gibi iş çıktısı üzerinden ölçmek isteyebilirsiniz. Tanımı siz koymazsanız, raporlar sizi yanıltır.

Handoff ve ajan deneyimi

Botun iyi olması yetmez. Ajan tarafı kötüyse müşteri deneyimi düşer. Kontrol listesi:

• Handoff olduğunda konuşma geçmişi eksiksiz aktarılıyor mu?
• Botun topladığı alanlar (sipariş no, konu, email) ajanın ekranında “structured” görünüyor mu?
• Ajan, bot akışını kaldığı yerden devralabiliyor mu?
• Not, etiket, makro, internal comment var mı?

İyi bir ajan deneyimi, ilk yanıt süresini ve “müşteriye tekrar tekrar aynı şeyi sorma” problemini azaltır. Bu, botun çözemediği yerde bile kaliteyi artırır.

Güvenlik ve erişim kontrolleri

Kabiliyet matrisi içinde güvenliği “kurumsal paket” diye geçiştirmeyin. Özellikle internal bot veya ödeme/sipariş verisi kullanan botlarda şart:

• SSO (SAML/OIDC) var mı?
• IP kısıtları, 2FA, cihaz politikaları var mı?
• Rol bazlı yetki: kim akış düzenleyebilir, kim yayınlayabilir?
• Veri maskeleme: kart verisi, kimlik, telefon gibi alanlar?

Birçok ekip, ilk POC’yi hızlı yapmak için güvenliği erteleyip sonra duvara tosluyor. Seçim aşamasında minimum gereksinimi koymak daha ucuz.

Test ve değerlendirme yetenekleri

Botu “yayına al, bakarız” diye yönetmek pahalı bir alışkanlık. Üründe şu yetenekleri arayın:

• Staging / test ortamı veya taslak yayın
• Versiyonlama ve geri alma (rollback)
• Senaryo bazlı test çalıştırma (en azından manuel test check-list’ini destekleyecek yapı)
• Farklı kitlelere kademeli yayın (pilot segment)

Basit ama etkili bir pratik: Yayına almadan önce 20 senaryoluk bir regression listesi oluşturun. “Kargo nerede”, “iade koşulları”, “adres değişikliği”, “yanlış sipariş no” gibi. Araç bunu yönetmeyi ne kadar kolaylaştırıyor?

Aşağıdaki tabloyu, kısa listeye kalan araçlar için doldurmak iyi çalışır:

Kategori	Soru	Beklenen minimum	Not
Kanal	Web + WhatsApp birlikte mi?	Tek inbox veya tutarlı profil
Analitik	Çözüm oranı tanımı	Özelleştirilebilir
Handoff	Bağlam aktarımı	Structured alan + özet
Güvenlik	RBAC	En az 3 rol
Test	Versiyonlama	Geri alma mümkün

Entegrasyon Yüzeyi

Entegrasyonlar, chatbot tools seçiminin “gizli maliyeti”. Demo aşamasında her şey olur gibi görünür; gerçek hayatta veri modeli uymaz, senkron bozulur, ekipler manuel iş yapar. Bu bölümü, entegrasyon risklerini azaltacak şekilde okuyun.

CRM ve e ticaret entegrasyonları

E-ticaret ve CRM entegrasyonlarında pratik sorular:

• Müşteriyi nasıl eşleştiriyor? Email mi, telefon mu, müşteri ID mi?
• Tekil müşteri profili var mı, yoksa her kanalda ayrı mı?
• Segment bilgisi çekilebiliyor mu? (VIP, ilk alışveriş, iade geçmişi)
• Bot, CRM’e not yazabiliyor mu? Etiket ekleyebiliyor mu?

Shopify gibi platformlarda entegrasyon “var” olabilir ama kapsam sınırlı olabilir. Örneğin sipariş listesi çekilir ama iade durumu çekilmez. Seçimden önce, sizin kritik 5 verinizi yazın:

• sipariş durumu
• kargo takip linki
• iade başlatma durumu
• ödeme yöntemi
• teslimat adresi (maskeli)

Sonra araca sorun: “Bunları native çekebiliyor musun, yoksa API geliştirme mi gerekecek?”

Helpdesk ve ticket entegrasyonları

Destek odaklı botlarda helpdesk entegrasyonu olmazsa olmaz. Arayın:

• Bot konuşmasından ticket açma
• Ticket’a konuşma transcript’i ve alanların yazılması
• Ticket kategorisi, öncelik, etiket atama
• Ajanın aynı ekrandan konuşma ve ticket yönetimi

Zendesk, Freshdesk gibi araçlarda entegrasyon seçenekleri çok. Ama önemli fark şurada: Bazı botlar sadece “ticket açar” ve biter. İyi entegrasyon, ticket’a doğru bağlamı taşır ve ajanı gereksiz sorudan kurtarır.

Ödeme kargo ve sipariş verisi

Ödeme ve kargo verisi, hem dönüşüm hem destek için kritik. Fakat aynı zamanda güvenlik açısından hassas.

• Kargo firması API’ları: gecikme, teslimat denemesi, şube bekleme
• Ödeme: başarısız işlem nedeni, provizyon, iade
• Sipariş: kısmi teslimat, paket bölünmesi

Burada en güvenli yaklaşım: Botun kendisi “ödeme detayını” tutmasın; sadece ilgili sistemden anlık sorgu yapıp sonucu sunsun. Veri saklama kapsamı ne kadar dar olursa risk o kadar düşer.

Webhook API ve otomasyon

Birçok ekip, “hazır entegrasyon yoksa webhook ile bağlarız” diye düşünür. Doğru, ama şu detayları netleştirin:

• Webhook çağrıları için retry/backoff var mı?
• Timeout ve hata yönetimi nasıl?
• İmzalama veya secret yönetimi var mı?
• Rate limit var mı?
• Loglama ve izleme var mı?

Ayrıca API ile bağlandığınızda, botun “konuşma akışı” ile “arka uç işlemi” senkron kalmalı. Örneğin iade başlatma çağrısı başarısız olduysa bot bunu doğru söylemeli ve tekrar denemeyi yönetmeli.

Veri senkronizasyon riskleri

Entegrasyonlarda en sık patlayan 3 risk:

1. Kimlik eşleştirme hatası
   Aynı telefonla iki hesap, farklı email, misafir checkout. Bot yanlış siparişi gösterebilir. Çözüm: doğrulama adımı ekleyin (sipariş no + email gibi).
2. Gecikmeli veri
   Kargo durumu 2 saat geriden geliyorsa bot “teslim edildi” diyemez. Çözüm: veri kaynağını ve güncellenme sıklığını netleştirin.
3. Yetki sınırı
   Bot, ajan gibi işlem yapmaya kalkarsa risk büyür. Çözüm: Botun yapacağı aksiyonları sınırlayın; “iptal et” yerine “iptal talebi oluştur” gibi.

Bu noktada, Canlı Destek Blog içindeki AI ve otomasyon içerikleri, özellikle entegrasyon ve operasyon tarafında fikir verir: AI ve chatbot içerikleri.

Bilgi Kaynağı Besleme

Chatbot tools seçerken “LLM var mı?” sorusu tek başına anlamsız. Asıl soru: Bot, doğru bilgiyi nereden alacak ve bu bilgi nasıl güncel kalacak? Bilgi kaynağı besleme, botun yanıt kalitesinin omurgası.

SSS ve yardım merkezi kaynakları

SSS ve help center içerikleri, bot için en temiz başlangıçtır. Ama ham haliyle beslemek yetmez.

Pratik düzenleme önerileri:

• SSS başlıklarını müşteri diliyle yazın (iade nasıl yapılır?)
• 1 soruya 1 cevap prensibi. Uzun, çok başlıklı cevaplar botu şaşırtır.
• Politika metinlerinde tarih ve sürüm bilgisi tutun (ör. “v2.3, 2026-01-10”)
• Cevapların içine “şu durumda canlı desteğe bağlanın” gibi net sınırlar ekleyin

Araç tarafında arayın:

• Kaynak bazlı yönetim (SSS koleksiyonu, kategori)
• İçerik değişince yeniden indeksleme kontrolü
• Kaynakların önceliklendirilmesi (politikalar, ürün, kampanya)

Ürün katalog ve politika içerikleri

E-ticarette ürün kataloğu beslemesi cazip ama riskli. Katalog çok büyükse botun “yanlış ürünü” önermesi kolaylaşır.

Burada iki yaklaşım var:

• Kontrollü: Popüler ürünler + kategori özetleri + beden/uyum tablosu
• Geniş: Tüm katalog + filtreleme + stok ve fiyat verisi

Seçim yaparken şu soruyu sorun: Bot gerçekten “katalogdan arama” mı yapacak, yoksa “ürün sayfası bağlamında” mı konuşacak? Ürün sayfasında çalışan bot, o sayfanın SKU’sunu biliyorsa başarı şansı artar.

Politika içeriklerinde (iade, garanti, KVKK) botun serbest yazmasına çok izin vermeyin. En iyi pratik: Bot, onaylı metni özetler ama gerektiğinde metnin ilgili maddesine link verir.

Doküman ve URL tabanlı besleme

Birçok chatbot tool, PDF/Doc ve URL ile besleme vaat eder. Güzel. Ama uygulamada sorunlar çıkar:

• PDF’te tablo ve görseller bozulur
• URL içerikleri dinamikse indeks yanlış olur
• Aynı bilginin iki yerde farklı sürümü kalır

Eğer URL tabanlı besleme yapacaksanız:

1. “Kaynak listesi” oluşturun (en fazla 30-50 URL ile başlayın)
2. Her URL’ye bir sahip atayın
3. Haftalık güncellik kontrolü koyun (en azından kritik sayfalar)
4. Botun cevaplarına “kaynak linki” ekleyebiliyor musunuz, test edin

Güncellik sürümleme ve sahiplik

Bilgi güncelliği, bot projesinin en az konuşulan ama en pahalı kısmı. Şu operasyon modelini kurun:

• Her içerik kümesinin bir sahibi (Support Ops, E-commerce Ops, Legal)
• Yayın onayı: taslak → onay → yayında
• Değişiklik kaydı: ne değişti, kim değiştirdi, ne zaman
• Kritik içerikler için periyodik gözden geçirme (ör. ayda 1)

Araç seçerken “content governance” yetenekleri önemli. En azından:

• Rollere göre düzenleme/yayın ayrımı
• Versiyon geçmişi
• Geri alma

Yanıt kalitesi için doğrulama

Yanıt kalitesini artırmanın en pratik yolu, botu “her soruya cevap veren” moddan çıkarıp doğrulama adımları eklemektir.

Örnek doğrulama desenleri:

• “Sipariş durumunu görebilmem için sipariş numaranı ve email adresini yaz.”
• “Bu konu iade politikasına giriyor. Şu iki seçenekten hangisi?” (14 gün içi / 14 gün sonrası)

Ayrıca kalite kontrol için küçük ama etkili bir ritim:

• Haftada 2 kez, en çok sorulan 20 soruyu inceleyin
• 10 tane “yanlış anlama” örneğini etiketleyin
• Bu etiketleri, yeni intent veya içerik iyileştirmesine çevirin

Handoff ve Eskalasyon

Handoff, botun başarısız olduğu an değil; doğru tasarlanırsa sistemin en güçlü parçası. Müşteri “insana bağlanmak” istediğinde sürtünme yaşarsa, bot ne kadar iyi olursa olsun nefret edilir.

Canlı destek devri tetikleyicileri

Handoff tetikleyicilerini baştan tanımlayın. En yaygın tetikleyiciler:

• Müşteri açıkça istiyor: “temsilci”, “canlı destek”
• Bot 2 kez üst üste fallback verdi
• Yüksek riskli konu: ödeme itirazı, yasal talep, KVKK başvurusu
• VIP müşteri veya yüksek sepet
• Duygu sinyali: aşırı öfke, tehdit, “şikayet edeceğim” (araç destekliyorsa)

Buradaki ince ayar: Handoff’u çok erken açarsanız botun değeri düşer. Çok geç açarsanız müşteri sinirlenir. Bu dengeyi kaçış analizi ile kurarsınız (İzleme bölümünde detay var).

SLA ve kuyruk yönlendirme

Handoff sonrası deneyim, kuyruk tasarımına bağlıdır:

• Konuya göre kuyruk: iade, ödeme, ürün, teknik
• Dile göre kuyruk (TR/EN)
• Çalışma saatine göre yönlendirme
• VIP veya öncelikli müşteri hattı

SLA tarafında pratik bir yaklaşım:

• Bot, “şu kadar sürede bağlanacağız” gibi söz vermesin.
• Bunun yerine, gerçekçi bir aralık verin ve alternatif sunun: “Yoğunuz, ticket açayım mı?”

Araç seçerken sorun: Kuyruklar ve atama kuralları ne kadar esnek? Basit “round-robin” mi, yoksa etiket/skill bazlı mı?

Ajan bağlam aktarımı

Ajanın müşteriye ilk sorduğu soru “sipariş numaranız?” olursa, botun topladığı her şey boşa gider. Bağlam aktarımı için minimum standart belirleyin:

• Müşteri kimliği (email/telefon)
• Sipariş no veya işlem id
• Botun anladığı konu (intent) ve son adım
• Müşterinin son 3 mesajı
• Botun verdiği cevaplar ve linkler

İyi araçlar, ajana “kısa özet” de verir. Özetin doğruluğunu test edin. Yanlış özet, hiç özet olmamasından kötü olabilir.

Çalışma saatleri ve acil durum

Çalışma saatleri dışında botun rolü değişir. İki temel model:

1. Self-servis ağırlıklı: kargo takibi, SSS, iade başlatma formu
2. Talep toplama: ticket açma, geri dönüş zamanı seçme

Acil durumlar için (kargo krizi, sistem kesintisi) botun “duyuru modu” olmalı:

• Ana mesajı en üste sabitleme
• İlgili akışları geçici kapatma
• Kriz bitince geri alma

Bu operasyon, araçta kolay değilse ekipler botu devre dışı bırakıp manuel kaosa düşer.

Ekip iş akışı sorumlulukları

Handoff sadece teknoloji değil, sorumluluk tasarımıdır. Netleştirin:

• Bot akışlarını kim günceller?
• Handoff kurallarını kim değiştirir?
• SLA ihlalinde kim alarm alır?
• Hangi konular bot kapsamı dışı?

Basit bir RACI tablosu bile karmaşayı azaltır:

İş	Responsible	Accountable	Consulted
Bot akış güncelleme	Support Ops	Head of Support	Legal, E-com
Politika içerikleri	Legal	Legal Lead	Support Ops
Entegrasyon bakımı	Dev/IT	CTO/IT Lead	Support Ops
Analitik raporu	Support Ops	Ops Manager	Product

Güvenlik ve Yönetişim

Güvenlik, “enterprise özellik” diye kenara atılınca, chatbot tools seçimi sürdürülemez hale gelir. Özellikle müşteri verisi, sipariş, ödeme, KVKK talepleri olan senaryolarda.

KVKK ve veri saklama

KVKK tarafında pratik sorular:

• Hangi veriler toplanıyor? (telefon, email, sipariş no, adres)
• Bu veriler nerede saklanıyor ve ne kadar süre?
• Silme talebi geldiğinde tüm sistemlerden silinebiliyor mu?
• Konuşma kayıtları anonimleştirilebiliyor mu?

Araç seçerken “data retention” politikasını net okuyun. Sadece “GDPR uyumlu” cümlesi yetmez. Ayrıca, bazı araçlar eğitim amacıyla konuşma verisini kullanabilir; bu opsiyonları kapatabilmek kritik olabilir.

Rol bazlı yetkilendirme

RBAC yoksa, ekip büyüdükçe sorun çıkar. Minimum roller:

• Viewer: rapor görür
• Editor: akış ve içerik düzenler
• Publisher/Admin: yayına alır, entegrasyon yönetir

Ek olarak şu ayrımlar değerli:

• Kanal bazlı yetki (WhatsApp yöneticisi ayrı)
• Müşteri verisine erişim kısıtı (maskeli görünüm)

Denetim kayıtları ve izlenebilirlik

Denetim kaydı (audit log) pratikte iki işe yarar:

• Hata olduğunda “kim neyi değiştirdi”yi bulursunuz
• İç kontrol ve denetimde kanıt sunarsınız

Arayın:

• Yayın geçmişi
• Ayar değişiklikleri
• Kullanıcı girişleri ve yetki değişimleri

Küçük ekipler için bile bu önemli. Çünkü botta yapılan küçük bir değişiklik, binlerce konuşmayı etkileyebilir.

İçerik onayı ve yayın politikası

Özellikle politika, fiyat, kampanya gibi konularda içerik onayı şart. Basit bir yayın politikası:

1. Taslak hazırlanır (Support Ops)
2. Hukuki/politika onayı (Legal)
3. Yayınlanır (Publisher)
4. İlk 24 saat yakından izlenir

Araç bunu desteklemiyorsa, en azından süreç dokümanı ile kontrol edin. Aksi halde “bot yanlış iade süresi söyledi” gibi krizler yaşanır.

Tedarikçi risk değerlendirmesi

Chatbot tool bir tedarikçidir. Sadece özellik değil, risk de alırsınız. Kontrol listesi:

• Veri merkezi konumu ve alt işleyenler
• SLA ve destek kanalı
• İhracat/taşınabilirlik: konuşma verisini dışa aktarabiliyor musunuz?
• Vendor lock-in riski: akışlarınızı taşıyabilir misiniz?
• Güvenlik sertifikaları varsa inceleyin (detay uydurmadan, belge talep edin)

Bu değerlendirme, özellikle ajanslar için de önemli. Müşteriye “bu aracı seçtik” dediğinizde, riskin bir kısmını siz taşırsınız.

Maliyet Modeli

Maliyet hesabı, “aylık ücret”ten ibaret değil. Chatbot tools maliyeti; kullanım, kanal, agent seat, AI tüketimi ve entegrasyon geliştirmeleriyle büyür.

MAU ve mesaj bazlı fiyatlama

Bazı araçlar MAU (Monthly Active Users) üzerinden fiyatlar. Bazıları mesaj sayısı veya konuşma sayısı.

MAU modelinde dikkat:

• “Aktif kullanıcı” tanımı nedir? 1 mesaj atan mı?
• Aynı kullanıcı farklı kanalda sayılıyor mu?
• Bot + canlı sohbet birlikte sayılıyor mu?

Mesaj bazlı modelde dikkat:

• Botun uzun cevapları maliyeti artırır mı?
• Fallback’ler ve tekrar sorular gereksiz mesaj şişirir mi?

Pratik öneri: Son 3 ayın konuşma loglarını çıkarın (varsa). Yoksa tahmin yapın:

• günlük konuşma
• ortalama mesaj sayısı
• yoğun saat oranı

Bu basit tahmin, yanlış pakete girmeyi engeller.

Agent seat ve kanal bazlı fiyatlama

Canlı destek platformu sınıfında maliyet çoğu zaman agent seat’ten gelir.

Kontrol edin:

• Bot kullansanız da agent seat gerekiyor mu?
• Supervisor/manager seat ücretli mi?
• WhatsApp veya Instagram gibi kanallar ek ücretli mi?
• Ek inbox veya ek marka maliyeti var mı? (ajanslar için kritik)

Bazı ürünlerde “kanal başına ücret” mantığı, büyüdükçe beklenmedik faturalara dönüşür. Özellikle WhatsApp tarafında, platform ücretleri ayrı bir katman olabilir.

AI kullanım maliyeti sürücüleri

AI maliyeti, “AI var mı?” sorusundan çok, ne kadar tüketiyor sorusudur.

Maliyeti büyüten sürücüler:

• Uzun prompt ve uzun konuşmalar
• Kaynak sayısının aşırı büyümesi
• Gereksiz serbest yazım (her adımda LLM çağırmak)
• Yanlış tasarlanmış fallback döngüleri

Maliyeti kontrol etmek için:

• Kontrollü akışları artırın (LLM’yi her yerde kullanmayın)
• Bilgi tabanını sadeleştirin
• En pahalı intent’leri tespit edip optimize edin

Tier limitleri ve ek ücretler

Tier’lar genelde şuralarda limit koyar:

• Bot sayısı
• Kanal sayısı
• Entegrasyon sayısı
• Analitik saklama süresi
• API çağrı limitleri

Satın almadan önce “overage” (aşım) ücretini sorun. Çünkü büyüme döneminde esas maliyet oradan gelir.

Toplam sahip olma maliyeti mantığı

TCO hesabı yaparken 4 kalemi birlikte düşünün:

1. Lisans (bot + agent + kanal)
2. AI tüketimi (varsa)
3. Entegrasyon geliştirme ve bakım
4. Operasyon zamanı (içerik güncelleme, QA, analiz)

Basit bir TCO şablonu:

• 12 aylık lisans
• 12 aylık tahmini AI
• 1 kere kurulum eforu (iç kaynak gün)
• Aylık bakım eforu (saat)

Burada amaç “tam doğru” sayı değil. Araçları aynı çerçevede kıyaslamak.

Değerlendirme ve Puanlama

Kıyaslama aşamasında ekipler genelde ikiye ayrılır: “en çok özellik” diyenler ve “en ucuz” diyenler. İkisi de tek başına yanlış. Doğru yöntem, kriterleri ağırlıklandırıp trade-off’ları görünür kılmak.

Kriter ağırlıkları belirleme

Önce kriterleri 100 puana dağıtın. Örnek ağırlık setleri:

E-ticaret dönüşüm odaklı:

• Kanal ve UX: 20
• Entegrasyon (sipariş/kargo): 25
• Bilgi kaynağı yönetimi: 15
• Analitik: 15
• Maliyet: 15
• Güvenlik: 10

Destek verim odaklı:

• Handoff ve ajan deneyimi: 25
• Helpdesk entegrasyonu: 20
• Analitik ve SLA: 20
• Kanal kapsamı: 15
• Güvenlik: 10
• Maliyet: 10

Ağırlıkları yazılı hale getirin. Çünkü seçim tartışmaları, en çok “neye önem veriyoruz” belirsizliğinde uzar.

Trade off karar noktaları

Bazı trade-off’lar kaçınılmaz:

• Güçlü AI vs kontrollü yanıt güvenliği
  Politika ve ödeme konularında kontrollü yaklaşım genelde daha güvenli.
• Hızlı kurulum vs derin entegrasyon
  Hızlı kurulum isteyen KOBİ, entegrasyona boğulursa proje biter.
• Çoklu kanal genişliği vs tek kanalda mükemmellik
  Her yerde olacağım derken hiçbir yerde iyi olmayın.
• Düşük lisans vs yüksek operasyon maliyeti
  Ucuz araç, içerik yönetimi ve testte sizi yorabilir.

Bu karar noktalarını “bilerek” alın. Sonradan sürpriz olmasın.

Kısa liste oluşturma

Kısa listeyi 3 araca indirmek idealdir. 5 araçla pilot yapmak ekipleri kilitler.

Kısa liste kriterleri:

• Zorunlu gereksinimleri karşılıyor mu? (must-have)
• Entegrasyon ve güvenlik “olabilir” seviyesinde mi?
• Operasyon ekibi aracı kullanabilir mi? (sadece teknik ekip değil)

Bu aşamada demo yerine, “bizim senaryomuz” üzerinden ürün turu isteyin. 60 dakikalık demo planı:

1. Kargo takibi akışı (gerçek veri ile)
2. İade politikası sorusu (kontrollü yanıt)
3. Handoff ve bağlam aktarımı
4. Analitik ekranında kaçış analizi
5. Rol ve yayın onayı

Pilot başarı ölçütleri

Pilotun amacı “her şeyi yapmak” değil, kritik varsayımları test etmektir.

Pilot KPI örnekleri:

• Self-servis çözüm oranı (net tanımlı)
• Fallback oranı
• Handoff sonrası ilk yanıt süresi
• Ticket kalitesi (eksik alan oranı)
• Müşteri memnuniyeti sinyali (varsa CSAT)

Pilot süresi: Genelde 2-4 hafta iyi çalışır. Daha kısa olursa veri az, daha uzun olursa ekip yorulur.

Satınalma öncesi kanıtlar

Satın alma öncesi mutlaka isteyin:

• Veri dışa aktarma örneği (konuşma, event, ticket)
• Entegrasyon dokümantasyonu ve sınırları
• Güvenlik dokümanları (en azından temel maddeler)
• SLA ve destek süreçleri
• Fiyatlandırma detayları: aşım ücretleri, kanal ücretleri

Sözlü vaatler unutulur. Kanıt isteyin, yazılı alın.

Kurulum İş Akışı

Kurulum, “botu açtık” işi değil. Konuşma tasarımı, içerik, entegrasyon, test ve yayına alma; hepsi bir sistem.

Konuşma tasarımı ve kapsam

Başlangıçta kapsamı dar tutmak, kaliteyi artırır. En iyi başlangıç seti genelde:

• Kargo takibi
• İade koşulları ve iade başlatma
• Sipariş değişiklikleri (adres, iptal talebi)
• Sık sorulan 10 soru

Konuşma tasarımında pratik kurallar:

• Her adımda tek soru sorun
• Serbest metin yerine seçenek sunun (özellikle ilk adımda)
• Hata durumunu tasarlayın (sipariş no yanlışsa ne olacak?)
• “Canlıya bağlan” seçeneğini saklamayın

Ayrıca botun kişiliğini abartmayın. Kısa, net, çözüm odaklı.

İçerik ve bilgi hazırlığı

İçerik hazırlığı genelde en çok ihmal edilen adım. Yapılacaklar:

1. Politika metinlerini güncelleyin (iade, kargo, garanti)
2. SSS’leri sadeleştirin, tekrarları silin
3. Ürün kategorilerine 1-2 paragraf özet hazırlayın
4. “Botun söylemeyeceği şeyler” listesini yazın (red lines)

Bu “red lines” listesi, özellikle serbest yanıt üreten botlarda çok işe yarar.

Entegrasyon ve kanal kurulumları

Entegrasyonu aşamalı kurun:

• Faz 1: Kimlik toplama + ticket açma + temel CRM notu
• Faz 2: Sipariş/kargo sorgu
• Faz 3: Aksiyonlar (iade başlatma, değişiklik talebi)

Kanal kurulumunda ise önce web’de stabil hale getirin, sonra WhatsApp/Instagram’a geçin. Çünkü sosyal kanalların policy ve template süreçleri, projeyi uzatabilir.

Yayın öncesi test senaryoları

Yayın öncesi test için 3 seviye öneririm:

• Fonksiyon testleri: akışlar çalışıyor mu?
• Negatif testler: yanlış sipariş no, boş alan, küfür, alakasız soru
• Handoff testleri: mesai dışı, yoğun saat, kuyruk dolu

Basit bir kontrol: Bot, bilmediği soruda “uyduruyor” mu? Eğer evet, canlıya devri hızlandırın veya kaynak kapsamını daraltın.

Yayına alma kontrolleri

Yayına almadan önce şu kontrolleri yapın:

• KVKK metni ve aydınlatma: gerektiği yerde gösteriliyor mu?
• Loglama: konuşmalar rapora düşüyor mu?
• Handoff: ajan ekranında bağlam görünüyor mu?
• Kriz kapatma: botu devre dışı bırakma veya duyuru modu var mı?
• Sahiplik: kim hangi güncellemeden sorumlu?

Yayın sonrası ilk 72 saat, “war room” gibi düşünün. Küçük ayarlar, büyük fark yaratır.

İzleme ve İyileştirme Döngüsü

Bot yayına alındıktan sonra değer üretmeye başlar ama aynı hızla bozulabilir. Ürünler değişir, kampanyalar değişir, müşteri dili değişir. Bu yüzden düzenli bir iyileştirme döngüsü kurmak şart.

Temel metrikler ve hedefler

Her ekip için değişse de, temel metrik seti:

• Toplam konuşma sayısı
• Self-servis çözüm oranı
• Fallback oranı (anlamadı)
• Handoff oranı
• Ortalama çözüm süresi (bot içinde)
• Ajan devraldıktan sonra ilk yanıt süresi

Burada kritik: Hedefleri gerçekçi koyun. İlk ay “%80 otomasyon” hedefi genelde hayal kırıklığıdır. Daha iyi yaklaşım:

• İlk 4 hafta: kalite ve güvenlik
• Sonraki 8 hafta: kapsam genişletme ve optimizasyon

Yanıt kalitesi ve kaçış analizi

Kaçış analizi, botun nerede başarısız olduğunu gösterir. Haftalık rutine koyun:

• En çok fallback alan 20 soru/intent
• En çok drop-off olan 10 adım
• Müşterinin “temsilci” dediği noktalar

Sonra aksiyona çevirin:

• Yeni intent ekleme
• Mevcut cevabı sadeleştirme
• Doğrulama adımı ekleme
• Handoff tetikleyicisi ayarı

Burada küçük bir içgörü: Fallback’lerin bir kısmı “bilgi eksikliği” değil, “dil” problemidir. Müşteri “kargom nerde” yazar, içerikte “teslimat takibi” geçer. Eş anlamlıları ve müşteri dilini beslemek büyük fark yaratır.

Handoff performansı ve SLA

Handoff metriklerini ayrı izleyin:

• Handoff sonrası bekleme süresi
• Kuyruk bazlı SLA
• Ajanın bot bağlamını kullanma oranı (varsa ölçüm)
• Handoff sonrası müşteri memnuniyeti sinyali

Eğer handoff sonrası süreler uzunsa, bot “çözüm” üretmiyor demektir. Sadece tampon görevi görür. Bu durumda ya bot kapsamını artırın (self-servis), ya da kuyruk ve vardiya planını düzeltin.

A B test ve iterasyon planı

Her şeyi aynı anda değiştirmeyin. A/B test veya kontrollü iterasyon daha sağlıklı.

Test edilebilecek şeyler:

• Açılış mesajı (kısa vs yönlendirici)
• İlk seçenek seti (3 seçenek vs 6 seçenek)
• Handoff butonunun yeri
• İade akışında soru sırası
• Ürün öneri formatı (kart vs liste)

İterasyon planı için basit bir kural:

• 2 haftada bir küçük değişiklik
• Her değişiklik için 1 ana metrik ve 1 risk metriği (ör. çözüm oranı artarken fallback artıyor mu?)

Bilgi güncelleme ritmi

Bilgi güncelleme ritmi yoksa bot yavaş yavaş yanlış konuşmaya başlar. Minimum ritim önerisi:

• Haftalık: en çok sorulan 20 sorunun kontrolü
• Aylık: politika ve kampanya sayfalarının gözden geçirilmesi
• Çeyreklik: kapsam değerlendirmesi, yeni akış adayları

Ayrıca “tek seferlik” güncellemeleri kaçırmayın:

• Yeni kargo firması
• İade süresi değişikliği
• Ödeme yöntemi değişikliği
• Yeni ürün kategorisi

Bu güncellemeler için içerik sahiplerini önceden belirlediyseniz, botun kalitesi korunur.