Service Blueprint Pratikte: Şeritler, Kör Noktalar, Bakım Maliyeti
Service blueprint, bir hizmetin müşteriye görünen yüzüyle arkada dönen işleri aynı zaman ekseninde yan yana koyan şema. Journey map müşterinin yaşadığını anlatır, blueprint o deneyimi üreten mekanizmayı da gösterir. Asıl değeri de burada: kullanıcının üç gün beklediği adımın arkasında hangi ekibin, hangi sistemin, hangi manuel onayın durduğunu görünür kılıyor.
Şemanın anatomisi: dört şerit, iki çizgi
Klasik blueprint yatay şeritlerden oluşur ve sıra tesadüfi değildir:
- Fiziksel kanıt: kullanıcının gördüğü somut şey. Ekran, e-posta, fatura, paket.
- Kullanıcı adımları: yolculuğun kendisi, kullanıcının yaptıkları.
- Sahne önü: kullanıcının doğrudan temas ettiği kişi ya da arayüz.
- Sahne arkası: aynı anda arkada olan işler. Operasyon ekibi, servis çağrıları, onay adımları.
- Destek süreçleri: hizmete dolaylı bakan altyapı. Ödeme sağlayıcı, kargo entegrasyonu, veri tabanı.
Şeritlerin arasındaki iki yatay çizgi şemanın asıl bilgisini taşır. Etkileşim çizgisi kullanıcının temas ettiği yeri işaretler. Görünürlük çizgisi ise kullanıcının artık hiçbir şey göremediği sınırı. Bu ikinci çizginin altında kalan her gecikme, kullanıcı tarafında yalnızca sessizlik olarak görünür. Şemayı çizip de görünürlük çizgisini koymazsan elinde biraz kalabalık bir akış diyagramı kalır.
Ne zaman çizilir
Blueprint'i araştırma öncesinde doldurmam. Elde tek bir kullanıcı görüşmesi, tek bir destek kaydı yokken çizilen şema hizmetin resmi olmuyor, ekibin hizmet hakkındaki varsayımlarının resmi oluyor, üstelik duvara asıldığı andan itibaren tartışılmaz hale geliyor.
İşe yaradığı iki an var. Birincisi, araştırma verisi elde toplandıktan sonra dağınık bulguları tek yere yerleştirirken. İkincisi, yol haritası yapılırken: iki farklı ekibin aynı adımı farklı sandığı yerler ancak şeritler alt alta gelince ortaya çıkıyor.
Mutlu yolun dışında kalanlar
Çizilen blueprint'lerin büyük çoğunluğu başarılı senaryoyu anlatır. Kullanıcı gelir, seçer, öder, teslim alır. Peki ödeme reddedilirse? Adres yanlış girilmişse? Kullanıcı iade etmek isterse, hem de kutuyu attıktan sonra?
Bu senaryolar hizmetin istisnası değil, hacminin belirgin bir kısmı. Ve gerçek acı da orada yaşanıyor, çünkü mutlu yol zaten test edilmiş durumda. Aynı yolculuğu ikinci kez, tek bir hata durumu için çizmeyi denemeye değer. Genelde ikinci şema birincisinden kısa çıkar ama içinde sahipsiz adım daha fazla olur.
Sahne arkasında sahibi olmayan adım
Sahne arkası şeridini doldururken her kutunun karşılığını sormak gerekiyor: bu adımı hangi servis yapıyor, hangi ekip sahipleniyor, çağrı nereye gidiyor? Cevabı "birisi bakıyor" olan kutular şemanın en değerli yerleri. Çünkü bunlar genellikle bir kişinin sabah e-postalarını açıp elle yaptığı, hafta sonu hiç dönmeyen, izlenmeyen, uyarı üretmeyen adımlar.
Kullanıcı tarafındaki karşılığı ise şu oluyor: cuma akşamı verilen sipariş pazartesiye kadar hiçbir durum değiştirmiyor. Arayüzde ekleyebileceğin en dürüst şey de bu noktada bir ilerleme çubuğu değil, gerçek bekleme süresini söyleyen bir cümle. Şema, tasarım ekibine "buraya bir mikro etkileşim koyalım" dedirtmek yerine "burada bekleme gerçek, önce onu kısaltalım" dedirtiyorsa işini yapmış demektir.
Canlı belge iddiası ve bakımı
Herkes blueprint'in güncel tutulması gerektiğini söylüyor, pek azı üç ay sonra güncelliyor. Sebebi niyet eksikliği değil, maliyet. Şemanın bakım yükü kutu sayısıyla birlikte artıyor: her yeni temas noktası beş şeridi birden etkiliyor, hizmetin küçük bir değişikliği şemanın birkaç yerinde düzeltme gerektiriyor. Yani "mümkün olan en fazla disiplini dahil et, olabildiğince detaylandır" tavsiyesiyle "canlı tut" tavsiyesi aynı anda uygulanamıyor.
Pratikte çalışan çözüm, kapsamı daraltmak. Bütün hizmeti tek şemada anlatmak yerine tek bir yolculuk seç, onu güncel tut. Bir de belgenin adını taşıyan bir sahibi olsun; sahipsiz şema üç hafta içinde arşiv dosyası oluyor. Güncelleme anını da takvime değil olaya bağla: yeni bir entegrasyon devreye alındığında ya da destek tarafında yeni bir şikayet kalıbı belirdiğinde aç, düzelt.