Servis Tasarımı: Frontstage, Backstage ve Blueprint Çizgileri

Servis tasarımının sözlüğü küçüktür: frontstage, backstage, temas noktası, bir de haritayı katmanlara bölen birkaç çizgi. Zor olan terimleri ezberlemek değil, hizmetin hangi parçasının müşteriye görüneceğine bilerek karar vermek. Aşağıda bu kararı verirken kullanılan kavramlar ve blueprint çizgilerinin sık karıştırılan tanımları var.

Sahne ve arka plan

Metafor tiyatrodan geliyor. Frontstage, müşterinin gördüğü ve dokunduğu her şey: vezne görevlisiyle konuşma, web sitesindeki form, çağrı merkezindeki bekleme müziği. Backstage ise aynı hizmeti ayakta tutan ama görünmeyen kısım: entegrasyonlar, onay akışları, destek ekibinin arka ofiste çözdüğü iş.

Ayrımın pratik değeri şu: frontstage'de yaşanan sorunların çoğu backstage'de doğar. Müşteri "sistem çok yavaş" der, gerçekte yavaş olan bir tedarikçi API'sidir. Sahnedeki belirtiyi düzeltmeye çalışmak yerine haritada belirtinin kaynağına kadar inebilmek için bu iki katmanı ayrı çizersiniz.

Blueprint'in çizgileri ve sık yapılan karışıklık

Servis blueprint'i satırlara bölünmüş bir haritadır ve satırları birbirinden çizgiler ayırır. Üçü standarttır:

• Etkileşim çizgisi (line of interaction): müşterinin eylemleri ile onunla doğrudan temas eden personelin eylemleri arasındadır. Bu çizgiyi her kesen ok bir temas noktasıdır.
• Görünürlük çizgisi (line of visibility): temas personelinin müşteriye görünen işi ile görünmeyen işi arasındadır.
• İç etkileşim çizgisi (line of internal interaction): temas personeli ile onlara hizmet veren destek süreçleri arasındadır.

Karışıklık genelde ilk ve üçüncü çizgide çıkar. "Etkileşim çizgisi personel ile arka plan arasındaki sınırdır" cümlesini çok göreceksiniz; bu aslında iç etkileşim çizgisinin tanımı. Fark ufak görünür ama haritayı bozar: etkileşim çizgisini yanlış yere koyarsanız temas noktalarınızı sayamazsınız, çünkü temas noktası tam olarak o çizgiyi kesen ok demektir. Bazı varyantlar destek süreçleriyle yönetsel planlamayı ayıran dördüncü bir çizgi (line of implementation) da ekler; işletme büyükse işe yarar, küçük ekipte gereksiz katman olur.

Görünürlük bir keşif değil, karar

Görünürlük çizgisi mevcut durumu kaydetmek için değil, taşımak için vardır. Kargo takip ekranı bunun en bilinen örneği: yıllarca backstage olan depo hareketleri bilinçli olarak sahneye çıkarıldı ve "nerede kaldı" çağrıları düştü. Ters yönü de geçerli, eczanede stok sorgusunun hangi tedarikçiye gittiğini müşteriye göstermenin bir faydası yok.

Karar verirken tek soru: bu bilgi müşterinin davranışını değiştirir mi? Değiştirmiyorsa çizginin altında kalsın.

Buna teknik bir sınır eklerim. Frontstage'deki bir ekranı, backstage'de yavaş veya güvenilmez çalışan bir servise senkron bağlamam. Görünür kılacaksanız o veriyi önceden hazırlanmış halde, düşen servis durumunda son bilinen değeri gösterecek şekilde verin; aksi halde şeffaflık diye eklediğiniz kutu, hizmetin en sık bozulan yeri olur.

Kudoz: haritanın dijital olmayan yarısı

Kudoz, öğrenme deneyimlerini ihtiyaç sahibi bireylerle eşleştiren bir platform. İlginç tarafı, deneyimin çoğunun uygulamanın dışında geçmesi: gönüllülerin bulunması, güvenlik kontrolleri, yüz yüze bilgilendirme, etkinlik sonrası takip. Ekran akışı sadece kesişme noktası.

Buradan çıkan pratik kural, blueprint'i ürünün başladığı yerden değil, kullanıcının ihtiyacının doğduğu yerden başlatmak. Ayrıca birden fazla kullanıcı grubu varsa (Kudoz'da katılımcı, gönüllü, koordinatör) her biri için ayrı satır açın; tek bir "kullanıcı" satırında birleştirmek, grupların çelişen ihtiyaçlarını görünmez yapar.

Nereden başlanır

Bir toplantı, bir duvar, bir tek hizmet yolculuğu. Müşteri eylemlerini soldan sağa sırayla yazın, üstüne temas noktalarını, altına o anda arkada ne çalıştığını ekleyin. Bilmediğiniz kutular çıkacak; en değerli çıktı zaten o kutular, çünkü sahiplenilmemiş adımları gösterirler. Tamamını modellemeye çalışmayın, ilk turda tek yolculuk yeter.