Aplikasi deal desk untuk persetujuan diskon yang dipercaya tim penjualan

Mengapa persetujuan diskon berantakan tanpa deal desk

Persetujuan diskon berantakan ketika berada di thread chat dan email yang tersebar. Seorang perwakilan meminta "pengecualian cepat", seseorang menjawab "oke", dan seminggu kemudian tak ada yang ingat apa yang disetujui, mengapa disetujui, atau syarat apa yang melekat.

Masalah biasanya dimulai kecil, lalu menumpuk:

• Detail penting hilang (diskon, jangka waktu, tanggal mulai, klausul khusus).
• Keputusan terjadi secara pribadi, sehingga tim lain tidak melihat apa yang terjadi.
• Persetujuan menjadi tidak konsisten (orang yang salah menandatangani, atau orang menyetujui versi yang berbeda).

Diskon menyentuh lebih banyak orang daripada yang diperkirakan banyak tim. Sales memiliki deal, tapi finance peduli margin dan syarat pembayaran, manajer peduli konsistensi, dan legal peduli risiko kontrak. Tanpa satu tempat untuk berkoordinasi, setiap deal menjadi kasus istimewa.

Aplikasi deal desk memperbaiki ini dengan memberi semua orang satu jalur bersama: kirim permintaan, rute ke pemberi persetujuan yang tepat, tangkap keputusan yang jelas, dan simpan untuk nanti. Tujuannya bukan menambah birokrasi. Tujuannya menghentikan pekerjaan ulang dan "persetujuan berdasarkan ingatan."

Contohnya dalam kenyataan: seorang perwakilan menawarkan 20% untuk memenangkan pembaruan, lalu procurement meminta 25% plus syarat net-60. Di chat, manajer mungkin menyetujui "25% oke," sementara finance kemudian keberatan karena syarat pembayaran mengubah ekonomi transaksi. Dengan alur permintaan dan persetujuan yang tepat, perwakilan mengirim paket lengkap sekali, orang yang tepat meninjau versi yang sama, dan jawaban akhir menjadi tidak ambigu.

Anda akan tahu ini berhasil ketika sales mendapat jawaban lebih cepat, pengecualian menit terakhir berkurang, argumen tentang "apa yang disepakati" hilang, dan Anda akhirnya memiliki data bersih untuk dilaporkan.

Tentukan apa yang harus ditangkap formulir permintaan Anda

Formulir permintaan diskon harus menjawab satu pertanyaan dengan cepat: apakah deal ini layak disetujui pada harga ini?

Mulailah dengan set minimum field yang membuat pemberi persetujuan memahami deal tanpa harus menyisir spreadsheet:

• Nama pelanggan dan segmen (baru vs. existing, ukuran)
• Produk/paket, lama kontrak, dan kuantitas
• Harga daftar dan harga yang diminta (hitung otomatis % diskon)
• Perkiraan tanggal close dan tanggal mulai
• Pemilik deal dan tim

Angka saja tidak menjelaskan mengapa diskon diberikan. Tambahkan sedikit konteks terstruktur, plus satu kotak catatan singkat. Contohnya: dropdown untuk alasan utama (menyamakan kompetisi, risiko pembaruan, ekspansi, pilot), field untuk pesaing utama, dan kotak catatan untuk detail seperti "Pesaing menawarkan 25% jika kita tanda tangan minggu ini."

Guardrail mencegah permintaan berkualitas rendah memenuhi antrean. Fokus pada beberapa persyaratan yang benar-benar mengurangi pekerjaan ulang:

• Justifikasi wajib yang terikat ke kode alasan (beberapa kalimat, bukan "butuh diskon untuk menang")
• Bukti hanya diperlukan di atas ambang tertentu (kutipan, lembar harga, email pesaing)
• Cara yang jelas untuk menandai pengecualian (bundle, syarat khusus, deal sensitif)

Buat formulir tetap cepat dengan menjadikan wajib hanya kolom yang benar-benar digunakan. Jika sebuah field jarang memengaruhi keputusan, buat itu opsional atau wajib bersyarat (mis. minta "pesaing" hanya ketika alasan adalah "menyamakan kompetisi").

Tentukan aturan akses sejak awal: siapa yang dapat mengirim (semua sales vs. Sales Ops), dan siapa yang dapat melihat permintaan (pemohon, manajer, finance, deal desk). Izin penting ketika catatan berisi margin, risiko pembaruan, atau masalah pelanggan.

Tetapkan tingkatan diskon dan aturan persetujuan yang akan diikuti orang

Persetujuan diskon berantakan ketika aturannya kabur. Orang menebak, persetujuan bolak-balik, dan hasil bergantung pada siapa yang sedang online.

Mulailah dengan tingkatan yang sesuai dengan bagaimana bisnis Anda memandang risiko. Buat sederhana agar sales bisa melayani dirinya sendiri:

• 0 hingga 10%: manajer sales
• 11 hingga 20%: manajer sales + finance
• 21 hingga 30%: direktur sales + finance
• 31% ke atas: persetujuan eksekutif

Lalu tambahkan sejumlah kecil aturan override untuk hal-hal yang benar-benar mengubah ekonomi atau risiko: new logo vs. renewal, jangka waktu multi-tahun, akun strategis, bahasa kontrak non-standar, dan syarat pembayaran non-standar. Jadikan override eksplisit sehingga renewal 15% tidak diperlakukan sama dengan new logo 12%.

Tetapkan pemberi persetujuan berdasarkan peran, bukan nama. Peran bertahan saat cuti dan perubahan organisasi. Untuk setiap tingkatan, definisikan siapa yang harus menyetujui dan dalam urutan apa. Finance biasanya memeriksa margin dan syarat pembayaran; legal harus terlibat hanya ketika syarat berubah atau risiko meningkat. Jika legal diperlukan untuk setiap permintaan, persetujuan melambat dan orang mencari jalan pintas.

Sales bekerja dengan tenggat, jadi ekspektasi respon penting. Tetapkan target yang jelas seperti "respon pertama dalam 4 jam kerja," plus rencana cadangan (delegasi, on-call rotation, atau eskalasi setelah waktu tertentu).

Jadikan alasan keputusan wajib sehingga hasil berguna nanti. Buat konsisten dan singkat:

• Disetujui: diskon dan kondisi apa pun ("20% disetujui, jangka waktu 2 tahun")
• Ditolak: alasan spesifik ("margin di bawah batas")
• Perlu perubahan: apa yang perlu diubah ("kurangi ke 15% atau tambahkan prepay tahunan")

Bangun formulir permintaan yang ramah sales

Jika perwakilan menghindari formulir, persetujuan akan kembali ke chat dan Anda kehilangan catatan.

Buat formulir dapat ditebak dan sulit salah isi. Gunakan label yang jelas, default cerdas, dan daftar pilihan daripada teks bebas bila memungkinkan (tipe deal, wilayah, mata uang). Hapus apa pun yang tidak mempengaruhi keputusan atau pelaporan.

Buat singkat, tapi minta follow-up yang tepat

Formulir tercepat menggunakan pertanyaan kondisional. Tanyakan diskon dulu, lalu tampilkan hanya yang diperlukan untuk tingkatan itu.

Follow-up umum yang efektif:

• Diskon lebih tinggi: minta justifikasi lebih kuat dan (jika relevan) detail pesaing
• Syarat khusus: kumpulkan catatan kontrak dan rute ke legal jika diperlukan
• Syarat pembayaran non-standar: sertakan detail untuk finance
• Deal multi-tahun: tangkap trade-off (komitmen, rencana pembaruan)

Validasi input sebelum sampai ke pemberi persetujuan

Pemberi persetujuan seharusnya tidak harus menolak kesalahan dasar. Tambahkan pemeriksaan sederhana (diskon dalam rentang, tanggal close tidak di masa lalu, justifikasi wajib untuk diskon besar). Jika Anda punya floor margin, validasi terhadapnya.

Perbaikan kecil tapi berdampak tinggi adalah "preview sebelum submit." Tunjukkan kepada perwakilan tingkatan yang diperkirakan dan siapa yang akan diminta untuk menyetujui. Contoh: "Diskon 22%: Manajer Sales + Finance." Itu mencegah kejutan dan mengurangi bolak-balik.

Buat dapat digunakan di ponsel: tata letak satu kolom, target ketuk besar, dan field teks pendek.

Langkah demi langkah: rute persetujuan dari pengiriman sampai keputusan

Alur routing yang baik terasa tak terlihat bagi sales. Mereka mengirim satu permintaan, mendapat jawaban jelas cepat, dan selalu tahu langkah selanjutnya.

Alur praktis yang bisa diadopsi kebanyakan tim:

1. Buat permintaan dan hitung tingkatan secara otomatis. Hitung persentase diskon dari harga daftar vs. harga yang ditawarkan, lalu peta ke tingkatan di aplikasi sehingga perwakilan tidak menebak.
2. Tugaskan pemberi persetujuan berdasarkan tingkatan dan tipe deal. Tingkat rendah mungkin ke manajer sales; tingkatan lebih tinggi menambahkan finance; tipe deal tertentu (renewal, multi-tahun, strategis) bisa diarahkan ke antrean berbeda.
3. Beritahu pemberi persetujuan dengan ringkasan jelas dan aksi sederhana. Sertakan angka kunci, alasan, dan catatan pendukung. Buat aksi jelas: Approve, Reject, Request changes.
4. Tangani revisi tanpa harus mulai dari awal. Jika perlu perubahan, kembalikan ke perwakilan dengan komentar wajib. Pertahankan ID permintaan yang sama sehingga semua orang tetap selaras.
5. Eskalasi ketika waktu respon terlewat. Jika seseorang tidak merespon tepat waktu, eskalasi ke backup atau delegasi.

Saat keputusan final dibuat, tutup permintaan, beri tahu pemangku kepentingan (perwakilan, manajer, finance, deal desk), dan kunci field yang tidak boleh diubah setelah persetujuan.

Catat setiap keputusan untuk jejak audit yang bersih

Persetujuan cepat penting, tapi catatan sama pentingnya. Anda ingin jejak yang menjawab: siapa yang menyetujui, kapan, berdasarkan informasi apa, dan apa yang berubah sepanjang proses?

Catat setiap perubahan status sebagai event, bukan hanya hasil akhir. Setiap event harus mencakup stempel waktu dan orang (atau sistem) yang melakukan perubahan.

Tangkap hal-hal yang benar-benar Anda perlukan nanti:

• Riwayat status (Submitted, Returned, Approved, Rejected, Expired) dengan waktu dan pelaku
• Detail keputusan (diskon yang disetujui, kondisi, komentar, lampiran yang diperlukan)
• Perubahan field penting (harga, % diskon, jangka waktu, tingkatan), sebelum dan sesudah
• Konteks dasar (ID deal/akun, perwakilan, peran pemberi persetujuan)

Revisi adalah tempat tim sering tersesat. Jika perwakilan mengubah jangka waktu atau syarat pembayaran setelah pengiriman, jejak audit harus menampilkannya dengan jelas dan memicu persetujuan ulang jika kebijakan Anda mengharuskannya. Perlakukan perubahan sebagai event baru, bukan sunyi edit.

Tentukan aturan retensi dan ekspor sejak awal: berapa lama Anda menyimpan permintaan dan lampiran, siapa yang dapat mengekspor, dan apakah ekspor harus dicatat.

Gunakan pelaporan untuk memperbaiki diskon dari waktu ke waktu

Manfaat sebenarnya bukan hanya "persetujuan lebih cepat." Melainkan menggunakan sejarah untuk membuat keputusan di masa depan lebih cepat, lebih adil, dan lebih mudah dipertanggungjawabkan.

Mulailah dengan beberapa metrik yang dapat dipercaya: waktu sampai keputusan, tingkat persetujuan, dan rata-rata diskon. Setelah itu stabil, iris berdasarkan dimensi yang sesuai dengan operasi tim Anda: perwakilan/manajer, wilayah, produk, ukuran deal, tingkatan, dan kode alasan.

Tampilan ini menyingkap pola yang tidak terlihat di thread chat dan spreadsheet: override berulang, alasan penolakan yang sama, bottleneck pada satu pemberi persetujuan, dan diskon yang meningkat di segmen tertentu.

Pelaporan bulanan tetap praktis jika dimulai dari pertanyaan:

• Di mana persetujuan paling lama, dan mengapa?
• Kode alasan mana yang paling sering disetujui, dan apakah masih relevan?
• Apakah tingkatan digunakan sebagaimana mestinya, atau orang mencari jalan memutar?
• Alasan penolakan mana yang berulang, dan apa yang bisa diperbaiki sales sebelum mengirim?

Untuk menjaga pelaporan bersih, standarkan field yang mendorong analisis. Catatan boleh berupa teks bebas, tetapi input kunci harus terstruktur: segmen, produk, harga daftar, diskon yang diminta, diskon akhir yang disetujui, tingkatan, dan daftar kode alasan yang stabil.

Contoh: menyetujui permintaan diskon 22% dari awal hingga akhir

Seorang perwakilan sales, Maya, sedang menutup paket tahunan senilai $48,000. Prospek meminta diskon 22% karena pesaing menawarkan 20%, dan mereka ingin kontrak ditandatangani sebelum Jumat.

Maya mengirim permintaan dengan data dasar deal (akun, paket, jangka waktu, tanggal close), angka (harga daftar, harga yang diminta, % diskon), dan konteks singkat (tekanan pesaing, tenggat waktu, apa yang pelanggan komitmenkan sebagai imbalan). Dia melampirkan bukti jika diperlukan oleh tingkatan.

Workflow menghitung tingkatan. Dalam contoh ini, apa pun di atas 21% diarahkan ke manajer terlebih dahulu, lalu finance. Manajer menyetujui dengan kondisi: jangka waktu 12 bulan dan pembayaran tahunan di muka. Finance meninjau margin dan syarat pembayaran, lalu baik menyetujui dengan kondisi, menolak dengan alasan jelas, atau mengembalikan untuk revisi tertentu.

Maya menerima keputusan yang bisa dia salin ke komunikasi dengan pelanggan, dengan kondisi tertulis dalam bahasa yang jelas. Setiap langkah dicatat: siapa yang memutuskan, kapan, apa yang berubah, dan mengapa.

Kesalahan umum yang memperlambat persetujuan

Kebanyakan keterlambatan bukan karena "pemberi persetujuan lambat." Mereka terjadi karena alur kerja memberi ruang untuk debat, pekerjaan ulang, atau blind spot.

Kesalahan 1: Aturan yang terdengar sederhana tapi tidak dapat dijalankan

"Diskon besar perlu persetujuan pimpinan" runtuh ketika seseorang bertanya, "Seberapa besar?" Buat tingkatan spesifik dan tuliskan apa yang mengubah rute (jangka waktu, syarat pembayaran, baru vs. pembaruan, bahasa non-standar).

Kesalahan 2: Formulir terlalu berat sehingga perwakilan menghindarinya

Saat formulir terasa seperti pekerjaan administrasi, perwakilan mencari jalan lain. Aturan praktis: jika sebuah field tidak digunakan untuk memutuskan atau untuk pelaporan nanti, jangan jadikan wajib. Isi otomatis bila memungkinkan, dan buat lampiran berbasis ambang.

Kesalahan 3: Tidak ada kode alasan, sehingga pelaporan menjadi berisik

Jika setiap permintaan menjadi cerita unik, Anda tidak bisa belajar darinya. Gunakan daftar kode alasan yang singkat dan stabil dan simpan teks bebas untuk detail pendukung.

Kesalahan 4: Edit setelah persetujuan tanpa persetujuan ulang

Jika harga, % diskon, jangka waktu, atau jadwal pembayaran berubah setelah persetujuan, perlakukan itu sebagai perubahan bermakna. Reroute otomatis saat field terlindungi diubah.

Kesalahan 5: Visibilitas buruk dan notifikasi yang berisik

Perwakilan terjebak ketika mereka tidak tahu di mana posisi permintaan. Pemberi persetujuan mengabaikan ketika setiap permintaan memberi notif ke semua orang. Jaga status jelas ("Menunggu Finance") dan notifikasi terfokus ke pemohon dan pemberi persetujuan saat ini.

Daftar periksa cepat dan langkah selanjutnya

Sebelum meluncurkan, lakukan tes "dunia nyata" cepat: dapatkah perwakilan mengirim dalam kurang dari dua menit, dapatkah pemberi persetujuan memutuskan tanpa mengejar detail, dan dapatkah finance menjelaskan keputusan beberapa bulan kemudian?

Gunakan daftar periksa ini untuk menangkap masalah umum lebih awal:

• Dasar formulir: field wajib benar-benar wajib (pricing, % diskon, jangka waktu, produk, wilayah, tanggal close).
• Logika tingkatan: tingkatan dan aturan override sesuai dengan bagaimana deal sebenarnya disetujui.
• Pemetaaan peran: setiap tingkatan memiliki pemberi persetujuan utama dan cadangan.
• Notifikasi: pemohon dan pemberi persetujuan menerima notifikasi yang tepat, tanpa duplikasi.
• Kualitas audit: setiap keputusan memiliki pemilik, stempel waktu, dan alasan yang jelas.

Aturan operasional sama pentingnya dengan formulir: apa yang terjadi saat perwakilan mengubah setelah umpan balik, bagaimana eskalasi bekerja, dan bagaimana delegasi saat keluar kantor ditangani.

Jika Anda ingin membuat prototipe cepat, bangun model data dulu (requests, approvals, comments, versions), lalu formulir, lalu routing, lalu log keputusan otomatis.

Jika Anda membangun ini dengan AppMaster (appmaster.io), Anda bisa membuat model data permintaan di Data Designer dan menyiapkan routing di Business Process Editor, sehingga formulir, workflow, dan jejak audit hidup di satu tempat dan tetap konsisten saat aturan Anda berubah.