Alur persetujuan kontrak untuk tim penjualan dan hukum

Mengapa penjualan dan hukum butuh alur persetujuan bersama

Kontrak paling sering macet saat serah terima antara penjualan dan hukum. Penjualan berusaha mempertahankan momentum dengan pelanggan. Tim hukum berusaha mengurangi risiko dan menjaga konsistensi klausul. Tanpa alur persetujuan kontrak bersama, serah terima berubah menjadi permainan tebak-tebakan: siapa yang bertanggung jawab langkah berikutnya, apa yang berubah, dan apa arti "disetujui" sebenarnya.

Kerugian sebenarnya jarang pada negosiasi itu sendiri. Yang hilang sepanjang jalan lebih merusak: versi terakhir, redline tepatnya, alasan sebuah klausul diterima, dan siapa yang mengambil keputusan. Saat riwayat itu tersebar di utas email dan nama file seperti "v7-final-FINAL," tim membuang waktu membaca ulang, mengirim ulang, dan memperdebatkan keputusan yang sudah dibuat.

Beberapa gejala muncul cepat:

• File duplikat beredar dengan suntingan sedikit berbeda
• Kepemilikan tidak jelas saat hukum menunggu penjualan (atau sebaliknya)
• Perubahan mengejutkan di akhir siklus yang membuka kembali debat lama
• "Disetujui" berarti hal berbeda bagi orang yang berbeda

Alur bersama yang baik terlihat membosankan — dan itu hal yang baik. Ada satu tempat untuk memeriksa status saat ini, versi saat ini, dan tindakan berikutnya yang diperlukan. Siapa pun harus bisa menjawab tiga pertanyaan dalam 10 detik: Kita berada di tahap apa? Siapa yang bertanggung jawab sekarang? Apa yang menghalangi tanda tangan?

Jika pelanggan meminta pengecualian pada ketentuan pembayaran standar Anda, tim penjualan tidak boleh hanya meneruskan lampiran baru dan berharap hukum melihat satu kalimat yang berubah. Permintaan itu harus membuat tugas jelas, merutekan redline ke pemeriksa yang tepat, dan mencatat keputusan. Banyak tim menangani ini dengan alat internal sederhana sehingga kedua pihak bekerja dari catatan yang sama.

Orang dan tanggung jawab (siapa melakukan apa)

Alur persetujuan kontrak bekerja terbaik ketika semua orang tahu dua hal: apa yang mereka miliki, dan apa yang mereka diizinkan untuk ubah. Jika peran kabur, Anda mendapatkan suntingan mengejutkan, redline yang hilang, dan persetujuan yang sebenarnya tidak terjadi.

Mulailah dengan menamai peran inti dan "tingkat kewenangan" mereka dalam proses. Menyunting berbeda dari menyetujui, dan keduanya berbeda dari menandatangani.

Peran tipikal dan kepemilikan yang jelas

Kebanyakan tim berakhir dengan seperangkat pemilik yang mirip:

• Perwakilan penjualan: membuat permintaan, menyusun syarat komersial, dan menjawab pertanyaan bisnis
• Manajer penjualan: menyetujui diskon, syarat non-standar, dan risiko kesepakatan sebelum hukum menghabiskan waktu
• Penasihat hukum: menyunting bahasa kontrak, menangani redline, dan memutuskan klausul mana yang bisa dinegosiasikan
• Keuangan: menyetujui ketentuan pembayaran, detail penagihan, pajak, penanda pengakuan pendapatan, dan risiko kredit
• Penandatangan yang berwenang: menandatangani hanya setelah semua persetujuan yang diperlukan selesai

Buat satu aturan eksplisit: hanya tim hukum yang menyunting bahasa hukum. Penjualan dapat mengusulkan perubahan (di komentar atau formulir intake), tetapi mereka tidak boleh menulis ulang klausul secara langsung. Demikian juga, hukum tidak boleh mengubah harga atau ruang lingkup tanpa melibatkan penjualan kembali.

Apa yang harus disediakan penjualan sejak awal

Review hukum berjalan lebih cepat ketika penjualan mengirimkan paket lengkap: nama hukum pelanggan, jumlah dan durasi kesepakatan, ruang lingkup produk, harga dan diskon, ekspektasi SLA, kebutuhan keamanan khusus, dan klausul "harus ada" dari pelanggan. Ketidakhadiran informasi dasar adalah alasan paling umum kontrak dikembalikan.

Sepakati waktu respons dan eskalasi. Misalnya, hukum merespons dalam 1 hari kerja untuk dokumen standar dan 3 hari untuk syarat non-standar. Jika waktu habis, jalur eskalasi harus jelas (pemimpin hukum, lalu manajer penjualan, lalu penandatangan).

Saat Anda mengatur ini dalam alat alur persetujuan kontrak, peta tanggung jawab ke izin sehingga proses menegakkan aturan secara otomatis. Tim kadang membangun aplikasi internal semacam ini di AppMaster, di mana Anda bisa menetapkan peran, izin, dan persetujuan tanpa menulis kode backend lengkap.

Definisikan model status sederhana dari draft hingga ditandatangani

Alur persetujuan kontrak bekerja terbaik ketika semua orang dapat menjawab satu pertanyaan dalam hitungan detik: "Saat ini kontrak ini berada di status apa, dan apa langkah selanjutnya?" Buat model sederhana, dan biarkan setiap status berarti satu hal yang jelas.

Berikut alur status praktis yang bisa Anda gunakan:

Buat aturan masuk dan keluar terlihat di dalam alur kerja, bukan hanya "pengetahuan tribal." Misalnya, "Disetujui" harus berarti harga, durasi, batas tanggung jawab, dan ketentuan data lolos pemeriksaan internal Anda, bukan sekadar "hukum sudah melihatnya."

Sertakan juga beberapa status realitas agar keterlambatan tidak tersembunyi di komentar:

• Blocked (butuh info internal atau keputusan)
• Menunggu pelanggan (dikirim, belum ada respons)
• Dijeda (kesepakatan ditangguhkan)

Jika Anda menerapkannya di alat, modelkan status sebagai satu bidang dengan nilai yang diizinkan secara ketat, dan wajibkan alasan saat memindahkan ke Blocked atau Dijeda. Pengaman kecil itu mencegah kontrak "misterius macet" dan menjaga penjualan serta hukum selaras.

Aturan versi yang mencegah “file mana yang final?”

Alur persetujuan kontrak runtuh cepat jika orang tidak bisa membedakan dokumen mana yang terbaru. Perbaikan termudah adalah memilih satu sumber kebenaran dan perlakukan yang lain sebagai salinan. Sumber ini bisa berupa catatan kontrak tempat file terbaru, status, dan komentar disimpan.

Buat satu aturan yang tidak boleh dinegosiasikan: hanya ada satu versi "Current" pada suatu waktu. Ketika revisi baru dibuat, versi sebelumnya diarsipkan dan dikunci. Orang masih bisa melihatnya, tetapi tidak bisa mengedit atau mengirimkannya ulang.

Aturan penamaan yang konsisten membantu bahkan ketika file diemail atau diunduh. Buat mudah diprediksi:

• Nama kesepakatan atau pelanggan (singkat)
• Jenis kontrak (MSA, NDA, Order Form)
• Nomor versi (v01, v02, v03)
• Tanggal (YYYY-MM-DD)
• Tag status (Clean atau Redline)

Redline pelanggan biasanya tempat kebingungan dimulai. Simpan dua file untuk setiap revisi: salinan redline yang menunjukkan suntingan dan salinan bersih yang merefleksikan perubahan yang diterima sejauh ini. Penjualan dapat membaca syarat bersih dengan cepat, dan hukum dapat melihat persis apa yang bergerak.

Tambahkan catatan perubahan singkat pada setiap revisi, ditulis untuk manusia. Satu kalimat cukup: "Mengubah batas tanggung jawab menjadi 12 bulan biaya sesuai permintaan pelanggan." Ini mencegah perdebatan ulang dan mempermudah serah terima saat seseorang sedang tidak di tempat.

Contoh: Penjualan mengirim "Acme MSA v01 2026-01-25 Clean." Pelanggan mengembalikan suntingan disimpan sebagai "Acme MSA v02 2026-01-27 Redline," dan hukum menghasilkan "Acme MSA v02 2026-01-27 Clean" plus catatan perubahan. Dari situ, v03 hanya dimulai jika ada yang berubah lagi.

Apa yang dikumpulkan sebelum review hukum dimulai

Review hukum berjalan lebih cepat saat dimulai dengan paket lengkap, bukan email setengah isi dan tiga lampiran "terbaru." Sebelum mengirim apa pun ke hukum, kumpulkan input yang sama setiap kali. Ini mengurangi bolak-balik dan menjaga alur persetujuan kontrak Anda terduga.

Mulailah dengan dasar kesepakatan yang memengaruhi risiko dan bahasa:

• Nama hukum pelanggan dan entitas penandatangan (plus negara/negara bagian)
• Nilai kesepakatan dan bentuk penagihan (sekali vs berulang, diskon)
• Durasi kontrak, perpanjangan/otomatis perpanjangan, dan periode pemberitahuan pemutusan
• Tanggal pengiriman atau tanggal mulai, plus tingkat layanan yang dijanjikan
• Klausul khusus yang diminta (keamanan, tanggung jawab, data, IP, eksklusivitas)

Selanjutnya, lampirkan dokumen sebenarnya sebagai satu bundel review: perjanjian utama plus setiap adendum, lampiran, order form, dan redline pelanggan jika sudah ada. Ikat bundel ini ke catatan kontrak yang sama seperti status dan riwayat versi.

Lalu buat kebutuhan persetujuan eksplisit sebelum hukum membaca kata pun. Tetapkan pemicu sederhana sehingga penjualan tahu apa yang akan memerlukan tanda tangan ekstra:

• Nilai kesepakatan melebihi ambang tertentu
• Ketentuan pembayaran non-standar (net 60/90, penagihan milestone, pengembalian dana)
• Perubahan batas tanggung jawab, perluasan indemnitas, atau jaminan yang tidak biasa
• Ketentuan pemrosesan data atau keamanan di luar posisi standar Anda
• Klausul apa pun yang ditandai "diperlukan pelanggan" yang tidak disetujui sebelumnya

Terakhir, beri hukum tempat untuk menggunakan kembali bahasa yang sudah disetujui. Bahkan perpustakaan klausul kecil yang disetujui mengurangi penulisan ulang paragraf yang sama setiap kali.

Contoh: Kontrak tahunan $45k dengan perpanjangan otomatis dan klausul tanggung jawab tanpa batas yang diminta pelanggan harus diajukan dengan file redline lengkap, detail perpanjangan, dan kebutuhan persetujuan keuangan dan pimpinan yang sudah diidentifikasi. Hukum kemudian bisa fokus pada keputusan, bukan berburu informasi.

Langkah demi langkah: alur persetujuan kontrak yang praktis

Alur persetujuan kontrak yang baik bisa diprediksi. Semua orang harus tahu apa yang terjadi selanjutnya, siapa yang memiliki langkah berikutnya, dan apa arti "selesai."

Dari draft ke review hukum

Penjualan memulai draft menggunakan template yang benar dan mengisi detail kesepakatan yang diperlukan (nama akun, harga, durasi, tanggal mulai, produk, dan tanggal target close). Jika ada yang hilang, kontrak tidak boleh maju.

Sebelum hukum melihatnya, jalankan beberapa pemeriksaan otomatis. Buat sederhana agar orang mempercayainya:

• Bidang yang wajib belum terisi
• Template yang salah atau klausul usang
• Nilai kesepakatan atau durasi memicu persetujuan tambahan
• Ketentuan pembayaran non-standar
• Tambahan privasi data atau addendum keamanan diperlukan

Jika draft lolos pemeriksaan, rute ke hukum dengan permintaan yang jelas, misalnya "hanya review" vs "setujui redline," plus catatan singkat tentang apa yang didorong pelanggan.

Dari redline ke penandatanganan

Hukum meninjau dan mengembalikan redline. Penjualan bernegosiasi dengan pelanggan, tetapi setiap pengiriman ke pelanggan harus dilacak sebagai revisi baru. Gunakan satu tempat untuk komentar agar keputusan tidak terkubur di email.

Pola revisi yang dapat diulang membantu:

• Buat versi baru untuk setiap pengiriman ke pelanggan
• Catat siapa yang mengubah dan mengapa
• Simpan redline terlampir ke versi itu
• Perbarui status segera setelah dikirim
• Tetapkan tanggal jatuh tempo untuk respons berikutnya

Saat pelanggan setuju, kirim versi akhir untuk persetujuan internal (keuangan, keamanan, penandatangan eksekutif) berdasarkan ambang yang Anda tetapkan. Penandatangan harus meninjau syarat final dan riwayat persetujuan, bukan utas yang berantakan.

Lalu pindahkan kontrak ke penandatanganan (e-sign atau manual). Setelah ditandatangani, kunci catatan, simpan salinan eksekusi, dan tandai sebagai ditandatangani agar pelaporan tetap akurat.

Aturan persetujuan, ambang, dan penanganan pengecualian

Alur persetujuan kontrak bekerja terbaik ketika persetujuan tidak berdasarkan siapa yang paling keras bersuara. Tuliskan aturan sederhana agar penjualan bisa memprediksi jalurnya, dan hukum bisa fokus pada risiko alih-alih mengejar orang.

Mulailah dengan seperangkat ambang kecil yang mudah diingat. Kaitkan ke ukuran kesepakatan, risiko, dan perubahan kebijakan, bukan preferensi pribadi. Sebagai panduan umum: hukum menyetujui bahasa, keuangan menyetujui perubahan yang memengaruhi aliran uang, dan keamanan/IT menyetujui perubahan yang memengaruhi data dan sistem.

Tentukan pemicu yang memerlukan persetujuan, seperti:

• Persetujuan keuangan: ketentuan pembayaran non-standar, diskon di atas persen tertentu, pengembalian dana, kredit, atau jadwal penagihan baru
• Persetujuan pimpinan: batas tanggung jawab di bawah minimum Anda, indemnitas tanpa batas, hak pemutusan yang tidak biasa, atau klausul referensi publik
• Persetujuan keamanan/IT: tipe data baru, sub-processor baru, atau kuesioner keamanan pelanggan
• Persetujuan pimpinan penjualan: komitmen tanggal pengiriman di luar kapasitas normal
• Persetujuan hukum: perubahan hukum yang mengatur, kerahasiaan, IP, atau pembatasan tanggung jawab

Pengecualian adalah sumber waktu hilang. Putuskan di muka bagaimana menangani kesepakatan mendesak, dokumen pelanggan, dan klausul non-standar. Anda bisa mengizinkan jalur dipercepat, namun wajibkan eskalasi lebih ketat dan catatan risiko tertulis. Kecepatan tidak boleh menghapus pertanggungjawaban.

Definisikan apa arti "disetujui dengan kondisi." Itu tidak boleh berupa anggukan samar. Artinya kontrak bisa lanjut hanya jika kondisi tertentu dipenuhi dan dilacak, misalnya "pelanggan menerima addendum DPA kami" atau "keuangan mengonfirmasi jadwal prabayar." Simpan setiap kondisi sebagai item checklist dengan pemilik dan tanggal jatuh tempo.

Tetapkan pemicu eskalasi jelas agar pekerjaan tidak macet:

• Tidak ada respons setelah 2 hari kerja untuk review standar
• Klausul berisiko tinggi ditemukan (mis. indemnitas tanpa batas) dengan eskalasi hari yang sama
• Tanggal penutupan kesepakatan dalam 72 jam dan review belum dimulai
• Lebih dari 2 putaran redline tanpa kemajuan

Jejak audit, komentar, dan notifikasi yang efektif

Jika orang tidak bisa melihat apa yang terjadi dan mengapa, alur persetujuan kontrak berubah menjadi obrolan samping, tangkapan layar, dan pengiriman ulang file. Perbaikannya sederhana: rekam keputusan di tempat kontrak disimpan.

Jejak audit harus menjawab tiga pertanyaan tanpa perlu bertanya: apa yang berubah, siapa melakukannya, dan kapan. Log perpindahan status (Draft ke Dalam review hukum), persetujuan atau penolakan, dan tindakan kunci seperti "redline diunggah" atau "dikirim ke pelanggan." Buat otomatis agar tidak dilewatkan saat hari sibuk.

Komentar berguna, tapi hanya ketika mencatat keputusan. Gunakan untuk menjelaskan "mengapa," bukan menyembunyikan ketentuan penting. Jika tanggal perpanjangan, diskon, atau batas tanggung jawab penting, simpan di bidang terstruktur (atau area ringkasan singkat) sehingga dapat dicari dan dilaporkan.

Aturan komentar sederhana membuat utas lebih mudah dibaca:

• Tuliskan keputusan dan alasannya (setuju, tolak, minta perubahan)
• Tandai klausul atau bagian (misalnya, "Ketentuan Pembayaran, Bagian 3")
• Hindari menempelkan seluruh teks kontrak ke komentar
• Letakkan syarat yang dinegosiasikan di bidang yang dapat dilacak, bukan di obrolan
• Tutup proses dengan pemilik berikutnya ("Kembali ke Penjualan untuk respons pelanggan")

Notifikasi harus keras hanya ketika tindakan diperlukan: saat kontrak berpindah tangan, redline tiba, persetujuan diminta, atau tenggat berisiko. Semua sisanya bisa berupa ringkasan harian (mis. "3 kontrak menunggu Penjualan" atau "2 menunggu Hukum"). Terlalu banyak notifikasi membuat orang mengabaikannya.

Terakhir, simpan item terkait pada catatan: email kunci, catatan panggilan, dan poin negosiasi. Ketika seseorang baru masuk di tengah transaksi, mereka harus memahami riwayat dalam lima menit.

Contoh: satu kontrak bergerak dari draft ke ditandatangani

Seorang perwakilan penjualan menutup kesepakatan mid-market senilai $85k ARR. Pelanggan meminta diskon 12% dan ingin mengubah batas tanggung jawab dari 12 bulan biaya menjadi 24 bulan. Ini kasus umum di mana penjualan, hukum, dan pelanggan semua menyentuh dokumen yang sama.

Tim menggunakan alur persetujuan kontrak sederhana dengan status jelas dan satu tempat untuk melacak file saat ini.

Berikut bagaimana kontrak ini bergerak:

• Draft (Penjualan): Penjualan memulai dari template terbaru, mengisi syarat, dan mengunggah sebagai v01. Status tetap Draft sampai semua bidang wajib lengkap.
• Dalam review hukum: Penjualan mengajukan draft dengan konteks. Hukum memberi redline dan komentar, lalu mengunggah v02.
• Dalam negosiasi: Penjualan mengirim v02 ke pelanggan. Pelanggan mengembalikan salinan dengan tanda yang meminta perubahan batas tanggung jawab. Penjualan mengunggahnya sebagai v03 (redline pelanggan).
• Disetujui: Hukum menerima bahasa diskon tapi menolak cap 24 bulan dan mengusulkan kompromi. Setelah syarat fallback disetujui secara internal, hukum menandai kontrak Disetujui dan v04 menjadi salinan bersih yang disetujui.

Saat momen rumit datang: setelah ditandai Disetujui, pelanggan mengirim redline "kecil" (mengubah pemberitahuan pemutusan). Aturan sederhana: redline baru apa pun membuka kembali review. Penjualan mengunggah v05 (redline pelanggan setelah persetujuan) dan status kembali ke Dalam review hukum, dengan persetujuan sebelumnya tercatat tetapi tidak lagi berlaku.

Untuk memastikan versi akhir yang ditandatangani, tim mengunci satu file sebagai Final for Signature, mencatat ID versinya (mis. v06), dan mewajibkan paket tanda tangan menggunakan file itu. Jika salinan yang dikembalikan saat ditandatangani berbeda, status berubah menjadi Blocked (atau Exception jika Anda menggunakan label itu) sampai tim menyelesaikannya sebelum menandatangani balik.

Kesalahan umum yang memperlambat persetujuan kontrak

Cara tercepat membuat kontrak macet adalah membiarkan pekerjaan keluar dari alur. Jika redline hidup di utas email, seseorang akan melewatkan perubahan, membalas pesan yang salah, atau meneruskan lampiran usang. Bahkan dengan niat baik, suntingan "hanya lewat email" menciptakan pekerjaan tersembunyi dan keputusan yang tidak jelas.

Pemblokir umum lain adalah memulai review hukum dengan dasar yang hilang. Jika detail kesepakatan tersebar di chat, catatan CRM, dan PDF draft, hukum akhirnya melakukan pekerjaan detektif. Itu menambah bolak-balik dan membuat penjualan merasa hukum "lambat," padahal draft sebenarnya belum siap.

Beberapa pelaku ulang yang sering muncul di sebagian besar tim:

• Perubahan dibuat di luar alat atau proses yang disepakati, sehingga tidak ada yang melihat apa yang berubah atau mengapa.
• Detail yang diperlukan dibiarkan kosong (entitas pelanggan, durasi, model harga, penanganan data), sehingga hukum harus mengejarnya.
• Sebuah kesepakatan "disetujui" tanpa mengonfirmasi file/versi tepat yang ditinjau dan diterima.
• Label status berlipat ganda ("Legal Review," "Legal Reviewing," "Review - Legal," "Pending"), sehingga orang berhenti mempercayai status.
• Tidak ada pemilik jelas ditetapkan untuk tindakan berikutnya, sehingga kontrak tetap diam meskipun semua orang mengira orang lain yang menanganinya.

Status yang terlalu rumit sangat licik. Jika daftar status lebih panjang daripada langkah yang sebenarnya diambil orang, itu menjadi permainan tebak-tebakan. Jaga label sederhana dan berbasis tindakan, dan pastikan setiap status memiliki langkah berikutnya yang jelas.

Terakhir, waspadai serah terima tanpa pemilik. Contoh: Penjualan mengirim draft yang direvisi jam 6 sore, menandainya "diperbarui," dan mengira hukum akan mengambilnya. Hukum mengira penjualan masih mengumpulkan info yang hilang. Tidak ada yang terjadi sampai pelanggan menanyakan pembaruan.

Alat hanya membantu jika menegakkan dasar: satu versi saat ini, bidang wajib sebelum pengiriman, dan pemilik berikutnya yang terlihat.

Daftar periksa cepat dan langkah berikutnya untuk menerapkan alur

Alur persetujuan kontrak bekerja ketika siapa pun bisa menjawab empat pertanyaan dalam beberapa detik: versi mana yang saat ini, siapa pemiliknya, apa langkah berikutnya, dan apa yang dihitung sebagai "selesai".

Pemeriksaan cepat (kapan pun Anda membuka kontrak)

• Versi saat ini diberi label jelas dan sesuai dengan redline terbaru
• Pemilik saat ini dinamai (satu orang, bukan tim)
• Langkah berikutnya eksplisit (review hukum, persetujuan keuangan, tanda tangan pelanggan)
• Persetujuan yang diperlukan terlihat (berdasarkan nilai, durasi, risiko)
• Metode penandatanganan dikonfirmasi (e-sign, tinta basah, atau keduanya)

Sebelum mengirim apa pun ke pelanggan, lakukan cek kebenaran cepat. Konfirmasi harga, diskon, dan ketentuan pembayaran sesuai dengan penawaran. Periksa kembali tanggal (mulai, perpanjangan, periode pemberitahuan) dan ketentuan non-standar. Validasi nama hukum dan alamat kedua belah pihak, dan pastikan setiap lampiran yang dirujuk disertakan (order form, DPA, SOW, addendum keamanan).

Sebelum menandai kontrak sebagai ditandatangani, pastikan Anda memiliki PDF eksekusi final (bukan tangkapan layar draft). Pastikan halaman tanda tangan lengkap, nama cocok dengan penandatangan, dan inisial yang diperlukan ada. Simpan di sistem catatan yang disepakati dan tangkap lokasi penyimpanan di catatan kesepakatan agar mudah ditemukan nanti.

Langkah berikutnya untuk menerapkan alur ini

Tetapkan nama status dan kriteria keluar, buat satu formulir intake agar penjualan menyerahkan paket lengkap, dan tuliskan ambang persetujuan (durasi, persen diskon, batas tanggung jawab). Lalu bangun aplikasi alur kerja internal ringan yang mencakup tabel kontrak, bidang status, penugasan "pemilik saat ini," dan checklist wajib untuk pengajuan.

Jika Anda menginginkan opsi tanpa kode yang masih menghasilkan aplikasi siap produksi, AppMaster (appmaster.io) sering dipakai untuk alur kerja internal seperti ini: Anda bisa memodelkan data, mengatur persetujuan, dan merutekan tugas antara penjualan, hukum, dan keuangan tanpa bergantung pada utas email panjang.