Siklus hidup permintaan pelanggan: petakan sebelum merancang layar

Mengapa layar tidak akan berhasil tanpa peta permintaan

Formulir permintaan yang terlihat rapi tetap dapat menghasilkan proses yang berantakan. Tim sering memilih kolom, tombol, dan dasbor terlebih dahulu, lalu baru menyadari bahwa tidak ada kesepakatan tentang apa yang terjadi setelah pelanggan mengeklik «Kirim».

Layar hanya menampilkan momen tertentu. Siklus hidup permintaan pelanggan menunjukkan seluruh jalurnya: di mana permintaan masuk, siapa yang meninjaunya, keputusan apa yang diambil, kapan pekerjaan dimulai, dan apa yang dianggap selesai. Tanpa peta ini, setiap layar mungkin terlihat masuk akal, sementara pekerjaan di antara layar tetap tidak jelas.

Bayangkan formulir dukungan dengan status «Sedang diproses». Apakah itu berarti seseorang sudah membaca permintaan, menugaskannya, menghubungi pelanggan, atau mulai mengerjakan masalah sebenarnya? Staf mungkin menggunakan label yang sama dengan cara berbeda. Pelanggan melihat sedikit perkembangan, dan manajer tidak dapat mengetahui di mana permintaan terhenti.

Memulai dari layar juga menyembunyikan proses serah terima. Permintaan mungkin berpindah dari dukungan ke penagihan, lalu ke manajer akun. Jika tim belum menentukan pemilik di setiap tahap, semua orang dapat mengira orang lain yang akan bertindak. Akibatnya, permintaan tertinggal di antrean bersama sampai pelanggan menindaklanjuti.

Pemetaan alur kerja permintaan membantu menemukan celah ini sebelum desain antarmuka dimulai. Tim perlu menentukan:

• Informasi apa yang memulai permintaan?
• Siapa yang memiliki tindakan berikutnya?
• Status apa yang dapat mengikuti setiap keputusan?
• Kapan tenggat dimulai, berhenti sementara, atau berakhir?
• Siapa yang perlu menerima notifikasi saat permintaan berubah?

Peta juga mencegah dasbor yang menyesatkan. Jumlah permintaan «terbuka» tidak banyak berarti jika di dalamnya termasuk item baru, permintaan yang menunggu informasi pelanggan, dan pekerjaan yang terhambat oleh tim lain. Status yang terpisah memberi staf bahasa bersama dan memberikan pembaruan yang lebih jujur kepada pelanggan.

Peta ini tidak perlu rumit. Yang penting, peta tersebut menggambarkan pekerjaan yang benar-benar dilakukan orang, termasuk detail yang belum ada, permintaan yang ditolak, dan kasus yang dibuka kembali. Setelah jalurnya jelas, layar lebih mudah dirancang karena setiap halaman memiliki tugas tertentu: mengumpulkan informasi, membantu pemilik bertindak, atau menunjukkan posisi permintaan kepada pelanggan.

Mulai dari satu permintaan dan hasil yang jelas

Mulailah dari jenis permintaan yang paling sering diterima tim Anda. Permintaan itu dapat berupa pengembalian dana, laporan pengiriman yang rusak, atau permintaan untuk mengubah detail akun. Jangan mencoba memetakan semua kebutuhan pelanggan dalam satu diagram. Peta yang terlalu luas akan cepat menjadi samar.

Tuliskan peristiwa awal dengan bahasa sederhana. Contohnya: «Pelanggan mengirimkan permintaan pengembalian dana untuk sebuah pesanan melalui formulir dukungan.» Ini menentukan kapan siklus hidup dimulai. Cara ini juga mencegah perdebatan yang sering muncul kemudian: apakah permintaan dimulai saat pelanggan mengirimkannya, saat dukungan membacanya, atau saat seseorang membuat tiket?

Lalu tentukan garis akhir dari kedua sisi. Permintaan pengembalian dana yang selesai berarti pelanggan telah menerima keputusan yang jelas dan, jika disetujui, tim pembayaran telah menerbitkan pengembalian dana. Tim dukungan juga memerlukan catatan tentang keputusan, alasan, jumlah, dan tanggalnya. Detail ini lebih penting daripada layar yang hanya bertuliskan «Selesai».

Pisahkan hasil dari antarmuka. «Tampilkan pesan sukses berwarna hijau» menjelaskan sebuah layar. «Pelanggan menerima konfirmasi yang mencantumkan jumlah pengembalian dana dan perkiraan tanggal pembayaran» menjelaskan pekerjaan yang harus dilakukan. Layar dapat berubah saat desain diperbarui. Pekerjaan dasarnya harus tetap konsisten, baik pelanggan menggunakan portal web, aplikasi seluler, maupun email.

Definisi singkat sering kali dapat mengungkap aturan yang belum ada sebelum desain dimulai:

• Jenis permintaan: pengembalian dana untuk pesanan yang sudah dibayar
• Mulai: pelanggan mengirim formulir atau menghubungi dukungan
• Selesai: pelanggan menerima keputusan disetujui atau ditolak, dan tim mencatatnya
• Pengecualian: dukungan meminta detail pesanan yang belum ada sebelum mengambil keputusan

Misalnya, pelanggan melaporkan tagihan ganda pada hari Senin. Permintaan baru benar-benar selesai setelah tim memastikan apakah tagihan tersebut ganda, mengirimkan keputusan, dan mencatat pengembalian dana jika ada. Menutup tiket setelah balasan pertama membuat pekerjaan yang sebenarnya tetap belum selesai.

Setelah jalur ini memiliki awal dan akhir yang tepat, tim dapat menambahkan status, pemilik, tenggat, dan notifikasi tanpa menebak-nebak. AppMaster nantinya dapat mengubah peta tersebut menjadi proses bisnis dan layar, tetapi peta harus menentukan pekerjaannya terlebih dahulu.

Daftarkan status yang dapat dimasuki permintaan

Status memberi tahu semua orang tentang posisi permintaan pelanggan saat ini. Buat daftar yang berfokus pada titik penting dalam pekerjaan, bukan setiap tindakan kecil. Staf harus dapat membaca sebuah status dan mengetahui apa yang perlu dilakukan berikutnya.

Permintaan dukungan atau layanan biasanya dapat memiliki status berikut:

• Baru: sistem menerima permintaan, tetapi belum ada yang meninjaunya.
• Sedang ditinjau: anggota tim memeriksa detail dan memutuskan cara menanganinya.
• Menunggu pelanggan: tim membutuhkan jawaban, berkas, atau konfirmasi dari pelanggan.
• Sedang diproses: seseorang telah menerima pekerjaan dan sedang menanganinya.
• Menunggu persetujuan atau pekerjaan eksternal: perkembangan bergantung pada manajer, pemasok, penyedia pembayaran, atau pihak lain.
• Terselesaikan: tim telah menyelesaikan pekerjaan yang diminta.
• Ditutup: pelanggan menerima hasilnya, atau tim menutup permintaan setelah jangka waktu yang telah ditentukan.

Gunakan nama yang sesuai dengan bahasa yang sudah digunakan orang. «Menunggu pelanggan» lebih jelas daripada «Menunggu input». «Sedang diproses» biasanya lebih jelas daripada «Aktif». Pelanggan tidak seharusnya membutuhkan glosarium internal untuk memahami status yang ditampilkan di portal.

Status menunggu memerlukan perhatian khusus. Status ini memisahkan pekerjaan yang dapat dilakukan tim hari ini dari pekerjaan yang bergantung pada orang lain. Permintaan pengembalian dana dapat berpindah dari «Sedang ditinjau» ke «Menunggu pelanggan» ketika pelanggan harus memberikan tanda terima. Jika manajer keuangan harus menyetujui jumlahnya, permintaan berpindah ke «Menunggu persetujuan». Penundaan ini membutuhkan pengingat dan aturan tenggat yang berbeda.

Hindari label yang berulang. «Terbuka», «Ditugaskan», dan «Sedang ditangani» sering kali menggambarkan situasi umum yang sama. Pertahankan satu status, kecuali setiap label mengubah pemilik, tindakan staf, atau tenggat yang berlaku. Status dan transisi alur kerja yang lebih sedikit dan lebih jelas juga membuat laporan lebih dapat dipercaya.

Uji setiap permintaan dengan pertanyaan sederhana: apakah permintaan ini dapat berada dalam dua status sekaligus? Jika bisa, nama statusnya mungkin tumpang tindih. Perbaiki sampai setiap status menggambarkan satu kondisi yang jelas.

Gambarkan transisi dan tentukan siapa yang memicunya

Nama status saja tidak cukup untuk menjelaskan alur kerja. Catat bagaimana permintaan berpindah, siapa yang dapat memindahkannya, dan apa yang harus benar sebelum perpindahan itu terjadi. Ini mencegah tombol di layar mengubah permintaan pada waktu yang keliru.

Tuliskan setiap transisi sebagai kalimat sederhana. Contohnya: «Agen dukungan memindahkan permintaan dari Baru ke Sedang ditinjau setelah memastikan pelanggan mencantumkan nomor pesanan.» Kalimat tersebut menyebutkan tindakan, pelaku, dan syaratnya.

Peta sederhana dapat mencakup perpindahan berikut:

• Pelanggan mengirim permintaan, lalu sistem membuat permintaan Baru.
• Agen dukungan menugaskannya kepada spesialis dan mengubah statusnya menjadi Sedang ditinjau.
• Spesialis mengubahnya menjadi Menunggu pelanggan ketika detailnya belum lengkap.
• Balasan pelanggan mengembalikannya ke Sedang ditinjau.
• Spesialis menandainya sebagai Terselesaikan setelah pekerjaan selesai.
• Pelanggan atau pemimpin dukungan menutup permintaan setelah konfirmasi.

Tentukan pelaku yang diizinkan untuk setiap panah. «Tim» terlalu samar. Gunakan peran seperti pelanggan, agen dukungan, spesialis penagihan, pemimpin tim, atau otomatisasi. Aturan sistem juga dapat memicu perubahan. Misalnya, otomatisasi dapat memindahkan permintaan dari Menunggu pelanggan ke Ditutup setelah 14 hari tanpa balasan, jika sesuai dengan kebijakan Anda.

Pengecualian memerlukan transisinya sendiri. Pelanggan mungkin dapat membatalkan permintaan Baru, tetapi tidak permintaan yang sudah selesai. Pemimpin tim dapat membuka kembali permintaan yang Ditutup jika masalahnya muncul lagi. Agen dapat mengembalikan Sedang ditinjau ke Baru hanya ketika seseorang salah menugaskan permintaan tersebut. Aturan ini melindungi kepemilikan permintaan dan menjelaskan mengapa beberapa perubahan status tidak tersedia.

Gambarkan jalurnya dengan kotak dan panah sebelum merancang layar. Cari loop yang tidak pernah berakhir, misalnya dua peran yang terus-menerus mengirim permintaan kembali satu sama lain. Periksa juga jalan buntu. Jika permintaan masuk ke Menunggu persetujuan, tentukan siapa yang menyetujui dan apa yang terjadi setelah persetujuan atau penolakan.

Di AppMaster, peta ini nantinya dapat menjadi logika proses bisnis, sementara peran mengatur tindakan yang terlihat oleh setiap pengguna. Buat peta yang cukup mudah dibaca sehingga anggota tim baru dapat mengikuti satu permintaan dari pengiriman sampai penutupan.

Tetapkan pemilik untuk setiap serah terima

Permintaan membutuhkan satu pemilik yang jelas setiap kali pekerjaan sedang aktif. Orang tersebut tidak harus menyelesaikan semua tugas sendirian. Namun, ia harus mengetahui status saat ini, menggerakkan permintaan ke tahap berikutnya, dan menjawab ketika seseorang meminta pembaruan. Kepemilikan bersama sering kali berarti tidak ada yang bertindak.

Pemilik dapat berubah seiring kemajuan permintaan. Agen dukungan mungkin memiliki permintaan baru, spesialis mungkin memiliki penyelidikan, dan manajer akun mungkin memiliki balasan akhir kepada pelanggan. Cantumkan setiap perubahan pada peta agar staf tidak perlu menebak siapa yang harus bertindak.

Pisahkan pemilik permintaan dari peninjau dan pemberi persetujuan. Pemimpin keuangan mungkin menyetujui pengembalian dana, tetapi agen dukungan tetap dapat menjadi pemilik permintaan. Agen meminta persetujuan, memantau respons, dan menyampaikan hasil kepada pelanggan. Pemimpin keuangan tidak seharusnya menerima semua tindak lanjut hanya karena mengeklik tombol setuju.

Pada setiap serah terima, catat pemilik dan tim yang aktif, pemicu perubahan kepemilikan, pekerjaan yang harus diselesaikan sebelum transisi berikutnya, serta orang yang mengambil alih jika pemilik tidak tersedia.

Rencanakan ketidakhadiran sebelum menimbulkan keterlambatan. Gunakan antrean tim, pengganti yang ditentukan, atau aturan yang menugaskan kembali permintaan setelah jangka waktu tertentu. Jika seorang spesialis sedang cuti, orang lain harus dapat melihat permintaan tersebut di antreannya, bukan membiarkannya pada pemilik yang tidak dapat merespons.

Buat kepemilikan terlihat di dalam aplikasi. Pesan obrolan pribadi dan rangkaian email dapat mendukung pekerjaan, tetapi tidak boleh menjadi dasar alur kerja. Setiap catatan permintaan harus menampilkan pemilik saat ini, serah terima sebelumnya, waktu penugasan, dan alasan penugasan ulang. Manajer dapat melihat permintaan yang sudah terlalu lama menunggu, dan staf yang berhubungan dengan pelanggan dapat memberikan pembaruan tanpa mencari-cari pesan.

Misalnya, ketika pelanggan melaporkan kesalahan penagihan, agen dukungan memiliki permintaan tersebut sampai memastikan bahwa bagian keuangan harus meninjaunya. Analis keuangan kemudian memiliki penyelidikan itu. Setelah bagian keuangan mencatat keputusan, kepemilikan kembali ke dukungan untuk memberikan respons kepada pelanggan dan menutup permintaan. Dengan begitu, dua orang tidak mengirim jawaban yang berbeda atau sama-sama mengira pihak lain sudah membalas.

Saat membangun alur kerja dalam aplikasi, sertakan perubahan pemilik di dalam transisi status itu sendiri. AppMaster dapat menghubungkan perubahan status, aturan penugasan, dan catatan audit dalam satu proses bisnis. Hal ini membantu menjaga kepemilikan tetap jelas ketika tim berkembang.

Tetapkan tenggat yang sesuai dengan pekerjaan

Sebuah permintaan sering kali membutuhkan dua tenggat. Tenggat respons mencakup balasan bermakna pertama, misalnya konfirmasi bahwa agen dukungan telah membaca permintaan dan membutuhkan detail tambahan. Tenggat penyelesaian mencakup waktu ketika tim menyelesaikan permintaan atau memberikan hasil yang disepakati.

Memisahkan kedua tanggal ini mencegah masalah umum: pelanggan menerima pengakuan yang cepat, tetapi permintaannya kemudian tidak disentuh selama berhari-hari. Permintaan akses mungkin membutuhkan respons dalam empat jam kerja dan penyelesaian dalam dua hari kerja. Sengketa penagihan yang rumit mungkin membutuhkan respons dalam satu hari kerja dan target penyelesaian yang lebih panjang.

Tuliskan dengan tepat kapan setiap hitungan waktu dimulai. Banyak tim memulai hitungan respons saat sistem menerima permintaan. Hitungan penyelesaian dapat dimulai pada waktu yang sama atau baru setelah tim memiliki informasi yang cukup untuk mengerjakannya. Pilih satu aturan dan terapkan secara konsisten.

Tentukan jeda dengan ketelitian yang sama. Hitungan waktu dapat berhenti sementara ketika permintaan menunggu balasan pelanggan, pihak ketiga yang disetujui, atau jendela pemeliharaan terjadwal. Hitungan tersebut harus dilanjutkan saat informasi yang kurang diterima atau hambatan berakhir. Jangan menghentikan tenggat hanya karena orang yang ditugaskan sedang sibuk atau tidak masuk. Pemilik atau manajer harus menugaskan ulang pekerjaan tersebut.

Tambahkan eskalasi sebelum tenggat hampir tercapai. Pengingat kepada pemilik saat 75% waktu yang tersedia telah berlalu memberi mereka kesempatan untuk bertindak. Pada 90%, beri tahu manajer mereka atau tim berikutnya yang bertanggung jawab. Jika tenggat terlewati, tandai permintaan sebagai terlambat dan nyatakan tindakan berikutnya.

Kebijakan sederhana dapat berjalan seperti ini:

• Hitungan waktu respons dimulai saat pelanggan mengirim permintaan.
• Hitungan waktu penyelesaian berhenti sementara setelah tim mengajukan pertanyaan tertentu dan permintaan masuk ke Menunggu pelanggan.
• Saat pelanggan membalas, hitungan waktu berlanjut dan permintaan kembali kepada pemiliknya saat ini.
• Mendekati tenggat, pemilik menerima pengingat, lalu manajer menerima eskalasi.
• Untuk permintaan yang terlambat, manajer menetapkan rencana pemulihan dan memberi tahu pelanggan.

Gunakan jam kerja hanya jika semua orang menyepakati jadwal yang mendasarinya. Tim yang menjanjikan bantuan tujuh hari seminggu tidak boleh diam-diam menghentikan hitungan setiap malam. Jika dukungan beroperasi Senin sampai Jumat, tentukan jam kerja, hari libur, dan zona waktu dalam aturan alur kerja. Aturan yang jelas membuat notifikasi tenggat adil bagi pelanggan dan staf.

Rencanakan notifikasi tanpa menimbulkan kebisingan

Notifikasi seharusnya menjawab satu pertanyaan praktis: apakah seseorang perlu mengetahui atau melakukan sesuatu sekarang? Jika tidak, simpan pembaruan di dalam catatan permintaan. Kotak masuk yang penuh notifikasi membuat pelanggan dan staf mengabaikan pesan, termasuk pesan penting.

Kirim pesan kepada pelanggan ketika permintaan berubah dengan cara yang berdampak pada mereka. Momen umum meliputi konfirmasi penerimaan, permintaan informasi tambahan, persetujuan atau penolakan permintaan, perubahan tanggal penyelesaian yang dijanjikan, dan penyelesaian pekerjaan. Jangan memberi tahu pelanggan hanya karena karyawan memperbaiki kesalahan ketik, menambahkan catatan internal, atau menugaskan ulang tugas tanpa mengubah hasil yang diharapkan.

Peringatan internal juga membutuhkan pemilik dan alasan untuk bertindak. Ketika permintaan berpindah ke «Perlu ditinjau», beri tahu peninjau. Ketika pelanggan membalas pertanyaan, beri tahu orang yang ditugaskan untuk menindaklanjutinya. Seluruh tim tidak perlu menerima peringatan untuk kedua peristiwa tersebut.

Buat pesan yang sederhana dan spesifik. Sebutkan permintaan, berikan status saat ini, dan jelaskan apa yang terjadi berikutnya. Contohnya:

• Pelanggan: «Kami telah menerima permintaan peralatan Anda #1842. Kami akan meninjaunya paling lambat Selasa.»
• Peninjau: «Permintaan #1842 membutuhkan persetujuan Anda paling lambat Selasa pukul 15.00.»
• Pelanggan: «Permintaan #1842 Anda disetujui. Tim kami akan menjadwalkan pengiriman dan memberi kabar paling lambat Jumat.»

Waktu pengiriman sama pentingnya dengan kata-kata. Pengingat tenggat harus sampai kepada orang yang ditugaskan cukup awal untuk bertindak, bukan lima menit sebelum tenggat. Untuk jangka waktu peninjauan dua hari, satu pengingat sehari sebelumnya dan satu lagi setelah tenggat terlewati biasanya sudah cukup. Setelah pemilik menyelesaikan pekerjaan, aplikasi harus menghentikan pengingat yang masih tertunda.

Catat aturan notifikasi di samping setiap transisi pada peta. Tuliskan siapa yang menerima pesan, peristiwa yang memicunya, saluran pengiriman, dan apakah aplikasi memerlukan pengingat. Dengan begitu, perilakunya jelas sebelum siapa pun membuat layar atau menulis otomatisasi.

Telusuri contoh permintaan pelanggan sederhana

Pelanggan melaporkan tagihan ganda melalui formulir dukungan. Formulir membuat permintaan #4821 dengan status «Baru» dan menugaskannya ke antrean dukungan. Pelanggan segera menerima konfirmasi yang mencantumkan nomor permintaan dan keterangan bahwa tim akan meninjau kasus tersebut dalam satu hari kerja.

Agen dukungan membuka permintaan, memeriksa catatan pesanan dan pembayaran, lalu mengubah statusnya menjadi «Sedang ditinjau». Agen tersebut memiliki permintaan itu. Jika catatan pembayaran tidak memiliki detail yang cukup, agen memilih «Menunggu pelanggan» dan meminta tangkapan layar rekening koran atau empat digit terakhir kartu.

Status ini membutuhkan tenggat. Aplikasi dapat mengingatkan pelanggan setelah tiga hari dan menutup permintaan setelah tujuh hari tanpa balasan. Agen harus menerima notifikasi ketika pelanggan menambahkan detail yang kurang agar permintaan tidak tertinggal tanpa diketahui di dalam antrean.

Setelah pelanggan membalas, permintaan kembali ke «Sedang ditinjau» dan, jika memungkinkan, kembali kepada agen yang sama. Kesinambungan penting karena agen baru tidak perlu mengajukan pertanyaan yang sama.

Jika agen memastikan adanya tagihan ganda, ia memindahkan permintaan ke «Keputusan pengembalian dana» dan menugaskannya kepada peninjau keuangan. Bagian keuangan memiliki waktu dua hari kerja untuk menyetujui atau menolak pengembalian dana. Pengingat sehari sebelum tenggat memberi peninjau waktu untuk bertindak sebelum pelanggan perlu menanyakan perkembangan.

Peninjau keuangan mencatat keputusan tersebut. Permintaan yang disetujui berpindah ke «Pemrosesan pengembalian dana», tempat tim pembayaran menerbitkan pengembalian dana dan memasukkan nomor referensinya. Permintaan yang ditolak kembali ke dukungan dengan alasan yang dapat dijelaskan agen secara terang kepada pelanggan.

Dukungan mengirim pesan terakhir hanya setelah tim menerbitkan pengembalian dana atau menjelaskan penolakannya. Agen kemudian mengubah status menjadi «Ditutup». Pelanggan menerima pemberitahuan penutupan yang berisi hasilnya, sementara tim menyimpan catatan setiap pemilik, keputusan, tenggat, dan pesan.

Peta ini mencegah celah yang umum terjadi: permintaan terlihat selesai di satu layar, tetapi masih menunggu tindakan di antrean tim lain.

Kesalahan umum yang membingungkan alur kerja

Sebagian besar alur kerja permintaan menjadi membingungkan karena label terdengar jelas bagi orang yang merancangnya, tetapi tidak bagi orang yang menggunakannya setiap hari. Status bernama «Tertunda» mungkin berarti pelanggan belum membalas, manajer harus menyetujui pekerjaan, atau teknisi sedang menunggu suku cadang. Setiap situasi memerlukan tindakan berikutnya yang berbeda.

Ganti label yang samar dengan status yang menjelaskan alasan penantian. «Menunggu detail pelanggan» memberi tahu pemohon apa yang harus dilakukan. «Menunggu persetujuan manajer» memberi tahu manajer apa yang menghambat perkembangan. Jika tim tidak dapat menyebutkan siapa yang harus bertindak berikutnya, ganti nama status tersebut atau hapus.

Kepemilikan juga sering menimbulkan masalah. Permintaan mungkin melibatkan dukungan, keuangan, dan operasional, tetapi beberapa nama tidak menciptakan tanggung jawab bersama. Tetapkan satu pemilik untuk setiap status aktif. Orang tersebut dapat meminta masukan dari pihak lain, tetapi tetap bertanggung jawab untuk menggerakkan permintaan atau menjelaskan keterlambatannya.

Sebuah tenggat perlu disertai tindakan. Tanggal jatuh tempo yang hanya mengirim pengingat tidak banyak membantu jika tidak ada yang merespons. Tentukan apa yang terjadi ketika waktunya habis: beri tahu pemilik, eskalasikan ke manajer, atau pindahkan permintaan ke antrean peninjauan. Sesuaikan tindakan dengan dampak keterlambatan.

Jangan membangun layar hanya karena sebuah status terdengar berguna. Setiap layar harus mendukung tugas, keputusan, atau serah terima yang jelas. Layar «Peninjauan kualitas» masuk akal hanya jika seseorang memeriksa kriteria yang telah ditentukan, lalu menyetujui permintaan atau mengembalikannya dengan alasan. Jika tim tidak dapat menjelaskan tindakan itu dengan jelas, hapus statusnya daripada menyembunyikan ketidakpastian di balik halaman lain.

Sebelum merancang layar, uji setiap bagian siklus hidup dengan empat pertanyaan:

• Apa arti status ini secara tepat?
• Siapa yang memiliki permintaan saat berada di sini?
• Peristiwa apa yang memindahkannya ke status berikutnya?
• Apa yang terjadi jika tenggat terlewati?

Pemeriksaan ini menemukan celah sejak awal. Pemeriksaan ini juga memudahkan pemetaan alur kerja permintaan untuk diubah menjadi aplikasi karena setiap status memiliki tujuan, pemilik, dan tindakan yang jelas.

Lakukan pemeriksaan cepat sebelum merancang layar

Peta permintaan harus mampu melewati peninjauan sederhana sebelum siapa pun membuka pembuat UI. Bacalah seolah-olah Anda adalah anggota staf yang menangani permintaan nyata pada hari Selasa yang sibuk. Jika Anda tidak dapat mengetahui apa yang terjadi berikutnya, layar tidak akan memperbaiki celah tersebut.

Berikan setiap status tugas yang jelas dan setidaknya satu jalur keluar. «Menunggu pelanggan» berarti tim membutuhkan informasi, jadi status ini harus berpindah ketika pelanggan membalas, membatalkan, atau melewatkan tanggal respons yang disepakati. Hindari status yang hanya menggambarkan perasaan umum, seperti «Sedang diproses», kecuali tim mengetahui dengan tepat pekerjaan apa yang dilakukan di sana.

Tinjau setiap transisi dengan menanyakan apa yang memicunya dan siapa yang boleh melakukannya. Agen dukungan dapat menandai permintaan sebagai terselesaikan setelah mengirim jawaban. Pelanggan dapat membukanya kembali. Aturan sistem dapat menutupnya setelah 14 hari tanpa balasan. Tuliskan izin tersebut agar orang tidak mengubah permintaan secara tidak sengaja.

Gunakan daftar pemeriksaan berikut:

• Setiap status memiliki tujuan, jalur keluar, dan status berikutnya yang masuk akal.
• Setiap transisi mencantumkan pemicu serta orang atau aturan yang diizinkan untuk memulainya.
• Setiap permintaan terbuka memiliki satu pemilik dan tanggal jatuh tempo atau tenggat respons.
• Setiap pembaruan kepada pelanggan terjadi ketika perubahan status berdampak pada mereka.
• Setiap jalur keterlambatan menyebutkan siapa yang diberi tahu dan apa yang harus mereka lakukan.

Periksa kepemilikan saat serah terima, karena kebingungan sering dimulai di sana. Jika agen dukungan mengirim masalah teknis ke bagian teknik, permintaan tersebut membutuhkan pemilik baru yang jelas. Agen awal dapat tetap menjadi pengamat, tetapi keduanya tidak boleh mengira pihak lain yang akan merespons.

Jaga agar notifikasi tenggat tetap praktis. Kirim pengingat internal sebelum tenggat, lalu lakukan eskalasi hanya jika permintaan tetap terbuka. Beri tahu pelanggan ketika Anda membutuhkan masukan mereka, ketika permintaan berpindah ke tim lain, dan ketika tim menyelesaikan atau menutupnya. Jangan memberi tahu pelanggan tentang setiap catatan internal.

Setelah peta terbaca dengan jelas di atas kertas, layar memiliki tugas yang jelas: menampilkan status, tindakan, pemilik, dan tanggal jatuh tempo yang tepat kepada orang yang tepat.

Ubah peta menjadi aplikasi

Setelah siklus hidup permintaan pelanggan jelas, setiap bagian peta memiliki tempat langsung di dalam aplikasi. Status menjadi kolom status. Pemilik menjadi pengguna atau tim yang ditugaskan. Tenggat menjadi kolom tanggal dan waktu. Transisi menjadi tindakan seperti «Tugaskan», «Minta detail», «Selesaikan», dan «Buka kembali».

Buat versi pertama tetap sederhana. Layar permintaan biasanya membutuhkan pelanggan, jenis permintaan, deskripsi, status saat ini, pemilik yang ditugaskan, tanggal jatuh tempo, riwayat aktivitas, dan berkas apa pun. Antrean terpisah dapat menampilkan permintaan yang membutuhkan perhatian setiap orang.

Alur kerja harus mengendalikan tindakan, bukan sekadar menampilkan label. Agen dukungan dapat memindahkan permintaan dari «Baru» ke «Sedang ditinjau». Hanya petugas penyelesaian yang ditugaskan yang dapat menandainya sebagai «Terselesaikan». Jika pelanggan membalas setelah penyelesaian, aplikasi dapat membuka kembali permintaan dan mengembalikannya ke antrean yang sesuai.

Sebelum membangun semua layar, uji rancangan yang berfungsi dengan orang-orang yang menerima dan menyelesaikan permintaan nyata. Minta mereka menangani kasus biasa, kasus mendesak, dan permintaan dengan informasi yang belum lengkap. Perhatikan saat mereka tidak dapat menemukan tindakan, tidak tahu siapa pemilik permintaan, atau harus meninggalkan aplikasi untuk mengajukan pertanyaan.

Gunakan masukan tersebut untuk memperbaiki peta sekaligus layar. Serah terima yang membingungkan dua tim mungkin membutuhkan status seperti «Menunggu persetujuan». Permintaan yang terlalu lama tertinggal mungkin membutuhkan tanggal jatuh tempo yang lebih jelas atau pengingat bagi pemiliknya. Jangan menambahkan status untuk menggambarkan setiap aktivitas kecil. Terlalu banyak pilihan membuat alur kerja lebih sulit diikuti.

AppMaster dapat mengubah desain ini menjadi aplikasi permintaan tanpa kode. Data Designer-nya dapat memodelkan permintaan, pengguna, tim, tenggat, dan riwayat status. Business Process Editor dapat menentukan penugasan, perubahan status, pengingat, dan eskalasi, sementara layar web atau seluler native dapat mendukung antrean permintaan, tampilan detail, dan laporan manajer.

Mulailah dari satu jenis permintaan dan kelompok pengguna yang kecil. Setelah mereka dapat membuat, menugaskan, memperbarui, dan menutup permintaan tanpa solusi sementara, tambahkan jenis permintaan berikutnya. Hasilnya adalah aplikasi yang mendukung pekerjaan nyata pada hari yang sibuk, bukan sekadar layar menarik yang membuat orang tidak yakin harus melakukan apa.