Skema pipeline penjualan untuk pendiri B2B: field, stage, dan pelacakan aktivitas minimal untuk memprediksi dengan jelas dan menjaga deal bergerak tanpa membuat CRM bengkak.
Awalnya, pipeline terasa jelas karena hanya ada beberapa deal dan sebagian besar konteks ada di kepala Anda. Lalu daftar bertambah, Anda melewatkan follow-up, dan pipeline mulai menceritakan kisah yang lebih indah daripada kenyataan. Itulah “pipeline berbohong”: bukan disengaja, tapi karena tidak ada yang memaksa sistem mengatakan yang sebenarnya.
Hal itu muncul dalam pola yang sama:
Reaksi umum adalah membangun CRM berlebih: lebih banyak field, lebih banyak stage kustom, catatan yang lebih panjang. Ironisnya, itu biasanya membuat forecast lebih buruk. Saat memperbarui terasa berat, orang memperbarui lebih sedikit, dan pipeline diam-diam membusuk.
Skema pipeline penjualan yang minimal justru melakukan hal sebaliknya. Struktur cukup untuk mengambil keputusan. Ia tidak mencoba menangkap semuanya. Ia menangkap beberapa fakta yang mencegah Anda menipu diri sendiri.
Jika hanya mengikuti satu aturan, gunakan ini: setiap deal terbuka harus memiliki (1) tindakan berikutnya yang eksplisit, (2) tanggal untuk tindakan itu, dan (3) tanggal close yang terkait dengan timeline pembeli yang nyata (sebuah pertemuan, langkah legal, review anggaran). Jika salah satu hilang, deal itu tidak aktif.
Stage juga harus berarti sesuatu. Sebuah deal maju hanya ketika sesuatu yang konkret terjadi, bukan karena terasa bagus. Tujuannya bukan dashboard yang cantik. Tujuannya adalah pandangan jujur yang bisa Anda gunakan untuk menjalankan bisnis.
Skema pipeline hanya bekerja jika semua orang memperlakukannya dengan cara yang sama. Sebelum Anda menambah field atau berdebat tentang stage, tentukan apa yang direpresentasikan oleh satu item pipeline.
Default yang bersih untuk B2B: satu deal sama dengan satu keputusan pembelian. Jika perusahaan yang sama mungkin membeli dua kali (dua tim, dua produk, dua anggaran), itu dua deal, bukan satu catatan yang berantakan.
Sederhanakan objek. Anda bisa berjalan jauh dengan tiga bucket: lead (orang yang bisa Anda hubungi), account (perusahaan), dan deal (pembelian spesifik yang Anda coba tutup). Jika Anda solo, Anda bahkan bisa melewati lead dan account formal dan cukup memastikan setiap deal jelas menyebut perusahaan dan kontak utama.
Tulis beberapa aturan operasi, terutama jika ada orang lain selain Anda yang menyentuh pipeline:
Contoh: Anda berbicara dengan Alex di Northwind tentang pilot untuk tim finance. Itu satu deal. Jika sebulan kemudian produk ingin kontrak terpisah, buat deal kedua. Jangan meregangkan satu catatan untuk menutupi dua keputusan.
Pipeline tetap berguna ketika setiap deal memiliki beberapa field yang benar-benar Anda cek setiap minggu. Tambah field “untuk berjaga-jaga,” dan mereka berubah menjadi hiasan.
Mulai dengan format nama deal yang mencegah duplikasi. Pola sederhana bekerja: Perusahaan - Produk/Ruang Lingkup - Kuartal/Bulan. Contoh: “Acme - Team plan - Mar 2026.” Ini membuat jelas ketika “Acme - Demo” dan “Acme - Follow-up” sebenarnya adalah deal yang sama.
Setiap deal juga perlu identitas jelas:
Peran penting karena mengubah apa yang Anda lakukan selanjutnya. Champion perlu enablement. Decision maker butuh business case.
Tambahkan field akuntabilitas:
Lalu tambahkan hanya data finansial dan waktu yang akan Anda gunakan:
Jika ragu tentang sebuah field, jangan masukkan. Anda selalu bisa menambahkannya nanti. Menghapus field setelah kebiasaan terbentuk jauh lebih sulit.
Kebanyakan pipeline yang “besar” sebenarnya tidak besar. Mereka penuh deal yang enak dilihat tapi tidak punya jalur jelas menuju jawaban ya.
Mulai dengan satu field yang memaksa kejelasan: Use case (ruang lingkup). Tulis apa yang pembeli coba capai dengan kata-kata sederhana, plus apa yang terlihat seperti “selesai.” Jika Anda tidak bisa mendeskripsikan hasil dalam dua kalimat, Anda mungkin belum memahami deal.
Selanjutnya, tangkap proses pengambilan keputusan di satu tempat. Ini bukan dump kontak. Ini cerita bagaimana keputusan dibuat: siapa yang menandatangani, siapa yang bisa memblokir, dan langkah apa yang harus diikuti (security review, legal, procurement). Jika Anda belum tahu penandatangan, anggap deal masih awal.
Tambahkan sinyal kecocokan harga, meskipun kasar. Rentang (“< $5k”, “$5-25k”, “$25k+”) sudah cukup, atau sederhana Likely / Unclear / Unlikely berdasarkan apa yang Anda dengar. Tujuannya adalah menghentikan kemajuan deal yang tidak mampu membayar Anda.
Terakhir, simpan field red flags satu baris. Jika butuh paragraf, itu masuk catatan.
Set ringkas yang bekerja untuk sebagian besar pendiri B2B:
Contoh: “Ingin pembersihan CRM sebelum perpanjangan, penandatangan VP Sales, security review diperlukan, anggaran kemungkinan $10-20k, bersaing dengan tidak melakukan apa-apa, red flag: champion tidak memegang kepemilikan proyek.” Catatan tunggal itu lebih sulit untuk menipu diri sendiri.
Pipeline menjadi buruk ketika berubah menjadi daftar keinginan. Perbaikannya bukan menambah field. Melainkan beberapa sinyal aktivitas yang memaksa setiap deal menjawab satu pertanyaan: apa yang terjadi selanjutnya?
Jika Anda hanya menambah satu lapisan ke skema pipeline, buatlah field aktivitas ini:
Aturan praktis: jika sebuah deal tidak punya next step atau tidak ada due date, itu bukan deal nyata. Parkir atau tutup saja. Ini melakukan lebih banyak untuk akurasi forecast daripada model scoring mana pun.
Simpan “Reason lost” singkat agar Anda benar-benar menggunakannya: harga, tidak ada anggaran, tidak ada keputusan, memilih pesaing, waktu, tidak cocok.
Contoh penerapan: Anda ada demo dengan ops lead pada hari Selasa. Tepat setelah panggilan, Anda set last activity date = Selasa, last touch channel = meeting, next step = “Kirim 2 studi kasus dan konfirmasi siapa yang menandatangani,” next step due date = Kamis. Jika Kamis berlalu tanpa balasan, deal berubah merah tanpa ada perdebatan tentang “kemajuan pipeline.”
Model stage yang baik melakukan satu pekerjaan: mengatakan kebenaran tentang di mana setiap deal berada, tanpa membuat Anda mengasuh belasan langkah kecil. Jika Anda tidak bisa mengatakan apa yang harus benar agar sebuah deal berada di stage, stage itu berubah menjadi perasaan.
Pengaturan enam stage ini bekerja untuk sebagian besar pendiri B2B:
New: Anda punya nama dan alasan untuk menghubungi. Sentuhan pertama sudah dilakukan atau dijadwalkan.
Qualified: Kecocokan dasar terkonfirmasi. Masalah nyata, pelanggan cocok dengan ICP Anda, dan ada jalur yang masuk akal untuk membeli.
Discovery done: Anda sudah melakukan percakapan nyata. Anda memahami use case, kriteria sukses, dan siapa yang terlibat.
Proposal sent: Harga dan ruang lingkup ada di tangan pelanggan. Next step dijadwalkan atau diminta secara eksplisit.
Negotiation/Legal: Procurement, security, persetujuan anggaran, atau edit kontrak sedang berlangsung.
Closed won / Closed lost: Hasil ditandai dan alasan dicatat.
Majukan deal hanya ketika sesuatu terjadi di dunia nyata (meeting selesai, proposal dikirim, legal dimulai). Jika tidak ada yang terjadi, stage tetap sama.
Nama stage bukan definisi stage. Jika Anda hanya memberi label kolom “Qualified” atau “Negotiation,” Anda akan berakhir dengan deal yang duduk di sana karena tidak ada yang setuju apa arti “selesai.”
Tulis aturan stage sebagai cek benar/salah sederhana. Ketika setiap deal di stage memiliki fakta yang sama, pipeline Anda tetap dapat dipercaya.
Kriteria masuk mengatakan apa yang harus sudah benar sebelum deal masuk stage. Kriteria keluar mengatakan apa yang harus berubah sebelum bisa maju. Jaga keduanya singkat dan dapat diukur.
Contoh:
Jika Anda tidak bisa menulis kriteria tanpa kata-kata seperti “baik,” “kuat,” atau “tertarik,” stage itu terlalu kabur.
Tetapkan usia maksimum untuk setiap stage sebagai peringatan dini, bukan hukuman. Contoh: Discovery max 14 hari, Proposal max 21 hari. Ketika deal mencapai batas, trigger reset: pesan next step, pindahkan kembali, atau tutup.
Tentukan tindakan default ketika kriteria tidak terpenuhi:
Ini mencegah “deal zombie” memperbesar forecast Anda.
Anda bisa membangun skema pipeline dalam beberapa jam jika memperlakukannya seperti produk kecil: aturan dulu, lalu hanya apa yang mendukung aturan tersebut.
Mulai di halaman kosong, bukan di dalam tool. Tulis stage dan kriteria masuk/keluar dalam bahasa Inggris sederhana. Jika Anda tidak bisa menjelaskan sebuah stage dalam satu kalimat, mungkin itu dua stage (atau bukan stage sama sekali).
Alur bangun sederhana:
Lakukan satu tes realistis saat setup: ambil sebuah deal yang sedang Anda kerjakan dan coba pindahkan stage demi stage. Jika Anda terus menebak, kriterianya terlalu kabur.
Satu aturan yang layak ditegakkan sejak awal: jika tanggal aktivitas berikutnya kosong, deal tidak bisa tetap di stage aktif.
Sebagian besar bloat CRM dimulai dari niat baik: Anda ingin lebih akurat, jadi Anda menambah field, stage, dan lebih banyak pencatatan. Hasilnya kebalikan. Orang berhenti memperbarui, dan pipeline menjadi tempat deal menua.
Jika dua stage terasa sama, mereka akan digunakan sama. “Discovery”, “Deep discovery”, dan “Discovery follow-up” sering berarti “kita sudah bicara,” tanpa event selanjutnya yang jelas. Stage harus berubah hanya ketika sesuatu yang nyata berubah.
Tes cepat: jika Anda tidak bisa mengatakan apa yang harus benar untuk masuk sebuah stage dalam satu kalimat, kemungkinan stage itu berlebih.
Tanggal close berguna hanya jika terkait dengan alasan. Perlakukan itu sebagai tanggal titik keputusan berikutnya (persetujuan anggaran, meeting procurement, batas tanda tangan), dan pindahkan saat event itu bergeser.
Catatan panjang menyembunyikan satu hal yang Anda butuhkan: apa yang terjadi terakhir, dan apa yang terjadi berikutnya. Jaga catatan singkat, dan lacak aktivitas dengan last activity date plus next step (dengan pemilik dan tanggal jatuh tempo).
Tanpa definisi, “qualified” menjadi “mereka terdengar bagus.” Pilih 3 sampai 4 cek yang harus benar (masalah, pembeli, timeline, dan beberapa bentuk anggaran). Jika salah satu hilang, itu belum qualified.
Pipeline yang hanya tumbuh berhenti menjadi pipeline dan berubah menjadi kuburan. Tutup lost cepat ketika deal tidak aktif atau tidak cocok, dan tangkap satu alasan jelas agar Anda bisa belajar.
Pilih satu waktu setiap minggu (30 menit cukup) dan anggap itu seperti pertemuan dengan diri Anda di masa depan. Kebersihan pipeline lebih soal memastikan setiap deal masih punya jalur nyata ke depan daripada menambah field.
Alur review sederhana:
Contoh konkret: jika sebuah deal ditandai “Proposal sent” tapi tidak ada meeting yang dijadwalkan untuk membahasnya, itu bukan deal di stage proposal. Pindahkan kembali, set next step, dan hentikan penghitungan sampai pembeli terlibat lagi.
Anda menjual alat analytics B2B ke perusahaan e-commerce 50 orang. Setelah panggilan pertama, Anda buat deal dan isi hanya apa yang akan Anda gunakan minggu depan. Skema sederhana membayar di sini karena memaksa kejelasan, bukan birokrasi.
Tepat setelah panggilan, record terlihat seperti:
Deal mulai di Discovery. Anda memajukannya hanya ketika invite kalender diterima (bukan ketika seseorang “terdengar tertarik”). Setelah demo, trigger untuk pindah ke evaluation adalah permintaan konkret (mis. “Bisakah Anda terhubung ke Shopify dan data gudang kami?”), diikuti pemeriksaan teknis yang disepakati.
Sekarang terjadi stall: CFO menghilang setelah menyangkut harga. Log Anda menunjukkan dua follow-up, tidak ada balasan, dan tanggal next step lewat. Aturannya sederhana: jika tidak ada next step yang disepakati, deal tidak bisa tetap di Proposal.
Jadi Anda mengambil langkah jujur: pindahkan kembali ke evaluation (jika perlu sponsor baru atau info yang hilang) atau close lost (jika decision maker tidak mau terlibat sampai batas waktu). Dalam contoh ini, Anda pindah kembali, perbarui stakeholder (Ops menarik finance manager), set tanggal next step baru, dan kembali ke Proposal hanya setelah CFO mengonfirmasi meeting keputusan.
Skema pipeline hanya bekerja jika Anda mempercayainya. Cara tercepat mencapai itu adalah mulai minimal dan jalani selama 30 hari. Itu menunjukkan apa yang sebenarnya Anda gunakan, bukan apa yang Anda kira butuhkan.
Selama bulan pertama, bersikap ketat: jika sebuah field tidak mengubah keputusan, hapus. Jika sebuah keputusan terus muncul dan Anda tidak bisa menjawabnya dari pipeline, tambahkan tepat satu field untuk menutup celah itu.
Tes sederhana sebelum menambah field baru: “Jika ini kosong, kita tidak bisa memutuskan apakah akan ___.”
Jika Anda ingin membangun CRM kustom ringan daripada memaksa yang generik, tools seperti Koder.ai (koder.ai) bisa membantu setelah Anda menulis stage, field wajib, dan aturan validasi. Jauh lebih mudah menghasilkan dan iterasi aplikasi sederhana ketika skema sudah jelas.
Sebuah pipeline “berbohong” ketika ia menunjukkan kemajuan yang sebenarnya tidak didukung oleh tindakan pembeli yang nyata. Penyebab paling umum adalah next step yang hilang, tanggal aktivitas terakhir yang usang, dan tanggal close yang terus digeser tanpa timeline yang dikonfirmasi oleh pembeli.
Buat tiga field yang tidak boleh kosong untuk setiap deal terbuka: tindakan konkret berikutnya, tanggal jatuh tempo untuk tindakan itu, dan tanggal close yang terkait dengan kejadian pembeli yang nyata seperti pertemuan, review, atau langkah tanda tangan. Jika salah satunya kosong, anggap deal tidak aktif sampai diisi.
Defaultnya adalah “satu deal = satu keputusan pembelian.” Jika perusahaan yang sama bisa membeli dua kali lewat tim, produk, atau anggaran berbeda, buat deal terpisah agar tidak mencampur timeline dan pemangku kepentingan.
Mulai dengan format nama deal yang mencegah duplikasi, sebuah perusahaan, kontak utama, pemilik, nilai yang diharapkan, tanggal target close, dan sumber yang jelas. Tambahkan hanya kualifikasi yang menjelaskan mengapa deal itu harus close: use case, proses pengambilan keputusan, dan kecocokan harga.
Satu kalimat use case plus apa yang dianggap “sukses” memaksa Anda memahami hasilnya, bukan sekadar minat pembeli. Jika Anda tidak bisa menjelaskan hasilnya dengan jelas, biasanya deal itu masih terlalu awal untuk diprediksi.
Tulis sebagai cerita singkat bagaimana keputusan dibuat: siapa yang menandatangani, siapa yang bisa memblokir, dan langkah apa yang harus terjadi (security, legal, procurement). Jika Anda belum tahu penandatangan, pertahankan deal di stage awal dan fokuskan next step Anda untuk menemukan orang dan proses tersebut.
Gunakan rentang kasar atau sederhana Likely/Unclear/Unlikely berdasarkan apa yang Anda dengar. Tujuannya bukan perhitungan harga yang sempurna, melainkan menghentikan pengembangan deal yang anggaran nyatanya tidak cocok dengan penawaran Anda.
Lacak last activity date, next step, next step due date, dan alasan close saat deal berakhir. Notes boleh ada, tetapi field aktivitas inilah yang mencegah deal melayang dan memaksa Anda memutuskan langkah selanjutnya.
Pindahkan stage hanya ketika sesuatu yang nyata terjadi, seperti panggilan discovery selesai, proposal benar-benar dikirim, atau legal diperkenalkan. Jika perubahan stage bisa terjadi hanya karena Anda “merasakan” sesuatu, definisi stage terlalu kabur dan forecast Anda akan menyimpang.
Tetapkan jumlah hari maksimum untuk setiap stage sebagai peringatan dini, lalu trigger reset saat batas tercapai. Aksi default sederhana: booking next step nyata, memindahkan deal kembali ke stage sebelumnya yang sesuai fakta, atau menutupnya sebagai no decision setelah upaya follow-up yang jelas.
