Desain jalur pengecualian membantu tim menangani permintaan yang ditolak, dokumen yang hilang, dan persetujuan parsial sebelum pengerjaan ulang memperlambat seluruh proses.
Kebanyakan tim memulai dengan versi bersih dari sebuah alur kerja. Sebuah permintaan masuk, seseorang meninjaunya, lalu disetujui. Terlihat efisien, tapi itu menyembunyikan tempat kerja nyata terjadi.
Jalur bahagia biasanya adalah jalan terpendek. Formulir lengkap, lampiran ada, dan peninjau tahu persis yang harus dilakukan. Dalam operasi nyata, itu jarang menjadi penyebab keterlambatan.
Keterlambatan dimulai ketika sesuatu hilang, tidak jelas, terlambat, atau cuma diterima sebagian. Seorang manajer mungkin menyetujui anggaran tapi menolak satu item. Keuangan mungkin memerlukan dokumen pajak yang tak pernah diunggah. Pemimpin dukungan bisa mengirim kembali permintaan karena kolom alasan terlalu samar. Setiap momen itu menciptakan langkah ekstra, pesan ekstra, dan waktu tunggu ekstra.
Jika situasi-situasi itu tidak direncanakan sejak awal, orang membuat keputusan secara improfis. Satu peninjau mengirim email. Lainnya meninggalkan komentar di alat. Yang ketiga menolak tanpa penjelasan. Pemohon dibiarkan menebak: apakah mereka memperbaiki masalah, mengirim ulang, atau meminta bantuan?
Kebingungan itu punya biaya. Ini memperlambat orang yang mengajukan, orang yang meninjau, dan siapa pun yang ikut menjelaskan apa yang terjadi. Alur kerja yang tampak sederhana di papan tulis berubah menjadi chat lanjutan, pengiriman ganda, dan alih tangan manual.
Alur persetujuan dasar mudah digambarkan:
Versi nyata jauh lebih kompleks. Bagaimana jika dokumen hilang? Bagaimana jika hanya sebagian permintaan disetujui? Bagaimana jika peninjau menolak tapi pengguna masih bisa memperbaikinya? Ini bukan kasus yang tidak biasa. Untuk banyak tim, ini adalah kasus normal.
Itulah mengapa desain jalur pengecualian layak mendapat perhatian sebelum layar digambar dan status dinamai. Jalur pengecualian mendefinisikan apa yang terjadi ketika kenyataan mengganggu rencana—dan kenyataan sering melakukan itu.
Jika Anda membangun aplikasi persetujuan internal, termasuk di platform tanpa kode seperti AppMaster, kasus ditolak dan tidak lengkap perlu perhatian sebanyak kasus disetujui. Mereka membentuk pesan yang dilihat orang, tindakan yang dapat mereka lakukan selanjutnya, dan apakah alur kerja membantu orang pulih atau meninggalkan mereka terjebak.
Jalur bahagia menunjukkan niat. Jalur pengecualian menunjukkan apakah proses dapat bertahan dalam penggunaan nyata.
Jalur pengecualian adalah apa yang terjadi ketika sebuah permintaan tidak bisa maju dengan cara normal. Ini bukan kasus tepi yang jarang. Ini bagian dari proses yang menangani kekacauan dunia nyata: permintaan ditolak, formulir tidak lengkap, satu bagian disetujui tapi bagian lain tidak, atau pekerjaan benar-benar terhenti.
Jalur pengecualian yang jelas menggunakan bahasa sederhana. Alih-alih status samar seperti "Gagal", katakan apa yang terjadi: "Ditolak karena anggaran melewati batas" atau "Menunggu dokumen identitas." Orang harus tahu apa yang salah, siapa yang harus bertindak, dan apa yang terjadi selanjutnya.
Kebanyakan alur kerja rusak dalam beberapa cara yang dapat diprediksi:
Informasi yang hilang adalah salah satu masalah paling umum. Bayangkan formulir onboarding pemasok yang membutuhkan dokumen pajak dan nomor rekening bank. Jika salah satunya hilang, sistem tidak boleh hanya berhenti. Ia harus menandai permintaan sebagai tidak lengkap, menunjukkan persis apa yang hilang, dan mengembalikannya ke orang yang tepat.
Persetujuan parsial sama pentingnya. Pikirkan permintaan perjalanan untuk tiket pesawat, hotel, dan anggaran makan. Manajer menyetujui penerbangan dan hotel tapi memotong anggaran makan. Proses kini membutuhkan aturan. Apakah karyawan menerima perubahan itu, memperbarui permintaan, atau membatalkan perjalanan?
Kebuntuan juga penting. Permintaan bisa saja tidak disentuh karena peninjau yang ditugaskan sudah meninggalkan perusahaan, tim tidak menyiapkan pengganti, atau proses mencapai langkah tanpa pemilik berikutnya. Secara teknis tidak ada yang rusak, tapi permintaan tetap tidak bisa bergerak.
Jika Anda tidak merancang jalur-jalur ini sejak awal, orang menanganinya lewat email, chat, atau catatan spreadsheet. Tak lama kemudian tak ada yang tahu versi mana yang final.
Ambil permintaan perjalanan untuk seorang manajer penjualan yang ingin menghadiri konferensi dua hari. Di atas kertas, alurnya tampak mudah: karyawan memasukkan tanggal perjalanan, perkiraan biaya, dan alasan. Manajer menyetujuinya, keuangan mengonfirmasi anggaran, dan perjalanan berlanjut ke pemesanan.
Alur itu bersih, tapi juga tidak lengkap.
Sekarang rusakkan permintaan yang sama. Karyawan mengunggah estimasi penerbangan dan tiket konferensi tapi lupa kutipan hotel. Jika sistem hanya tahu "dikirim" dan "disetujui", orang cepat terjebak. Keuangan mungkin melihat permintaan tidak lengkap, manajer mungkin menganggapnya siap, dan karyawan mungkin tidak tahu apa yang hilang.
Alur yang lebih baik memberi permintaan itu status sendiri, seperti "Menunggu dokumen" atau "Perlu pembaruan." Karyawan harus melihat pesan jelas: "Tambahkan kutipan hotel sebelum permintaan ini bisa dikirim ke keuangan." Manajer tidak perlu menolak seluruh perjalanan hanya untuk meminta satu berkas.
Sekarang tambahkan masalah kedua. Manajer setuju karyawan boleh pergi, tapi tidak untuk jumlah penuh. Mereka menyetujui penerbangan dan satu malam hotel, tapi menolak biaya workshop tambahan dan malam hotel kedua.
Di sinilah banyak tim menyadari mereka tidak benar-benar punya proses persetujuan parsial.
Jika alur tidak bisa menyetujui hanya sebagian permintaan, orang mulai memakai jalan pintas. Mereka mungkin menolak seluruh permintaan dan meminta karyawan mengajukannya lagi. Atau keuangan mungkin menyetujui jumlah penuh karena sistem hanya menyimpan satu keputusan ya-tidak.
Model yang lebih jelas melacak setiap item biaya, atau setidaknya total yang disetujui. Permintaan mungkin menunjukkan:
Contoh tunggal itu menunjukkan mengapa kesalahan alur persetujuan sering berasal dari aturan yang hilang, bukan orang yang ceroboh. Jika Anda mendefinisikan aturan-aturan itu sebelum mendesain layar, sisa alur menjadi jauh lebih mudah dipercaya.
Cara yang baik untuk memperbaiki alur kerja adalah mengasumsikan permintaan tidak akan lewat dengan bersih. Pergeseran itu saja mengubah kualitas desain dengan cepat.
Mulailah dengan kasus berantakan: formulir tidak lengkap, kebijakan tidak jelas, peninjau absen, atau hanya sebagian permintaan yang harus lanjut. Kebanyakan tim bisa mengelompokkan ini ke dalam tiga pola utama:
Itu membuat pekerjaan lebih mudah dikelola. Alih-alih menemukan jawaban baru untuk setiap kasus tepi, Anda mendefinisikan seperangkat pola kecil dan menerapkannya ke setiap tipe permintaan.
Bekerjalah dalam urutan ini.
Pertama, daftar setiap titik di mana permintaan bisa berhenti. Pikirkan dokumen yang hilang, nilai tidak valid, pelanggaran kebijakan, tenggat yang terlewat, pengajuan duplikat, dan tinjauan manual. Jika permintaan bisa menunggu, gagal, atau kembali ke pengirim, tuliskan.
Selanjutnya, putuskan apa yang terjadi di setiap kasus. Untuk setiap pengecualian, jawab empat pertanyaan sederhana:
Contohnya, bayangkan karyawan mengajukan klaim biaya perjalanan sebesar $600. Bukti hotel hilang, dan satu makanan melebihi kebijakan. Jika Anda hanya merancang jalur bahagia, permintaan itu akan macet atau ditolak sebagai satu blok besar. Jika Anda merancang pengecualian terlebih dahulu, sistem bisa menunda klaim untuk bukti yang hilang, memberi tahu karyawan dengan pesan jelas, dan tetap menandai item yang diizinkan sebagai disetujui bersyarat.
Di situlah aturan persetujuan parsial penting. Anda perlu memutuskan apakah jumlah yang disetujui bisa bergerak sekarang, apakah sisanya ditangguhkan, dan apakah pemohon bisa mengedit hanya bagian yang disengketakan atau harus mengajukan ulang seluruh klaim.
Jika Anda membangun proses di AppMaster, ini saatnya memetakan cabang-cabang itu dalam logika bisnis sebelum Anda memoles UI. Lebih mudah mempercayai alur kerja ketika tolak, kembalikan untuk perbaikan, dan setujui dengan kondisi diperlakukan sebagai jalur terpisah alih-alih disembunyikan di balik satu status samar.
Akhirnya, uji satu skenario nyata dari awal sampai akhir. Gunakan angka sebenarnya, satu celah dokumen nyata, dan satu pelanggaran kebijakan. Jika seseorang yang membaca alur tidak bisa mengatakan apa yang terjadi selanjutnya dalam waktu kurang dari satu menit, desain masih terlalu samar.
Layar terasa konkret, jadi tim sering mulai di sana. Mereka menggambar tombol, formulir, dan dasbor sebelum sepakat pada aturan. Itu biasanya menciptakan masalah kemudian, karena antarmuka akhirnya menyembunyikan keputusan yang sebenarnya tidak pernah dibuat.
Urutan yang lebih baik sederhana: definisikan status, alih tangan, tenggat waktu, dan bukti yang diperlukan untuk bergerak maju. Lalu bangun layar di sekitar itu.
Desain jalur pengecualian menjadi jauh lebih mudah ketika seperangkat aturan kecil dan jelas. Jika sebuah permintaan bisa disetujui, ditolak, dikembalikan untuk diperbaiki, atau disetujui sebagian, status-status itu perlu nama sederhana yang hanya berarti satu hal. Hindari duplikat samar seperti "Dikembalikan," "Dibuka kembali," dan "Perlu perubahan" kecuali memang berperilaku berbeda.
Ambil contoh permintaan pembelian. Seorang manajer membukanya dan melihat kutipan hilang. Jika tim belum memutuskan apa yang terjadi selanjutnya, orang mulai improvisasi. Satu manajer menolaknya. Yang lain membiarkannya pending. Yang ketiga mengirim pesan chat dan tidak mengubah apa pun di sistem. Tak lama kemudian tidak ada yang mempercayai status.
Tulis aturannya dulu. Ketika kutipan hilang, permintaan berpindah ke "Perlu dokumen." Pengirim memegang langkah selanjutnya. Permintaan tetap di sana selama lima hari kerja. Jika tidak ada yang datang, status berubah menjadi "Kadaluarsa" dan perlu pengajuan baru.
Aturan tunggal itu membentuk produk lebih baik daripada mockup. Sekarang Anda tahu apa yang harus dilihat pengguna, pengingat apa yang dikirim, dan riwayat apa yang disimpan.
Set aturan praktis harus menjawab empat pertanyaan:
Persetujuan parsial membutuhkan perhatian yang sama. Jika perjalanan disetujui tapi biaya hotel tidak, apakah pemohon mengedit catatan yang sama atau membuat yang baru? Apakah keuangan meninjau hanya bagian yang diubah, atau semuanya lagi? Jika itu tidak diputuskan awal, layar mungkin tampak rapi sementara proses di baliknya tetap berantakan.
Ketika tim menyelesaikan aturan terlebih dahulu, antarmuka menjadi lebih sederhana. Lebih penting lagi, pengguna tahu persis apa yang harus dilakukan selanjutnya, bahkan ketika jawabannya adalah "belum disetujui."
Pesan pengecualian yang buruk memperlambat segala sesuatu. Orang tidak hanya perlu tahu sesuatu gagal. Mereka perlu tahu apa yang terjadi, apa dampaknya, dan apa yang harus dilakukan selanjutnya.
Di sinilah desain menjadi nyata bagi pengguna. Aturan internal Anda mungkin jelas, tapi jika layar hanya mengatakan "Error" atau "Pending review," orang akan menebak, mengirim ulang berkas yang salah, atau meminta bantuan dukungan.
Ambil contoh persetujuan vendor. Pengguna mengirim formulir dengan dokumen pajak, detail bank, dan bukti asuransi. Detail bank baik, dokumen pajak kadaluwarsa, dan bukti asuransi hilang. Jika sistem hanya menunjukkan "Permintaan tidak disetujui," pengguna tidak punya langkah selanjutnya yang jelas.
Pesan yang lebih baik terdengar seperti ini: "Detail bank Anda disetujui. Kami masih membutuhkan dokumen pajak terbaru dan bukti asuransi sebelum persetujuan akhir." Satu kalimat itu menghemat waktu karena memisahkan apa yang sudah selesai dari apa yang masih perlu dikerjakan.
Pesan yang baik biasanya menjawab empat pertanyaan kecil:
Bagian terakhir itu penting. Orang lebih mungkin menyelesaikan tugas ketika langkah selanjutnya jelas. "Unggah berkas yang hilang dan kirim ulang untuk ditinjau" jauh lebih baik daripada "Diperlukan tindakan."
Label samar juga menimbulkan kecemasan. "Menunggu tinjauan" bisa berarti menunggu orang, data hilang, atau pemeriksaan internal. Jika Anda tahu alasannya, katakan dengan jujur. "Menunggu persetujuan manajer" dan "Menunggu bukti alamat" bukan situasi yang sama dan tidak boleh terlihat sama.
Jika proses memungkinkan persetujuan parsial, tampilkan itu dengan jelas di status. Ringkasan singkat sering bekerja lebih baik daripada satu label:
Sekarang pengguna bisa memperbaiki hanya yang penting. Mereka tidak perlu memulai dari awal.
Ini juga tempat resubmisi harus mudah ditemukan. Letakkan tindakan berikutnya dekat dengan pesan, bukan di layar lain. Jika Anda membangun alur di AppMaster, akan membantu mencocokkan teks status yang dilihat pengguna dengan status proses bisnis sehingga aplikasi mengatakan persis apa yang sedang dilakukan alur kerja.
Pesan yang baik mengurangi tiket dukungan, mempercepat persetujuan, dan membuat proses terasa adil. Orang bisa menerima penolakan ketika mereka memahaminya.
Kebanyakan pengerjaan ulang dimulai dari satu asumsi yang salah: jalur normal adalah hal utama untuk dirancang. Tim memetakan pengajuan, ditinjau, selesai, dan berhenti di sana. Lalu kehidupan nyata muncul: file hilang, manajer menginginkan perubahan, atau hanya sebagian permintaan yang bisa lanjut.
Kesenjangan itu menciptakan pekerjaan ekstra dengan cepat. Orang menemukan perbaikan manual, mengirim pesan samping, dan mengganti nama status secara improvisasi. Beberapa minggu kemudian, tidak ada yang mempercayai alur karena setiap pengecualian terasa seperti kasus khusus.
Salah satu kesalahan umum adalah memperlakukan jalur ideal sebagai produk dan segala lainnya sebagai pembersihan. Bayangkan permintaan biaya yang membutuhkan struk, persetujuan departemen, dan tinjauan keuangan. Jika struk hilang, apakah permintaan berhenti, kembali ke karyawan, atau ditolak? Jika aturan itu tidak jelas sejak awal, tim biasanya menambalnya nanti dengan email dan komentar.
Nama status yang membingungkan menyebabkan putaran pengerjaan ulang lain. Label seperti "In review 2" atau "Pending action" terdengar sepele, tapi memaksa orang menebak apa yang terjadi selanjutnya. Nama yang jelas mengurangi kesalahan karena menunjukkan masalah, pemilik, hasil, atau langkah berikutnya.
Kepemilikan adalah tempat lain di mana alur kerja rusak. Permintaan tidak boleh pernah duduk di status yang tidak dimiliki siapa pun. Jika sebuah kasus menunggu, seseorang harus bertanggung jawab untuk memajukannya, meminta info tambahan, atau menutupnya. Jika tidak, penundaan senyap menumpuk dan pengguna mengira sistem kehilangan permintaan mereka.
Persetujuan parsial sering ditangani dengan buruk juga. Tim memperlakukannya seperti penolakan penuh karena terasa lebih sederhana. Tapi hasil itu berarti hal berbeda. Jika permintaan perjalanan meminta penerbangan, hotel, dan makan, keuangan mungkin menyetujui penerbangan dan hotel tapi menolak makan. Kasus itu butuh jalur tersendiri, pesan tersendiri, dan sering tindakan lanjutan tersendiri.
Saat persetujuan parsial digabungkan dengan penolakan, orang mengajukan ulang seluruh permintaan, menduplikasi dokumen, dan memulai ulang tinjauan yang sudah selesai. Itu pengerjaan ulang murni.
Tes sederhana membantu: baca setiap status non-happy-path dan tanyakan, "Siapa pemiliknya, apa yang dilihat pengguna, dan apa yang terjadi selanjutnya?" Jika jawabannya kabur, proses kemungkinan akan rusak di titik yang sama nanti.
Sebelum Anda membangun layar atau mengotomatisasi apa pun, lakukan satu pemeriksaan terakhir pada kasus berantakan. Desain jalur pengecualian yang baik seringkali hanya beberapa keputusan jelas yang dibuat lebih awal, sebelum kebingungan berubah menjadi pengerjaan ulang.
Jika sebuah permintaan ditolak, dijeda, atau hanya disetujui sebagian, seseorang harus selalu tahu apa yang terjadi selanjutnya, siapa yang melakukannya, dan informasi apa yang masih hilang.
Gunakan pemeriksaan cepat ini pada setiap pengecualian di proses Anda:
Lalu jalankan satu tes sederhana. Serahkan proses ke seseorang yang tidak ikut merancangnya. Beri mereka permintaan yang ditolak dan permintaan dengan satu dokumen hilang. Jika mereka tidak bisa mengatakan apa yang harus dilakukan dalam waktu kurang dari satu menit, proses masih terlalu samar.
Contoh kecil menunjukkan intinya. Bayangkan manajer menyetujui permintaan perangkat lunak tapi menolak bagian perangkat keras. Jika status hanya mengatakan "Disetujui sebagian," karyawan mungkin berasumsi semuanya bisa dilanjutkan. Status yang lebih baik mengatakan persis apa yang disetujui, apa yang ditolak, dan apakah karyawan bisa mengirim ulang bagian yang hilang.
Jika Anda ingin mengubah aturan-aturan itu menjadi aplikasi internal yang berfungsi, petakan status pengecualian dulu dan bangun jalur bahagia kemudian. Di AppMaster, itu bisa berarti mendefinisikan status, aturan bisnis, dan field wajib sebelum memikirkan layar yang dipoles. Ini cara praktis membangun aplikasi tanpa kode yang menangani pekerjaan nyata, bukan hanya versi idealnya.
Langkah berikutnya sederhana: daftar lima pengecualian teratas Anda, tetapkan pemilik untuk masing-masing, dan tulis pesan yang harus dilihat pengguna. Jika tiga bagian itu jelas, biasanya pembangunan menjadi jauh lebih mudah.
Mengapa jalur bahagia saja tidak cukup untuk alur persetujuan?Karena keterlambatan nyata biasanya terjadi saat sesuatu hilang, tidak jelas, terlambat, atau hanya disetujui sebagian. Jika Anda merancang hanya alur bersih, orang akan memperbaiki masalah lewat obrolan, email, dan solusi manual.
Jalur pengecualian mana yang harus saya desain terlebih dahulu?Mulailah dengan kasus yang paling sering terjadi: penolakan, informasi yang hilang, dan persetujuan parsial. Setelah itu tambahkan gangguan seperti permintaan tanpa pemilik atau tanpa langkah selanjutnya yang jelas.
Status apa yang sebaiknya dimiliki aplikasi persetujuan?Gunakan seperangkat status kecil yang jelas yang masing-masing hanya berarti satu hal. Default praktis bisa berupa: disetujui, ditolak, butuh dokumen, butuh perubahan, disetujui sebagian, dan kadaluarsa jika Anda menggunakan tenggat waktu.
Bagaimana proses harus menangani dokumen yang hilang?Pengguna harus melihat dengan tepat apa yang hilang dan apa yang harus dilakukan selanjutnya. Default yang baik adalah memindahkan permintaan ke status seperti "Butuh dokumen", menamai item yang hilang dengan jelas, dan mengembalikannya ke orang yang tepat daripada menolak seluruh permintaan.
Bagaimana cara menangani persetujuan parsial tanpa menciptakan pengerjaan ulang?Perlakukan sebagai jalur tersendiri, bukan penolakan penuh. Tampilkan apa yang disetujui, apa yang ditolak, total yang disetujui jika relevan, dan apakah pemohon bisa menerima perubahan, mengedit permintaan, atau mengirim ulang hanya bagian yang disengketakan.
Apa yang harus terjadi ketika sebuah permintaan terjebak tanpa tindakan?Beri setiap status menunggu seorang pemilik dan aturan waktu. Jika peninjau absen atau permintaan duduk terlalu lama, alur kerja harus mengeskalasi, menetapkan ulang, atau kadaluarsa daripada tetap macet.
Apa yang membuat pesan pengecualian benar-benar berguna?Buat pesan singkat dan spesifik. Beritahu pengguna bagian mana yang ditolak atau hilang, bagian mana yang sudah diterima, apa yang harus mereka lakukan selanjutnya, dan apa yang terjadi setelah mereka mengirim ulang.
Haruskah saya merancang layar terlebih dahulu atau aturan alur kerja terlebih dahulu?Tentukan aturan terlebih dahulu. Sepakati status, pemilik, tenggat waktu, berkas yang dibutuhkan, dan tindakan selanjutnya sebelum Anda sketsa tombol atau dasbor, karena antarmuka harus mencerminkan keputusan yang sudah jelas.
Bagaimana saya bisa menguji apakah jalur pengecualian cukup jelas?Uji satu skenario nyata dari awal sampai akhir dengan angka nyata dan satu atau dua masalah, seperti berkas yang hilang atau pelanggaran kebijakan. Jika orang baru tidak bisa mengatakan apa yang harus dilakukan dalam waktu kurang dari satu menit, alurnya masih terlalu samar.
Bagaimana saya membangun jenis alur kerja ini di AppMaster?Petakan status pengecualian dalam logika bisnis Anda sebelum memoles UI. Di AppMaster, itu berarti mendefinisikan status, field wajib, kepemilikan, dan cabang seperti tolak, kembalikan untuk perbaikan, dan setujui bersyarat terlebih dahulu.
10 Mar 2026
10 menit
08 Mar 202610 menit
07 Mar 20267 menitEksperimen dengan AppMaster dengan paket gratis.
Saat Anda siap, Anda dapat memilih langganan yang tepat.
