AI Tools9 menit baca

Bisakah satu kalimat membuat alur persetujuan kontrak di Box?

Box Architect dimulai dari hasil bisnis yang diinginkan. Contoh penerimaan kontrak menunjukkan apa yang bisa dirancang dan apa yang masih perlu diputuskan pemilik proses.

K
Ken Jo

Tim penjualan menerima kontrak vendor dengan lampiran bernama “final”. Nilai pembelian tercantum pada jadwal di halaman 13. Kolom yurisdiksi kosong, dan peninjau yang ditunjuk sedang tidak ada. Siapa pun yang pernah menangani permintaan itu tahu berapa banyak pekerjaan yang tersembunyi di balik instruksi “kirim kontrak untuk disetujui”. Langkahnya tersebar di dokumen kebijakan, kebiasaan tim, dan pertimbangan orang yang pertama membuka berkas.

Box, platform pengelolaan konten perusahaan, memperkenalkan Box Architect di BoxWorks pada 5 November 2026. Produk yang diumumkan berawal dari hasil yang dijelaskan dalam bahasa sehari-hari dan menggunakan prosedur serta konten yang sudah tersimpan di Box untuk mengusulkan alur kerja. Box mengatakan Architect akan merangkai komponen pendukung seperti formulir, templat metadata, agen, dan aplikasi, lalu menampilkan hambatan untuk dipertimbangkan pemilik proses. Perusahaan mengatakan peluncuran beta bagi pelanggan Enterprise Advanced akan dimulai pada kuartal keempat 2026. Pengumuman dan ketersediaan BoxWorks

Draf pertama alur kerja bisa lebih mudah dibuat. Pekerjaan yang bernilai adalah menentukan cara menangani kasus yang membuat proses gagal. Penerimaan kontrak adalah contoh yang cukup sempit untuk memperlihatkan keputusan yang perlu masuk draf, hal yang perlu diperiksa sebelum peluncuran, dan ukuran keberhasilan uji coba.

Bagian luar kantor pusat Box di Redwood City, California

Kantor pusat Box di Redwood City, difoto pada Maret 2017 oleh Jeanjung212. Foto kontekstual dipangkas dan diubah ukurannya, CC BY-SA 4.0. Sumber gambar · Lisensi.

Sasaran bisnis berubah menjadi draf yang bisa diperiksa

Panduan Box pada 5 November menjelaskan rangkaian perancangan, pembangunan, dan perbaikan. Proses dimulai dari hasil yang diinginkan dan prosedur organisasi yang ada. Architect mengusulkan tahap, keputusan, serta serah terima, lalu dapat merangkai komponen Box terkait. Perusahaan menyebut Box Forms, Extract, Automate, Apps, Doc Gen, dan Sign sebagai kemampuan yang mungkin digunakan. Pemilik proses bisa merevisi draf, mencoba kasus tepi, dan menambahkan tahap peninjauan serta persetujuan sebelum penerapan. Box juga menyebut produk akan menyarankan perbaikan setelah menemukan masalah seperti informasi yang berulang kali tidak lengkap. Pengumuman produk Box Architect

Alur kerja lebih mudah dipahami jika setiap langkah punya tindakan spesifik. Penerimaan mengambil berkas. Ekstraksi menemukan isian. Perutean menentukan peninjau. Persetujuan mencatat keputusan. Distribusi membagikan hasil yang disetujui kepada penerima berwenang. Langkah-langkah itu bisa memakai dokumen sama dengan konsekuensi berbeda. Seseorang mungkin dapat mengambil nilai pembelian dari kontrak meski hanya bagian pengadaan yang boleh menyetujuinya. Orang yang menyetujui pembelian pun belum tentu perlu memberi pihak luar akses ke seluruh folder.

Penerimaan kontrak melewati ekstraksi dan pemeriksaan kebijakan sebelum persetujuan atau antrean pengecualian

Contoh persetujuan kontrak memisahkan penerimaan, ekstraksi, perutean, dan keputusan. Ilustrasi orisinal oleh Telli.sh.

Instruksi awal dengan cakupan jelas bisa berbunyi seperti ini.

Terima perjanjian vendor yang masuk dan tentukan pemilik permintaan, jenis kontrak, nilai, dan yurisdiksi. Teruskan permintaan lengkap kepada pemilik yang tercantum dalam tabel perutean yang disetujui. Kirim isian yang hilang, nilai yang bertentangan, dan yurisdiksi yang belum dikenal ke peninjau yang ditunjuk. Tahan pembagian eksternal sampai orang yang berwenang menyetujui versi dan penerima yang tepat.

Instruksi itu lebih berguna jika merujuk ke kebijakan nyata. Tambahkan versi terkendali tabel perutean dan tentukan apa yang terjadi jika dua aturan berlaku. Jelaskan nilai mana yang dipakai, termasuk apakah mata uang dan masa kontrak memengaruhi ambang. Jika bagian hukum dan pengadaan sama-sama terlibat, tentukan apakah tinjauan berjalan paralel atau salah satunya harus menunggu. Usulan alur memberi orang sesuatu yang konkret untuk diperiksa sambil menyelesaikan pilihan itu.

Box menyatakan konten tetap berada di Box dengan izin dan kebijakannya. Tim perancang tetap perlu menguji dengan akun yang mewakili karyawan pengirim, peninjau, dan pengguna tanpa akses ke perjanjian. Artefak pentingnya adalah diagram alur yang disetujui, lengkap dengan masukan, serah terima, jalur pengecualian, dan pemilik keputusan. Dengan diagram itu, anggota baru bisa memahami apa yang terjadi pada berkas tanpa harus menyusun ulang percakapan dengan asisten. Pengumuman produk Box Architect

Antrean pengecualian membuktikan apakah desain bekerja

Bayangkan dua salinan perjanjian. Berkas unggahan menyebut total $49.500, sedangkan amendemen yang ditandatangani menaikkannya menjadi $52.000. Angka mudah diekstrak. Menentukan berkas mana yang mengendalikan persetujuan adalah tugas lain. Dalam contoh ini, kedua nilai perlu muncul dalam laporan pengecualian bersama halaman dan nama berkas sumber, lalu perutean otomatis berhenti. Jika alur memilih satu angka tanpa mempertahankan perbedaan itu, peninjau mungkin tidak pernah tahu ada nilai kedua.

Bayangkan juga catatan dengan isi yang tepat dan akses yang keliru. Seseorang punya izin meminta tinjauan tetapi melampirkan berkas di luar folder yang diizinkan. Orang itu perlu melihat permintaannya diblokir atau tidak lengkap tanpa mendapatkan pratinjau dokumen terbatas. Jika pemilik dokumen memindahkan berkas, tautan lama atau tugas persetujuan perlu berperilaku sesuai aturan akses organisasi. Perilaku ini perlu masuk uji coba karena penerapan di perusahaan jarang punya satu folder dengan akses sama bagi semua karyawan.

Kasus ketiga menguji penggantian. Pemberi persetujuan memilih versi 4, tetapi versi 5 tiba sesaat sebelum permintaan tanda tangan. Tentukan apakah tinjauan dibuka kembali, bagaimana versi 4 tetap terlihat dalam catatan audit, dan siapa yang bisa melanjutkan permintaan. Ini contoh keputusan persetujuan yang harus terikat pada versi tertentu. Ringkasan per klausul tetap bisa berguna, tetapi alur perlu menunjukkan persis perjanjian mana yang dicakup keputusan manusia.

Kasus ujiBukti yang dibutuhkan peninjauTindakan yang diharapkan saat uji coba
Perjanjian standarVersi dokumen, isian wajib, aturan peruteanTetapkan peninjau yang ditunjuk
Nilai bertentanganKedua angka dengan rujukan halaman atau berkasJeda dan minta klarifikasi
Berkas wajib dibatasiHasil pemeriksaan akses dan tindakan perbaikan yang diizinkanTahan alur tanpa menampilkan dokumen
Revisi baru datang setelah persetujuanVersi yang disetujui dan versi baruBuka kembali tinjauan atau ikuti aturan revisi yang terdokumentasi
Permintaan duplikat masuk dua kaliID permintaan yang ada dan cap waktu penerimaanTautkan atau tandai tanpa membuat persetujuan kedua

Permintaan dalam tabel adalah ilustrasi. Bangun uji coba dengan dokumen contoh yang jawabannya sudah diketahui dan campuran tata letak serupa dengan dokumen tim. Perjanjian satu halaman yang rapi berguna untuk menetapkan alur normal. Pindaian PDF yang diputar, lampiran multibahasa, atau kolom tanda tangan yang hilang menunjukkan apakah proses tetap bisa dipahami saat keyakinan ekstraksi turun.

Alur kedua dapat menguji apakah metode ini cocok di tim lain. Tim utang usaha bisa mengekstrak pengenal faktur dan membandingkan nilai dengan pesanan pembelian sebelum mengirim selisih untuk ditinjau. Pekerjaan itu memakai pola penerimaan yang sama dengan persetujuan kontrak, tetapi buktinya berbeda. Peninjau faktur memerlukan nomor pesanan, rincian item, dan aturan toleransi alih-alih ketentuan kontrak. Fokuskan uji pertama pada salah satu alur. Saat tim kedua mencoba metode sama, periksa apakah mereka bisa menggunakan ulang struktur penerimaan dan pengecualian sambil mengganti sumber terkendali serta persetujuannya. Itu tanda penggunaan ulang yang lebih berguna daripada diagram yang sekadar tampak mirip.

Beta Architect dan kontrol yang sudah tersedia memiliki jadwal berbeda

Dalam pengumuman 5 November, Box mengelompokkan beberapa produk di bawah otomatisasi alur berbasis agen dan perlindungan. Architect dijadwalkan mulai hadir dalam beta untuk pelanggan Enterprise Advanced. Box mengatakan kemampuan perlindungan ancaman yang baru akan tersedia bagi paket yang memenuhi syarat pada awal 2027. Box juga menyatakan kontrol keamanan agen sudah tersedia secara umum bagi pelanggan Shield dan Enterprise Advanced. Kontrol ini mencakup kebijakan berbasis klasifikasi, pembatasan tindakan melalui server Model Context Protocol milik Box, dan peringatan berbasis ambang. Periksa paket dan akses tenant sebelum menjadikan demo satu kemampuan sebagai dasar ekspektasi untuk kemampuan lain. Pengumuman peluncuran dan ketersediaan Box

Perbedaan ini penting untuk alur yang dapat membuat catatan atau membagikan berkas. Misalnya, Box mendokumentasikan aturan administratif MCP untuk tindakan tulis yang dipanggil agen AI eksternal. Administrator bisa memakai kontrol tersebut untuk membatasi operasi yang didukung pada jalur itu. Alur persetujuan bawaan Box tetap perlu diuji melalui komponen yang benar-benar digunakannya. Petakan setiap tindakan tulis ke komponen dan kebijakannya, lalu periksa hasil nyata dari peran yang menjalankannya. Dokumentasi Box Support untuk pembatas MCP

Merancang alur dan mengendalikan eksekusinya membawa biaya berbeda. Peninjau mungkin menghabiskan lebih sedikit waktu menghubungkan formulir dan metadata, tetapi lebih banyak waktu merapikan aturan dan menyiapkan dokumen uji. Jika kebijakan tersebar di versi lama, drive bersama, dan surel, perbaikan pertama mungkin berupa satu tabel perutean yang mutakhir. Alur yang dapat diulang membuat penyimpangan terlihat karena setiap pengecualian punya tujuan. Proses yang disetujui juga lebih cepat direvisi bila pergantian penanggung jawab hanya menyentuh satu aturan kecil dibandingkan selusin serah terima terpisah.

Beri pemilik alur satu perubahan kebijakan konkret untuk disimulasikan. Misalkan aturan pembelian baru menurunkan ambang tinjauan bagian hukum mulai 1 Desember. Kasus yang sudah ditinjau mungkin masih mengikuti aturan lama, sedangkan kiriman baru perlu mengikuti aturan baru. Catat cap waktu yang menentukan pilihan tersebut dan siapa yang boleh menyetujui perubahan. Simpan satu kontrak uji pada masing-masing sisi tanggal mulai berlaku. Jika revisi draf juga mengubah instruksi ekstraksi, ulangi pemeriksaan nilai dan mata uang secara terpisah agar tim dapat mengetahui apakah jalur baru muncul karena kebijakan atau karena dokumennya dibaca secara berbeda.

Bandingkan dua draf sebelum mengirim kontrak nyata

Uji coba membandingkan proses manual dan draf Architect pada set data uji yang sama sebelum pelepasan oleh manusia

Pakai paket uji dan aturan penilaian yang sama untuk proses manual dan draf Architect. Ilustrasi orisinal oleh Telli.sh.

  1. Pilih satu alur sempit. Mulai dengan satu unit bisnis dan satu jenis perjanjian. Catat proses saat ini dan pilih pemilik proses yang bisa menjawab pertanyaan tentang perutean dan eskalasi.
  2. Kumpulkan materi sumber yang disetujui. Catat versi kebijakan dan otorisasi yang boleh dipakai alur. Siapkan dokumen fiktif atau dokumen yang identitasnya telah dihilangkan dengan benar, termasuk pengecualian yang diketahui dan akun uji tanpa akses.
  3. Buat draf alur di tenant yang memenuhi syarat. Berikan sasaran dan prosedur terkait kepada Architect setelah akses beta tersedia. Tinjau formulir, metadata, perutean, dan keputusan yang diusulkan bersama pemiliknya. Nyatakan antrean pengecualian secara eksplisit.
  4. Ulangi kasus yang sama secara manual dan melalui draf. Nilai apakah setiap isian wajib berasal dari versi benar, apakah perutean sampai ke peran tepat, dan apakah informasi terbatas tetap terlindungi.
  5. Tinjau perubahan sebelum aktivasi. Catat draf awal, perubahan manual, pemberi persetujuan yang ditunjuk, dan cara kembali ke kondisi sebelumnya. Tempatkan pembagian atau penandatanganan nyata di balik persetujuan wajib. Pastikan perilaku ketika eksekusi diulang atau aturan berubah.

Pisahkan waktu pembuatan dari waktu operasional. Catat menit untuk membuat draf pertama yang layak dan menit untuk memperbaikinya setelah tinjauan awal. Saat mengulang kasus, catat proporsi kasus lengkap yang dirutekan dengan benar, proporsi pengecualian yang terdeteksi, dan jumlah keputusan yang harus dibatalkan manusia. Sertakan kasus tanpa izin meski jarang. Alur yang memproses 20 contoh mudah tetapi mengungkap satu perjanjian terbatas telah menunjukkan masalah yang harus diselesaikan sebelum dirilis.

Untuk gelombang nyata pertama, pertahankan cara manual menangani kiriman dan tentukan siapa yang bisa menghentikan eksekusi baru. Bandingkan catatan yang dilihat tim dengan yang dilihat pengirim. Keduanya perlu mengetahui apakah permintaan menunggu informasi, menunggu persetujuan, atau telah dikembalikan, dengan rincian sesuai akses masing-masing peran. Jika proses lebih mudah dibuat tetapi karyawan harus menebak ke mana kontraknya pergi, pekerjaan telah bergeser dari penyiapan ke dukungan.

Alur yang berguna bisa dijelaskan saat berhenti

Bagian paling menarik dari usulan Architect adalah desain yang bisa disunting antara sasaran bisnis dan proses yang berjalan. Pemilik proses mendapat bahan untuk dibahas dengan bagian hukum, pengadaan, dan TI sebelum kontrak sungguhan berpindah. Uji coba yang berhasil menjawab pertanyaan yang tetap penting setelah demo selesai. Ketika dokumen terhenti, bisakah pemilik proses mengetahui aturan mana yang menghentikannya, versi mana yang dilihat, dan siapa yang bisa mengambil tindakan berikutnya?

Sumber


Untuk menyimpan percakapan dan keputusan di balik pekerjaan dalam catatan yang dapat dicari, buat akun Telli.sh.


← Kembali ke blog