Bir asistanın gün sonunda kaç mesaja yanıt verdiği, işin gerçekten çözülüp çözülmediğini göstermez. Yanıtlanan mesaj, müşterinin bir cevap aldığını anlatır; çözülen talep ise sorunun ya da ihtiyacın sonuna kadar ilerlediğini gösterir. Bu iki sayıyı ayrı tutmadan yapılan okumalar, ekip için yanıltıcı sonuçlar üretebilir. Aşağıda işletmenin kendi görüşme kayıtlarıyla uygulayabileceği pratik bir ayrım anlatılıyor.
Hacim Neyi Anlatır, Neyi Anlatmaz?
Toplam yanıt sayısı, asistanın kaç mesaja cevap verdiğini gösterir ve kapasite planlaması için faydalıdır. Ancak bu sayı, verilen cevabın doğru olduğunu ya da müşterinin ihtiyacının karşılandığını söylemez. Gece saatlerinde yüz mesaja verilen eksik bir yanıt, hacim açısından başarılı görünürken müşteri için hiçbir şeyi çözmez. Bu yüzden hacim, diğer ölçümlerle birlikte okunmalıdır. Konu bazında daha ayrıntılı bir çerçeve için otel chatbot performans ölçümü sayfasındaki yaklaşımı inceleyebilirsiniz.
Hacim artışı da tek başına bir sonuç değildir. Tekrarlanan soruların, kampanya dönemlerindeki yoğunluğun ya da aynı konuda yeniden yazan müşterilerin bu artışta payı olabilir. Bu durumlar hacmi artırabilir; fakat artışın hangi nedenden kaynaklandığını anlamak için konu bazında ayrı bir döküm gerekir. Hazır bir neden raporu varsaymak yerine, bu dökümü işletmenin kendi görüşme kayıtlarından yapmak daha güvenilir bir başlangıçtır. Böylece tekrar eden soruların kaynak güncellemesi mi yoksa gerçek bir ihtiyaç değişikliği mi olduğu daha net görülür.
Doğru Bilgi İçin Ayrı Bir Kontrol Yapmak
Doğru bilgi ölçümü, asistanın verdiği yanıtın kaynakla uyumlu olup olmadığını kontrol eder. Bunun için örnek görüşmelerden bir kısım seçilir ve yanıt, işletmenin onaylı web sayfası, PDF belgesi ya da soru-cevap kaynağıyla karşılaştırılır. Fiyat, saat, adres veya koşul gibi değişken bilgiler bu kontrolde öncelik almalıdır, çünkü yanlış bir saat müşteriyi doğrudan etkiler. Test senaryolarının nasıl kurulacağı için senaryo test listesi sayfası yardımcı olabilir.
Bu kontrolün sonucu bir yüzde olarak sunulmadan önce örnek boyutu ve seçim yöntemi not edilmelidir. Ekip yalnızca kolay sorularla örnek oluşturursa elde edilen sonuç, zor sorularda da aynı kaliteyi gösteriyormuş gibi okunabilir. Yanlış ya da eskimiş bir kaynak bulunduğunda düzeltme, kaynağı güncellemekle başlar ve aynı soru yeniden test edilir. Bu döngü, yanıt kalitesinin zaman içinde neden değiştiğini izlemeyi kolaylaştırır.
Sonraki Adım Olmadan Çözüm Olmaz
Bir görüşmede doğru bilgi verilmiş olabilir ve yine de talep açık kalmış olabilir. Örneğin müşteri müsaitlik sorar, asistan genel çalışma saatlerini yanıtlar; müsaitlik ise canlı bir kaynaktan doğrulanmadığı için kesinleşmez. Bu durumda yalnızca bilgi yanıtı tamamlanmıştır, talep ise sonraki adımını bekliyordur. Bu iki durumu aynı sonuç gibi saymak, ölçümde çözüm oranını olduğundan yüksek gösterir.
Sonraki adım ölçümünde görüşmenin sonunda ne kaldığı kaydedilir: ekibe devredildi mi, müşteri başka bir kanala geçti mi, yoksa görüşme sessiz bitti mi. Bu alanlar, görüşmenin kapanma biçimini ayırır. Sohbet kapanması tek başına satış ya da çözüm kanıtı değildir. Müşteri yazmayı bıraktığında talebin bittiği varsayılmamalı; açık bir adım varsa bu ayrıca işaretlenmelidir.
Kayıt Şeması Ve Sınıflama Mantığı
Kayıt şemasını küçük tutmak sürdürülebilirlik sağlar. Her görüşme için kanal, konu sınıfı, yanıtın bilgi kaynağıyla uyumu, sonraki adımın durumu ve ekip devrinin yapılıp yapılmadığı alanlarında kayıt tutulabilir. Alanların her biri tek bir soruya cevap vermelidir; böylece bir alanın değeri diğerini gizlemez. Müşteri taleplerinin özetlenmesi ile kayıt sisteminin ayrımı için CRM talep özeti sayfası faydalı bir çerçeve sunar.
Sınıflama için sabit kategoriler belirleyin: bilgi sorusu, talep özeti, kesin işlem gerektiren istek, şikâyet ve kapsam dışı mesaj gibi. Aynı konuşmada birden fazla konu varsa en çok etkilenen talebe göre bir not düşülür ve ikinci konu ayrıca işaretlenir. Kategorilerin tanımı yazılı olmalıdır; kişiden kişiye değişen yorumlar ölçümü bozar. Yeni bir kategori eklenecekse, mevcut kayıtların geriye dönük olarak nasıl sınıflandırılacağı da kararlaştırılmalıdır.
Ekip Çözümü Ve Bildirim Ayrımı
Yeni bir görüşme bildirimi geldiğinde ekip bunu çözüm olarak okumamalıdır. Bildirim, konuşmanın dikkat istediğini gösterir; işin çözüldüğü ya da bir personelin atandığı anlamına gelmez. Web ve WhatsApp konuşmalarında push bildirimi cihaz izni ve abonelik ile çalışır, e-posta bildirimi ise ayrı ayarlanır. Bu ayarlar eksikse ekip konuşmayı geç görebilir ve ölçümde bu gecikme yanıtsızlık gibi görünebilir. Bildirim akışının takibi için sohbet bildirimi takibi sayfasına bakabilirsiniz.
Ekip çözümünü ölçmek için devralınan görüşmeler ile personel tarafından kapatılan talepler ayrı izlenir. Panelde görüşme ve özetler incelenebilir; ancak bu, çözümün otomatik olarak raporlandığı anlamına gelmez. Vardiya değişiminde açık kalan konuşmalar için sahip kişi ve son işlem tarihi kayda eklenmelidir. Böylece bir görüşmenin neden uzun süre açık kaldığı, kayıt üzerinden geriye dönük olarak izlenebilir.
Ölçüm Planını Kurulumdan Önce Yazmak
Ölçüm planı ilk yayından önce yazılmalı ve kapsamı net olmalıdır. Hangi kanalın, hangi konu sınıfının ve hangi dönemin kapsanacağı baştan belirlenir. Kaynak uyumu kontrolünü kimin yapacağı, örnek boyutunun ne olacağı ve sonuçların hangi aralıkla gözden geçirileceği de plana eklenmelidir. Bu hazırlık yapılmadan elde edilen rakamlar, sonradan karşılaştırılabilir bir temel oluşturmaz.
Kontrol grubu olmadan elde edilen değişimler nedensel bir başarı kanıtı sayılmaz. Yeni bir kaynak eklenmesi ya da talimat değişikliği sonrasında görülen farkın, mevsim, kampanya veya kanal değişimi gibi etkenlerden ayrılması gerekir. Bu nedenle plan, değişim sonuçlarını kesin oranlar olarak değil, izlenecek bir yön olarak yorumlamalıdır. Değişikliklerin tarihli notlarla tutulması, sonradan neyin neyi etkilediğini tartışmayı kolaylaştırır.
Ölçüm Alanlarını Ayırmak
| Ölçüm alanı | Sorduğu soru | Örnek kayıt |
|---|---|---|
| Yanıtlanan mesaj | Asistan bu mesaja cevap verdi mi? | Kanal ve konu sınıfı |
| Doğru bilgi | Yanıt onaylı kaynakla uyumlu mu? | Kaynak uyum notu |
| Sonraki adım | Talep bilgi, devir ya da işlem bekliyor mu? | Adım durumu alanı |
| Ekip çözümü | Personel talebi kapattı mı? | Devralma ve kapanış tarihi |
Tüm sütunları görmek için tabloyu yana kaydırın.
Temsili Konuşma Örneği
Aşağıdaki konuşma TEMSİLİDİR; gerçek bir müşteri görüşmesi değildir ve herhangi bir işletmenin kaydı değildir.
Müşteri: Bu hafta sonu ofis açık mı? Ayrıca rezervasyonumu bugün kesinleştirebilir misiniz?
Asistan: Hafta sonu çalışma saatlerini web sitemizdeki güncel bilgiye göre paylaşabilirim. Rezervasyonu kesinleştirmek için canlı müsaitlik kontrolü gerekir; bu bilgiye erişimim olmadığı için talebinizi ekibe iletmeniz gerekir.
Müşteri: Tamam, lütfen iletin. Ne zaman dönüş olur?
Asistan: Ekibin dönüş süresi için kesin bir zaman veremem. Bu görüşme, bilgi yanıtı verildi ve sonraki adım açık olarak ayrı kaydedilebilir şekilde işaretlenebilir.
Uygulama Adımları
- Yanıtlanan mesajı, doğru bilgi ve çözüm için ayrı alanlarda ölçün.
- Kayıt alanlarını birkaç net alanla sınırlandırın ve her alan için değer listesi yazın.
- Örnek görüşmeleri onaylı kaynakla karşılaştırın ve örnek seçim yöntemini not edin.
- Görüşmenin sonunda sonraki adımın durumunu işaretleyin: bilgi tamam, devir bekliyor veya işlem gerekli.
- Bildirim izni ve e-posta ayarlarını kontrol edin, gecikmeyi ölçüme dahil edin.
- Ekip devrini ve bekleyen görüşmelerin sahibini kayıt altına alın.
- Kaynak ve talimat değişikliklerini tarihli not edin; sonuçları kontrol grubu olmadan nedensel başarı olarak yorumlamayın.
Yanıtlanan mesaj, asistanın çalıştığını gösterir; çözülen talep ise işin gerçekten ilerlediğini gösterir. İkisini aynı sayıya indirmek, ekibin yanlış öncelik almasına yol açabilir. Net bir kayıt şeması ve dürüst bir sonraki adım takibiyle, hangi sorunun asistanda, hangisinin ekipte kaldığını daha sağlıklı görebilirsiniz. Kanallarınızı ve ölçüm ihtiyacınızı paylaşmak için iletişim sayfasından ulaşabilirsiniz.
