Artikel khusus pengacara Lin Shang-Lun: BD yang hebat—yang dijual adalah kekuatan integrasi AI

Pengembangan bisnis di era AI: bisa berevolusi secara menyeluruh dengan menargetkan titik sakit tim sendiri—bahkan kalau Anda bukan full-time developer pun masih bisa melakukannya. Tren seperti ini seharusnya menjadi sikap awal yang wajib dimiliki untuk setiap posisi.
(Pengantar: Artikel khusus pengacara Lin Shang-lun》Profesional yang paham AI, apakah akan menjadi pemenang di era AI? )
(Tambahan konteks: Artikel khusus pengacara Lin Shang-lun》Melihat dari kasus Tsai A-Ka: ketakutan pada AI—Anda yang marah bukan karena AI, tapi takut tersalip)

Daftar Isi

Toggle

• Hal yang dia buat, sebenarnya sangat tepat mengenai titik sakit
• Membahas bagaimana dia memasukkan AI ke dalamnya
• Tapi menurut saya, Output masih bisa lebih banyak
• Dari sudut pandang pengacara, ada satu hal yang pasti harus dilakukan: tekan halusinasi
• Beberapa fungsi yang menurut saya bisa ditambahkan lagi ke BD Agent yang dia buat
  • Menghasilkan revisi kontrak secara otomatis dari catatan rapat
  • Menyesuaikan tingkat kekuatan kontrak berdasarkan posisi saat negosiasi
  • Peninjauan kepatuhan, menahan risiko di depan
• Terakhir

Di sebuah pameran teknologi, saya bertemu dengan atasan Business Development (BD) yang akan bekerja di perusahaan besar yang segera jadi. Yang lebih spesial, dia sendiri yang turun tangan membuat satu set sistem internal yang dipakai BD di perusahaan mereka dengan AI. Dia sangat terbuka, mengeluarkan ponselnya untuk menunjukkan prototype miliknya. Kami pun mulai mengobrol—sambil melihat sambil ngobrol.

Karena saya sendiri biasanya juga mengerjakan pengembangan AI, dan sekaligus saya pengacara, saat melihat karyanya saya tidak bisa tidak memikirkan beberapa lapis. Tulisan ini anggap saja sebagai rangkuman obrolan hari itu: mencatat apa yang saya lihat, serta arah yang bisa terus “dimainkan” setelah saya ngobrol dengannya.

Hal yang dia buat, sebenarnya sangat tepat mengenai titik sakit

Dia sejak awal menyebut masalah yang sangat nyata: tim BD mereka volume pengembangan di luar terlalu besar—sampai tidak ada manajer yang bisa mencerna laporan harian semua orang. Manajer hanya bisa memberi instruksi yang sangat kasar, tidak bisa membuat taktik yang presisi untuk setiap toko dan setiap titik lokasi. Selain itu, setelah BD melempar semuanya, sangat mudah terjadi tabrakan jadwal/kontrak: semua orang harus menyinkronkan progres satu sama lain, dan itu malah super tidak efisien.

Karena itu dia membuat sebuah aplikasi. Saat login masuk ke tampilan admin; di situ ada banyak layer. Layer yang paling inti memvisualisasikan semua titik yang dibuka BD di luar dan kondisi deal-nya. Manfaatnya langsung terasa:

Pertama, semua orang tidak perlu lagi sinkronisasi lisan satu sama lain; sebelum seseorang memulai gelombang pengembangan baru, dengan sekali lihat bisa diketahui siapa yang sudah mengerjakan apa, dan setiap titik sudah sampai tahap mana. Kedua, dari sudut pandang dia sebagai atasan, dia bisa langsung melihat seluruh pipeline: toko mana yang macet di tahap apa terlihat jelas.

Jujur, sekali lihat pun sudah terasa ini dibuat oleh orang yang benar-benar paham BD. Logika pada antarmukanya bukan ide yang muncul begitu saja dari seorang engineer; memang benar dirancang seperti itu setelah dia merasakan proses bisnis di lapangan.

Membahas bagaimana dia memasukkan AI ke dalamnya

Saya penasaran dan bertanya: AI itu sebenarnya dipakai untuk apa. Dia bilang dia menyambungkan sebuah AI yang merapikan semua pengetahuan, kontrak-kontrak sebelumnya, dan contoh kerja sama yang biasa dipakai BD saat mengembangkan—lalu mengubahnya menjadi basis data.

Dia memberi contoh yang sangat praktis: kadang BD mengembangkan ke brand berbasis jaringan/ritel berantai, tapi cara menegosiasikan kontraknya sama sekali berbeda dengan toko tunggal. Jaringan itu skalanya besar, pengaruhnya kuat; sering kali perlu melakukan pertukaran kepentingan. Namun saat BD dilatih, sulit sekali menjelaskan dengan jelas “pihak lawan itu levelnya seperti apa, dan kita bisa menukar apa sebagai bargaining chip.” Jadi hal itu dia serahkan ke AI untuk menjawab. Menurut saya, titik masuk ini cukup tepat.

Saya juga bertanya bagaimana dia membuat basis data. Dia menjawab dengan jujur: sebenarnya cukup dideploy di Google Sheet, dibaca langsung pakai JS. Tapi dia menekankan satu hal: setiap BD melihat apa, dan AI menjawab apa—semuanya ada catatan, semuanya bisa ditelusuri. Dia bahkan lebih dulu menulis “definisi merchant”: AI menjalankan definisi tersebut dulu, menilai tipe pelanggan baru, lalu kembali mencocokkan dengan contoh kerja sama.

Ada satu detail kecil yang ingin saya tekankan. Saat saya bilang padanya bahwa pada Gemini Flash versi gratis ada jebakan—batas token bisa membuat hasilnya tidak sesuai harapan—dia ternyata sudah memikirkan itu lebih dulu. Dia merencanakan jalur untuk setiap pertanyaan dan “mengunci” semuanya: jika menghadapi jenis masalah tertentu, maka hanya baca beberapa halaman yang relevan. Dengan begitu bukan hanya tidak melewatkan bacaan, tapi juga menghemat waktu dan menghemat token. Pendekatan “tidak memaksa, menilai dulu baru mengambil data” seperti ini memang menang di inti.

Tapi menurut saya, Output masih bisa lebih banyak

Sampai di sini, saya bilang sesuatu yang cukup terus terang padanya: “Produk kamu ini memang bagus, dan sangat sesuai dengan cara pakai tim kalian. Tapi—rasanya ‘cita rasa AI’-nya belum terlalu terasa.”

Saya bukan sedang cari kesalahan, tapi merasa masih ada ruang untuk main lebih jauh. Yang dia lakukan sekarang, pada dasarnya mengubah jejak kerja BD yang dulu sifatnya tidak transparan, tidak bisa dikontrol, dan sulit ditarik kembali—menjadi transparan, terlihat, dan bisa diatur. Dari sisi input, fondasinya sudah sangat kuat.

Tapi dari sudut pandang developer, saya pikir dia mandek di output. Saat ini hasilnya hampir seluruhnya terkumpul di ChatBox dan perapihan data. ChatBox memang hal bagus, tapi menurut saya output-nya bisa dikirim ke lebih banyak tempat, misalnya:

Pertama, keluarkan langsung dokumen format perusahaan, seperti MOU dan laporan, bukan membuat orang membaca percakapan lalu menyusunnya sendiri. Kedua, gunakan antarmuka dan alur yang berbeda untuk menangkap tugas yang berbeda; jangan semua urusan dimasukkan ke satu kotak dialog. Lapisan bawahnya tetap LLM, tapi bisa membuat desain Agent yang berbeda untuk skenario yang berbeda: satu jenis tugas, satu jenis alur.

Dari sudut pandang pengacara, ada satu hal yang pasti harus dilakukan: tekan halusinasi

Bagian ini saya obrolkan dengan dia dari sudut pandang pengacara. Karena karyanya menyentuh kontrak dan kondisi bisnis; ruang toleransi untuk kesalahan lebih kecil daripada yang biasanya dibayangkan orang.

Kebiasaan saya: output dari AI tidak boleh ada hal yang dibuat-buat secara sembarangan. Jadi saya menyarankan dia menambahkan dua hal:

Satu, cantumkan rujukan dan asal-usulnya. Setelah setiap hasil output, beri citation; klik saja untuk melihat “kalimat ini berasal dari dokumen yang mana, bagian yang mana.” Ini sebenarnya sangat penting baginya—karena BD yang membawa bargaining chip dari AI untuk bertempur di lapangan harus bisa memverifikasi sumbernya. Kalau tidak bisa konfirmasi sumbernya, itu berarti mereka sedang mengambil risiko dengan “informasi yang belum terverifikasi”.

Dua, turunkan temperature. Semakin butuh presisi dan tidak boleh main-main, semakin harus menekan probabilitas acak model. Dengan dua hal ini digabung, ruang halusinasi akan jauh berkurang.

Beberapa fungsi yang menurut saya bisa ditambahkan lagi ke BD Agent yang dia buat

Di perusahaan mereka ada bagian Legal dan pengacara; kontrak kebanyakan template publik dan tidak banyak diubah. Kedengarannya seperti AI tidak punya ruang, tapi justru saya merasa skenario yang “terlihat stabil” itulah yang paling bisa dimanipulasi. Saya sempat ngobrol santai dengannya tentang beberapa arah:

2. Menghasilkan revisi kontrak secara otomatis dari catatan rapat

Setelah BD selesai bicara, yang paling melelahkan adalah mengubah diskusi rapat selama dua jam menjadi pasal-pasal resmi. Ini bidang yang AI kuasai: ambil template, lalu masukkan seluruh catatan rapat ke dalamnya; AI akan menghasilkan versi baru berdasarkan kesimpulan. Bagian yang dihapus atau diubah ditandai dengan tracked changes, jadi tim legal tinggal melihat area mana yang bergerak.

3. Menyesuaikan tingkat kekuatan kontrak berdasarkan posisi saat negosiasi

Yang ini menurut saya paling menarik, karena nyambung langsung dengan logika di sistemnya. Masalah template publik adalah ia tidak bisa mencerminkan perbedaan kekuatan setiap kali negosiasi. Saat negosiasi dengan perusahaan besar, posisi kita lemah—maka ketentuan bisa dibuat lebih fleksibel; saat negosiasi dengan pihak kecil, posisi kita kuat—ketentuannya bisa dibuat lebih tegas. Tidak ada satu kontrak pun yang cocok untuk semua; tiap kontrak harus dikustom. Kalau Agent-nya bisa otomatis menghasilkan versi yang berbeda tingkat kekuatan berdasarkan “skala pihak lawan,” bukankah itu sejalan dengan gagasan di sistemnya tentang “senjata yang sesuai dengan tier/level” saat menghadapi pihak tertentu?

4. Peninjauan kepatuhan, menahan risiko di depan

Konten yang dipublikasikan BD sering punya risiko kepatuhan. AI bisa membantu memeriksa per kalimat: kata-kata mana yang terlalu berlebihan atau terlalu “mengunci,” melanggar aturan hukum yang mana, perlu dihapus atau ditambah dengan peringatan. Untuk tim BD yang setiap hari turun ke lapangan, kemampuan “mencegah sebelum kejadian” ini sebenarnya sangat berguna.

Saya juga mengingatkan dia satu hal: kalau perusahaan punya beberapa pasal yang secara khusus ingin dipertahankan, itu tidak bertentangan. Ucapannya bisa diubah, gaya bahasanya bisa disesuaikan, tetapi tetap mempertahankan hak dan kepentingan pihak kita—secara teknis itu benar-benar bisa dilakukan.

Terakhir

Obrolan hari itu meninggalkan kesan yang cukup dalam. Dia butuh tiga minggu, bahkan sengaja memakai anggarannya sendiri: sebelum prototype selesai, dia tidak menghabiskan sumber daya perusahaan. Dia mengubah titik sakit yang nyata menjadi sesuatu yang bisa digunakan; dan karyawan sudah memakainya, bos juga mengangguk setuju.

Dua lebih bulan belakangan, dia terus melakukan hal yang sama—mencari titik sakit, mencari kapan AI bisa masuk. Menurut saya, ini sikap yang semestinya dimiliki orang yang ingin memakai AI: bukan “AI itu keren, ayo coba-coba,” melainkan “ini masalah yang sakitnya nyata; bisa nggak AI datang untuk meredakan sakitnya.”

Pada intinya, AI yang paling berguna biasanya bukan yang paling “wah,” melainkan yang paling paham cara kerja bisnis dan paling dekat dengan titik sakit yang benar-benar nyata. Melihat seorang BD yang sedemikian jago mulai memikirkan logika pekerjaannya dengan AI, saya justru cukup menantikan apa yang akan dia buat setelah ini.