İnsan devri: pilotun sonunda değil, başında verilecek karar

Bir sesli yapay zekâ pilotunda ilk gösterim çoğu zaman aynı yerden başlar: müşteri konuşur, asistan yanıt verir, görüşme akıcı biçimde ilerler. Peki istek belirsizleştiğinde ne olur? Talep tanımlı kapsamın dışına çıktığında dosyayı kim alır? Sistem bir işlem yaptıktan sonra yanıt vermezse müşteri ne duyar?

Bu sorular istisna gibi görünür. Oysa günlük operasyonu ayakta tutan sınırları tarif eder. İnsan devrini baştan tasarlamak, otomasyonun nerede işe yarayacağını da daha açık hale getirir.

Önce hangi işin tamamlanacağını belirleyin

“Müşteriye yardımcı olmak” bir amaçtır. “Talebi doğru destek kuyruğuna, gerekli bilgiler ve bir sorumluyla kaydetmek” ise kontrol edilebilir bir sonuçtur. Pilotun sonunda hangi kaydın oluşacağını bilmiyorsanız, neyin insana devredilmesi gerektiğini de net tanımlayamazsınız.

Bir randevu akışında müşteri tercihinin alınması, uygunluğun doğrulanması ve randevunun kaynak takvime yazılması ayrı aşamalardır. Her aşama için beklenen kanıtı belirleyin. Bir sonraki adıma ancak öncekinin sonucu yeterince açık olduğunda geçin.

Devri başlatacak koşulları yazın

Müşteri talebi yeterince anlaşılmadığında önce açıklayıcı bir soru gerekebilir. Ancak her sorun bir soru daha sorarak çözülmez. Kapsam dışı istekler, hassas durumlar veya etkisi yüksek bir karar, tanımlı insan yoluna gitmelidir.

Bu sınırları operasyon ekibiyle birlikte yazın. “Gerekirse aktar” yerine, hangi koşulun hangi ekibi devreye sokacağını belirtin. Alıcı ekibin çalışma saatlerini, beklenen dönüş süresini ve ulaşılamadığında uygulanacak adımı da kararlaştırın. Teknik olarak aktarım başlatılması, birinin sorumluluğu aldığı anlamına gelmez.

Görüşmeyi değil, bağlamı da aktarın

İyi bir devir müşterinin aynı hikâyeyi yeniden anlatma ihtiyacını azaltır. Alıcı kişi müşterinin talebini, doğrulanan bilgileri, yapılan kontrolleri ve açık kalan işi görebilmelidir. Ham bir konuşma dökümü tek başına bu ihtiyacı karşılamayabilir.

Kısa bir devir kaydı şu dört soruya yanıt vermeli: Müşteri ne istiyor? Şimdiye kadar ne yapıldı? Hangi bilgi veya işlem doğrulanamadı? Dosyayı kim, hangi sonraki adımla devralacak? Gereksiz kişisel ayrıntıları bu kayda taşımayın; yalnız işi sürdürecek bağlamı tutun.

Sonucu belirsiz işlemi tekrar etmeyin

Bir takvim veya destek sistemi yanıt vermediğinde iki farklı durum olabilir: işlem hiç gerçekleşmemiştir ya da gerçekleşmiş, fakat yanıt geri gelmemiştir. Bunları aynı hata olarak ele almak ikinci bir randevuya veya mükerrer kayda yol açabilir.

Bu nedenle akış, belirsiz sonucu mevcut kayıt veya işlem makbuzu üzerinden uzlaştırabilmelidir. Müşteriye doğrulanmamış başarı söylenmemeli; açık iş bir sorumlu ve takip zamanı ile görünür kalmalıdır. Aynı anda, bu belirsizlikten etkilenmeyen temiz talepler kendi kurallarıyla ilerleyebilir.

Pilotu yalnız kolay senaryoyla test etmeyin

Net talebin yanında eksik bilgi, çelişkili kayıt, uygun olmayan saat, kapsam dışı istek ve ulaşılamayan alıcı ekip gibi örnekler kullanın. İlk testleri gerçek müşteri verisi gerektirmeyen sentetik girdilerle yapın. Her örneğin beklenen sonucunu önceden yazın; çıkan gerçek sonucu ayrı kaydedin.

Bir erişim testi veya düzgün konuşma, bütün iş akışını doğrulamaz. Randevunun doğru takvimde oluştuğunu, destek kaydının doğru kuyruğa gittiğini ve devrin gerçekten kabul edildiğini kendi kaynaklarında kontrol edin.

Bir sonraki toplantıda kullanılacak kısa kontrol

• Bu akış hangi talebi tamamlayacak, hangilerini dışarıda bırakacak?
• İnsan devrini hangi somut koşul başlatacak?
• Alıcı ekip hangi bağlamı görecek?
• Ekip ulaşılamazsa sorumlu ve sonraki tarih kimde kalacak?
• Başarıyı hangi kaynak kayıtla doğrulayacağız?

Qfix’in mevcut pilot çerçevesi, tek bir akışın beklenen sonucunu, insan devri sınırını, sistem bağlantısını ve kontrol görünümünü birlikte tanımlamayı önerir. Belirli bir projede hangi işlemlerin kullanılabildiği, o projenin bağlantıları ve kabul edilmiş iş kurallarıyla ayrıca doğrulanmalıdır.

Kaynaklar: Qfix pilot çerçevesi, Qfix platformu, randevu akışı.