Destek taleplerini mesajlaşma kanallarından ortak sıraya taşımak

Örnek bir iş senaryosu

Bir müşteri aynı sorunu önce telefonla, sonra e-postayla bildirirse iki kişi birbirinden habersiz çalışabilir. Mükerrer talepleri ilişkilendirmek, asıl kaydı belirlemek ve iletişim geçmişini birleştirmek gerekir. Buna karşılık benzer açıklamaya sahip iki farklı sorunu yanlışlıkla tekleştirmemek için ürün, tarih ve müşteri bağlamı kontrol edilmelidir.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Destek ekibinin çalışma görünümünde yeni, üzerinde çalışılan ve dış yanıt bekleyen talepler ayrılmalıdır. Bekleme nedeni olmadan “bekliyor” durumu kullanmak işin neden ilerlemediğini gizler. Müşteriden bilgi istendiğinde hangi bilginin beklendiği ve son iletişim tarihi kaydedilmelidir. İç notlar yanlışlıkla müşteriye gönderilmemelidir; arayüz bu iki alanı belirgin ayırmalıdır. Talep başka ekibe devredilirken kısa bir çözüm denemeleri özeti eklenmesi tekrar işi azaltır. Kapanan taleplerden sık kullanılan çözümler bilgi tabanına aktarılabilir, ancak müşteri kimliği ve özel ayrıntılar temizlenmelidir. Böylece destek sistemi yalnızca kuyruk değil, kurumsal öğrenme kaynağı haline gelir.

Ekiple yapılacak günlük iş akışı denemesi

Bir haftalık gerçek iş düzeninden temsili birkaç kayıt seçin. Yeni talep, değişiklik, iptal ve tamamlanma içeren örnekler kullanın. Her kaydın kim tarafından açıldığını, kime devredildiğini ve hangi bilgiyle kapatıldığını yazın. Aynı işi farklı kişilerin farklı yöntemlerle yürüttüğü noktaları belirleyin. Her fark sorun değildir; bazıları işin koşullarından kaynaklanır. Ancak ortak bilgi ve sorumluluk gerektiren adımlar standartlaştırılmalıdır. Pilot uygulamada bu adımları görünür hale getirin. Kullanıcıların işini tamamlamak için başka defter veya mesajlaşma grubuna neden ihtiyaç duyduğunu anlamaya çalışın.

Durum adlarını ekibin anlayacağı biçimde seçin. “İşlemde” gibi geniş bir ifade yerine hangi aşamanın sürdüğünü anlatan durumlar daha yararlı olabilir. Ancak çok fazla durum da günlük kullanımı zorlaştırır. Her durumun başlangıç ve bitiş koşulu belirlenmelidir. Bir kayıt bekliyorsa beklediği kişi veya bilgi görünür olsun. Otomatik bildirimler bu durumlardan üretiliyorsa yanlış veya eski bildirimlerin nasıl durdurulacağı test edilmelidir. Personel değiştiğinde açık kayıtların devri de senaryoya dahil edilmelidir. Sahipsiz işlerin ayrı görünmesi unutulmalarını azaltır.

İlk değerlendirmede yalnızca tamamlanan kayıt sayısını ölçmeyin. Tekrar açılan işler, eksik bilgi nedeniyle beklemeler ve sistem dışında yürütülen adımlar da önemlidir. Kullanıcının yaptığı düzeltmeler uygulamanın nerede zorlandığını gösterebilir. Eğitim ihtiyacı ile tasarım sorununu birbirinden ayırmak için kullanıcıyı gerçek görev sırasında gözleyin. Rol ve veri erişimi de günlük işin parçası olarak kontrol edilmelidir. Herkesin bütün verileri görmesi kolay başlangıç gibi görünse de gereksiz erişim yaratır. İşin gerektirdiği bilgiyle sınırlı, anlaşılır bir çalışma alanı hem öğrenmeyi hem de sorumluluk takibini kolaylaştırır.

Ekibinize sorabileceğiniz sorular

• Atanmamış talep var mı?
• Aynı sorun yeniden açılıyor mu?
• Müşteri son durumu anlayabiliyor mu?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.