06 Feb 2026·6 menit
Perangkat lunak alur persetujuan manual: petakan proses dulu
Perangkat lunak alur persetujuan manual bekerja terbaik ketika Anda mendefinisikan status, pemilik, tenggat, dan pengecualian sebelum menambahkan pengingat atau aturan.
Perangkat lunak alur persetujuan manual bekerja terbaik ketika Anda mendefinisikan status, pemilik, tenggat, dan pengecualian sebelum menambahkan pengingat atau aturan.
Email bekerja untuk persetujuan ketika proses kecil dan informal. Satu orang mengirim permintaan, yang lain membalas, dan pekerjaan bergerak maju. Namun begitu lebih banyak orang terlibat, celahnya cepat terlihat.
Masalah pertama adalah visibilitas. Permintaan persetujuan berada di samping buletin, undangan kalender, dan pesan sehari-hari. Seseorang berencana meninjau kemudian, lalu permintaan itu turun di inbox dan menghilang.
Masalah berikutnya adalah kebingungan versi. Satu orang membalas thread asli, yang lain meneruskan lampiran yang diedit, dan orang lain menyetujui salinan yang lebih lama. Setelah beberapa putaran, tidak ada yang benar-benar yakin file, harga, atau kata-kata mana yang terbaru.
Kepemilikan juga menjadi samar. Jika sebuah permintaan membutuhkan masukan dari keuangan, legal, dan pemimpin tim, siapa yang bertanggung jawab ketika itu berhenti bergerak? Dalam email, jawaban itu seringkali tidak jelas. Orang mengira orang lain yang menanganinya, sehingga tidak ada yang terjadi.
Keadaan memburuk ketika seseorang sedang cuti atau ketika jalur berubah berdasarkan jumlah, risiko, atau jenis pelanggan. Pengecualian itu biasanya tinggal di kepala orang, bukan dalam proses bersama. Itu membuat jalur persetujuan sulit diprediksi dan lebih sulit dilacak.
Biayanya lebih besar daripada beberapa balasan yang lambat. Penundaan bisa menahan pembelian, kontrak, peluncuran, keputusan perekrutan, dan pekerjaan pelanggan. Tim akhirnya mengejar pembaruan alih-alih mengerjakan pekerjaan itu sendiri.
Contoh sederhana menunjukkan masalahnya. Permintaan diskon penjualan dikirim ke manajer lewat email, lalu diteruskan ke keuangan. Keuangan meminta angka yang direvisi, tapi perwakilan hanya memperbarui satu thread. Manajer menyetujui versi yang lebih awal, keuangan menunggu konfirmasi, dan pelanggan tidak mendengar apa-apa selama dua hari.
Itu sebabnya tim mulai mencari perangkat lunak alur persetujuan manual. Masalah sebenarnya bukan hanya kecepatan. Email menyembunyikan status, kepemilikan, tenggat, dan pengecualian sampai sesuatu rusak.
Sebelum Anda membangun apa pun dalam perangkat lunak, tuliskan bagaimana proses persetujuan benar-benar berjalan hari ini. Jika Anda melewatkan langkah itu, kemungkinan besar Anda akan menyalin kebingungan email ke alat baru alih-alih memperbaikinya.
Mulailah kecil. Jangan pindahkan semua alur persetujuan sekaligus. Pilih satu proses yang sering terjadi, menyebabkan penundaan, atau menghasilkan tindak lanjut terbanyak, seperti permintaan pembelian, persetujuan konten, permintaan diskon, atau permintaan akses.
Lalu lihat beberapa contoh nyata. Tiga sampai lima thread email terbaru biasanya cukup untuk menunjukkan pola. Gunakan kasus aktual, bukan ingatan. Orang lupa serah-terima kecil, balasan samping, dan pengecualian menit terakhir.
Saat meninjau contoh itu, tangkap dasar-dasarnya dengan bahasa sederhana:
Catat juga informasi apa yang dibutuhkan setiap langkah. Seorang manajer mungkin perlu jumlah anggaran, nama vendor, dan tanggal jatuh tempo sebelum mengambil keputusan. Jika informasi itu sering hilang, penundaan sebenarnya bukan masalah persetujuan. Itu masalah kualitas permintaan.
Tenggat waktu juga tempatnya di peta. Tuliskan berapa lama setiap langkah seharusnya berlangsung, apa yang terjadi jika tidak ada yang merespons, dan apakah permintaan mendesak mengikuti jalur berbeda. Daftarkan aturan pengecualian saat Anda di sana. Mungkin persetujuan di atas jumlah tertentu perlu peninjauan keuangan. Mungkin penyetuju cadangan masuk jika pemilik utama sedang tidak hadir.
Letakkan seluruh proses pada satu halaman menggunakan kata-kata yang sudah dipakai orang. Tulis "Keuangan memeriksa jumlah" atau "Manajer minta detail yang kurang," bukan sesuatu yang abstrak dan seperti sistem. Tujuannya adalah proses yang dikenali orang, bukan diagram yang terlihat rapi.
Saat orang yang mengerjakan kerja itu mengatakan, "Ya, ini memang terjadi seperti ini," peta Anda siap.
Daftar status yang bagus harus lulus tes sederhana: jika dua orang membaca permintaan yang sama, mereka harus sampai pada kesimpulan yang sama tentang apa yang terjadi selanjutnya.
Itulah mengapa perangkat lunak alur persetujuan manual bekerja paling baik dengan daftar status yang pendek dan jelas. Kebanyakan tim tidak membutuhkan sepuluh label. Mereka membutuhkan beberapa label yang memberi tahu semua orang di mana posisi permintaan sekarang.
Mulai praktis bisa terlihat seperti ini:
Setiap status harus berarti satu hal yang tepat. Menunggu persetujuan berarti permintaan siap dan seseorang harus meninjaunya. Perlu perubahan berarti belum disetujui, tapi bisa kembali setelah diperbarui. Ditolak berarti permintaan berhenti kecuali ada aturan yang mengizinkan dibuka kembali.
Kebingungan dimulai ketika tim membuat hampir-duplikat seperti Tertunda, Dalam tinjauan, Sedang direview, dan Menunggu tanda tangan. Bagi sistem, itu berbeda. Bagi orang, seringkali artinya sama. Itu menyebabkan pelaporan berantakan, serah-terima yang tidak jelas, dan pertanyaan tambahan.
Jika sebuah status butuh penjelasan panjang, ganti namanya. Label yang baik mudah dipindai dalam daftar, dasbor, atau layar ponsel. Orang harus memahaminya tanpa membuka catatan.
Pintar juga memisahkan status dari kepemilikan. Menunggu persetujuan biasanya lebih jelas daripada Dengan keuangan. Yang pertama memberi tahu keadaan permintaan. Yang kedua mencampur keadaan dengan penyetuju saat ini.
Mulailah dengan set terkecil yang bekerja. Anda selalu bisa menambah status nanti jika itu menyelesaikan masalah nyata.
Sebuah alur cepat rusak ketika sebuah langkah menjadi milik "tim" alih-alih satu orang. Setiap tahap perlu pemilik yang jelas. Orang itu bisa meminta masukan dari orang lain, tetapi satu nama atau satu peran yang ditugaskan harus bertanggung jawab untuk menggerakkan permintaan maju.
Ini lebih penting ketika Anda pindah dari rantai persetujuan email ke perangkat lunak. Di email, orang mengandalkan kebiasaan. Seseorang memperhatikan thread, meneruskannya, atau mendorong penyetuju berikutnya. Perangkat lunak tidak bisa bergantung pada tebak-tebakan semacam itu.
Untuk setiap langkah, jawab empat pertanyaan sederhana:
Serah-tangan harus sama jelasnya. Jika manajer menyetujui dan keuangan meninjau berikutnya, tuliskan itu langsung di alur kerja. Jangan biarkan sebagai "kirim ke keuangan" kecuali sistem tahu orang atau peran mana yang harus menerima.
Ambil contoh permintaan peralatan sederhana. Itu dimulai dengan manajer karyawan. Jika biayanya melewati jumlah tertentu, itu pindah ke keuangan. Jika pemilik keuangan sedang tidak ada, seorang pengendali cadangan mengambil alih setelah satu hari kerja. Jika pemohon melakukan kesalahan, hanya pemohon dan penyetuju pertama yang bisa membuka kembali. Jika permintaan tidak lagi diperlukan, hanya pemohon atau manajer departemen yang bisa membatalkannya.
Aturan ini mungkin terasa ketat, tetapi mereka mencegah kekacauan biasa: permintaan terhenti, peninjauan duplikat, dan celah panjang di mana semua orang mengira orang lain bertanggung jawab.
Alur kerja terhenti ketika hanya ada satu tenggat untuk seluruh permintaan. Setiap tahap membutuhkan tanggal jatuh tempo sendiri agar tim bisa melihat di mana waktu benar-benar hilang.
Misalnya, tinjauan manajer mungkin mendapat satu hari kerja, keuangan dua hari, dan legal tiga hari. Dalam kebanyakan kasus, jam harus mulai saat permintaan masuk ke sebuah status, bukan saat email pertama dikirim. Itu membuat pekerjaan yang terlambat lebih mudah terlihat.
Sebelum Anda mengotomasi apa pun, tentukan empat hal dasar:
Ketika tenggat terlewat, putuskan langkah selanjutnya sejak awal. Aturan sederhana biasanya terbaik: kirim satu pengingat, lalu eskalasi ke pemilik cadangan atau pimpinan tim jika tidak ada perubahan. Jangan biarkan pekerjaan terlambat tetap di status yang sama tanpa tindakan.
Permintaan mendesak butuh jalur sendiri, tetapi buat sempit. Jika semua bisa ditandai mendesak, label itu menjadi tidak berguna. Batasi untuk beberapa kasus jelas, seperti masalah yang berdampak pada pelanggan atau tenggat kepatuhan.
Aturan pengecualian sama pentingnya. Jika sebuah permintaan kekurangan informasi, pindahkan ke status seperti Menunggu pemohon dan jeda timer. Jika ditolak tapi bisa diperbaiki, kirim ke pengerjaan ulang daripada menutupnya. Jika berada di luar kebijakan normal, arahkan ke penyetuju pengecualian yang bernama alih-alih membiarkan orang mengimprovisasi lewat email.
Contoh permintaan pembelian sederhana menunjukkan mengapa ini penting. Keuangan menerima permintaan tapi kutipan vendor hilang. Tanpa aturan, tenggat keuangan akan lewat dan semua orang bingung. Dengan aturan, permintaan pindah ke Perlu info lebih lanjut, pemohon menjadi pemilik aktif, dan tenggat dijeda sampai kutipan ditambahkan.
Bayangkan permintaan pembelian untuk laptop baru. Seorang karyawan mengisi formulir dengan item, biaya, alasan, dan tanggal yang dibutuhkan. Alurnya tidak perlu rumit.
Versi dasar mungkin memakai status ini:
Permintaan mulai sebagai Diajukan dan menuju manajer. Jika karyawan hanya menulis "laptop untuk karyawan baru" dan tidak mencantumkan kode anggaran, manajer seharusnya tidak menyetujui dan menjelaskan masalah itu lewat email samping. Lebih rapi mengubah status menjadi Perlu info lebih lanjut dan mengembalikannya. Karyawan menjadi pemilik lagi, menambahkan detail yang hilang, dan mengirim ulang.
Setelah permintaan lengkap, manajer meninjaunya dan mengubah status menjadi Disetujui manajer. Kepemilikan lalu berpindah ke keuangan. Keuangan memeriksa anggaran, aturan vendor, dan batas pengeluaran. Jika semuanya benar, status menjadi Disetujui keuangan.
Sekarang tambahkan pengecualian dunia nyata. Penyetuju keuangan sakit selama tiga hari. Jika aturan itu tidak direncanakan, permintaan hanya akan menunggu. Pengaturan yang lebih baik menamai pemilik cadangan sejak awal. Setelah tenggat lewat, atau segera setelah ketidakhadiran diketahui, permintaan pindah ke cadangan itu alih-alih menunggu.
Saat keuangan menyetujui, permintaan menjadi Selesai. Jika tim Anda ingin menambahkan langkah pembelian terpisah nanti, Anda bisa menambahkannya. Versi pertama sebaiknya tetap sederhana.
Kesalahan terbesar adalah menyalin proses email persis seperti adanya. Itu terasa aman, tetapi biasanya mengunci masalah lama ke dalam sistem baru.
Email menyembunyikan titik lemah. Orang menjelaskan hal di thread samping, mengejar pembaruan secara manual, dan menyetujui permintaan tanpa aturan yang jelas. Jika proses yang sama dipindah ke perangkat lunak tanpa perubahan, kebingungan itu tidak hilang. Hanya menjadi lebih mudah terlihat.
Kesalahan umum lain adalah menambahkan terlalu banyak detail terlalu cepat. Tim membuat daftar panjang status karena ingin setiap langkah kecil terlihat. Pada praktiknya, itu membuat proses lebih sulit diikuti. Jika permintaan bisa ditandai sebagai pending review, under review, menunggu komentar, dikembalikan, dikirim ulang, dan siap tanda tangan, kebanyakan orang tidak akan tahu label mana yang harus dipakai.
Hal yang sama terjadi dengan penyetuju. Jika lima orang ditambahkan untuk berjaga-jaga, pekerjaan melambat dan tidak ada yang merasa bertanggung jawab penuh.
Beberapa tanda peringatan muncul dengan cepat:
Tim juga terburu-buru menambahkan pengingat dan eskalasi sebelum aturan dasar ditetapkan. Pengingat hanya membantu ketika sistem sudah tahu apa yang dihitung sebagai menunggu, siapa yang terlambat, dan apa yang harus terjadi selanjutnya. Jika aturan itu samar, pengingat hanya menambah kebisingan.
Kesalahan lain adalah mengabaikan pengecualian sampai setelah peluncuran. Rantai persetujuan nyata selalu memilikinya. Seseorang sakit. Permintaan mendesak muncul. Formulir tidak lengkap. Item yang ditolak kembali dengan edit. Jika situasi itu tidak direncanakan lebih awal, orang kembali ke email pada saat hal tidak biasa pertama kali terjadi.
Sederhana lebih baik daripada lengkap di hari pertama. Perbaiki langkah yang lemah dulu, pertahankan sedikit status, tetapkan satu pemilik per langkah, dan putuskan bagaimana pengecualian bekerja sebelum menambahkan otomatisasi.
Sebelum Anda menyalakan aturan routing, pengingat, atau eskalasi, periksa apakah prosesnya cukup jelas untuk bekerja tanpa email.
Tes yang berguna sederhana: dapatkah permintaan standar bergerak dari awal sampai akhir melalui satu jalur yang jelas sebagian besar waktu? Jika tidak, perbaiki jalurnya dulu.
Jalankan pertanyaan-pertanyaan ini:
Jika Anda tidak bisa menjawab itu dengan jelas, berhenti dulu. Label yang bersih, kepemilikan yang jelas, dan aturan pengecualian tertulis menghemat lebih banyak waktu daripada otomatisasi cerdas.
Itu sebabnya banyak tim menggambar proses dalam dokumen sederhana atau di papan tulis sebelum membangunnya dalam alat. Jika Anda membuat aplikasi persetujuan internal, Koder.ai bisa menjadi cara praktis untuk mengubah alur berbahasa biasa menjadi perangkat lunak kerja tanpa siklus pengembangan panjang.
Jangan luncurkan proses baru ke seluruh perusahaan sekaligus. Mulailah dengan satu tim dan satu jenis permintaan, seperti persetujuan pembelian atau sign-off konten. Pilot kecil membuat lebih mudah menemukan masalah sebelum menyebar.
Di sinilah perangkat lunak alur persetujuan manual mendapatkan kepercayaan atau menciptakan resistensi. Jika orang bisa menyelesaikan permintaan nyata dengan kebingungan lebih sedikit dibanding email, adopsi menjadi jauh lebih mudah.
Pilih alur yang cukup sering terjadi untuk diuji, tapi tidak berisiko jika perlu diubah setelah seminggu. Jelaskan kepada kelompok pilot bahwa tujuannya bukan kesempurnaan. Tujuannya menemukan bagian yang canggung saat peluncuran masih kecil.
Selama pilot, perhatikan momen ketika orang meninggalkan sistem dan melakukan sesuatu secara manual. Itu biasanya tanda paling jelas bahwa sesuatu hilang.
Perhatikan:
Setelah beberapa kasus nyata pertama, perbaiki dasar-dasarnya sebelum menambahkan fitur. Perjelas serah-tangan, sederhanakan nama status, dan sesuaikan tenggat agar sesuai kenyataan. Tunda laporan, eskalasi, dan otomatisasi ekstra sampai alur inti bekerja bersih.
Ritme tinjauan sederhana membantu. Periksa proses setelah 5 sampai 10 permintaan pertama, lalu lagi setelah dua minggu. Tanyakan satu pertanyaan sederhana: di mana orang masih butuh cara pintas?
Jika Anda ingin menguji alat persetujuan internal dengan cepat, Koder.ai berguna untuk menjadi prototipe alur dari chat dan mengubahnya menjadi aplikasi kerja. Itu sering cukup untuk memvalidasi proses sebelum berkomitmen pada peluncuran lebih besar.
Peluncuran yang aman biasanya membosankan dengan sengaja. Itu tanda yang baik. Orang harus tahu apa yang terjadi selanjutnya, siapa pemiliknya, dan apa yang harus dilakukan saat sesuatu tidak sesuai jalur normal.
Beralih dari email ketika persetujuan melibatkan lebih dari satu atau dua orang, bergantung pada tenggat waktu, atau sering memerlukan tindak lanjut. Jika orang terus menanyakan status, menyetujui versi yang salah, atau kehilangan permintaan di inbox, email sudah menghabiskan waktu dan menimbulkan risiko.
Petakan proses nyata seperti yang berjalan sekarang. Lihat beberapa thread persetujuan terbaru dan tuliskan bagaimana permintaan dimulai, siapa yang meninjaunya, informasi apa yang dibutuhkan, di mana terjadi loop balik, dan bagaimana akhirnya berakhir. Itu memberi Anda proses bersih untuk dibangun, bukan menyalin kekacauan inbox ke alat baru.
Mulailah dengan sekumpulan kecil yang mudah dipahami. Dalam banyak kasus, empat atau lima status sudah cukup, misalnya Draf, Menunggu persetujuan, Disetujui, Ditolak, dan Perlu perubahan. Jika dua label terasa hampir sama, hapus salah satunya.
Biasanya tidak. Status harus menunjukkan keadaan permintaan, bukan siapa yang menanganinya. Label seperti Menunggu persetujuan lebih jelas daripada Dengan keuangan, karena kepemilikan bisa berubah sementara keadaan tetap sama.
Berikan setiap langkah satu pemilik yang jelas dan satu cadangan. Jika penyetuju utama absen, cadangan harus mengambil alih berdasarkan aturan sederhana, misalnya setelah satu hari kerja atau segera setelah ketidakhadiran diketahui. Itu mencegah permintaan terdiam di limbo.
Tetapkan tanggal jatuh tempo untuk setiap tahap, bukan hanya untuk seluruh permintaan. Timer biasanya mulai saat permintaan masuk ke tahap itu. Jika tenggat lewat, tindakan selanjutnya harus sudah ditentukan, misalnya satu pengingat lalu eskalasi ke cadangan atau pimpinan tim.
Kembalikan melalui alur dengan status yang jelas seperti Perlu info lebih lanjut atau Menunggu pemohon. Jadikan pemohon sebagai pemilik aktif lagi dan jeda tenggat sampai detail yang hilang ditambahkan. Itu lebih rapi daripada menanganinya lewat email samping.
Tidak. Permintaan mendesak harus memiliki jalur terpisah tapi sempit. Batasi aturan agar orang tidak bisa menandai semuanya sebagai mendesak. Reservasikan untuk kasus jelas seperti dampak ke pelanggan, tenggat kepatuhan, atau pekerjaan yang sangat sensitif waktu.
Kesalahan paling umum adalah menyalin proses email persis seperti adanya. Masalah lain meliputi terlalu banyak status, terlalu banyak penyetuju, kepemilikan yang samar, dan aturan pengecualian yang baru ditentukan setelah peluncuran. Mulailah sederhana dan perbaiki langkah yang lemah terlebih dahulu.
Jalankan pilot kecil dengan satu tim dan satu jenis permintaan sebelum peluncuran penuh. Perhatikan di mana orang masih kembali ke email atau chat, lalu perbaiki status, alih-tangan, dan tenggat. Jika ingin memprototaip alat persetujuan internal dengan cepat, Koder.ai bisa membantu mengubah alur bahasa biasa menjadi alat kerja tanpa siklus pembangunan panjang.