5.9 Desain layanan

Tinjauan dan motivasi

Desain layanan adalah praktik membentuk seluruh layanan yang dialami seseorang, lintas setiap kanal dan sepanjang rentang waktu penuh, alih-alih satu layar atau aplikasi. Ketika seseorang memperpanjang paspor, membuka rekening bank, atau melaporkan lampu jalan rusak, mereka tidak mengalami produk Anda. Mereka mengalami layanan: panggilan telepon, situs web, surat di pos, antrean, email yang tak pernah tiba, petugas kasus yang harus mengetik ulang data mereka ke sistem yang tidak dapat melihat apa yang sudah diketahui situs web. Bab 5.1 membahas kerajinan merancang antarmuka individual. Desain layanan memperbesar jarak pandang ke seluruh perjalanan dan ke segala yang di balik meja yang membuat bagian depan meja berfungsi.

Pembedaan “di balik meja” itu inti persoalan. Desain layanan membagi dunia menjadi panggung depan (front-stage), yakni segala yang dilihat dan disentuh pengguna, dan panggung belakang (back-stage), yakni orang, sistem, dan proses yang menyampaikan layanan tetapi tak terlihat oleh pengguna. Pengalaman panggung depan yang baik gagal sepanjang waktu karena panggung belakang tak dapat mendukungnya. Formulir pemesanan mengilap yang tumpah ke spreadsheet yang diperiksa petugas dua kali sehari adalah panggung depan cepat yang ditempelkan pada panggung belakang lambat, dan pengguna merasakan ketidakcocokan itu sebagai keheningan tiga hari. Merancang seluruh layanan berarti merancang kedua separuh bersama, dan sambungan di antaranya.

Bagi tim besar ini tak terhindarkan masalah organisasi. Layanan hampir selalu mencakup beberapa tim, departemen, dan sistem, dan batas antara pemilik itu persis tempat pengalaman pengguna berantakan. Dalam pengaturan enterprise, satu perjalanan pelanggan dapat melintasi penjualan, penyediaan, penagihan, dan dukungan, masing-masing dengan perkakas dan target sendiri dan tak satu pun bertanggung jawab atas keseluruhan. Di pemerintah taruhannya lebih tinggi lagi: orang yang menghadapi peristiwa hidup seperti kematian orang terdekat atau bayi baru harus menavigasi selusin lembaga terpisah, masing-masing meminta bukti yang sama, karena layanan diorganisasi di sekitar struktur pemerintah alih-alih kebutuhan orang. Desain layanan adalah cara Anda membuat seluruhnya menyatu untuk manusia di pusatnya.

Prinsip utama

Rancang seluruh layanan lintas kanal dan waktu, bukan satu layar. Pengguna tidak peduli di mana batas tim Anda.
Panggung depan dan panggung belakang adalah satu sistem. Pengalaman hanya sebaik yang dapat ditopang operasi di baliknya.
Bagan organisasi muncul dalam layanan. Jika tim tersilo, layanan akan terasa tersilo, jadi desain tim dan desain layanan harus bergerak bersama.
Serah terima antarkanal dan antartim adalah tempat layanan patah. Rancang sambungan sama sengajanya dengan langkah.
Perkakas yang dihadapi staf adalah bagian layanan. Agen yang frustrasi dengan konsol buruk menghasilkan pelanggan yang frustrasi.
Ukur layanan dari ujung ke ujung, dari niat pertama pengguna sampai hasil nyata mereka, bukan metrik lokal satu kanal.
Organisasikan di sekitar tujuan pengguna atau peristiwa hidup, bukan departemen internal Anda.

Rekomendasi

Petakan perjalanan pelanggan lintas setiap kanal

Mulai dengan memetakan perjalanan sebenarnya yang ditempuh seseorang menuju hasil, sebagai bagian dari pengalaman pelanggan yang lebih luas. Peta perjalanan menata tahap-tahap yang dilalui pengguna, dari pertama menyadari kebutuhan hingga mencapai tujuan dan sesudahnya, dan mencatat pada setiap tahap apa yang ingin mereka lakukan, apa yang mereka pikirkan dan rasakan, dan di kanal mana mereka berada. Nilainya datang dari mencakup kanal: kebanyakan perjalanan nyata melompat antara situs web, saluran telepon, email, aplikasi, dan lokasi fisik, dan rasa sakit terburuk hidup di celah antarkanal itu, di mana konteks hilang dan pengguna harus mulai dari awal. Tambatkan peta pada riset (bab 5.8) alih-alih asumsi Anda, karena perjalanan yang Anda bayangkan dan perjalanan yang benar-benar ditempuh orang jarang sama. Tandai “momen yang penting,” beberapa titik di mana pengalaman menentukan berhasil atau gagal, dan pusatkan upaya Anda di sana alih-alih menyebarnya rata. Perjalanan yang tampak mulus pada satu kanal mana pun masih bisa menyengsarakan dari ujung ke ujung, dan hanya pandangan lintas kanal yang mengungkapnya.

Bangun service blueprint yang menghubungkan panggung depan dengan panggung belakang

Artefak inti disiplin ini adalah service blueprint. Di mana peta perjalanan mengambil sudut pandang pengguna, blueprint menambah lapisan di bawahnya. Blueprint tipikal berjalan dalam swimlane horizontal: tindakan pelanggan di bagian atas, lalu titik sentuh panggung depan yang berinteraksi dengannya, lalu “garis visibilitas” di bawahnya tempat tindakan panggung belakang yang diambil staf, dan terakhir sistem dukungan dan proses yang memungkinkan segala di atasnya. Baca satu kolom dari atas ke bawah dan Anda dapat melihat persis apa yang harus terjadi di balik layar agar satu momen panggung depan berfungsi, dan di mana ia akan patah jika sistem lambat atau serah terima kabur. Blueprint adalah tempat Anda menemukan kegagalan senyap: pengetikan ulang manual, pekerjaan batch semalam, tim yang tidak tahu ia adalah dependensi. Gambar bersama staf operasional yang benar-benar menjalankan panggung belakang, bukan hanya desainer, karena staf itu tahu di mana pekerjaan nyata terjadi. Blueprint yang hanya menunjukkan jalur bahagia adalah dekorasi; blueprint-kan jalur kegagalan dan pemulihan juga.

Rancang panggung belakang dan perkakas yang dihadapi staf sebagai kelas satu

Perlakukan perkakas yang dipakai staf Anda sebagai bagian produk, karena bagi pelanggan itu memang demikian. Ketika agen pusat panggilan, petugas kasus, atau pemilih gudang bergumul dengan konsol internal yang lambat, jelek, dan setengah rusak, gesekan itu diteruskan langsung kepada orang yang mereka layani, sebagai tunggu lebih lama, jawaban salah, dan frustrasi yang terlihat. Perkakas internal kronis kurang didanai justru karena penggunanya terikat dan tak bisa pergi, itulah persis mengapa bab 5.1 memperingatkan bahwa perangkat lunak pengguna terikat dibayar dalam galat dan produktivitas hilang alih-alih churn. Beri sistem yang dihadapi staf riset, desain, dan standar kualitas yang sama dengan yang Anda beri pada yang menghadap pelanggan. Beri perhatian khusus pada serah terima, momen ketika kasus berpindah dari satu tim, sistem, atau kanal ke yang lain, karena serah terima yang jatuh tak terlihat oleh siapa pun kecuali pengguna yang menunggu. Rancang apa yang dilihat sisi penerima, konteks apa yang ikut bersama kasus, dan apa yang terjadi ketika serah terima gagal.

Selaraskan desain tim dengan desain layanan

Harapkan bagan organisasi muncul dalam layanan. Inilah hukum Conway, pengamatan bahwa sistem akhirnya mencerminkan struktur komunikasi organisasi yang membangunnya, dibahas mendalam di bab 1.2. Jika empat tim memiliki empat langkah sebuah perjalanan dan jarang berbicara, pengguna akan merasakan empat langkah terputus dengan retakan di antaranya. Jadi desain layanan dan desain tim adalah masalah yang sama dilihat dari dua sudut, dan Anda tidak dapat memperbaiki pengalaman terfragmentasi hanya dengan layar lebih baik jika kepemilikan mendasarnya terfragmentasi. Gunakan blueprint dan peta perjalanan Anda untuk bertanya apakah tim Anda digambar di sekitar perjalanan pengguna atau di sekitar kenyamanan internal, dan bersedialah membentuk ulang tim, atau menciptakan peran yang secara eksplisit memiliki perjalanan ujung ke ujung, agar seseorang bertanggung jawab atas keseluruhan dan bukan hanya irisannya. Ketika Anda tidak dapat menggambar ulang tim, setidaknya jadikan serah terima antarmereka kontrak eksplisit dengan konteks dan tingkat layanan yang disepakati.

Ukur kualitas layanan dari ujung ke ujung

Pilih metrik yang mengikuti pengguna dari niat pertama sampai hasil nyata, bukan metrik yang menyanjung satu kanal secara terpisah. Tim situs web dapat mencapai tingkat penyelesaian formulir 98 persen sementara sepertiga dari penyelesaian itu gagal diam-diam dalam antrean panggung belakang, dan metrik lokal tak akan pernah menunjukkannya. Ukur penyelesaian ujung ke ujung (apakah orang itu benar-benar mendapat apa yang dicarinya), waktu ujung ke ujung (berapa lama dari niat ke hasil, termasuk tunggu panggung belakang yang tak terlihat), dan upaya (seberapa sulit, di semua kanal yang harus mereka pakai). Padukan data operasional dengan bacaan langsung tentang bagaimana rasanya, entah lewat survei transaksional, pertanyaan ala Net Promoter Score, atau riset berkelanjutan. Awasi penurunan antarkanal terutama, karena sambungan itu adalah tempat kualitas terukur dan kualitas terasa paling menyimpang. Kaitkan metrik layanan ini dengan pelacakan hasil manajemen produk (bab 10.14) agar angka menggerakkan prioritisasi alih-alih duduk di dasbor yang tak ditindaklanjuti siapa pun.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
Kepemilikan layanan ujung ke ujung (satu tim memiliki satu perjalanan)	Akuntabilitas jelas, pengalaman koheren, sambungan dirancang	Memotong struktur organisasi yang ada, sulit diisi staf dan didanai, dapat menjadi hambatan
Kepemilikan per kanal atau per langkah	Cocok dengan tim yang ada, cakupan lokal jelas, mudah diisi staf	Tak seorang pun memiliki keseluruhan; celah antarkanal; optimasi lokal
Blueprint layanan penuh di muka	Memunculkan kegagalan panggung belakang sebelum dikirim, pemahaman bersama	Memakan waktu, dapat basi, berisiko analisis sebelum tindakan
Hanya pemetaan perjalanan ringan	Cepat, murah, cukup baik menemukan celah terburuk	Melewatkan kegagalan panggung belakang dan sistem yang akan ditangkap blueprint
Konsistensi omnichannel (terpadu lintas kanal)	Serah terima mulus, konteks terbawa lintas kanal	Integrasi mahal, menuntut data bersama dan tim yang selaras

Ketegangan pusatnya adalah antara layanan yang dibutuhkan pengguna, yang mengalir melintasi batas Anda, dan organisasi yang sebenarnya Anda punya, yang digambar di sepanjangnya. Selesaikan secara proporsional alih-alih dogmatis. Anda tidak perlu mereorganisasi seluruh perusahaan untuk merancang satu layanan dengan baik, tetapi Anda butuh setidaknya satu orang atau tim yang bertanggung jawab atas hasil ujung ke ujung, dipersenjatai blueprint yang membuat panggung belakang terlihat dan mandat memperbaiki sambungan. Belanjakan blueprinting terberat Anda pada perjalanan yang bervolume tinggi, berpertaruhan tinggi, atau berkegagalan tinggi, dan pakai peta perjalanan lebih ringan untuk sisanya. Tujuannya bukan artefak sempurna; melainkan layanan yang berfungsi bagi orang di pusatnya.

Pertanyaan untuk didiskusikan dengan tim Anda

Siapa yang memiliki seluruh layanan dari ujung ke ujung, dari niat pertama pengguna sampai hasil nyata mereka, dan wewenang apa yang sebenarnya mereka punya? Di kebanyakan organisasi besar jawaban jujurnya “tak ada,” karena kepemilikan dipecah menurut kanal dan departemen, dan setiap pemilik diukur pada irisannya sendiri. Celah itu adalah tempat layanan gagal, karena sambungan antarpemilik milik tak seorang pun dan tak mendapat perhatian. Putuskan apakah Anda akan menciptakan pemilik ujung ke ujung eksplisit, pemilik layanan atau pemilik perjalanan, dan jelaslah apakah orang itu benar-benar dapat mengubah sistem panggung belakang dan batas tim atau sekadar bertanggung jawab atas metrik yang tak dapat digerakkannya. Bawa bagan organisasi Anda saat ini dan blueprint perjalanan teratas Anda dan letakkan berdampingan untuk melihat siapa yang menyentuh perjalanan dan siapa yang bertanggung jawab atasnya. Jika keduanya tidak cocok, Anda telah menemukan sumber kegagalan serah terima terburuk Anda. Jawabannya harus mengubah cara Anda mendanai dan mengisi staf pekerjaan, bukan sekadar siapa yang menghadiri standup.
Apakah tim kita digambar di sekitar perjalanan pengguna atau di sekitar kenyamanan internal kita, dan apakah kita bersedia mengubahnya? Hukum Conway (bab 1.2) berarti layanan Anda akan mencerminkan struktur komunikasi Anda entah Anda berniat atau tidak, sehingga perjalanan yang dipecah di empat tim yang tak berkomunikasi akan terasa seperti empat langkah terputus. Langkah nyaman adalah memperbaiki layar dan membiarkan bagan organisasi, tetapi itu memperlakukan gejala sementara penyebab terus meregenerasinya. Lihatlah dengan jujur apakah batas tim Anda menciptakan celah serah terima persis yang dikeluhkan pengguna Anda, dan timbang biaya nyata membentuk ulang tim terhadap biaya berkelanjutan pengalaman terfragmentasi. Bawa titik sakit dari peta perjalanan Anda dan periksa berapa banyak yang berada persis di batas tim. Jika sebagian besar demikian, UI lebih baik tidak akan menyelamatkan Anda, dan percakapan harus tentang desain tim. Apa yang Anda putuskan di sini menentukan apakah perbaikan layanan Anda bertahan atau diam-diam terkikis.
Seberapa baik perkakas yang dihadapi staf kita melayani orang yang memakainya, dan bagaimana itu tampak bagi pelanggan? Perkakas internal adalah perangkat lunak yang paling andal diabaikan di organisasi besar mana pun, karena penggunanya terikat dan anggarannya renungan belakangan, namun petugas kasus atau agen yang bergumul dengan konsol rusak meneruskan gesekan itu langsung kepada pelanggan sebagai keterlambatan dan galat. Tanyakan kapan terakhir Anda melakukan riset pada sistem yang dihadapi staf sendiri, atau apakah Anda mengasumsikan bahwa karena staf dibayar untuk mengatasi, perkakas baik-baik saja. Pertimbangkan bahwa panggung belakang adalah tempat sebagian besar kegagalan layanan senyap benar-benar terjadi, dalam pengetikan ulang manual dan konteks hilang di serah terima, yang tak satu pun dapat dilihat metrik panggung depan. Bawa anggota staf nyata ke ruangan dan tonton mereka menyelesaikan tugas umum, lalu telusuri bagaimana perjuangan mereka sampai ke pelanggan. Jika Anda belum pernah mendanai perkakas internal seperti produk, ini kemungkinan perbaikan besar termurah untuk kualitas layanan ujung ke ujung.
Metrik ujung ke ujung tunggal mana yang akan memberi tahu kita apakah seluruh layanan benar-benar berfungsi, dan mengapa kita tidak melacaknya hari ini? Bagi tim besar pertanyaan ini tidak nyaman karena jawaban jujurnya biasanya setiap kanal dan departemen punya metrik lokal hijau sementara tak seorang pun mengukur apakah orang itu mendapat apa yang dicarinya. Tingkat penyelesaian formulir, waktu penanganan panggilan, dan jumlah penutupan tiket semuanya menyanjung pemilik yang melaporkannya, dan masing-masing dapat tetap sehat sementara hasil yang menyatu gagal dalam antrean panggung belakang. Putuskan ukuran penyelesaian atau waktu ujung ke ujung yang mengikuti pengguna dari niat pertama sampai hasil nyata, dan jelaslah siapa yang akan menginstrumentasinya di seluruh sistem yang tak pernah dibangun untuk berbagi data. Bawa dasbor per kanal saat ini, blueprint satu perjalanan bervolume tinggi, dan estimasi penurunan senyap antarkanal agar celah antara hijau lokal dan merah ujung ke ujung terlihat. Dalam pengaturan enterprise dan pemerintah, sepakati siapa yang bertanggung jawab atas angka seluruh perjalanan dan siapa yang berwenang bertindak atasnya, karena metrik yang tak dapat digerakkan pemilik tunggal mana pun adalah metrik yang tidak mengubah apa-apa.
Di mana layanan kita memaksa pengguna mengulang diri, dan berapa biaya membangun versi “beri tahu kami sekali”? Pengambilan data duplikat adalah sinyal paling jelas bahwa layanan diorganisasi di sekitar batas internal Anda alih-alih kebutuhan pengguna, dan itu mahal di kedua sisi: pengguna memasukkan ulang bukti yang sama pada setiap serah terima, dan setiap departemen membayar untuk mengumpulkan dan memverifikasi ulang. Pertimbangan yang bersaing adalah bahwa catatan bersama yang memungkinkan “beri tahu kami sekali” menuntut integrasi lintas sistem dan tim yang mungkin tak punya riwayat memercayai data satu sama lain, sehingga biaya pembangunan dan kerja tata kelola data itu nyata. Bawa peta perjalanan yang dianotasi dengan setiap titik di mana pengguna menyuplai informasi yang sudah Anda pegang, dan hitungan kasar berapa catatan terpisah menyimpan bidang yang sama. Untuk layanan pemerintah yang mencakup beberapa lembaga, tambahkan dasar hukum untuk berbagi data itu di antara mereka, karena persetujuan, hukum privasi, dan aturan tata kelola informasi menentukan apakah “beri tahu kami sekali” bahkan diizinkan sebelum Anda bertanya apakah terjangkau.
Ketika konteks diserahterimakan antara tim, sistem, atau kanal, apa yang sebenarnya ikut bersama kasus, dan apa yang terjadi ketika serah terima gagal? Serah terima adalah tempat layanan patah diam-diam, karena kegagalan tak terlihat oleh siapa pun kecuali pengguna yang menunggu, dan dalam organisasi besar setiap serah terima melintasi batas di mana tak ada pemilik tunggal yang merasa bertanggung jawab atas apa yang jatuh. Putuskan dengan sengaja data, riwayat, dan status apa yang harus berpindah bersama kasus, apakah sisi penerima dapat melihatnya, dan apa jalur pemulihan ketika transfer macet atau tiba tidak lengkap. Bawa blueprint layanan Anda untuk perjalanan nyata dan telusuri setiap garis di mana kasus berpindah tangan, menandai konteks apa yang dipertahankan dan apa yang diketik ulang atau hilang. Dalam layanan enterprise dan sektor publik yang terikat perjanjian tingkat layanan atau waktu respons undang-undang, perlakukan setiap serah terima sebagai kontrak eksplisit dengan konteks yang disepakati dan cadangan terdefinisi, karena serah terima tak terdokumentasi adalah pelanggaran yang menunggu terjadi yang tidak akan diperingatkan dasbor mana pun.

Lensa sektor

Startup. Dengan segelintir orang dan tanpa waktu untuk artefak rumit, blueprint-kan hanya satu perjalanan yang membawa nilai inti Anda, dan blueprint cukup untuk melihat di mana panggung depan menyerahkan ke panggung belakang yang lambat atau manual. Lakukan di papan tulis dalam satu sore, bukan sebagai studi enam minggu. Keunggulan Anda adalah seluruh layanan hidup di beberapa kepala, jadi memperbaiki serah terima yang rusak adalah percakapan, bukan negosiasi lintas departemen. Belanjakan keunggulan itu sebelum Anda menumbuhkan batas yang membuat serah terima mahal.

Bisnis kecil. Anda tidak punya desainer layanan dan tak ada anggaran untuknya, jadi langkah praktisnya adalah menelusuri perjalanan Anda sendiri sebagai pelanggan, mencatat setiap titik di mana Anda membuat seseorang mengulang diri atau menunggu langkah manual, dan memperbaiki yang terburuk. Pilih perkakas yang sudah menyatukan kanal Anda (kotak masuk bersama, sistem pemesanan yang memberi tahu staf) daripada membangun integrasi yang tak dapat Anda pelihara. Ketika membeli sistem, timbang seberapa baik ia menyerahkan konteks ke langkah berikutnya, karena perkakas murah yang menjatuhkan rincian pelanggan antara penjualan dan pemenuhan berbiaya lebih dalam bisnis ulang yang hilang daripada yang dihematnya.

Enterprise. Masalah inti adalah satu perjalanan melintasi penjualan, penyediaan, penagihan, dan dukungan, masing-masing dengan metrik lokal hijau dan tak satu pun bertanggung jawab atas keseluruhan. Investasikan pada service blueprint penuh untuk perjalanan bervolume tinggi dan berpertaruhan tinggi Anda, tunjuk pemilik ujung ke ujung bernama dengan wewenang atas sambungan, dan bakukan metrik ujung ke ujung yang selamat dari audit dan menggerakkan prioritisasi lintas tim. Perlakukan catatan kasus bersama dan konsol yang dihadapi staf sebagai produk berdana, dan jadikan setiap serah terima lintas tim kontrak eksplisit dengan konteks dan tingkat layanan yang disepakati.

Pemerintah. Layanan harus diorganisasi di sekitar peristiwa hidup warga, bukan struktur lembaga, dan ditahan pada standar layanan terbit dengan transparansi dan akuntabilitas publik. Aturan pengadaan membentuk apa yang dapat Anda bangun, jadi pilih catatan bersama dan pola “beri tahu kami sekali” di tempat dasar hukum untuk berbagi data ada, dan dokumentasikan dasar itu sebelum Anda merancang alur. Lakukan riset dengan pengguna nyata, termasuk yang paling rentan, blueprint-kan panggung belakang lintas lembaga, dan ukur seluruh perjalanan alih-alih irisan setiap lembaga, karena publik menilai layanan dari apakah mereka mendapat hasilnya, bukan departemen mana yang berhasil.

Contoh

Startup. Startup sepuluh orang yang menjual produk asuransi rumah menganggap dirinya perusahaan aplikasi, dan aplikasinya memang bagus. Tetapi churn tinggi dan dukungan kewalahan, jadi para pendiri mem-blueprint perjalanan klaim yang sebenarnya. Mereka menemukan layanan sesungguhnya adalah momen ketika pelanggan punya pipa pecah tengah malam: aplikasi menyerahkan ke antrean email, yang menyerahkan ke penilai pihak ketiga yang tak terlihat pelanggan, yang menelepon kembali pada jam kerja dari nomor tak dikenal yang masuk ke kotak suara. Panggung depan yang mengilap duduk di atas panggung belakang yang lambat dan buram, dan “momen yang penting,” klaim yang menegangkan, persis tempat ia gagal. Memperbaiki serah terima, memberi pelanggan visibilitas atas langkah penilai, dan memperlakukan alur kerja klaim sebagai bagian produk berbuat lebih banyak untuk retensi daripada fitur aplikasi baru mana pun.

Enterprise. Sebuah perusahaan telekomunikasi menjual internet bisnis dengan pemesanan daring dua menit dan mimpi buruk pengiriman dua minggu. Penjualan, penyediaan, rekayasa lapangan, dan penagihan masing-masing memiliki satu bentangan perjalanan dan masing-masing mencapai targetnya sendiri, sementara pelanggan mengalami permintaan berulang untuk informasi yang sama, jendela janji temu terlewat, dan tagihan pertama yang tak cocok dengan penawaran. Service blueprinting lintas keempat departemen mengekspos sambungannya: konteks mati pada setiap serah terima karena tak ada catatan bersama pesanan yang mengikuti pelanggan. Perusahaan menunjuk pemilik pesanan-ke-aktivasi ujung ke ujung, membangun catatan kasus bersama yang ikut bersama pesanan, dan menyambung ulang insentif tim di sekitar hasil yang menyatu. Metrik lokal nyaris tak berubah; waktu aktivasi ujung ke ujung dan tingkat keluhan keduanya turun tajam.

Pemerintah. Sebuah pemerintah nasional mendesain ulang layanan “kematian anggota keluarga,” salah satu peristiwa hidup tersulit yang dihadapi warga. Sebelumnya yang berduka harus secara terpisah memberi tahu otoritas pajak, layanan pensiun, lembaga kendaraan, kantor paspor, dan pemerintah daerah, masing-masing dengan formulir sendiri dan masing-masing menuntut akta kematian yang sama. Mengorganisasi layanan di sekitar peristiwa hidup alih-alih lembaga, tim membangun satu perjalanan “beri tahu kami sekali” yang mengambil informasi yang dimasukkan seseorang dan mendistribusikannya ke setiap departemen yang relevan di balik garis visibilitas. Menyelaraskan dengan standar layanan sektor publik, mereka meriset dengan orang yang baru berduka, mem-blueprint panggung belakang lintas lembaga, dan mengukur seluruh perjalanan alih-alih bagian setiap lembaga. Penyelesaian naik, kontak duplikat turun, dan warga tidak lagi harus mengulang duka belasan kali.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil desain layanan datang dari menutup celah antara kanal dan tim, karena di situlah nilai bocor. Kegagalan ujung ke ujung mahal dengan cara yang disembunyikan dasbor per kanal: perjalanan yang selesai daring tetapi gagal di panggung belakang menghasilkan kontak dukungan, pengerjaan ulang, dan sering pelanggan hilang, dan tak satu pun biaya itu mendarat pada kanal yang tampak berhasil. Ketika Anda mengukur dan memperbaiki seluruh layanan, Anda mengurangi upaya terduplikasi (data yang sama ditangkap lima kali), permintaan kegagalan (kontak yang disebabkan murni oleh layanan gagal pertama kali), dan churn dari pengalaman yang terasa rusak meski setiap bagian secara teknis berfungsi. Di enterprise imbalannya muncul sebagai siklus pesanan-ke-kas lebih pendek dan eskalasi lebih sedikit; di pemerintah muncul sebagai biaya melayani lebih rendah dan penyelesaian berhasil lebih tinggi untuk layanan yang tak dapat didapat orang di tempat lain.

Total biaya kepemilikan harus menimbang biaya melakukan desain layanan terhadap biaya jauh lebih besar fragmentasi yang sudah Anda bawa. Biaya yang terlihat adalah riset, blueprinting, koordinasi lintas tim, dan kadang investasi pada sistem bersama dan perkakas staf. Biaya tersembunyi tidak melakukannya tersebar di anggaran dukungan, operasi, dan kerusakan reputasi, itulah persis mengapa pimpinan meremehkannya: tak ada anggaran tim tunggal yang menunjukkan harga penuh serah terima yang rusak. Untuk mengajukan kasus, beri angka pada permintaan kegagalan dan kerja terduplikasi dalam satu perjalanan bervolume tinggi, blueprint-kan, dan tunjukkan kepada pimpinan seberapa banyak biaya ada di sambungan antara tim mereka yang ada. Lalu jalankan percontohan terbatas pada perjalanan itu, ukur ujung ke ujung sebelum dan sesudah, dan pakai hasilnya untuk memperjuangkan perubahan struktural yang lebih sulit. Membingkai desain layanan sebagai penghapusan biaya yang sudah dibayar, hanya tak terlihat, cenderung menggerakkan pemangku kepentingan keuangan dan tata kelola lebih daripada seruan keanggunan mana pun.

Anti-pola dan jebakan

Pulau kanal. Setiap kanal dirancang dan diukur sendiri, sehingga perjalanan tampak baik di mana-mana dan berfungsi di mana pun dari ujung ke ujung.
Lipstik panggung depan. UI mengilap yang ditempelkan pada panggung belakang lambat atau manual, sehingga pengalaman patah begitu pengguna membutuhkan panggung belakang merespons.
Bagan organisasi sebagai layanan. Layanan yang distrukturkan di sekitar departemen Anda alih-alih tujuan pengguna, memaksa pengguna menavigasi batas internal Anda.
Teater blueprint. Blueprint rumit yang digambar sekali, dikagumi, dan tak pernah dipakai mengubah cara layanan benar-benar berjalan.
Pemetaan hanya jalur bahagia. Perjalanan dan blueprint yang mengabaikan kegagalan dan pemulihan, tempat layanan nyata benar-benar menyakitkan.
Perkakas staf yang diabaikan. Memperlakukan sistem internal yang dihadapi staf sebagai kelas dua, sehingga gesekannya bocor langsung ke pelanggan.
Amnesia serah terima. Konteks hilang pada setiap transfer antara tim, sistem, atau kanal, sehingga pengguna menjelaskan ulang situasinya berulang-ulang.
Metrik yang menyanjung. Target lokal per kanal yang tetap hijau sementara hasil ujung ke ujung gagal diam-diam.

Model kematangan

Tingkat 1, Memulai: Setiap kanal dan tim dirancang dan dijalankan secara terisolasi, reaktif. Tak ada yang memiliki layanan ujung ke ujung, tidak ada peta perjalanan atau blueprint, dan kegagalan panggung belakang tetap tak terlihat sampai muncul sebagai keluhan. Pengguna rutin mengulang diri lintas kanal karena tak ada yang melihat keseluruhan.
Tingkat 2, Mengembangkan: Beberapa perjalanan dipetakan dan celah lintas kanal terburuk diketahui, tetapi praktik tambal-sulam dan bergantung pada antusiasme individu. Peta perjalanan ada namun jarang mencapai panggung belakang, kepemilikan masih per kanal, perkakas staf renungan belakangan, dan di mana blueprinting terjadi sama sekali ia bervariasi dari tim ke tim.
Tingkat 3, Membakukan: Perjalanan kunci di-blueprint dari panggung depan ke belakang bersama staf operasional, memakai metode terdokumentasi yang diterapkan konsisten di seluruh organisasi. Pemilik layanan bernama bertanggung jawab ujung ke ujung, serah terima adalah kontrak eksplisit dengan konteks yang disepakati, perkakas staf dirancang dengan sengaja, dan pendekatan ditegakkan alih-alih opsional.
Tingkat 4, Mengelola: Layanan diukur dan dikendalikan dengan data. Penyelesaian ujung ke ujung, waktu ujung ke ujung (termasuk tunggu panggung belakang tak terlihat), upaya pengguna, permintaan kegagalan, dan penurunan antarkanal dilacak terhadap garis dasar, dan kegagalan serah terima serta pengambilan data duplikat dikuantifikasi alih-alih diasumsikan. Blueprint dijaga mutakhir, pemilik layanan dimintai pertanggungjawaban pada target ujung ke ujung, dan keputusan go atau no-go atas perubahan bertumpu pada bukti itu alih-alih metrik kanal lokal.
Tingkat 5, Mengorkestrasi: Desain tim dan desain layanan selaras sehingga kepemilikan mengikuti perjalanan, dan organisasi distrukturkan di sekitar tujuan pengguna dan peristiwa hidup alih-alih departemen. Metrik ujung ke ujung menggerakkan prioritisasi, organisasi terus mem-blueprint, mengukur, dan membentuk ulang baik pengalaman maupun operasi bersama, dan beradaptasi seluruh layanan seiring kebutuhan pengguna, kanal, dan batas lintas tim bergeser.

Gagasan untuk didiskusikan

Ketika perjalanan melintasi beberapa tim, lebih baik menunjuk satu pemilik ujung ke ujung atau menggambar ulang tim di sekitar perjalanan, dan apa yang menentukan pilihan?
Seberapa banyak kualitas layanan Anda dapat diperbaiki dengan desain panggung depan lebih baik, dan seberapa banyak membutuhkan perubahan panggung belakang atau bagan organisasi?
Di mana dalam layanan Anda pengguna paling sering harus mengulang diri, dan berapa biaya membangun versi “beri tahu kami sekali”?
Bagaimana Anda mendanai dan memprioritaskan perkakas yang dihadapi staf ketika penggunanya terikat dan tak dapat memilih dengan kaki mereka?
Haruskah layanan diorganisasi di sekitar peristiwa hidup atau tujuan pengguna bahkan ketika itu bertentangan langsung dengan garis pendanaan dan pelaporan Anda?
Metrik ujung ke ujung tunggal mana yang paling baik memberi tahu Anda apakah seluruh layanan berfungsi, dan mengapa Anda tidak melacaknya hari ini?

Poin-poin utama

Rancang seluruh layanan lintas kanal dan waktu, bukan satu layar, dan ingat pengguna tidak peduli di mana batas tim Anda jatuh.
Panggung depan dan panggung belakang adalah satu sistem; pengalaman hebat hanya sebaik yang dapat ditopang operasi di baliknya.
Service blueprint adalah artefak inti Anda: ia menghubungkan titik sentuh panggung depan dengan orang, sistem, dan serah terima panggung belakang yang menyampaikannya.
Bagan organisasi muncul dalam layanan (hukum Conway), jadi desain layanan dan desain tim harus bergerak bersama.
Perlakukan perkakas yang dihadapi staf dan serah terima antartim sebagai bagian layanan kelas satu, karena gesekannya mencapai pelanggan.
Ukur layanan dari ujung ke ujung, dari niat pertama sampai hasil nyata, dan organisasikan di sekitar tujuan atau peristiwa hidup pengguna alih-alih departemen Anda.

Referensi dan bacaan lanjutan

Marc Stickdorn dan Jakob Schneider, This Is Service Design Thinking
Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence, dan Jakob Schneider, This Is Service Design Doing
Andy Polaine, Lavrans Lovlie, dan Ben Reason, Service Design: From Insight to Implementation
Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review
Matthew Skelton dan Manuel Pais, Team Topologies
Melvin Conway, “How Do Committees Invent?“, Datamation
UK Government Digital Service, Service Manual dan Service Standard
U.S. General Services Administration, 18F Methods dan Playbook U.S. Digital Service
Nielsen Norman Group, artikel tentang service blueprinting dan pemetaan perjalanan pelanggan