Pengecualian alur kerja bisnis: jalur yang menjaga pekerjaan tetap berjalan

Mengapa masalah alur kerja sehari-hari memerlukan jalur yang jelas

Sebagian besar alur kerja terlihat sederhana di diagram: seseorang mengirim permintaan, manajer menyetujuinya, lalu tim menyelesaikan pekerjaan. Dalam praktiknya, pekerjaan jarang mengikuti garis lurus itu. Formulir bisa datang tanpa pusat biaya, pelanggan dapat meminta pengecualian, atau pemberi persetujuan melewatkan tenggat waktu.

Tanpa jalur yang sudah ditentukan, proses akan terhenti. Orang mulai menyalin detail ke chat, mengirim email pengingat, atau membuat spreadsheet untuk melacak masalah. Permintaan asli menggantung, sementara beberapa orang menyimpan versi berbeda dari informasi yang sama.

Pengecualian alur kerja bisnis yang jelas menjaga permintaan tetap berada dalam proses. Alur kerja dapat meminta detail yang kurang dari pemohon, mengembalikan permintaan yang ditolak beserta alasannya, atau menetapkan tugas yang terlambat kepada penanggung jawab pengganti. Semua orang dapat melihat status saat ini dan siapa yang harus bertindak berikutnya.

Hal ini juga membuat laporan lebih berguna. Jika sepuluh permintaan pembelian menunggu kode anggaran, berarti formulir pengajuan memiliki masalah yang berulang. Jika permintaan sering masuk ke tinjauan manual, aturan persetujuan mungkin perlu disesuaikan. Pesan chat cenderung menyembunyikan pola seperti ini.

Kesalahan proses dan keputusan bisnis memerlukan penanganan yang berbeda. Kesalahan proses menghentikan alur kerja karena data wajib tidak ada atau tidak valid. Misalnya, karyawan mengirim klaim biaya tanpa tanda terima. Alur kerja seharusnya mengembalikan klaim tersebut dan menjelaskan apa yang harus ditambahkan karyawan.

Keputusan bisnis memerlukan pertimbangan. Pesanan mungkin melebihi batas pengeluaran normal, tetapi manajer dapat menyetujuinya karena pemasok membutuhkan komponen pengganti yang mendesak. Datanya lengkap, tetapi aturan saja tidak dapat menentukan hasilnya.

Jika kedua kasus diperlakukan sebagai «kesalahan» umum, kebingungan akan muncul. Pemohon mungkin tidak tahu apakah harus memperbaiki kolom, memberikan bukti, atau menunggu keputusan. Berikan setiap pengecualian nama yang mudah dipahami, penanggung jawab yang jelas, dan hasil yang sudah ditentukan.

Misalnya, alur kerja yang dibuat di AppMaster dapat mengembalikan permintaan yang belum lengkap kepada pengirimnya, sementara pengecualian kebijakan dikirim kepada manajer. Catatan permintaan tetap berada di satu tempat, bukan berpindah-pindah di antara kotak masuk. Pilihan sederhana ini dapat mengurangi banyak pekerjaan tindak lanjut.

Tentukan setiap pengecualian sebelum membangun alur kerja

Alur kerja memerlukan jalur yang jelas ketika kemajuan normal terhenti. Mulailah dengan empat pengecualian alur kerja bisnis yang umum: informasi yang kurang, permintaan yang ditolak, pekerjaan yang terlambat, dan kasus yang memerlukan tinjauan manual. Masing-masing membutuhkan aturan sendiri, bukan status samar seperti «terjadi masalah».

Untuk setiap pengecualian, catat pemicu, penanggung jawab, tenggat waktu, dan tindakan berikutnya. Dengan begitu, permintaan tidak akan terjebak dalam antrean hanya karena tidak ada yang tahu siapa yang harus merespons.

Tentukan sejak awal apakah setiap jalur mengembalikan pekerjaan kepada pemohon atau mengakhiri permintaan. Informasi yang kurang biasanya dikembalikan kepada orang yang mengirimkannya. Permintaan yang ditolak dapat dikembalikan untuk diperbaiki, tetapi permintaan yang melanggar kebijakan tetap sebaiknya ditutup dengan alasan yang jelas. Staf tidak perlu menebak apakah mereka boleh mengirim ulang.

Gunakan nama status yang menggambarkan keadaan saat ini. «Menunggu pemohon», «Ditolak», «Terlambat», dan «Memerlukan tinjauan manual» lebih baik daripada label seperti «Pengecualian 2» atau «Menunggu tindakan». Orang yang melihat daftar harus langsung memahami apa yang terjadi dan siapa yang perlu memindahkan item tersebut ke tahap berikutnya.

Tetapkan tenggat waktu untuk pengecualian itu sendiri, bukan hanya untuk permintaan awal. Misalnya, beri pemohon waktu dua hari kerja untuk mengunggah faktur yang kurang. Jika mereka tidak merespons, alur kerja dapat mengirim pengingat dan kemudian menutup permintaan setelah periode yang ditentukan. Dengan begitu, pekerjaan lama tidak menumpuk tanpa terlihat.

Dalam aplikasi tanpa kode, buat pengecualian sebagai perubahan status yang terlihat dan jalur terpisah dalam proses bisnis. Business Process Editor visual dari AppMaster dapat memetakan keputusan, menetapkan penanggung jawab, dan mengarahkan permintaan ke langkah berikutnya. Gunakan istilah yang sama dalam daftar status, notifikasi, dan layar staf.

Arahkan permintaan yang kekurangan informasi

Permintaan dengan kolom kosong tidak seharusnya berada dalam antrean yang sama dengan pekerjaan yang siap disetujui. Berikan status yang jelas, seperti «Menunggu informasi», lalu keluarkan dari jalur persetujuan aktif. Orang dapat melihat alasan kemajuan terhenti, bukan mengira peninjau melewatkan permintaan tersebut.

Status ini harus memicu pesan langsung kepada pemohon. Hindari catatan samar seperti «Detail tambahan diperlukan». Sebutkan item yang kurang dan jelaskan seperti apa jawaban yang dapat diterima: «Silakan lampirkan penawaran pemasok dan masukkan biaya bulanan sebelum kami meninjau permintaan pembelian ini.»

Biarkan permintaan asli tetap terbuka dan dapat diedit. Pemohon seharusnya dapat menambahkan penawaran atau memperbaiki tanggal tanpa mengetik ulang departemen, kode anggaran, dan deskripsi. Jalur penanganan pengecualian alur kerja yang baik mempertahankan detail yang sudah diperiksa, komentar, serta waktu ketika status permintaan berubah.

Buat jalur pengembalian yang jelas

Setelah pemohon menambahkan informasi yang kurang, kirim permintaan ke langkah berikutnya yang sudah ditentukan. Biasanya, permintaan kembali kepada orang yang meminta detail tersebut. Jika informasi baru mengubah keputusan, permintaan mungkin perlu kembali ke tahap persetujuan pertama.

Catat kolom atau dokumen yang kurang, orang yang bertanggung jawab untuk menjawab, peninjau yang memeriksa pembaruan, tenggat waktu respons, dan alasan penutupan jika permintaan berakhir. Catatan ini membantu menjawab pertanyaan di kemudian hari. Manajer dapat melihat bahwa permintaan faktur menunggu dokumen pajak, bukan menyalahkan bagian keuangan karena persetujuan yang lambat.

Gunakan pengingat dan aturan penutupan

Tetapkan pengingat sebelum tenggat waktu respons. Satu pengingat setelah dua hari kerja dan satu lagi pada tanggal jatuh tempo adalah pola yang praktis. Kirim pengingat kepada pemohon, lalu tembuskan kepada manajernya hanya jika proses memang memerlukan eskalasi.

Pengecualian alur kerja bisnis juga memerlukan titik akhir. Jika tidak ada respons setelah periode tertentu, tutup permintaan sebagai «Tidak lengkap» dan catat alasannya. Jangan menghapusnya. Pemohon mungkin membutuhkan riwayat tersebut ketika mengirim permintaan baru.

Alat alur kerja tanpa kode seperti AppMaster dapat menyimpan status permintaan, mengirim notifikasi, dan mengarahkan formulir yang telah diperbarui kembali kepada peninjau melalui proses bisnis visual. Rekan kerja harus dapat melihat apa yang kurang, siapa yang harus bertindak, dan apa yang terjadi jika tidak ada tindakan.

Tangani permintaan yang ditolak tanpa kehilangan konteks

Permintaan yang ditolak tidak boleh menghilang di kotak masuk atau di balik label status yang samar. Orang yang mengirimkannya perlu mengetahui apa yang gagal, siapa yang mengambil keputusan, dan apakah masalahnya dapat diperbaiki. Manajer juga membutuhkan catatan yang sama ketika pertanyaan muncul di kemudian hari.

Simpan alasannya dalam kolom terstruktur, bukan hanya komentar bebas. Formulir permintaan pembelian dapat menyediakan alasan seperti «Anggaran tidak tersedia», «Permintaan duplikat», «Persetujuan kurang», atau «Pelanggaran kebijakan». Tambahkan kolom komentar singkat untuk detail yang tidak tercakup oleh alasan yang dipilih.

Hal ini membuat laporan lebih mudah digunakan. Manajer dapat melihat apakah sebagian besar permintaan gagal karena staf tidak mengisi pusat biaya atau karena kebijakan membingungkan. Cara ini juga mencegah peninjau menulis beberapa versi alasan yang sama, seperti «melebihi anggaran» dan «anggaran terlalu tinggi».

Permintaan yang ditolak memiliki tiga kemungkinan hasil. Kembalikan untuk diperbaiki jika pemohon dapat memperbaiki masalah, seperti penawaran yang tidak ada, alasan bisnis yang kurang jelas, atau jumlah yang salah. Tutup jika permintaan melanggar aturan yang telah ditetapkan, seperti menggunakan pemasok yang tidak disetujui atau melebihi batas yang diizinkan. Kirim kasus yang belum jelas ke tinjauan manual ketika manajer atau pemilik kepatuhan perlu mengambil keputusan.

Permintaan yang dikembalikan harus mempertahankan detail asli, lampiran, dan jejak persetujuannya. Minta pemohon mengedit permintaan yang sudah ada, bukan membuat permintaan lain. Alur kerja dapat mengubah status menjadi «Perubahan diminta», menetapkannya kembali kepada pemohon, lalu mengirim alasan penolakan dan komentar peninjau yang dipilih.

Ketika pemohon mengirim ulang, catat versi baru dan kirimkan kepada peninjau yang sesuai. Pertahankan penolakan sebelumnya dalam riwayat. Riwayat itu menjelaskan alasan permintaan terhenti dan menunjukkan apakah pemohon sudah menangani masalahnya.

Permintaan yang ditutup juga memerlukan penanganan yang baik. Simpan pemohon, peninjau, tanggal keputusan, kode penolakan, catatan, dan bukti terlampir dalam satu catatan. Pemohon seharusnya dapat melihat permintaan tertutup miliknya, sementara manajer dapat melihat riwayat lengkap timnya.

Di AppMaster, model data dapat mencakup status permintaan, alasan penolakan, catatan peninjau, tanggal keputusan, dan tabel riwayat. Proses bisnis visual dapat mengembalikan permintaan yang masih dapat diperbaiki kepada pemohon dan menutup pelanggaran kebijakan secara otomatis. Perbaikan rutin tetap berjalan, sementara keputusan akhir tetap terdokumentasi.

Tetapkan aturan untuk tugas yang terlambat

Tenggat waktu harus sesuai dengan pekerjaan, bukan menggunakan pengatur waktu yang sama untuk setiap tugas. Manajer mungkin membutuhkan satu hari kerja untuk menyetujui biaya rutin, sedangkan tinjauan legal mungkin memerlukan lima hari. Kapasitas tim juga penting. Tenggat waktu dua jam tidak banyak membantu jika orang yang ditugaskan menghabiskan sebagian besar harinya melayani pelanggan.

Tuliskan aturan tenggat waktu dalam alur kerja. Jelaskan kapan waktu mulai dihitung, apakah akhir pekan ikut dihitung, dan kejadian apa yang menandai tugas selesai. Aturan yang jelas mencegah perdebatan ketika permintaan datang terlambat pada Jumat sore atau menunggu informasi dari tim lain.

Kirim pengingat sebelum tenggat waktu. Pengingat saat 75% waktu yang tersedia telah berlalu sering memberi penanggung jawab cukup waktu untuk bertindak. Untuk tugas lima hari, kirim pengingat pada hari keempat. Sertakan nama tugas, waktu jatuh tempo, penanggung jawab saat ini, dan tindakan yang diperlukan. Pesan «Anda memiliki tugas yang tertunda» tidak banyak membantu.

Ketika tenggat waktu terlewati, tetapkan tindakan berikutnya kepada orang atau peran tertentu yang memiliki wewenang untuk memutuskan. Jangan kirim pekerjaan terlambat ke kotak masuk umum. Cara itu menyamarkan tanggung jawab dan sering menimbulkan tugas terlambat lainnya.

Hasilnya harus sesuai dengan jenis keterlambatan. Jeda permintaan jika tugas yang terlambat menghambat keputusan yang aman, seperti pemeriksaan kepatuhan yang belum selesai. Alihkan tugas jika penanggung jawab awal sedang tidak hadir atau tidak memiliki kapasitas. Lanjutkan dengan peringatan yang terlihat jika keterlambatan tidak menghambat langkah berikutnya, seperti catatan internal yang terlambat. Lakukan eskalasi kepada manajer jika keterlambatan memengaruhi janji kepada pelanggan, pembayaran, atau tenggat waktu eksternal.

Tetapkan batas untuk eskalasi berulang. Permintaan pembelian dapat berpindah dari pembeli kepada pimpinan pengadaan setelah satu pengingat terlambat, lalu kepada manajer keuangan setelah satu hari kerja berikutnya. Riwayat permintaan harus tetap utuh agar penanggung jawab baru dapat melihat komentar dan lampiran sebelumnya.

Pengecualian alur kerja bisnis membutuhkan lebih dari sekadar peringatan. Pengecualian memerlukan penanggung jawab, aturan keputusan, dan hasil yang tercatat. Di AppMaster, proses bisnis visual dapat mengarahkan tugas terlambat kepada orang yang tepat dan menjaga permintaan tetap berjalan tanpa spreadsheet tenggat waktu terpisah.

Tambahkan langkah tinjauan manual yang mudah digunakan

Sebagian permintaan tidak cocok dengan aturan. Nama pemasok mungkin terlihat asing, biaya mungkin melebihi batas normal, atau dua kolom mungkin saling bertentangan. Kasus seperti ini memerlukan keputusan seseorang, bukan rute otomatis.

Jaga agar proses tinjauan manual tetap terarah. Kirim hanya permintaan yang memang membutuhkan pertimbangan dan tampilkan alasan pengalihannya. Status samar seperti «Memerlukan tinjauan» menambah pekerjaan karena peninjau harus mencari tahu sendiri alasan alur kerja terhenti.

Berikan konteks yang cukup kepada peninjau

Layar tinjauan harus menampilkan permintaan asli, kolom atau aturan yang memicu pengecualian, komentar sebelumnya, dan file pendukung. Manajer yang menyetujui pembelian harus dapat melihat jumlah, pemasok, kode anggaran, pemohon, dan penawaran di satu tempat.

Berikan pilihan yang sesuai dengan jalur alur kerja berikutnya: setujui dan teruskan permintaan, tolak dan tutup, kembalikan kepada pemohon untuk diperbaiki, atau teruskan kepada orang atau tim tertentu. Minta alasan singkat untuk setiap keputusan pengecualian. «Melebihi anggaran» atau «Penawaran yang ditandatangani tidak ada» membantu pemohon bertindak dan meninggalkan catatan bagi peninjau berikutnya. Persetujuan rutin tidak memerlukan penjelasan panjang.

Tetapkan batas waktu untuk keputusan

Pekerjaan manual dapat berubah menjadi tugas terlambat jika tidak ada yang memiliki keputusan tersebut. Tetapkan tenggat waktu saat alur kerja menetapkan peninjau, misalnya dua hari kerja untuk permintaan pembelian standar. Kirim pengingat sebelum tenggat waktu, lalu arahkan permintaan kepada peninjau pengganti atau manajer jika orang yang ditugaskan tidak tersedia.

Hindari mengirim permintaan yang sama kepada semua orang secara bersamaan, kecuali siapa pun di antara mereka memang memiliki wewenang mengambil keputusan. Cara itu dapat menghasilkan jawaban yang bertentangan. Tetapkan satu penanggung jawab terlebih dahulu, catat setiap tindakan, dan kunci permintaan setelah keputusan akhir.

Di AppMaster, Business Process dapat mengarahkan pengecualian ke tugas tinjauan, menyimpan keputusan dan komentar, lalu melanjutkan melalui jalur persetujuan, penolakan, atau permintaan perubahan yang terpisah. Tugas tetap terhubung dengan permintaan asli, sehingga orang tidak perlu menyusun ulang riwayat dari email.

Contoh: permintaan pembelian yang keluar dari jalur

Seorang staf mengirim permintaan pembelian monitor baru senilai $2.400. Permintaan tersebut berisi daftar barang dan departemen, tetapi penawaran pemasok tidak ada. Alih-alih mengirimnya kepada manajer, alur kerja mengubah status menjadi «Menunggu informasi» dan menetapkan tugas berikutnya kepada pemohon.

Pemohon menerima pesan yang menyebutkan dokumen yang kurang dan memberikan tanggal jatuh tempo. Manajer tidak menerima permintaan yang belum lengkap, sehingga antrean persetujuan tetap berguna. Setelah pemohon mengunggah penawaran, alur kerja mencatat waktu unggah, mengubah status menjadi «Siap ditinjau anggaran», dan mengirim permintaan kepada penanggung jawab keuangan.

Bagian keuangan memeriksa sisa anggaran departemen dan menolak permintaan karena jumlahnya melebihi batas bulanan. Alur kerja permintaan yang ditolak mempertahankan formulir asli, penawaran, komentar, dan riwayat persetujuan dalam satu tempat. Statusnya berubah menjadi «Ditolak karena anggaran», dan pemohon menerima pembaruan yang jelas: «Kurangi pesanan menjadi $1.800 atau tunggu hingga bulan depan.»

Pemohon menghapus dua unit monitor lalu mengirim ulang permintaan. Alur kerja membuat tugas tinjauan keuangan baru, bukan meminta pemohon memulai dari awal. Bagian keuangan menyetujui jumlah yang telah diperbaiki. Status berubah menjadi «Menunggu persetujuan manajer», dan manajer menerima tugas dengan riwayat lengkap penolakan sebelumnya.

Ketika persetujuan datang terlambat

Manajer memiliki waktu dua hari kerja untuk merespons. Pada hari kedua, alur kerja mengirim pengingat. Jika tenggat waktu terlewati, manajemen tugas terlambat mengubah status menjadi «Persetujuan manajer terlambat» dan menetapkan tugas eskalasi kepada pimpinan tim manajer tersebut.

Pemohon juga menerima pembaruan. Mereka dapat melihat bahwa permintaan sedang menunggu keputusan yang dieskalasikan, lengkap dengan tenggat waktu awal dan waktu eskalasi dalam catatan permintaan.

Pimpinan tim menyetujui pesanan setelah memeriksa catatan anggaran dan penawaran pemasok. Alur kerja mengubah status permintaan menjadi «Disetujui untuk pembelian», menetapkan bagian pembelian untuk menempatkan pesanan, dan memberi tahu pemohon bahwa pesanan dapat dilanjutkan.

Contoh ini menunjukkan mengapa pengecualian alur kerja bisnis memerlukan status dan penanggung jawabnya sendiri. Setiap cabang memberi tahu satu orang apa yang harus dilakukan berikutnya, sementara pemohon menerima pembaruan tanpa harus mengejar orang lewat chat. Setelah bagian pembelian menutup pesanan, catatan tetap menyimpan permintaan penawaran yang kurang, penolakan keuangan, pengajuan ulang, persetujuan yang terlambat, dan keputusan akhir.

Kesalahan umum saat membangun jalur pengecualian

Tim sering membangun jalur normal terlebih dahulu, lalu menambahkan satu rute serba guna untuk semua hal lainnya. Rute itu biasanya berakhir pada manajer yang sudah sibuk. Detail yang kurang, permintaan yang ditolak, dan persetujuan yang terlambat membutuhkan orang serta tindakan yang berbeda. Mengirim semuanya ke satu kotak masuk menimbulkan keterlambatan dan menyembunyikan pola yang sebenarnya dapat diperbaiki tim.

Gunakan nama yang menjelaskan apa yang terjadi dan apa yang harus dilakukan. «Masalah» dan «Perlu perhatian» memaksa peninjau membuka setiap item sebelum memahaminya. Label seperti «Penawaran pemasok kurang», «Ditolak oleh bagian keuangan», atau «Persetujuan terlambat dua hari» memberi titik awal yang berguna kepada orang berikutnya.

Beberapa aturan desain dapat mencegah pengecualian berubah menjadi kejar-kejaran email:

• Arahkan setiap pengecualian kepada penanggung jawab yang dapat bertindak, serta penanggung jawab pengganti saat terjadi ketidakhadiran.
• Beri tahu penanggung jawab sebelum tenggat waktu terlewati, lalu lakukan eskalasi jika tidak ada respons.
• Minta peninjau memilih alasan dan menambahkan catatan singkat sebelum menolak, mengembalikan, atau menyetujui item.
• Pertahankan permintaan asli, lampiran, dan komentar sebelumnya ketika seseorang meminta perbaikan.
• Catat kapan pengecualian dimulai, siapa yang menanganinya, dan kapan pengecualian berakhir.

Tenggat waktu yang tidak terlihat menimbulkan masalah tertentu. Tugas dapat tidak tersentuh selama berhari-hari karena semua orang mengira orang lain yang bertanggung jawab. Aturan manajemen tugas terlambat harus memberi tahu penerima tugas terlebih dahulu, lalu supervisor yang namanya jelas setelah periode tertentu. Gunakan aturan yang dapat diukur, misalnya satu pengingat setelah 24 jam dan eskalasi setelah 48 jam.

Langkah tinjauan juga membutuhkan batasan. Jika peninjau dapat mengambil keputusan apa pun tanpa mencatat alasannya, proses tinjauan manual akan sulit diperbaiki. Seiring waktu, tim mungkin melihat permintaan yang sama terus dikembalikan tanpa mengetahui apakah masalahnya biaya, kebijakan, bukti yang kurang, atau kolom formulir yang salah.

Pertahankan permintaan ketika dikembalikan untuk diperbaiki. Pemohon harus dapat melihat alasan penolakan di samping informasi yang dikirim, memperbarui hanya kolom yang terdampak, lalu mengirim ulang catatan yang sama. Memulai permintaan baru menghilangkan konteks, menggandakan pekerjaan, dan melemahkan laporan tentang alur kerja permintaan yang ditolak.

Penanganan pengecualian alur kerja yang baik meninggalkan catatan yang dapat dipahami dengan cepat. Catatan tersebut menunjukkan apa yang gagal, siapa yang memiliki tindakan berikutnya, dan alasan permintaan berubah arah.

Pemeriksaan singkat dan langkah berikutnya

Pengecualian alur kerja tidak boleh meninggalkan permintaan dalam antrean tanpa nama. Untuk setiap jalur pengecualian, tentukan peristiwa yang memulainya, orang yang bertanggung jawab, dan tindakan yang mengakhirinya. Dengan begitu, pengecualian alur kerja bisnis berubah menjadi pekerjaan rutin, bukan penyelidikan mendadak.

Sebelum menerbitkan alur kerja, pastikan setiap pengecualian memiliki pemicu yang jelas, seperti kolom wajib yang kosong, penolakan, atau tenggat waktu yang terlewat. Tetapkan satu penanggung jawab untuk tindakan berikutnya, meskipun beberapa orang dapat melihat permintaan. Pesan harus menjelaskan apa yang terjadi, apa yang harus dilakukan penerima, dan kapan tindakan itu harus dilakukan. Pastikan staf yang perlu bertindak dapat melihat status saat ini dan riwayat keputusan, lalu arahkan pekerjaan terlambat kepada orang atau peran tertentu, bukan kotak masuk umum.

Uji jalur dengan kasus yang realistis. Kirim permintaan tanpa lampiran. Tolak permintaan dengan alasan. Biarkan persetujuan melewati tenggat waktunya. Kemudian periksa apakah orang yang tepat menerima pesan yang berguna dan dapat menyelesaikan tugas tanpa meminta konteks tambahan.

Alur kerja permintaan yang ditolak juga memerlukan jalur kembali kepada pemohon. Simpan permintaan asli, alasan penolakan, dan catatan peninjau secara bersamaan. Pemohon harus dapat memperbaiki masalah dan mengirim ulang, bukan membuat catatan duplikat yang kehilangan keputusan sebelumnya.

Untuk manajemen tugas terlambat, tentukan apa yang terjadi setelah setiap tenggat waktu terlewat. Pengingat pertama dapat dikirim kepada pemilik tugas. Eskalasi berikutnya dapat dikirim kepada manajer atau peninjau pengganti. Jangan mengirim pengingat tanpa batas. Tetapkan titik ketika seseorang harus menyelesaikan, mengalihkan, memperpanjang, atau menutup tugas.

AppMaster memungkinkan tim membuat rute ini dengan proses bisnis visual. Tim dapat memodelkan perubahan status, tenggat waktu, notifikasi, persetujuan, dan tinjauan manual tanpa menulis logika alur kerja dengan tangan. Mulailah dengan satu proses bervolume tinggi, uji kasus pengecualian bersama orang yang menggunakannya, dan sesuaikan rute ketika pekerjaan nyata menunjukkan celah.

Tinjau alur kerja setelah beberapa minggu pertama. Hitung pengecualian yang paling sering terjadi dan baca catatan dari tinjauan manual. Jika detail yang sama terus menyebabkan keterlambatan, ubah formulir permintaan atau tambahkan pemeriksaan lebih awal. Perbaikan kecil di awal mencegah pengecualian menumpuk kemudian.