Cara Menjual Saat Pengguna Bukan Pembelinya

• Dalam situasi 'pengguna memakai produk tetapi bukan pihak yang berwenang membayar', kuncinya adalah memahami siapa yang benar-benar memiliki wewenang dan pengaruh
• Pengambil keputusan yang memiliki wewenang nyata belum tentu orang yang sama dengan pembeli atau pengguna pertama
• Di organisasi kecil, penghematan waktu sangat penting, sehingga developer dapat langsung mengadopsi tool dan meyakinkan atasan hingga berujung pada pembelian
• Di organisasi besar, kendala keamanan dan prosedur lebih kuat, sehingga keputusan pembelian ada pada CTO atau manajemen, dan memerlukan siklus penjualan yang panjang
• Pihak yang punya otoritas pembelian tidak selalu sama dengan pemegang anggaran; yang menjadi target utama adalah orang yang paling merasakan nilai produk dan mampu mendorong adopsinya
• Strategi yang efektif adalah membantu pengguna meyakinkan manajemen dengan menyediakan data konkret dan materi persuasi
• Keberhasilan akhir terletak pada perancangan proses yang mendukung pengguna agar dapat berperan sebagai tenaga penjualan internal

---

Pembuka – Titik awal pertanyaan

• Bagaimana sebaiknya mendekati situasi ketika pengguna yang benar-benar memakai produk berbeda dari pelanggan yang membuat keputusan pembelian?
• Konteksnya adalah penjualan software B2B yang umum, di mana developer mencoba produk terlebih dahulu, lalu CTO atau Director of Engineering membuat keputusan akhir

Pertanyaan mendasar tentang otoritas

• Pertanyaan 'siapa yang benar-benar memegang kuasa?' adalah poin yang paling inti
• Yang menentukan alur pembelian bukan sekadar otoritas pembayaran kartu atau prioritas untuk mencoba produk, melainkan pengaruh nyata dan motivasi

Skenario berdasarkan struktur organisasi

Untuk organisasi kecil: struktur datar dan keputusan cepat

• Developer sering kali mencari produk dan memimpin adopsinya secara langsung
• Motivasi utama CTO adalah masuk ke pasar dan beriterasi dengan cepat, sehingga usulan tool dari developer memiliki pengaruh besar terhadap pengambilan keputusan
• Pola penyebaran ala Trojan-horse, di mana developer cepat mencoba tool secara gratis lalu kemudian beralih ke versi berbayar, sering terjadi

Untuk organisasi besar: keamanan dan kepatuhan menjadi kendala utama

• Ada kendala selain waktu, seperti keamanan, dan keputusan pimpinan sangat menentukan seluruh proses
• Pengguna (developer) tidak diizinkan memasang atau membeli secara mandiri, sehingga siklus penjualannya panjang dan kompleks
• Standar dalam menilai nilai/risiko lebih berfokus pada keamanan dan hasil akhir daripada UI/UX atau DX

Perspektif tentang pengaruh nyata dan nilai

• Pemegang anggaran tidak selalu menjadi pihak yang punya otoritas nyata
• Yang penting adalah 'siapa yang memiliki leverage' dan 'insentif siapa yang paling kuat mendorong proses berjalan'
• Perlu dipahami secara realistis siapa pihak yang benar-benar dapat menukar nilai yang setara dengan harga produk

Contoh alur adopsi produk yang konkret

1. Pengguna/developer mendaftar produk
2. Menggunakan free trial di lingkungan lokal
3. Mengalami langsung nilai fungsi yang nyata (misalnya perbandingan sebelum/sesudah Pull Request, penyorotan masalah)
4. Menyadari nilai → muncul harapan akan efisiensi kerja dan otomatisasi
5. Pengguna meyakinkan pimpinan tentang kebutuhannya
6. Pimpinan melakukan pengujian internal dan meninjau anggaran lalu menyetujui atau menolak
7. Pimpinan memberikan persetujuan pembelian akhir
8. Pembelian produk selesai, lalu meluas lebih jauh di dalam organisasi

Pertanyaan tentang insentif di kedua sisi

• Pahami motivasi mendasar developer saat mengusulkan tool (kemudahan kerja, menonjolkan kapabilitas pribadi, mencapai tujuan perusahaan, dll.)
• Pahami motivasi pimpinan dalam membeli (meningkatkan efisiensi pengembangan, lebih cepat mencapai tujuan perusahaan, dll.)
• Jika motivasi inti ini ada, strategi berikut dapat diajukan

Strategi respons yang praktis

1. Sediakan alat persuasi seperti laporan perbandingan sebelum/sesudah yang akurat agar pengguna dapat meyakinkan pimpinan
   • Dalam proses ini, yang penting bukan nasihat abstrak, melainkan hasil berbasis data kuantitatif
   • Angka nyata seperti "berapa banyak waktu yang dihemat dibanding metode sebelumnya" menjadi kunci persuasi
2. Pahami bagaimana percakapan pembelian benar-benar berlangsung melalui wawancara pelanggan (developer), lalu selesaikan lebih dulu hambatan dalam proses persuasi

• Dengan kata lain, alih-alih langsung meyakinkan pemegang otoritas pembelian, Anda perlu menyediakan semua dukungan lingkungan dan materi konkret agar pengguna berhasil menjalankan peran penjualan internal
• Dalam proses ini, keberhasilan pengguna langsung menjadi keberhasilan vendor (struktur win bagi pengguna-vendor-pimpinan-perusahaan)

Penutup dan ringkasan

• Strategi terbaik adalah mendukung pengguna agar berhasil menjalankan peran penjualan internal untuk produk
• Fokus harus diberikan pada penyediaan dasar kuantitatif dan materi nilai yang konkret yang dibutuhkan untuk meyakinkan pimpinan
• Sebelumnya, perlu dilakukan analisis yang cermat terhadap struktur pengambilan keputusan berdasarkan ukuran organisasi dan kendalanya
• Pada akhirnya, ditekankan bahwa ketika pengguna berhasil, vendor dan perusahaan juga akan berhasil secara bersamaan

[GN⁺]

Opini Hacker News

• Rasanya sangat menjengkelkan saat hanya ingin mengunduh sesuatu tetapi diminta info kontak, lalu tak lama kemudian tenaga penjualan terus menelepon atau mengirim email, dan walau sudah ditolak dengan sopan tetap mengabaikannya dan berulang kali meminta meeting; saya memang tidak punya wewenang membeli, tetapi saya bisa menyebarkan ketidakpuasan di dalam tim, sehingga citra produknya akhirnya memburuk; kalau engineer meminta rekomendasi, tentu saya akan menyebut hal-hal seperti ini; contohnya Veeam, AWS, dan Keyence

  • Sebagai IT Manager, saya mengalami hal seperti ini hampir tiap minggu; karena tidak mendapat balasan dari saya, kadang mereka mem-bypass dengan mengirim email acak ke rekan kerja saya atau orang lain di perusahaan, dan kalau begini biasanya domain tersebut langsung diblokir secara menyeluruh; juga, tolong jangan paksa orang menonton demo hanya untuk mendapatkan satu penawaran harga; kalau saya sudah meneliti produknya dan memang perlu, kemungkinan saya juga sudah mencoba trial, jadi lebih masuk akal memberi tahu harga dulu daripada presentasi sales atau demo

  • Auth0 dan Okta juga mengalami masalah yang sama; saya benar-benar memegang wewenang pembelian dan anggarannya, tetapi kontak yang terlalu berlebihan membuat saya jadi tidak suka

  • Saya sangat suka konsep "power of annoyance"; bahkan jika produknya gratis, bila tim sales atau marketing terlalu agresif justru persepsi terhadap perusahaan bisa memburuk; pelanggan harus dihubungi dengan cara yang mereka inginkan, bukan semata dengan cara yang diinginkan pihak perusahaan, kalau tidak hasilnya bisa berbalik; tetapi ini memang sulit dari sisi desain insentif

  • Saya pernah mengalami kasus ekstrem dari beberapa tim marketing SaaS yang mengirim email setiap 5~15 menit; kadang mungkin itu tindakan impulsif dari individu karyawan, tetapi tampaknya ada juga kasus ketika pihak atas organisasi atau bahkan CEO sendiri menyetel alat email marketing ke level maksimum

  • Produk Microsoft juga perlu ditambahkan ke daftar ini; untuk mendaftar harus membuat "professional account", dan untuk itu akun gmail tidak diterima, jadi hambatan masuknya tinggi; bahkan saat hanya ingin memakai trial 30 hari dan mengevaluasi produk, ada kasus di mana saya sama sekali tidak bisa mengaksesnya karena masalah akun; kalau untuk trial saja sudah sesulit ini, saya bahkan tidak bisa membayangkan proses adopsi nyatanya; AI-based CRM, ERP, Dataverse, dan sejenisnya jadi tidak menarik untuk dipakai

• Fenomena ini berakar pada masalah Principal-Agent; eksekutif perusahaan memegang anggaran, tetapi yang benar-benar memakai produk atau alat adalah developer dan staf lapangan; dari sudut pandang founder, sering ada nasihat bahwa pengguna harus dijadikan pihak kita agar mereka bisa meyakinkan leadership, dan intinya adalah karena kita tidak bisa bicara langsung dengan orang yang benar-benar memegang kartu kredit, kita harus sebisa mungkin membantu pengguna meyakinkan leadership; dengan kata lain, pengguna atau developer dibuat menjalankan peran sales secara efektif; pendekatan ini mungkin bisa berlaku untuk model freemium dan semacamnya, tetapi di industri seperti sistem rumah sakit dan EHR (electronic health records), di mana keputusan pembelian sepenuhnya diambil secara sepihak oleh administrator, pengguna bahkan nyaris tidak punya kesempatan mencoba produknya, jadi saya penasaran bagaimana cara mengatasinya

  • Di lapangan sering juga terjadi situasi sebaliknya; sales yang licin membidik pemegang anggaran sambil menghalangi komunikasi dengan pengguna sebenarnya, lalu menutup kontrak lebih dulu; ketika para pengguna merasa tidak puas dan menunjukkan masalahnya, uangnya sudah telanjur dibayarkan

  • Untuk menjalankan saran "beri pengguna peluang terbaik untuk meyakinkan leadership, dan buat mereka terlihat menonjol hanya dengan bisa memberi tahu leadership tentang opsi ini", kami juga pernah membuat "CEO Page" terpisah https://www.rsync.net/products/ceopage.html

• Sedikit tambahan soal cara kerja enterprise sales: bahkan pengambil keputusan itu sendiri kadang tidak benar-benar memahami power dynamic di perusahaannya; hal lain yang perlu diperhatikan adalah apakah orang ini berada di cost center atau di unit yang menghasilkan pendapatan, apakah ini mendorong adopsi teknologi baru atau hanya produk yang sudah terstandar, dan siapa yang akan menganggap produk ini sebagai ancaman terhadap risiko atau kekuasaan; informasi seperti ini harus tercermin dalam strategi untuk menentukan kepada siapa menjual, siapa yang harus dihindari, dan kapan mendekati secara kecil-kecilan atau dalam skala besar

• Pendekatan yang sering dipakai Slack dan Postman adalah: "96% tim Anda sudah memakai produk kami. Bukankah sekarang membeli jadi masuk akal?"

  • Ini lalu memancing pertanyaan balik, "Kalau semua orang sudah memakainya, kenapa harus beli?"; pertanyaan ini menunjukkan seberapa besar jarak antara pembeli dan pengguna, terutama di lingkungan UKM

  • Memberikan software gratis kepada mahasiswa juga didorong oleh alasan yang sama

  • Hal seperti ini juga sering terjadi pada tim kecil di dalam perusahaan besar; jika ada tim keamanan, mereka bisa mempersoalkan penggunaan yang tersebar di banyak workspace Slack, jadi logika seperti "daripada 400 orang memakai 12 workspace, bagaimana kalau dikelola lewat satu akun resmi saja" bisa cukup efektif

  • Salah satu keuntungan tersembunyi dari commercial open source atau model serupa adalah makin tinggi adopsi pengguna individu, makin besar pula adopsi di tingkat perusahaan

• Perusahaan yang dulu saya dirikan juga menghadapi masalah ini; kami harus menjual kepada tim developer yang tidak punya kewenangan pembelian nyata, dan pada perusahaan kecil atau kasus pengecualian di mana ada orang yang berwenang, kontrak memang lebih mudah, tetapi dalam kebanyakan kasus kami harus meyakinkan pengambil keputusan di level atas soal penghematan biaya melalui siklus sales yang panjang; pada akhirnya proses ini memakan waktu lama dan tingkat keberhasilannya rendah, yang menjadi salah satu penyebab utama kegagalan perusahaan kami; saya senang topik seperti ini dibahas lebih terbuka, karena banyak bisnis kecil mengalaminya tetapi nasihat formal yang tersedia ternyata tidak banyak

• Model seperti ini cocok ketika pengguna bisa langsung memakai produk dan masih berada dalam organisasi yang sama, tetapi kalau pengguna tidak berkaitan langsung dengan pengambil keputusan atau sulit membuktikan justifikasi pembeliannya (misalnya pop keyless entry untuk mobil), saya penasaran bagaimana pendekatan yang tepat; bagi pengemudi manfaatnya besar, tetapi dari sudut pandang CTO Ford, ajakan meeting itu bisa terasa sama sekali tidak perlu; dalam situasi seperti ini, setelah produk dikembangkan, saya ingin meminta saran tentang cara masuk ke pasar

  • Dalam kasus seperti ini, strategi bottom-up terasa menarik; alih-alih membidik kantor pusat Ford, menargetkan dealer mobil bekas, bengkel mobil, atau toko aksesori sebagai langkah awal bisa efektif; mengambil contoh remote starter, pengguna membutuhkannya tetapi produsen mobil tidak terlalu peduli, jadi pada awalnya pasar terbentuk lewat cross-sell di toko audio, lalu belakangan produsen juga mulai menawarkannya sebagai opsi; saya juga punya pengalaman serupa dengan perangkat antimaling, dan memulai dari kecil, membangun basis pelanggan, lalu perlahan mendekati perusahaan besar memang efektif

  • Cara lain adalah menonjolkan fakta bahwa pesaing sudah mengadopsi pop tersebut untuk memicu FOMO (fear of missing out)

• Di enterprise, tidak cukup hanya menjual ke CTO; kalau itu perusahaan yang benar-benar memainkan peran inti seperti AWS atau Azure, mungkin cukup meyakinkan CTO dan engineer utama untuk mendorong perubahan di seluruh organisasi, tetapi untuk kebanyakan software, keputusan sering diambil oleh line manager, director, atau kepala departemen; bahkan software yang diadopsi pun bisa berbeda di tiap departemen, jadi targetnya harus dipecah lebih rinci

• Marketplace B2B2C sangat menarik; dalam model yang tidak membebankan biaya kepada pengguna "B2B" dan hanya mengambil komisi per transaksi, para pengguna itu dimanfaatkan sebagai tenaga penjualan yang tersebar; tiap pengguna harus dibantu agar bisa menarik pelanggan B2C melalui instance mereka masing-masing; dari sudut pandang tim founder, ini sering terasa membingungkan karena banyak yang harus dibangun, tetapi keuntungannya adalah hambatan masuk awal menjadi rendah, dan setiap kali sebuah akun berhasil menyampaikan nilai dengan baik kepada pelanggan akhir, pendapatan bisa tumbuh besar secara alami

• Ini sangat relate dengan perusahaan kami juga; kami membuat API business intelligence terkait entity resolution, dan karena tim engineering, product, dan data science semuanya terlibat, pemisahan antara pembeli dan pengguna menjadi rumit; para engineer secara intuitif paham betapa sulitnya mencocokkan data perusahaan yang kompleks, tetapi para eksekutif hanya melihat proyeknya terlambat; jadi belakangan ini pendekatan seperti "tim Anda menghabiskan berbulan-bulan untuk data matching" terdengar lebih meyakinkan; ada satu perusahaan yang mencoba membangunnya sendiri selama 10 tahun dan sampai sekarang pun masih belum berfungsi dengan benar; tentu saja kami juga merasa pendekatannya berbeda-beda tergantung perusahaan dan situasinya

  • Saya penasaran bagaimana Anda menyampaikan nilai teknis seperti ini kepada pengguna; apakah Anda mulai dengan cold email ke engineer untuk membuka percakapan lalu memperluasnya?

• Model lain adalah seperti TikTok, yang hanya mengambil persentase sebagai perantara per transaksi