CPQ: Konfigurasi, Harga, dan Penawaran untuk Penjualan B2B yang Kompleks

Di banyak perusahaan B2B, penawaran dibuat dengan cara yang sama selama bertahun-tahun: tenaga penjual membuka berkas penawaran lama, mengganti nama pelanggan, mengubah beberapa baris, menanyakan harga ke tim produk lewat pesan singkat, lalu mengirimkan PDF. Selama produk sederhana, cara ini cukup. Ketika produk memiliki banyak opsi, harga bergantung pada volume dan kontrak, serta diskon memerlukan persetujuan, penawaran menjadi sumber kesalahan: konfigurasi yang tidak bisa diproduksi, harga di bawah margin, diskon di luar kewenangan, dan penawaran yang butuh berhari-hari untuk selesai.

CPQ, singkatan dari configure, price, quote, adalah pendekatan dan kelas perangkat lunak yang menyelesaikan masalah itu. Artikel ini menjelaskan kapan bisnis membutuhkan CPQ, fungsi intinya, cara menyusun aturan konfigurasi dan harga, persetujuan margin, hubungan dengan CRM dan ERP, serta langkah penerapan yang realistis, termasuk kapan cukup memakai alat yang lebih sederhana.

Ringkasan

• CPQ memastikan penawaran valid secara teknis, benar secara harga, dan sesuai kewenangan sebelum sampai ke pelanggan
• Aturan konfigurasi menolak kombinasi yang tidak bisa dibuat, sehingga kesalahan tertangkap saat penawaran, bukan saat produksi
• Harga berasal dari satu sumber: daftar harga, tingkat volume, kontrak khusus, dan aturan diskon
• Persetujuan margin otomatis mempercepat penawaran yang aman dan menahan yang berisiko
• Integrasi dengan CRM dan ERP mengubah penawaran yang disetujui menjadi pesanan tanpa input ulang

Kapan penawaran manual mulai bermasalah

Penawaran manual bukan masalah bagi semua bisnis. Tanda bahwa Anda telah melewati batasnya:

• Siklus penawaran memakan berhari-hari karena menunggu jawaban teknis dan harga dari beberapa orang
• Dua tenaga penjual memberi harga berbeda untuk konfigurasi yang sama
• Pesanan masuk ke produksi dengan konfigurasi yang tidak kompatibel atau tidak bisa dibuat
• Diskon diberikan tanpa persetujuan, atau persetujuan terjadi lewat pesan yang tidak tercatat
• Margin aktual proyek berbeda jauh dari yang diperkirakan saat penawaran
• Daftar harga diperbarui, tetapi templat penawaran lama masih beredar
• Tidak ada riwayat revisi, sehingga sulit menjawab "versi mana yang disepakati pelanggan"

Bila beberapa gejala ini terasa, biayanya nyata: waktu tenaga penjual yang habis untuk administrasi, margin yang bocor, dan pelanggan yang menunggu lebih lama daripada pesaing.

Tiga komponen CPQ

Configure: konfigurasi produk

Konfigurasi adalah proses memilih opsi sehingga menghasilkan produk atau solusi yang valid. Sistem menyimpan aturan: opsi A hanya kompatibel dengan model B dan C; paket X mewajibkan komponen Y; jumlah maksimal sambungan untuk kapasitas tertentu; bahan tertentu tidak bisa dipadukan dengan lapisan tertentu. Saat tenaga penjual memilih opsi, sistem menyembunyikan atau menolak pilihan yang tidak valid dan menambahkan komponen wajib otomatis.

Hasilnya berupa daftar komponen yang konsisten dan, bila perlu, daftar bahan atau spesifikasi yang dapat diteruskan ke produksi. Untuk produksi berdasarkan pesanan, hubungannya dibahas di ERP make-to-order dan job costing untuk percetakan dan fabrikasi.

Price: penetapan harga

Harga bukan satu angka. Ia gabungan dari beberapa sumber:

• Daftar harga dasar per produk atau komponen, mungkin berbeda per wilayah atau mata uang
• Tingkat volume: semakin banyak, semakin murah per unit
• Harga kontrak khusus untuk pelanggan tertentu yang sudah disepakati sebelumnya
• Promosi dan diskon berjangka waktu
• Biaya tambahan: instalasi, pengiriman, pelatihan, atau garansi diperpanjang
• Pajak, sesuai ketentuan yang berlaku
• Untuk layanan langganan, harga berulang dan biaya awal dipisahkan

Sistem menghitung harga dari aturan ini secara konsisten, sehingga dua penawaran dengan konfigurasi sama menghasilkan harga sama. Pendekatan penetapan harga yang lebih luas ada di strategi harga dan penetapan harga toko online, yang konsep dasarnya juga berlaku di B2B, dan model langganan dibahas di model bisnis langganan dan tagihan berulang.

Quote: dokumen penawaran

Setelah konfigurasi dan harga valid, sistem menghasilkan dokumen penawaran dari templat: merek, ringkasan solusi, rincian harga, syarat pembayaran, masa berlaku, dan ketentuan standar. Beberapa fitur yang berguna:

• Templat per jenis produk dan per bahasa; untuk pembeli internasional, lihat [website B2B untuk eksportir dan manufaktur](/blog/website-b2b-untuk-eksportir-dan-manufaktur-menarik-pembeli-internasional)
• Masa berlaku penawaran yang tertera dan dapat diperingatkan sebelum kedaluwarsa
• Versi dan revisi dengan riwayat perubahan
• Tautan penerimaan oleh pelanggan, atau tanda tangan elektronik, seperti yang dibahas di [tanda tangan elektronik dan e-meterai untuk alur dokumen bisnis](/blog/tanda-tangan-elektronik-dan-e-meterai-untuk-alur-dokumen-bisnis)
• Opsi alternatif dalam satu penawaran, misalnya paket standar, lanjutan, dan premium

Menyusun aturan konfigurasi tanpa kewalahan

Kesalahan yang umum adalah mencoba memodelkan semua kemungkinan sejak awal. Aturan yang terlalu banyak menjadi sulit dirawat dan tidak ada yang berani mengubahnya. Pendekatan yang lebih sehat:

• Mulai dari satu lini produk dengan volume penjualan tertinggi
• Dokumentasikan aturan dalam bentuk tabel sederhana: komponen, ketergantungan, pengecualian
• Libatkan orang yang memahami produk secara teknis, biasanya tim teknik atau produksi, dan jangan hanya mengandalkan bagian penjualan
• Tentukan pemilik aturan; perubahan produk harus memperbarui aturan sebagai bagian dari rilis produk
• Sediakan jalur pengecualian: konfigurasi khusus yang tidak ada di aturan diajukan sebagai permintaan rekayasa, bukan dipaksakan masuk atau dihindari

Bila produk Anda berupa layanan atau proyek software dan bukan barang fisik, pola yang sama muncul sebagai paket dan modul. Pembahasan struktur biaya proyek ada di menghitung biaya sebenarnya project software dan model harga proyek software.

Aturan harga dan diskon

Diskon adalah tempat margin paling sering bocor. Rancang aturan yang jelas:

• Batas diskon per peran: tenaga penjual sampai batas tertentu, manajer sampai batas yang lebih tinggi, direktur di atasnya
• Diskon bergantung pada volume atau durasi kontrak, bukan semata permintaan pelanggan
• Diskon pada komponen tertentu mungkin dilarang, misalnya layanan atau barang dengan margin tipis
• Penggabungan diskon dibatasi; diskon bertumpuk dapat menghasilkan harga di bawah biaya
• Harga minimum atau lantai yang tidak boleh dilampaui tanpa persetujuan khusus

Pastikan sistem menampilkan margin kepada pihak yang berwenang melihatnya, tetapi menyembunyikan biaya dan margin dari dokumen yang dilihat pelanggan, dan bila perlu dari tenaga penjual junior.

Alur persetujuan

Persetujuan yang baik cepat untuk kasus aman dan teliti untuk kasus berisiko. Sistem memeriksa aturan secara otomatis:

• Penawaran dalam batas kewenangan penjual dilepas tanpa persetujuan
• Penawaran di luar batas diteruskan ke atasan yang tepat, bersama ringkasan margin, diskon, perbandingan dengan penawaran serupa, dan alasan dari penjual
• Persetujuan memiliki batas waktu dan eskalasi bila tidak ditanggapi
• Semua keputusan tercatat dengan siapa, kapan, dan alasannya

Prinsip alur persetujuan yang umum dibahas di alur approval pembelian, dan rancangannya serupa meski dipakai untuk sisi penjualan. Hindari alur dengan terlalu banyak tingkat; setiap tingkat tambahan menambah hari pada siklus penjualan.

Integrasi dengan CRM dan ERP

CPQ yang terpisah dari sistem lain hanya memindahkan masalah. Integrasi yang bernilai:

• CRM: penawaran dibuat dari peluang penjualan dan nilainya kembali ke pipeline, sehingga ramalan penjualan memakai angka nyata. Lihat [kebutuhan CRM untuk bisnis B2B](/blog/kebutuhan-crm-untuk-bisnis-b2b) dan [mendefinisikan tahapan pipeline penjualan](/blog/mendefinisikan-tahapan-pipeline-penjualan)
• ERP: katalog produk, stok, waktu tunggu, dan biaya standar mengalir ke CPQ, sedangkan penawaran yang diterima menjadi pesanan penjualan tanpa input ulang. Kualitas data induk menentukan keberhasilan, seperti dibahas di [master data ERP](/blog/master-data-erp-kode-barang-pelanggan-pemasok)
• Penagihan: syarat pembayaran dan termin dari penawaran mengalir ke faktur; lihat [otomatisasi faktur dan penagihan piutang B2B](/blog/otomatisasi-faktur-dan-penagihan-piutang-b2b)
• Portal pelanggan: pelanggan dapat melihat, menyetujui, dan memesan ulang dari penawaran yang pernah diberikan; lihat [portal pelanggan dan pemasok B2B](/blog/portal-pelanggan-dan-pemasok-b2b)

Pola integrasi dapat memakai API atau webhook seperti pada webhook dan integrasi real-time untuk bisnis. Dalam arsitektur modular seperti composable ERP, CPQ dapat menjadi modul tersendiri yang terhubung lewat API.

Metrik yang perlu dipantau

Setelah CPQ berjalan, pantau untuk membuktikan manfaatnya:

• Waktu dari permintaan sampai penawaran terkirim
• Persentase penawaran yang menjadi pesanan
• Rata-rata diskon dan margin aktual dibandingkan margin rencana
• Jumlah penawaran yang memerlukan persetujuan, dan waktu persetujuannya
• Jumlah pesanan yang dikembalikan ke penjualan karena konfigurasi tidak valid
• Jumlah revisi per penawaran

Data ini juga memperkaya analisis kinerja tim, selaras dengan metrik performa tim sales. Bandingkan sebelum dan sesudah penerapan, dan hati-hati menyimpulkan sebab-akibat karena musim dan kondisi pasar ikut berpengaruh.

Kapan CPQ penuh tidak diperlukan

Tidak semua bisnis membutuhkan platform CPQ khusus. Beberapa alternatif yang lebih ringan:

• Produk sederhana dengan daftar harga tetap: modul penawaran di CRM atau ERP sudah cukup
• Konfigurasi terbatas: templat penawaran dengan rumus terkontrol dan daftar pilihan dapat memadai, selama versi dan akses dikendalikan
• Volume penawaran rendah: biaya penerapan mungkin tidak sebanding; cukup perbaiki disiplin templat dan persetujuan
• Penjualan jasa dengan lingkup unik tiap proyek: penawaran lebih mirip proposal dan penilaian profesional daripada konfigurasi, jadi fokus pada templat, perhitungan biaya, dan persetujuan

Pertimbangkan pula opsi membangun solusi khusus yang ringan bila alur Anda unik. Kerangka keputusannya sama seperti pada custom software vs software jadi. Rule of thumb: bila aturan konfigurasi dan harga Anda sering berubah, rumit, dan berdampak pada margin, investasi CPQ cenderung sepadan.

Rencana penerapan bertahap

• Minggu 1 sampai 3: kumpulkan 20 penawaran terakhir, catat di mana waktu dan kesalahan terjadi, dan tentukan lini produk percontohan
• Minggu 4 sampai 6: dokumentasikan aturan konfigurasi, struktur harga, dan batas diskon untuk lini tersebut
• Minggu 7 sampai 10: bangun atau konfigurasi alat, templat penawaran, dan alur persetujuan; uji dengan penawaran lama sebagai pembanding
• Minggu 11 sampai 12: pelatihan tenaga penjual dan pilot dengan beberapa orang
• Setelahnya: integrasi ke CRM dan ERP, lalu perluasan ke lini produk lain

Libatkan tenaga penjual sejak awal. Alat yang terasa memperlambat mereka akan dihindari, dan penawaran kembali dibuat di luar sistem.

Kesalahan yang sering terjadi

• Memodelkan semua produk dan pengecualian sekaligus sehingga proyek tidak selesai
• Tidak menetapkan pemilik aturan, sehingga aturan usang
• Persetujuan terlalu berjenjang sehingga penawaran lebih lambat dari sebelumnya
• Membiarkan jalur penawaran di luar sistem tetap terbuka
• Tidak menghubungkan ke ERP, sehingga pesanan tetap diketik ulang
• Menampilkan biaya dan margin internal pada dokumen pelanggan

Pertanyaan yang sering diajukan

Apakah CPQ hanya untuk perusahaan besar?

Tidak harus. Perusahaan menengah dengan produk yang dapat dikonfigurasi atau harga yang kompleks juga mendapat manfaat. Yang menentukan adalah kerumitan penawaran dan dampak kesalahannya, bukan ukuran perusahaan.

Berapa lama penerapan?

Untuk satu lini produk dengan aturan yang sudah terdokumentasi, pilot dapat berjalan dalam beberapa bulan. Waktu terbesar biasanya habis untuk merapikan aturan dan data, bukan untuk teknologinya.

Apakah CPQ menggantikan CRM?

Tidak. CRM mengelola hubungan dan pipeline, sedangkan CPQ mengelola konfigurasi, harga, dan dokumen penawaran. Keduanya saling melengkapi.

Penutup

CPQ mengubah penawaran dari pekerjaan administratif yang rawan salah menjadi proses yang konsisten: konfigurasi yang valid, harga dari satu sumber, persetujuan sesuai kewenangan, dan data yang mengalir ke pesanan serta penagihan. Nilainya terlihat pada siklus penjualan yang lebih singkat, margin yang lebih terjaga, dan pelanggan yang mendapat jawaban lebih cepat. Mulailah dari satu lini produk dan aturan yang terdokumentasi dengan baik. Bila Anda ingin merancang alur penawaran yang terhubung dengan CRM dan ERP, tim Agsora dapat membantu memetakan aturan dan membangun solusinya.