Kasus penggunaan
Bangun alur persetujuan dengan rekayasa berbantuan AI
Ubah persetujuan utas email menjadi sebuah sistem: permintaan bertipe, perutean berbasis ambang, delegasi, eskalasi — dan catatan yang bertahan saat audit bertanya.
Ciao adalah platform rekayasa berbantuan AI enterprise untuk membangun alur persetujuan — aplikasi yang menerima permintaan bertipe, merutekannya berdasarkan aturan seperti ambang jumlah dan departemen, mengumpulkan keputusan, dan mencatat semuanya dalam log append-only. Berbeda dari persetujuan yang dijalankan lewat email, setiap keputusan punya penyetuju, stempel waktu, dan versi persis yang ditinjau. Perubahan alur kerja itu sendiri melewati tinjauan Guardrails, QA otomatis, dan pengujian keamanan sebelum merge.
Dipublikasikan 2026-07-03 · Terakhir diperbarui 2026-07-03
Persetujuan adalah sistem, bukan balasan
Alur persetujuan melakukan empat hal: menerima permintaan, merutekannya ke orang yang tepat, mengumpulkan keputusan, dan mencatat semuanya. Kebanyakan perusahaan menjalankan ini lewat email — di mana balasan "kelihatannya oke" adalah kontrolnya. Tak seorang pun bisa mengatakan di kemudian hari versi mana yang disetujui, apakah kebijakan ambang diterapkan, atau mengapa sebuah permintaan duduk selama sembilan hari di inbox seseorang saat mereka sedang cuti.
Kesenjangan itu menjadi mahal saat waktu audit tiba. Auditor bertanya tiga hal: siapa yang menyetujui ini, apa persis yang mereka lihat, dan apakah kebijakan yang dinyatakan diterapkan? Email tidak menjawab satu pun dengan andal. Begitu pula utas chat, dan begitu pula spreadsheet dengan kolom "disetujui?".
Ciao membangun alur persetujuan sebagai aplikasi nyata: formulir permintaan bertipe, aturan perutean tertulis dalam kode, delegasi dan eskalasi yang menangani kalender nyata, dan catatan append-only dari setiap keputusan. Disiplin yang sama berlaku untuk alur kerja itu sendiri — mengubah aturan perutean atau ambang adalah perubahan kode tergovernansi dengan tinjauan tercatat, bukan edit senyap.
Apa yang sebenarnya dibutuhkan alur persetujuan
- Formulir permintaan bertipe — Permintaan belanja, akses, kontrak, dan pengecualian masing-masing menangkap field yang benar-benar dibutuhkan keputusan — tervalidasi saat entri.
- Aturan perutean — Berdasarkan ambang jumlah, departemen, pusat biaya, region, atau peran — deterministik, berversi, dan bisa dibaca saat dipersoalkan.
- Rantai multi-langkah — Penyetuju berurutan, penyetuju paralel, dan aturan kuorum untuk keputusan yang butuh lebih dari satu tanda tangan.
- Delegasi dan di luar kantor — Persetujuan dirutekan ulang saat seseorang sedang pergi — dengan delegasinya sendiri tercatat.
- Timer SLA dan eskalasi — Permintaan yang duduk terlalu lama dieskalasi otomatis; pelaporan cycle-time menunjukkan di mana sesuatu macet.
- Konteks pada permintaan — Komentar, lampiran, dan rekam tertaut hidup pada permintaan, sehingga penyetuju memutuskan dari bukti, bukan ingatan.
- Log keputusan append-only — Siapa menyetujui apa, kapan, dan versi persis yang mereka lihat — tak berubah, bisa diekspor, bisa diaudit.
- Tindakan saat persetujuan — Integrasi yang membuat PO, menyediakan akses, atau memperbarui ERP begitu keputusan mendarat — menutup loop-nya.
Bagaimana build alur persetujuan berjalan di Ciao
1. Tuliskan kebijakannya
"Belanja di bawah 1.000 butuh manajer; di atas 10.000 menambahkan finance; vendor baru selalu menambahkan procurement." Aturan itu, dinyatakan secara sederhana, menjadi spesifikasinya.
2. Hasilkan formulir dan perutean
Jenis permintaan, field, peran, dan perutean mendarat sebagai skema Supabase dan kode perutean yang bisa dibaca.
3. Tangani kalender manusia
Delegasi, aturan di luar kantor, timer eskalasi, dan ritme pengingat — bagian yang tak pernah ditangani email.
4. Sambungkan konsekuensinya
Permintaan yang disetujui bertindak: PO di ERP, akses disediakan di sistem IT, kontrak dipindahkan ke tanda tangan — melalui integrasi terkendali.
5. Uji keputusan dan batasnya
QA memutar ulang rantai persetujuan, tepi ambang, dan batas izin — termasuk jalur di mana seseorang mencoba menyetujui permintaannya sendiri.
6. Govern aturannya sendiri
Kode perutean dan ambang adalah area terlindungi Guardrails: kebijakan berbahasa sederhana, deteksi risiko, tinjauan manusia tercatat pada setiap perubahan.
7. Deploy dan laporkan
Kirim ke cloud Anda, VPC privat, atau on-prem. Pelaporan cycle-time dan bottleneck datang dari data yang sama.
Checklist keamanan dan governansi
- ✓ Pemohon tidak bisa menyetujui permintaan mereka sendiri — ditegakkan dan diuji
- ✓ Pemisahan tugas dipetakan ke jenjang peran di backend
- ✓ Log keputusan append-only dengan penyetuju, stempel waktu, dan versi yang ditinjau
- ✓ Perubahan pada aturan perutean dan ambang memerlukan tinjauan Guardrails tercatat
- ✓ SSO melalui SAML atau OIDC; tautan persetujuan mengautentikasi, tidak pernah melewati
- ✓ Probe kontrol akses dijalankan terhadap aplikasi langsung sebelum penandaan dipercaya
- ✓ Delegasi dan eskalasi tercatat berdampingan dengan keputusan
- ✓ Deployment ke VPC privat atau on-prem di mana kebijakan mewajibkannya
Variasi alur persetujuan
Persetujuan belanja
Requisition dirutekan berdasarkan jumlah dan pusat biaya, dengan konteks anggaran pada permintaan dan PO dibuat saat disetujui.
Persetujuan kontrak
Sign-off legal, finance, dan bisnis secara berurutan, dengan versi dokumen persis dikunci ke setiap keputusan.
Permintaan akses IT
Permintaan akses berbasis peran dengan persetujuan pemilik, pemberian time-boxed, dan jejak tinjauan untuk resertifikasi.
Persetujuan brand dan kampanye
Tinjauan kreatif dengan aset berversi, komentar markup, dan catatan siapa mengloloskan apa untuk peluncuran.
Requisition perekrutan
Permintaan headcount dirutekan melalui manajer, finance, dan HR, terikat ke aturan anggaran dan grade.
Register pengecualian kebijakan
Pengecualian diminta, dijustifikasi, dibatasi waktu, dan disetujui — dengan pengingat kedaluwarsa alih-alih pengecualian senyap permanen.
Kebutuhan persetujuan, terpenuhi
| Kebutuhan | Cara Ciao memenuhinya |
|---|---|
| Penyetuju yang tepat setiap kali | Aturan perutean deterministik berversi dalam kode yang bisa dibaca |
| Ketidakhadiran tidak menghentikan permintaan | Delegasi, perutean ulang di luar kantor, dan eskalasi SLA |
| Bukti audit | Log append-only: penyetuju, stempel waktu, versi persis yang ditinjau |
| Tanpa persetujuan sendiri | Pemisahan peran ditegakkan di backend dan diuji dalam pemutaran ulang QA |
| Keputusan memicu tindakan | Integrasi membuat PO, menyediakan akses, memperbarui sistem pencatatan |
| Perubahan aturan terkendali | Tinjauan Guardrails tercatat sebelum perubahan perutean atau ambang di-merge |
| Lingkungan terbatas | Opsi deployment cloud sendiri, VPC privat, atau on-prem |
Pertanyaan yang sering diajukan
Bagaimana kami mencegah seseorang menyetujui permintaannya sendiri?
Pemisahan peran ditegakkan di backend — mesin perutean mengecualikan pemohon dari rantainya sendiri — dan pemutaran ulang QA mencakup percobaan persetujuan-sendiri sebagai kasus kegagalan yang diuji. Probe kontrol akses mengonfirmasi batasnya pada aplikasi langsung.
Apa yang sebenarnya didapat auditor?
Log append-only per permintaan: pemohon, penyetuju, stempel waktu, versi persis yang dilihat setiap penyetuju, komentar, dan lampiran. Di sisi engineering, jejak audit juga mencakup siapa yang mengubah aturan alur kerja itu sendiri dan siapa yang meninjau perubahan itu.
Bisakah pengguna bisnis mengubah aturan perutean dengan aman?
Perubahan aturan dideskripsikan dalam bahasa sederhana tetapi dikirim sebagai perubahan kode tergovernansi: Guardrails mendeteksi bahwa sebuah ambang atau aturan perutean bergeser, menerapkan kebijakan berbahasa sederhana Anda, dan mencatat tinjauan manusia sebelum merge. Perubahannya cepat — dan tercatat.
Bisakah persetujuan memicu tindakan di sistem ERP atau IT kami?
Ya. Permintaan yang disetujui bisa membuat purchase order, menyediakan akses, atau memperbarui rekam melalui integrasi terkendali, dan sandbox kustom memungkinkan pekerjaan integrasi itu terjadi terhadap backend Rails, Java, Go, Python, dan Node.
Bisakah ini berjalan di dalam batas jaringan kami?
Ya — akun AWS, Azure, atau GCP Anda sendiri, VPC privat, atau on-prem di bawah ketentuan terpisah, dengan SSO melalui SAML atau OIDC dan MFA opsional.
Berapa biayanya?
Alur persetujuan biasanya adalah bagian dari program governansi yang lebih luas alih-alih satu aplikasi tunggal. Program pengembangan serius dimulai dari USD 10.000 per tahun; sales bisa melingkupkan lanskap persetujuan Anda — belanja, akses, kontrak — dalam satu percakapan.
Halaman terkait
Pengembangan serius dimulai dengan tanggung jawab serius.
Bangun Alur Persetujuan dengan Rekayasa Berbantuan AI | Ciao