Yapay Zeka Satış Asistanı Kurulumu: Müşteri Karşılama, Nitelendirme ve Çok Dilli Chatbot

Bir satış ekibi düşünün: gelen her mesaja aynı beş soruyu sorup cevaba göre müşteriyi doğru kişiye yönlendiren, gece yarısı da mesai saatinde de aynı sabırla çalışan, üç dilde konuşabilen bir ön saflı temsilci. Bu, kural tabanlı bir menü botu değil — doğal dilde konuşan, bağlamı hatırlayan, ne zaman devretmesi gerektiğini bilen bir yapay zeka satış asistanıdır. Bu yazı, tam olarak bunun nasıl kurulduğunu anlatıyor.

Kural tabanlı WhatsApp botlarıyla karıştırılmaması gereken bir konu bu: burada anlatılan asistan, önceden yazılmış menülerle değil, büyük dil modeliyle (LLM) çalışır — serbest yazılan cümleleri anlar, bağlama göre soru sorar, gerektiğinde konuyu değiştirir. Kural tabanlı WhatsApp chatbot kurulumunun maliyeti, türleri ve teklif değerlendirme süreci için ayrı bir kaynağımız var: WhatsApp chatbot yaptırma rehberi. Bu yazıda o konuya girmiyoruz; odağımız LLM tabanlı satış asistanının davranış tasarımı, nitelendirme mantığı ve çok dilli kurulumu.

Genel amaçlı bir yapay zeka ajanı kurmakla (görev otomasyonu, araç bağlama, otonomi seviyeleri) ilgileniyorsanız AI agent kurulumu rehberimize bakabilirsiniz — orada mimari kararları ve genel kurulum adımlarını ayrıntılı işledik. WhatsApp’a özel satış takip mesajları, teklif hatırlatma dizileri ve huni aşamasına göre tetiklenen şablonlar için ise WhatsApp satış otomasyonu yazımıza yönlendiriyoruz. Bu yazı, o iki konunun kesiştiği ama aynı olmadığı bir üçüncü alanı kapsıyor: müşteriyle canlı, doğal dilde konuşan ve onu nitelendirip doğru yere yönlendiren yapay zeka satış asistanının kendisi.

Yapay Zeka Satış Asistanı Nedir, Neden Farklıdır

”Satış asistanı” terimi son bir yılda enflasyona uğradı; her otomasyon aracı kendini böyle tanıtıyor. Ayrımı netleştirelim.

Kural tabanlı bot: Önceden tanımlanmış bir karar ağacı üzerinde çalışır. “1 için fiyat, 2 için randevu” gibi menülerle ilerler. Kullanıcı beklenmedik bir şey yazdığında ya anlamaz ya da en yakın anahtar kelimeyle eşleştirmeye çalışır. Ucuzdur, öngörülebilirdir, ama doğal bir sohbet hissi vermez.

LLM tabanlı yapay zeka satış asistanı: Büyük dil modeli (GPT, Claude, Gemini gibi) üzerine kurulur. Kullanıcı ne yazarsa yazsın anlamaya çalışır, bağlamı hatırlar, konuşmayı doğal bir akışta yönetir. “Fiyat ne kadar” ile “bu ne kadar tutar acaba” ile “bütçem sınırlı, en uygun paket hangisi” cümlelerinin aynı niyeti taşıdığını anlar — kural tabanlı bir bot bu üçünü üç ayrı anahtar kelime kümesiyle tanımlamak zorunda kalırdı.

Farkın satış sürecine yansıması şuradadır: kural tabanlı bot bilgi toplayabilir ama gerçek anlamda nitelendirme yapamaz, çünkü nitelendirme doğası gereği dallanan, bağlama duyarlı bir konuşmadır. “Bütçeniz nedir” sorusuna “duruma göre değişir” cevabı geldiğinde, LLM tabanlı asistan bunu takip eden bir soru üretebilir; kural tabanlı bot çoğunlukla tıkanır ve önceden yazılmış bir yedek cümleye döner.

Ne Zaman LLM Tabanlı Asistan, Ne Zaman Kural Tabanlı Bot

Bu ayrım her işletme için LLM tabanlı asistanın doğru seçim olduğu anlamına gelmez. Karar çerçevesi:

Pratikte en sağlıklı kurgu çoğu zaman melezdir: kritik ve riskli cevaplar (fiyat taahhüdü, tıbbi bilgi) şablonlu kalır, serbest sohbet ve nitelendirme LLM’e bırakılır, belirsizlikte insan devri devreye girer. Bu yazının ilerleyen bölümlerinde bu melez mimariyi adım adım kuracağız.

Mimarinin Dört Katmanı

Bir yapay zeka satış asistanı kurulumu dört katmandan oluşur. Bu katmanları ayrı ayrı tasarlamadan doğrudan “bot yazmaya” başlamak, en sık görülen hatadır.

1. Karşılama Katmanı

Müşterinin ilk mesajına verilen tepki. Amaç, botun kendini insan gibi tanıtmadan, samimi ve amaca yönelik bir açılış yapmasıdır. İyi bir karşılama üç şeyi aynı anda yapar: kimliğini netleştirir (yapay zeka asistanı olduğunu gizlemez), müşterinin neden yazdığını anlamaya çalışır, ve konuşmanın kontrolünü kaybetmeden ilk yönlendirmeyi yapar.

Kötü örnek: “Merhaba! Size nasıl yardımcı olabilirim?” — bu açık uçlu soru, müşteriyi hiçbir yöne itmez ve konuşma rastgele bir noktadan başlar.

İyi örnek: “Merhaba, ben [İşletme Adı]‘nın yapay zeka asistanıyım. Ürün/hizmet hakkında bilgi almak, fiyat öğrenmek ya da randevu oluşturmak için buradayım — hangisiyle başlayalım, yoksa direkt sorunuzu yazabilirsiniz.” Bu açılış, hem yön verir hem de serbest yazma kapısını kapatmaz.

2. Nitelendirme Katmanı

Müşterinin gerçek bir satış adayı olup olmadığını, hangi ürün/hizmete uygun olduğunu ve aciliyetini anlamak için tasarlanmış soru dizisidir. Bir sonraki bölümde ayrıntılı işleyeceğiz.

3. Bilgi ve Yanıt Katmanı

Asistanın soruları cevaplarken kullandığı bilgi kaynağı. LLM’in kendi genel bilgisiyle değil, işletmenin kendi verisiyle (fiyat listesi, hizmet kapsamı, sık sorulan sorular, politika metinleri) cevap üretmesi gerekir — buna “grounding” ya da “RAG” (retrieval-augmented generation) denir. Bu katman doğru kurulmazsa asistan var olmayan bir kampanyadan ya da yanlış bir fiyattan bahsedebilir; bu hem güven kaybı hem de bazı durumlarda hukuki risk demektir.

4. Devir (Handoff) Katmanı

Asistanın ne zaman, nasıl ve kime devredeceğini belirleyen mantık. Ayrı bir bölümde ele alacağız çünkü kurulumun en çok ihmal edilen ama en kritik parçasıdır.

Bu dört katman birbirinden bağımsız tasarlanmalı, sonra birleştirilmelidir. Doğrudan tek bir uzun prompt yazıp “hallolsun” demek, ilk yüz konuşmada tutarsızlık üretir.

Otomatik Müşteri Adayı Nitelendirme: Nasıl Kurulur

Nitelendirme (qualification), bir satış görüşmesinin en değerli ama en çok göz ardı edilen adımıdır. İnsan satış temsilcileri bunu sezgisel yapar; yapay zeka asistanı için bunu açık bir çerçeveye dökmek gerekir.

Nitelendirme Çerçevesi: BANT’ın Sohbet Diline Çevrilmesi

Klasik BANT çerçevesi (Bütçe, Yetki, İhtiyaç, Zaman) satış eğitimlerinde tanıdıktır ama doğrudan soru listesine dönüştürülürse sorgu formu gibi hissettirir ve müşteriyi kaçırır. Doğru yaklaşım, bu dört boyutu doğal konuşma akışına gizlemektir.

Asistan bu dört boyutu tek seferde sormaz; konuşmanın akışına göre bir ya da ikisini sorar, gerekirse ilerleyen turlarda tamamlar. LLM’in gücü tam burada devreye girer: önceki cevaba göre hangi sorunun daha doğal olduğuna karar verebilir.

Nitelendirme Akışının Adımları

1. İlk niyet tespiti: Müşteri neden yazdı — bilgi almak mı, fiyat öğrenmek mi, şikayet mi, mevcut müşteri desteği mi? Yanlış niyet tespiti, tüm sonraki akışı bozar; bu yüzden ilk sınıflandırma en yüksek doğrulukla yapılmalıdır.
2. Segment belirleme: Müşteri hangi ürün/hizmet kategorisine uygun? Çok ürünlü işletmelerde bu adım, sonraki soruların hangi bilgi tabanından besleneceğini belirler.
3. Aciliyet ve zaman çerçevesi: Müşteri bu hafta mı karar verecek, yoksa üç ay sonra mı? Bu bilgi, takip sıklığını ve satış ekibine iletim önceliğini belirler.
4. Bütçe uyumu (yumuşak sinyal): Doğrudan rakam sormak yerine paket/aralık önerip tepkiyi ölçmek, çoğu sektörde daha az itici bir yöntemdir.
5. Karar verici tespiti: B2B senaryolarda özellikle önemli — konuşulan kişi karar verici değilse, teklif ve takip süreci farklı kurgulanmalıdır.
6. Skorlama ve yönlendirme: Toplanan sinyaller bir puana (sıcak/ılık/soğuk gibi) dönüştürülür ve buna göre ya insana anında devredilir ya da otomatik bir sonraki adıma (bilgi gönderme, randevu linki) yönlendirilir.

Nitelendirme Skorlama Tablosu Örneği

Bu skorlama mantığı, LLM’in konuşma sonunda ürettiği bir yapılandırılmış çıktı (structured output — JSON gibi) ile CRM’e aktarılır. Yani asistan sadece sohbet etmekle kalmaz, konuşmanın sonunda “bu leadin özeti: segment X, aciliyet yüksek, bütçe uyumlu, karar verici” gibi bir veri paketini de üretir. Bu paket, satış ekibinin devraldığında sıfırdan başlamak zorunda kalmamasını sağlar — asistanın en somut katkısı budur.

Çok Dilli Satış Chatbotu Kurulumu

Uluslararası müşteri ya da hasta trafiği alan işletmeler için (sağlık turizmi, e-ticaret, danışmanlık, eğitim) çok dilli destek artık bir lüks değil, temel gerekliliktir. LLM tabanlı asistanların burada net bir avantajı var: ayrı ayrı dil modelleri kurmaya ya da önceden çevrilmiş menüler hazırlamaya gerek kalmadan, aynı model çoğu büyük dile doğal şekilde cevap verebilir.

Neden LLM Tabanlı Yaklaşım Çok Dilde Üstün

Kural tabanlı botlarda çok dilli destek, her dil için ayrı menü ağacı ve ayrı çeviri metni anlamına gelir — üç dil desteklemek, üç kat bakım yükü demektir. LLM tabanlı asistanda ise sistem talimatı (system prompt) ve bilgi tabanı tek dilde (genellikle Türkçe) tutulabilir; model, kullanıcının yazdığı dili algılayıp o dilde cevap üretir. Bakım tek noktadan yapılır, dil sayısı arttıkça yük neredeyse hiç büyümez.

Uluslararası Hasta/Müşteri Senaryosu

Özellikle sağlık turizmi gibi sektörlerde tipik bir akış şöyledir: bir hasta adayı Instagram reklamından geliyor, İngilizce ya da Arapça yazıyor, tedavi süreci, fiyat aralığı ve konaklama hakkında sorular soruyor. Bu senaryoda asistanın yapması gerekenler:

1. Dil tespiti: İlk mesajdan hangi dilde yazıldığını anlamak (LLM’ler bunu ek bir araç gerekmeden yapabilir).
2. O dilde tutarlı devam: Konuşma boyunca aynı dilde kalmak — kullanıcı dil değiştirirse (örneğin İngilizce başlayıp Türkçe’ye geçerse) asistanın da geçiş yapması.
3. Kültürel ve yasal hassasiyet: Tıbbi bilgilerde taahhüt dili kullanmamak, kesin sonuç vaat etmemek — bu, dil fark etmeksizin sabit bir kural olmalı ve sistem talimatına açıkça yazılmalıdır.
4. Zaman dilimi farkındalığı: Farklı ülkelerden gelen taleplerde, insana devir söz konusu olduğunda müsait olunan saat aralığının netleştirilmesi (aksi halde müşteri gece yarısı “biri arayacak” mesajı alıp kimseyi bulamaz).
5. Yerel iletişim kanalı tercihi: Bazı ülkelerde WhatsApp yaygın değildir; bu durumda e-posta veya web sitesi sohbet penceresi gibi alternatif kanalların da aynı bilgi tabanına bağlı olması gerekir.

Çok Dilli Kurulumda Kontrol Listesi

1. Sistem talimatına “kullanıcının yazdığı dilde cevap ver” kuralı açıkça eklenmeli — bu olmadan model bazen varsayılan dile (genelde İngilizce) kayabilir.
2. Bilgi tabanı tek dilde tutulup modelin çeviri/uyarlama yapmasına izin verilmeli; her dil için ayrı belge tutmak bakım yükünü gereksiz büyütür.
3. Fiyat, ölçü birimi (para birimi, tarih formatı) gibi yerel farklılıklar için açık kurallar tanımlanmalı — model kendi başına “1000” yazdığında hangi para birimini kastettiğini bilemez.
4. Desteklenen dillerin bir üst sınırı belirlenmeli ve test edilmeli; “tüm diller” iddiası pratikte az konuşulan dillerde kalite düşüşüne yol açabilir.
5. İnsana devir anında, devralan kişinin de o dilde iletişim kurabileceğinden emin olunmalı — aksi halde nitelendirme başarılı olur ama devir noktasında müşteri kaybedilir. Bu genelde çok dilli ekiplerde bir kişiye/role atanarak çözülür.
6. Dil karışık mesajlarda (örneğin bir cümlede iki dil) asistanın baskın dile göre cevap vermesi ve gerektiğinde netleştirme sorusu sorması test edilmeli.

İnsana Devir (Handoff) Mantığı

Yapay zeka satış asistanı kurulumlarında en çok atlanan ama başarısızlığın en sık kaynağı olan katman budur. Asistan ne kadar iyi olursa olsun, devretmesi gereken anı kaçırırsa güven kaybı hızla büyür.

Devir Ne Zaman Tetiklenmeli

• Müşteri açıkça insanla konuşmak istediğini belirttiğinde (bu talep hiçbir koşulda görmezden gelinmemeli veya ertelenmemeli).
• Asistan, bilgi tabanında karşılığı olmayan bir soruyla karşılaştığında — model burada tahmin üretmemeli, “bilmiyorum, ekibe iletiyorum” demeli.
• Nitelendirme skoru “sıcak” eşiğini geçtiğinde — yüksek potansiyelli bir lead’i botun elinde fazla tutmak, kapanma oranını düşürür.
• Şikayet, memnuniyetsizlik ya da duygusal yoğunluk tespit edildiğinde — bu durumlarda otomatik cevap, sorunu büyütme riski taşır.
• Fiyat pazarlığı ya da özel/istisnai bir talep söz konusu olduğunda — asistanın yetki sınırının net biçimde tanımlanması gerekir.
• Aynı soru art arda iki-üç kez farklı şekillerde soruluyorsa (bu genelde asistanın cevabının tatmin etmediğinin işaretidir).

Devir Sırasında Neyin Aktarılması Gerekir

Kötü bir devir, insanı sıfırdan başlatır ve müşteriyi “az önce söyledim” demek zorunda bırakır. İyi bir devir, şu paketi insana taşır:

• Konuşmanın kısa özeti (asistanın ürettiği yapılandırılmış özet)
• Nitelendirme sinyalleri (segment, aciliyet, bütçe uyumu, karar verici durumu)
• Devrin tetiklenme sebebi (müşteri istedi mi, asistan mı bilemedi, skor mu yüksekti)
• Konuşmanın tamamına erişim linki/geçmişi

Bu paket olmadan devir, sadece “birine sohbeti atma” işlemine döner ve nitelendirmenin tüm değeri kaybolur.

Devir Sonrası Beklenti Yönetimi

Asistan devir yaptığında müşteriye net bir zaman beklentisi vermelidir: “Ekibimizden biri birkaç dakika içinde size dönecek” gibi somut bir ifade, belirsiz “en kısa sürede” ifadesinden daha güven verici çalışır — yeter ki bu beklenti gerçekten karşılanabilsin. Karşılanamayan bir zaman vaadi, botsuz süreçten daha kötü bir deneyime dönüşür.

Hangi LLM/Platform Seçenekleri Var

Yapay zeka satış asistanı kurmak için üç temel yol var; hangisinin doğru olduğu işletmenin teknik kapasitesine ve özelleştirme ihtiyacına bağlı.

Karar Tablosu

LLM Model Seçimi Üzerine Notlar

Model seçimi teknik bir ayrıntı gibi görünse de satış asistanı kalitesini doğrudan etkiler. Genel eğilimler:

• Doğal dil anlama ve çok dilli kalite: Büyük, güncel modeller (Claude, GPT serisi, Gemini gibi) çoğu büyük dilde tutarlı sonuç verir; az konuşulan dillerde farklar belirginleşir, bu yüzden hedef dillerde test şarttır.
• Maliyet-performans dengesi: Yüksek hacimli, basit nitelendirme akışlarında daha küçük/ucuz modeller yeterli olabilir; karmaşık, çok adımlı satış görüşmelerinde daha güçlü modeller hata oranını belirgin düşürür.
• Yapılandırılmış çıktı desteği: Nitelendirme özetini CRM’e aktarmak için modelin güvenilir JSON/yapılandırılmış çıktı üretebilmesi kritik bir teknik gereksinimdir; bu özellik olmadan devir paketi manuel yazılmak zorunda kalır.
• Veri işleme ve konum: Özellikle sağlık gibi hassas veri içeren sektörlerde, seçilen modelin/platformun veri işleme politikaları ve sunucu konumu KVKK açısından değerlendirilmelidir; bu yazı hukuki görüş niteliği taşımaz, kendi danışmanınızla teyit edin.

Platform seçimi tek başına başarıyı belirlemez — asıl fark, bilgi tabanının kalitesi, nitelendirme akışının tasarımı ve devir mantığının netliğindedir. En pahalı modeli kötü tasarlanmış bir akışa bağlamak, ucuz bir modeli iyi tasarlanmış bir akışa bağlamaktan çoğunlukla daha kötü sonuç verir.

Kurulum Süreci: Adım Adım

Yukarıdaki katmanları teoride anlamak yetmez; gerçek bir kurulum projesi belirli bir sırayla ilerler. Aşağıdaki adımlar, hem no-code hem kod tabanlı kurulumlar için geçerli bir iskelet sunar.

1. Aşama: Kapsam ve Hedef Netleştirme

Kurulumdan önce üç soru netleşmeli: Asistan hangi kanallarda çalışacak (web sitesi, WhatsApp, Instagram)? Hangi dillerde hizmet verecek? Başarı nasıl ölçülecek (devredilen lead sayısı, ilk yanıt süresi, nitelendirme doğruluğu)? Bu üçü baştan yazılmadan başlayan projeler, ortasında kapsam kaymasıyla karşılaşır.

2. Aşama: Bilgi Tabanının Hazırlanması

Asistanın besleneceği kaynak — hizmet/ürün açıklamaları, fiyat mantığı (kesin rakam değil, aralık ve koşullar), sık sorulan sorular, yasaklı/riskli konular listesi — bir doküman haline getirilir. Bu aşama genelde en çok zaman alan aşamadır çünkü işletmenin dağınık bilgisini (satış ekibinin kafasında, eski PDF’lerde, web sitesinde) tek bir tutarlı kaynağa toplamak gerekir.

3. Aşama: Karşılama ve Nitelendirme Akışının Tasarımı

Karşılama cümlesi, nitelendirme soruları ve skorlama mantığı bu yazıda anlatılan çerçeveye göre yazılır. Bu aşamada sistem talimatı (system prompt) taslağı oluşturulur ve örnek konuşmalarla masa başında test edilir — canlıya almadan önce en az on-onbeş farklı senaryo (standart soru, alakasız soru, agresif pazarlık, dil değişimi, şikayet) yazılı olarak denenmelidir.

4. Aşama: Devir Mekanizmasının Kurulması

Hangi durumda kime, hangi kanaldan (uygulama bildirimi, e-posta, CRM görevi) devir yapılacağı teknik olarak bağlanır. Bu aşamada satış ekibinin devir paketini nasıl göreceği (özet + sinyaller + geçmiş linki) somut bir arayüzde test edilir.

5. Aşama: Sınırlı Pilot

Asistan, tüm trafiğe değil önce tek bir kanala veya belirli bir saat aralığına (örneğin yalnızca mesai dışı saatler) açılır. Pilot süresince her konuşma insan gözüyle örneklenir, yanlış cevaplar bilgi tabanı düzeltmesine dönüştürülür, devir eşiği gerekirse yeniden kalibre edilir.

6. Aşama: Tam Kapsamlı Yayın ve İzleme

Pilot sonuçları yeterli görüldüğünde asistan tüm kanallara açılır. Yayın sonrası izleme düzenli olmalıdır: haftalık örnekleme, devredilen lead kalitesinin satış ekibiyle birlikte değerlendirilmesi ve bilgi tabanının güncel tutulması (yeni ürün, kampanya, fiyat değişikliği anında yansıtılmalı) sürecin sürdürülebilirliğini belirler.

Kurulum Öncesi Kontrol Listesi

1. Hedef kanallar ve diller net biçimde yazılı mı?
2. Bilgi tabanı tek, güncel ve tutarlı bir kaynakta mı toplandı?
3. Nitelendirme soruları sohbet akışına gömülü mü, yoksa sorgu formu gibi mi hissettiriyor?
4. Devir eşiği (hangi skor, hangi durum) açıkça tanımlandı mı?
5. Devir paketinde konuşma özeti ve sinyaller otomatik oluşuyor mu?
6. Tıbbi/hukuki/fiyat taahhüdü sınırları sistem talimatına açıkça yazıldı mı?
7. Çok dilli senaryo en az iki-üç hedef dilde gerçek kullanıcı cümleleriyle test edildi mi?
8. Pilot dönemi ve örnekleme planı belirlendi mi?
9. Aylık kullanım maliyeti (API + platform) hacim tahminine göre hesaplandı mı?

Vaka Kurgusu: Uluslararası Hasta Danışmanlığı Kliniği

Bir estetik/sağlık kliniği, Instagram ve web sitesi üzerinden yoğun yurt dışı talep alıyor ama İngilizce ve Arapça mesajların çoğuna yanıt gece saatlerine kayıyor, bir kısmı da hiç cevaplanmıyordu. Mevcut kural tabanlı bot yalnızca Türkçe menü sunuyor, yabancı dildeki serbest mesajları anlayamıyordu.

Uygulama: Klinik, LLM tabanlı bir karşılama ve nitelendirme asistanı kurdurdu. Asistan üç dilde (Türkçe, İngilizce, Arapça) karşılama yapacak şekilde tasarlandı; sistem talimatına “kullanıcının dilinde cevap ver, tıbbi sonuç taahhüt etme, fiyat aralığını genel bilgi olarak ver ama kesinleşmiş fiyat söyleme” kuralları eklendi. Nitelendirme akışında hastanın ilgilendiği işlem, seyahat planı (tarih aralığı) ve daha önce benzer bir işlem araştırıp araştırmadığı soruluyor; bu üç sinyal bir araya geldiğinde konuşma anında ilgili dil bilen danışmana devrediliyor, devir paketinde konuşma özeti ve sinyaller birlikte iletiliyordu. Tıbbi soru içeren her mesajda asistan genel bilgi verip kesin cevabı insana bırakıyordu — bu kural hiç esnetilmedi.

Sonuç penceresi: İlk altı haftalık pilot dönemde, mesai dışı gelen taleplerin önemli bölümü aynı gün içinde ilk cevabı aldı; danışmanlar sohbete girdiğinde sıfırdan başlamak yerine hazır bir özetle devraldı. En büyük fark, önceden cevapsız kalan yabancı dildeki mesajlarda görüldü — asistan devreye girene kadar bu trafiğin büyük kısmı sessizce kayboluyordu. Klinik, kazanımı büyük ölçüde bu kayıp trafiğin geri kazanılmasına bağladı, tek başına “bot kurmuş olmaya” değil.

(Vaka temsilidir.)

Sık Yapılan Hatalar

1. Asistanı insan gibi göstermeye çalışmak. Kimliğini gizleyen ya da belirsiz bırakan bir asistan, ortaya çıktığında güven kaybına yol açar. Açık kimlik, aksine beklenti yönetimini kolaylaştırır.
2. Nitelendirmeyi sorgu formuna dönüştürmek. Art arda beş-altı doğrudan soru sormak, doğal bir satış görüşmesi hissi vermez ve müşteri kaçırma oranını yükseltir; sorular sohbet akışına gömülmelidir.
3. Bilgi tabanı olmadan modeli serbest bırakmak. Grounding kurulmadan çalışan bir asistan, olmayan kampanyalardan ya da yanlış fiyattan bahsedebilir — bu hem güven hem hukuki risk taşır.
4. Devir eşiğini net tanımlamamak. “Uygun görülürse devret” gibi belirsiz bir kural, asistanın kararsız kalmasına ve sıcak lead’lerin uzun süre botta beklemesine yol açar.
5. Devir paketini boş bırakmak. Konuşma özeti ve nitelendirme sinyalleri olmadan yapılan devir, insanı sıfırdan başlatır — nitelendirmenin sağladığı zaman kazancını sıfırlar.
6. Çok dilli desteği “tüm diller” iddiasıyla test etmeden sunmak. Az konuşulan dillerde kalite testi yapılmadan yayına alınan asistan, o dildeki müşterilerde tutarsız ya da yanlış cevaplar üretebilir.
7. Tıbbi/hukuki taahhüt sınırını dil bazında değiştirmek. Bir dilde uygulanan katı kural (örneğin kesin sonuç vaat etmeme), diğer dillerde gevşetilmemeli — sistem talimatına dilden bağımsız, sabit kural olarak yazılmalı.
8. Pilot dönemi atlamak. Asistanı doğrudan tüm trafiğe açmak yerine, sınırlı bir kanal veya saat aralığında test edip konuşmaları insan gözüyle örneklemek, canlıya geçtikten sonra ortaya çıkacak hataları önceden yakalar.
9. Maliyet planlamasında kullanım hacmini hesaba katmamak. LLM API maliyeti, konuşma hacmiyle doğrusal büyür; yalnızca kurulum maliyetine bakıp aylık kullanım maliyetini göz ardı etmek, bütçe sürprizine yol açar.

Sık Sorulan Sorular

Yapay zeka satış asistanı kurulumu, doğru tasarlandığında ekibinizin zamanını en değerli konuşmalara yönlendiren, çok dilli trafiği kaybetmeden karşılayan ve devir anında insanı sıfırdan başlatmayan bir sistem haline gelir. Karşılama metninden nitelendirme sorularına, bilgi tabanından devir kurallarına kadar bu yazıda anlatılan adımları kendi işletmenize özel uyarlamak için yapay zeka otomasyon hizmetlerimize göz atabilirsiniz.