AI agent pemeriksa penawaran membantu sales operations menelaah quotation sebelum dikirim: apakah kebutuhan pelanggan di CRM sesuai dengan produk, harga, stok, dan syarat yang tersedia di ERP? Tujuannya adalah menemukan ketidaksesuaian yang perlu diselesaikan, bukan memberi AI hak menjanjikan harga atau tanggal pengiriman.
Masalahnya sering muncul di antara sistem. Sales memakai catatan terbaru, katalog memiliki versi berbeda, dan stok berubah ketika proposal masih direview. Sebuah agent dapat mencari konteks yang belum lengkap dan menyiapkan daftar exception. Namun perhitungan harga, aturan diskon, serta otorisasi komersial harus tetap dijalankan sistem dan PIC yang berwenang.
Bedakan Pemeriksaan Penawaran dari Penjualan Otonom
Dalam panduan ini, ruang lingkup agent berhenti pada rekomendasi kesiapan quotation. Agent membaca sumber yang diizinkan, membandingkan informasi, mencari detail yang kurang, dan menjelaskan temuan. Ia tidak mengirim email ke pelanggan, mengubah daftar harga, menahan stok, maupun menandatangani kontrak tanpa alur persetujuan tersendiri.
Chatbot hanya dapat menjadi antarmuka percakapan. Workflow automation menjalankan langkah tetap, misalnya memeriksa margin dengan rumus. AI agent relevan ketika langkah pemeriksaan perlu menyesuaikan kondisi: mencari spesifikasi pengganti, memeriksa versi dokumen, atau meminta klarifikasi berdasarkan exception. Jika semua langkah dapat ditentukan dari awal, workflow biasa lebih sederhana.
Tentukan Pemilik Data dan Keputusan
Sales operations memiliki alur pemeriksaan. Account manager bertanggung jawab atas kebutuhan pelanggan dan komunikasi. Finance menjaga batas margin serta syarat pembayaran. Warehouse atau planning memberikan makna status stok dan kapasitas. Product specialist memvalidasi kompatibilitas. Head of sales menyetujui exception komersial sesuai matriks kewenangan.
Tim IT menjaga kontrak API, identitas pengguna, logging, dan pembatasan akses. Jangan memberikan satu akun agent akses penuh ke seluruh ERP hanya karena lebih mudah saat demo. Akses harus mengikuti data dan tindakan yang diperlukan oleh use case ini. Pembacaan harga khusus pelanggan juga harus terikat akun serta entitas perusahaan yang tepat.
Kontrak Data Minimum dari CRM dan ERP
Dari CRM
Ambil opportunity ID, customer ID, badan usaha pemesan, alamat kirim, kebutuhan produk, satuan, jumlah, target waktu, PIC, dan versi quotation. Tandai informasi yang merupakan permintaan pelanggan dan informasi yang masih asumsi sales. Nama pelanggan saja bukan kunci integrasi yang andal karena perusahaan bisa memiliki cabang atau entitas dengan nama mirip.
Dari ERP dan Katalog
Sediakan SKU, satuan dasar, aturan konversi, daftar harga yang berlaku, mata uang, masa berlaku harga, kebijakan diskon, serta status persediaan. Bedakan stok fisik, stok yang telah dialokasikan, dan jumlah yang tersedia untuk dijanjikan menurut kebijakan perusahaan. Agent tidak boleh menyamakan angka saldo gudang dengan komitmen pengiriman.
Jika harga atau stok tidak dapat dibaca, keluaran harus menyebut pemeriksaan belum lengkap. Menebak dari quotation sebelumnya dapat menghasilkan rekomendasi yang tampak masuk akal tetapi salah. Untuk rancangan koneksi antarsistem, pelajari layanan sistem integrator dan API Layana.ID.
Alur Pemeriksaan yang Dapat Diaudit
- Kunci quotation yang akan direview melalui ID dan nomor versi.
- Baca kebutuhan CRM dan ambil data ERP dengan timestamp serta identitas sumber.
- Jalankan validasi deterministik untuk jumlah, satuan, perhitungan, margin, dan masa berlaku.
- Gunakan AI untuk menelaah ketidakcocokan deskripsi, kebutuhan yang belum dipenuhi, serta bukti pendukung.
- Kirim exception ke PIC yang tepat; jangan memberi label siap ketika pemeriksaan wajib belum selesai.
- Validasi ulang data yang berubah sebelum approver mengizinkan quotation dikirim.
Hasil pemeriksaan sebaiknya memuat status per baris produk, temuan, sumber, waktu baca, tindakan yang disarankan, dan PIC. Ringkasan tunggal “aman” tidak memberi cukup informasi bagi reviewer. Perhitungan finansial tetap dilakukan kode atau fungsi ERP; model tidak dijadikan kalkulator utama untuk nilai yang mengikat.
Contoh Ilustratif: Stok Ada, Tetapi Sudah Dialokasikan
Misalkan sales distributor menyiapkan penawaran sepuluh unit perangkat. ERP menunjukkan saldo fisik dua belas unit, tetapi delapan sudah dialokasikan ke pesanan lain. Agent menemukan perbedaan antara saldo fisik dan ketersediaan, lalu menandai tanggal kirim sebagai belum dapat dikonfirmasi.
Warehouse mengonfirmasi empat unit tersedia. Account manager kemudian menawarkan pengiriman bertahap atau meminta lead time pemasok. Persetujuan pelanggan tetap diperoleh melalui proses sales. Contoh ini merupakan skenario desain, bukan hasil implementasi Layana.ID dan bukan bukti bahwa agent dapat menjamin ketersediaan.
Approval Harus Terikat Versi dan Tindakan
Persetujuan quotation versi A tidak otomatis berlaku untuk versi B. Jika jumlah, harga, tujuan kirim, atau syarat pembayaran berubah, alur harus menilai ulang bagian yang terdampak. Simpan siapa yang menyetujui, nilai yang dilihat, timestamp, dan cakupan persetujuannya.
Untuk tindakan eksternal, gunakan pemisahan yang jelas antara menyusun draf dan mengirim. Bila agent kelak diberi tool untuk membuat reservasi, tindakan tersebut membutuhkan kontrol tersendiri: kewenangan, identitas transaksi, deduplikasi, masa berlaku, dan konfirmasi hasil. Jangan menambahkan kewenangan tersebut hanya untuk membuat pilot terlihat lebih canggih.
Risiko yang Harus Muncul dalam Pengujian
Uji SKU mirip, satuan karton versus unit, dua mata uang, harga kedaluwarsa, stok berubah setelah review, customer ID salah, dan API ERP tidak merespons. Tambahkan dokumen pelanggan berisi instruksi yang mencoba mengubah aturan agent; dokumen adalah data, bukan sumber otorisasi. Baca kontrol prompt injection untuk AI agent bisnis sebagai panduan terkait.
Kasus kegagalan perlu menghasilkan keluaran terbatas yang jujur. Jika API timeout, agent dapat menyimpan pemeriksaan parsial dan meminta review manual. Ia tidak boleh mengulang tindakan yang mengubah transaksi sebelum memastikan apakah percobaan sebelumnya sudah berhasil. Walaupun pilot ini hanya membaca, prinsip tersebut penting untuk pengembangan tahap berikutnya.
Pilot: Bandingkan dengan Pemeriksaan Manusia
Mulai pada satu kelompok produk dan satu alur quotation. Siapkan kasus historis yang diizinkan serta kasus sintetis untuk exception berisiko. Reviewer menyusun hasil rujukan sebelum melihat hasil agent. Ukur ketidaksesuaian yang terdeteksi, temuan palsu, temuan yang terlewat, waktu review, dan proporsi kasus dengan sumber lengkap.
Prioritaskan kesalahan kritis seperti customer salah atau harga yang tidak berlaku. Rata-rata kualitas yang tinggi tidak cukup jika satu kasus tersebut lolos. Gate penerimaan harus menyebut jenis kesalahan yang tidak boleh lolos, prosedur eskalasi, dan cara memantau perubahan data setelah pilot. Manfaat bisnis diuji terhadap baseline; tidak diasumsikan dari demo yang lancar.
Pertanyaan yang Sering Diajukan
Apakah Harus Mengganti ERP?
Tidak selalu. Pemeriksaan dapat dirancang di sekitar ERP yang ada bila data, API, serta definisi statusnya memadai. Kebutuhan integrasi harus dipetakan dahulu; kemampuan setiap ERP berbeda dan perlu diverifikasi.
Apakah Agent Bisa Mengirim Penawaran Otomatis?
Itu merupakan perluasan scope dan risiko. Pilot yang dibahas berhenti pada pemeriksaan dan draf exception. Pengiriman memerlukan approval, validasi versi, aturan penerima, dan bukti bahwa dokumen yang disetujui sama dengan dokumen yang dikirim.
Diskusikan Pilot Pemeriksaan Penawaran
Siapkan contoh quotation yang telah dianonimkan, struktur CRM, aturan harga, definisi stok, dan matriks approval. Jelajahi layanan AI dan machine learning Layana.ID lalu diskusikan pemetaan kebutuhan B2B untuk menentukan alur pilot yang realistis.
Referensi
Anthropic — Building Effective Agents mendukung pembedaan workflow dan agent. Kontrak data, alur quotation, skenario, dan KPI di artikel ini adalah rekomendasi desain editorial, bukan benchmark atau portofolio. Sumber diperiksa 14 Oktober 2026.