Müşteri sorusunu bot ne zaman cevaplayabilir?

Müşteri sorusunu bot ancak cevabın kaynağı bir kayıt alanında ya da yazılımda tanımlı bir kuralda duruyorsa cevaplayabilir; kaynak bir kişinin yargısıysa cevaplayamaz. Hangi kademede olduğunuz, sohbet yüzeyi seçilmeden önce sistemin ne tuttuğuna ve kuralın nerede durduğuna göre belli olur. Pilatesco’nun randevu yazılımında ders hakkının geri gelip gelmediğini kural belirliyor; kural sisteme yazılmadan önce aynı cevap mesaja bakan kişiden çıkıyordu.

Ayrım satın alma kararınızı da belirliyor, çünkü iki eksiklik iki farklı biçimde arızalanıyor. Kaydı olmayan soruda önüne konan hiçbir şey cevap üretemez ve sessiz kalır. Kuralı olmayan soruda ise sessizlik yok: önüne konabilecek bir kaynak vardır, geçmiş mesajlaşma. Oradan üretilen cevap, o gün mesaja bakan kişinin o günkü uygulamasını taşır.

Bu ayrım bir ürün seçimi değil, bir teşhis. Elinizdeki soru listesini kademelere ayırdığınızda hangi sorunun bugün cevaplanabilir olduğunu, hangisinin önce sistemde bir iş gerektirdiğini görüyorsunuz. Aşağıdaki bölümlerde dört işten örnek var; dördünde de bot yok, dördü de cevabın kaynağının nerede durduğunu gösteriyor.

Cevabın kaynağı kayıt mı, kural mı, karar mı

Bir soruyu botun cevaplayıp cevaplayamayacağını sorunun konusu belirlemiyor. Fiyat sorusu her zaman insana, durum sorusu her zaman makineye gitmiyor. Belirleyen şey cevabın nereden geldiği: bir kayıt alanından, işletmenin yazılı kuralından ya da bir kişinin yargısından.

Çıktısı bir kayıttan okunan adımın müşteriye devredilebileceğini satış öncesi self servis adımları yazısında yazdık. Aynı ürünün içinde onay kapısından geçen ve geçmeyen iki yolun neden yan yana durabildiğini de insan denetimi yazısında anlattık.

Bu yazının eklediği şey ikisinin arasındaki kademe. Cevabı ne bir alan ne bir imza üretiyor; işletmenin kendi kuralı üretiyor. O kural ya sistemde ya bir kişide duruyor ve nerede durduğu botun okuyup okuyamayacağını belirliyor.

Elinizdeki soru listesini üç testle ayırabilirsiniz. Cevabın durduğu alan dolu mu. Cevabı üreten kural sistemde tanımlı mı. Cevabın arkasında bir imza gerekiyor mu. İlk ikisine evet diyen soru okunabilir; üçüncüsüne evet diyen soru okunamaz ve yazının geri kalanı bu üç testin işletmedeki karşılığını anlatıyor.

Bot cevap vermeden önce soruyu bir kayda bağlamak zorunda

Müşteriniz “servisim ne zaman gelecek” diye yazdığında ortada bir cevap yok, bir soru var. Cevabın okunacağı yer, o sorunun hangi kayda bağlandığına göre değişiyor ve bağlama kararı okuma kararından önce geliyor.

Diotek’in sitesinde ziyaretçiden gelen iki talep iki ayrı varlığa bağlanıyor: keşif randevusu mekânı, servis talebi kurulu cihazı merkeze alıyor. Aynı cümleyle sorulmuş bir durum sorusunun kaynağı bu ikisinden yalnız biri oluyor ve hangisi olduğu sorunun kelimelerinden değil, sorunun bağlandığı kayıttan anlaşılıyor. Keşif ile servisin neden aynı formdan geçmediğini randevu ve servis talebi ayrımı yazısında yazdık; burada bizi ilgilendiren tek şey her talebin neye bağlandığı.

AlgoKlima’nın servis yönetiminde garanti, bakım ve arıza kayıtları müşteri kartında değil cihazın altında duruyor. Aynı adreste birden çok cihaz varsa müşteri kartı tek başına “bu cihazın son bakımı ne zaman yapıldı” sorusunu cevaplamıyor. Soru önce hangi cihazdan söz edildiğine bağlanıyor, kayıt sonra okunuyor. Bu bir bot özelliği değil, veri modelinin sonucu; kaydın önüne ne konursa konsun sıra aynı kalıyor. AlgoKlima kendi ürünümüz; işletiyoruz ve geliştirmesi sürüyor. Geçmişin cihazla birlikte taşınmasını çevrimdışı çalışan saha uygulaması yazısında anlattık; buradaki konu yalnız bağlamanın cihaz üzerinden yapılması.

Bağlamanın nasıl kapandığı, kaydın neye bağlı olduğuna göre değişiyor. Müşteriniz hangi kaydı kastettiğini kendisi söylüyorsa soru tek adımda bağlanıyor. Söylemiyorsa geriye tek yol kalıyor: sistemin müşteriye bağlı kayıtlardan seçenekleri çıkarıp sorması. Bu ikinci yol ancak kayıtlar müşteriye bağlıysa mümkün; cihaz kaydı müşteriye bağlı değilse çıkarılacak liste de yok.

Bağlanamayan sorunun cevabı yok, yalnız sorusu var. Müşteriniz hangi cihazı ya da hangi randevuyu kastettiğini söylemediğinde okunacak alan belirsiz kalıyor. Böyle bir soruda kaynağı doğru tek çıktı bir cevap değil, bağlamayı tamamlayan geri sorudur: hangi cihaz, hangi tarih. Bir kaydın önüne konan bot bu geri soruyu sormuyorsa, elindeki kayıtlardan birini kendisi seçmiş olur ve seçimini size söylemez. Cevap doğru görünür, kayıt yanlış cihazın kaydıdır.

Bu adım her müşteride görünmüyor. Tek cihazı ve tek açık talebi olan müşteride soru kendiliğinden bağlanıyor, çünkü seçenek tek. Bağlama ancak aynı müşteri kartının altında birden çok cihaz ya da birden çok açık talep varken bir iş hâline geliyor. Küçük bir müşteri kütüğünde adım hiç görünmeden geçer; kütük büyüdükçe cevabın doğruluğu bu adıma bağlanır.

Kural yazılımda mı, bir kişinin ezberinde mi

Pilatesco’nun randevu yazılımında “iptal ettim, hakkım geri geldi mi” sorusunun cevabı tek bir alandan okunmuyor. İki şeyin birleşiminden çıkıyor: müşteri kaydının üzerinde duran paket bakiyesi ve iptal, gelmeme, tamamlanan dersi bakiyeye farklı işleyen kural. Rezervasyon takvime yazılırken paketten bir ders hakkı düşüyor; hangi durumun hakkı geri verdiği kuralda tanımlı, konuşmada belirlenmiyor. Bakiye müşteri kaydının üzerinde duruyor, ayrı bir deftere yazılmıyor; bu yüzden bakiyeyi okumak için kimseye sormak gerekmiyor.

Bu kademeyi kayıt kademesinden ayıran test kısa: alan dolu ama cevap yok mu. Pilatesco’nun önceki düzeninde rezervasyon takvimde yazılıydı ve iptal yapılmıştı; alanlar doluydu. “Hakkım geri geldi mi” sorusunun cevabı yine de ne takvimde ne bakiyedeydi: kalan ders hakkı takvimin dışında defterde, iptalin ne yapacağı mesajlaşmada duruyordu. Cevabın kaynağı bir alan değildi; o gün mesaja cevap veren kişinin kuralı uygulayışıydı. Kural sisteme yazıldığında kaynak kişiden kayda geçti.

Yazının asıl yükü burada. Kural sistemde değilken bir botun önüne konabilecek tek kaynak geçmiş mesajlaşmadır ve mesajlaşma kuralı taşımaz, o gün verilmiş cevabı taşır. Oradan üretilecek cevap işletmenizin kuralı değil, bir kişinin o günkü uygulaması olur. Kayıt eksikliğinin sonucu sessizliktir; kural eksikliğinin sonucu kaynağı yanlış bir cevaptır. İkincisi daha zor fark edilir, çünkü dışarıdan bakınca sistem çalışıyor görünür: soru cevaplanmıştır, cevabın nereden geldiği görünmez.

AlgoKlima’nın “cihazım garantide mi” sorusu bu kademeye düşmüyor. Garanti kaydı cihazın altında duruyor; soru cihaza bağlandığında cevap doğrudan alandan okunuyor. Cümle olarak “iptal ettim, hakkım geri geldi mi” ile aynı türden bir durum sorusu, kademesi farklı. Ayrımı yapan şey, cevabın hangi yerden geldiği.

Kuralın nerede durduğunu anlamanın pratik bir yolu var. Kuralı uygulayan kişiye sormak yerine, kuralın uygulandığı yerdeki ekrana bakın. İptal düğmesine basıldığında paket bakiyesi sistemde mi düzeliyor, yoksa birinin bakiyeyi elle düzeltmesi mi gerekiyor? Elle düzeltme gerekiyorsa kural sistemde değil, düzeltmeyi yapan kişide duruyor. Bu ayrım bir bot kararından önce gelen ve bot olmasa da işe yarayan bir teşhis.

Kuralın kendi sınırı da var. “Bu seferlik hakkımı geri verir misiniz” sorusu kuralın tanımladığı durumların dışına çıkma isteğidir; kural yazılı olsa bile bu soruyu kural cevaplamaz, bir sonraki kademeye düşer. İkinci sınır bakım tarafında: kural sık değişiyor ve değişikliği sisteme taşıyan kimse yoksa, sistemdeki kural defterdekinden eski kalır ve kaynak sessizce kişiye döner. Kuralı yazmak bir kerelik iş değil; kuralın sahibi belli olmadığında yazılı kural da eskir.

Karar gerektiren soruda bot cevap vermez, doğru talebi açar

Diotek’in sitesinde teklif mekân görülmeden verilmiyor, çünkü cihaz kapasitesi mekâna bağlı. “Şu mekâna hangi cihaz uyar, kaça çıkar” sorusunun cevabı ne bir alanda duruyor ne bir kuraldan türüyor; keşifte üretiliyor. Kapı tam burada: cevabın kaynağı kayıt ya da kuraldan karara döndüğü anda okuma biter.

Kapıdan sonra üretilecek çıktının biçimi asıl konu. “Sizi arayacağız” cümlesi bir çıktı değil, çıktının ertelenmesidir. Diotek’te ziyaretçi cihaz seçmeden önce mekân için bir tarih istiyor ve bu istek keşif randevusu talebi olarak kayda düşüyor; talep montaj sonrası servis kuyruğuna karışmadan kendi akışında operasyona ulaşıyor. Böyle bir akışın önüne konan bir bot cevap üretmez, o kaydı açar. Talep girişi telefon hattına bağlı olmadığı için hat meşgulken ve mesai dışında gelen istek de yazılı kalıyor.

Hat meşgulken açılan kayıt, akşam geri dönülecek bir not değil; kendi tipiyle kuyruğa giren bir taleptir. Ziyaretçi, isteği hiçbir yere yazılmadığı anda kayboluyor.

Talep kaydının taşıdığı şey de belirli. Kayıt hangi tipte açıldığını, hangi mekân ya da cihazla ilgili olduğunu ve isteğin ne zaman geldiğini taşıyor. Bu üçü olmadan kayıt bir mesajdır ve mesaj operasyonda bir kişinin okumasını bekler. Botun kapıdaki değeri cevap vermesinde değil, insanın devraldığı işi eksiksiz devretmesinde.

İmza gerektiren çıktı ekrana devredildiğinde geriye ne kaldığını satış öncesi self servis yazısında anlatmıştık. Buradaki fark, botun o çıktıyı hiç üretmemesi ve yaptığı tek işin talebi açmak olması.

Tahlil.com’un hekim panelinde ön okuma hastaya değil hekime gidiyor. Model bir taslak hazırlıyor, hekim yorumu panelde yazıp onaylıyor, hastaya ulaşan metnin son hâli hekimin elinden çıkıyor. Karar kademesinde botun çıktısı imzayı atacak kişiye gidiyor. Onay kapısının akışın neresinde durduğunu ve bildirimin neden onayla tetiklendiğini insan denetimi yazısında yazdık; buradaki tek konu taslağın kime gittiği.

Yanlış cevap sorusu da kademeye göre ayrışıyor. Kayıt kademesinde yanlış cevap yanlış kayıttır: bot kayıtta ne varsa onu göstermiştir ve düzeltilecek şey kayıttır. Kural kademesinde eksik ya da yanlış yazılmış kuraldır; kural düzeltilince aynı sorunun cevabı da değişir. Karar kademesinde botun hiç cevap vermemesi gerekirdi ve cevap talebi kapatan kişinin cevabıdır. Tahlil.com’da hastaya ulaşan her yorumun sorumluluğu onu onaylayan hekimde kalıyor. Kademeyi bilmek, arıza çıktığında nereye bakılacağını da veriyor.

Kapı sorunun tamamını durdurmuyor. Karar taşıyan bir sorunun bir parçası kayıttan okunabilir: “keşif randevum ne zaman” sorusu, talep açıldıktan sonra kayıt kademesine düşüyor. Kapıda duran şey, sorunun yargı taşıyan parçası.

Hangi soru nereden cevaplanır

Aşağıdaki tablo yeni bir olgu eklemiyor; önceki bölümlerin mekanizmasını dört işin soru tipleri üzerinden yan yana koyuyor. Üçüncü sütun her satırda koşullu okunur: dört projenin hiçbirinde bot yok, sütun o kaynağın önüne bir bot konsaydı neyi okuyabileceğini söylüyor. Satırların hiçbiri bir ürün tarifi değil; her satır o işte cevabın fiilen nerede durduğunu söylüyor.

Tablonun ilk iki satırı cümle olarak birbirine benziyor ve iki ayrı kademeye düşüyor. Sorunun uzunluğu ya da konusu bu ayrımı vermiyor; veren şey cevabın nerede durduğu. Son iki satır da aynı kademede duruyor ama farklı sebeple: birinde karar mekânda, ötekinde imzada veriliyor.

Tabloda dört ayrı iş var ve dördü de aynı soruyu farklı yerden cevaplıyor: cevabın kaynağı, kaydın kurulduğu yere bağlı.

Bot kurmadan önce cevabın kaynağı hazır mı

Bot cevabı üretmiyor, var olan kaynağı okuyor. Bu yüzden sıra tersine çevrilemez: önce kaynak, sonra okuyucu.

Pilatesco’da bir bot kurulmadan önce yapılması gereken iş kuralın yazılıma taşınmasıydı. Kalan ders hakkı defterden müşteri kaydının üzerine, iptalin ne yapacağı mesajlaşmadan kurala geçti. Kural yazılırken karar verilen şey iptalin, gelmemenin ve tamamlanan dersin bakiyede ne yapacağıydı; bu üç durumun ayrı ayrı tanımlanması işin kendisiydi. Bu iş yapılmadan önüne ne konursa konsun “hakkım geri geldi mi” sorusu okunamazdı, çünkü okunacak bir yer yoktu.

Diotek’te yapılması gereken iş talep tiplerinin ayrı kayıtlara ayrılmasıydı; keşif randevusu ile servis talebi baştan iki ayrı akış olarak kuruldu. Karar kademesinde bir botun açacağı talebin tipi, ancak o tipler kayıtta ayrı duruyorsa var. Tip yoksa geriye serbest metin kalıyor ve o metin operasyonda yine telefonla ayıklanıyor. Bir talep kaydının tipi, o talebin hangi kuyruğa düşeceğini ve kimin göreceğini belirliyor; tipsiz kayıt kimseye ait olmuyor.

Üçüncü durum daha temel: sorunun karşılığı kayıtta hiç yok. Bu teşhisi cevapsız kalan müşteri sorusu yazısında dört desenle anlattık; buradaki tek eklenti, o teşhisin bota ne yaptığı. Karşılığı olmayan soruda bot sessiz kalıyor ve sessizlik bir arıza gibi görünmüyor; bu yüzden kimse kaydın nerede tutulduğuna bakmıyor.

Bot cevaplayamıyorsa eksik üç yerden birinde ve üçünün düzeltmesi farklı. Sorunun karşılığı kayıtta yoksa düzeltilecek şey kayıt modelidir. Kural defterde ya da mesajlaşmada yaşıyorsa kuralın yazılması gerekir. Soru yargı taşıyorsa botun açacağı talep tipinin tanımlanması gerekir. Üçünde de düzeltilen şey bot değil kaynak.

Sıralama da önemli. Kayıt modeli düzeltilmeden yazılan kural boşlukta duruyor, çünkü kural okuyacağı alanı bulamıyor. Talep tipi tanımlanmadan açılan kayıt da bir kuyruğa düşmediği için kimsenin işine girmiyor; onay kapısının ve talep tipinin akışta nereye konacağını yapay zekâ danışmanlığında bu yüzden kayıtlarla birlikte konuşuyoruz. Önce sorunun karşılığı olan alan, sonra o alanı yorumlayan kural, en sonunda yargı taşıyan soruların düşeceği talep tipi. Bu sırayı belirleyen şey kayıtlar.

Kaynak hazır olsa bile bot gerekmeyebilir. Sorunun kaynağı bir alansa, o alanı müşteriye göstermenin tek yolu bir sohbet yüzeyi değil; bot, kaynağın önüne konabilecek okuma biçimlerinden yalnız biri. Kaynağı olan her soru bot gerektirmiyor; kaynağı olmayan hiçbir soru botla çözülmüyor.

Müşterilerinizden gelen soruların hangisinin karşılığı bugün bir kayıt alanında duruyor, hangisi bir kişinin ezberinde? Talebi müşteriye, kurulu cihaza ya da bir kurala bağlayan yapıları CRM çalışmalarımızda kuruyoruz.