Faz 2 · 2.1
Müşteri Yolculuğunu Haritalama
Bir projeye başlamadan önce, müşterinin bugün o süreci nasıl yaşadığını uçtan uca çizin: ilk temas noktasından (arama, WhatsApp, web) sonuca kadar hangi adımlardan geçiyor, hangi noktada bekliyor, hangi noktada bir insana devrediliyor?
Bu haritalama çalıştayı genellikle ekiplerin kendi süreçlerini ilk kez bütünsel gördüğü an olur. Bunun bir nedeni var: her ekip süreci kendi ölçtüğü metrikten görür. Müşteri hizmetleri ortalama görüşme süresine bakar, operasyon çağrı hacmine, IT sistem çalışma süresine. Müşteri hizmetleri "bekleme süresi uzun" der, operasyon "çağrı hacmi yüksek" der, IT "entegrasyon karmaşık" der. Bunlar aslında aynı sürecin farklı belirtileri, ama üç ayrı ekip birbirinden habersiz üç ayrı şikâyet olarak taşır. Süreci tek bir zaman çizelgesinde yan yana koyduğunuzda, üç ekibin de aslında aynı süreçten bahsettiği ortaya çıkar; sadece her biri farklı bir parçasını görüyordur.
Bu aşamanın amacı analiz değil, kayıttır. Nerenin sorunlu olduğuna henüz karar vermiyorsunuz, sadece süreci olduğu gibi, tarafsızca çiziyorsunuz. Somut bir örnek: bir bankanın "kart blokajını kaldırma" süreci haritalandığında ortaya böyle bir tablo çıkabilir:
| Adım | Kanal | Süre | Sistem |
|---|---|---|---|
| Arama | IVR | 45 sn | Santral |
| Kimlik doğrulama | İnsan temsilci | 90 sn | CRM |
| Blokaj nedeni sorgulama | İnsan temsilci | 60 sn | Kart yönetim sistemi |
| Blokaj kaldırma onayı | İnsan temsilci | 30 sn | Kart yönetim sistemi |
| Teyit | SMS | Anlık | SMS gateway |
Bu tablo tek başına bir yargı taşımaz, sadece süreci görünür kılar. Ama bu görünürlük bile genelde yeterince şaşırtıcıdır: ekiplerin çoğu, kendi sürecinin bu kadar çok adımdan oluştuğunu ya da bu kadar farklı sistemi kapsadığını yazılı görmemiştir.
Çalıştay formatı (öneri): Müşteri hizmetleri, operasyon, IT ve uyum ekiplerinden birer temsilci, 2-3 saatlik bir oturumda mevcut süreci adım adım çizer. Her adım için dört soru sorulur: bu adımda ne oluyor, hangi kanalda, ne kadar sürüyor, hangi sistem kullanılıyor. Çıktı bir akış diyagramı değil; her adımın bu dört soruya cevap verdiği bir dokümandır. Bu doküman, sonraki fazın (sıkışma noktalarını belirleme) ham malzemesi olur.
Sık yapılan iki hata var. Birincisi, haritalamayı sadece IT ekibiyle yapmak. IT süreci sistemler üzerinden görür, sistemin ne yaptığını bilir ama müşterinin nerede sabırsızlandığını bilmez. Süreç sahibi olan ekipler (müşteri hizmetleri, operasyon) katılmadan çizilen bir harita, teknik açıdan doğru ama gerçeklikten kopuk olur. İkincisi, "olması gereken" süreci haritalamak, gerçekte olanı değil. Prosedür dokümanında yazan akışla temsilcinin fiilen yaptığı iş çoğu zaman farklıdır; temsilciler, sistemin eksik kaldığı yerlerde kendi geçici çözümlerini geliştirir. Haritalama bu geçici çözümleri de görünür kılmalıdır, yoksa asıl sorun haritada hiç görünmez.