Product manager membuka dashboard dan melihat hanya 8% akun memakai fitur export laporan bulanan. Angka itu tampak buruk. Tim mulai mempertimbangkan redesign, onboarding tambahan, atau bahkan menghapus fiturnya.

Namun, denominator tersebut mungkin salah. Tidak semua akun perlu mengekspor laporan. Sebagian pelanggan memakai integrasi API, sebagian hanya membaca dashboard, dan sebagian belum mencapai akhir periode pelaporan. Di antara akun yang benar-benar membutuhkan export, bisa jadi mayoritas berhasil menggunakannya tepat saat dibutuhkan.

Fitur B2B yang penting tidak selalu dipakai setiap hari atau setiap minggu. Approval tahunan, pemulihan akun, audit log, bulk import, dan penutupan buku bisa bernilai tinggi justru karena menyelesaikan pekerjaan yang jarang tetapi berisiko. Jika keberhasilannya dinilai hanya dari weekly active usage, tim dapat mengoptimalkan frekuensi yang tidak relevan dan melewatkan kegagalan yang sebenarnya.

Mulai dari konteks penggunaan, bukan event yang paling mudah dihitung

Pertanyaan pertama bukan “berapa banyak pengguna mengklik fitur ini?”, melainkan “siapa yang seharusnya membutuhkan fitur ini, dalam situasi apa, dan pekerjaan apa yang harus selesai?”

Ambil contoh fitur bulk import pada software inventaris. Akun baru mungkin memakainya sekali saat migrasi. Akun lama baru memakainya ketika membuka cabang atau mengganti katalog. Mengukur persentase seluruh pengguna yang melakukan import setiap minggu tidak memberi gambaran yang berguna. Mayoritas pengguna memang tidak sedang berada dalam konteks tersebut.

Definisikan tiga hal sebelum memilih metric:

  1. Eligible account: akun yang secara realistis memiliki kebutuhan, misalnya akun baru dengan lebih dari 500 SKU atau akun lama yang sedang menambah lokasi.
  2. Trigger: kejadian yang membuat kebutuhan muncul, misalnya aktivasi awal, pergantian sistem, atau pembukaan cabang.
  3. Desired outcome: pekerjaan yang harus selesai, misalnya data produk masuk dengan benar dan dapat dipakai untuk transaksi.

Definisi ini mencegah dashboard menyatukan orang yang tidak membutuhkan fitur dengan orang yang membutuhkan tetapi gagal menemukannya.

Susun rantai sinyal dari eligibility hingga outcome

Untuk fitur low-frequency, satu metric jarang cukup. Gunakan rantai sinyal yang menunjukkan di mana nilai terhenti.

1. Opportunity rate

Opportunity rate adalah proporsi eligible account yang benar-benar menghadapi trigger dalam periode pengamatan. Angka ini bukan target performa fitur. Ia menjelaskan ukuran kesempatan yang tersedia.

Jika hanya 40 dari 300 akun eligible membuka cabang pada kuartal ini, basis evaluasi adopsi bukan 300 akun, apalagi seluruh pengguna. Basisnya adalah 40 akun yang memiliki kesempatan nyata untuk memakai fitur.

2. Discovery dan setup success

Di antara akun yang menghadapi trigger, berapa yang menemukan jalur tersebut dan berhasil menyiapkannya? Pisahkan discovery dari setup karena tindakannya berbeda.

Jika pengguna tidak pernah membuka bulk import, masalahnya mungkin discoverability, dokumentasi, atau handoff dari customer success. Jika mereka memulai tetapi berhenti saat memetakan kolom, masalahnya berada pada setup. Menyatukan keduanya sebagai “tidak mengadopsi” membuat tim salah memilih perbaikan.

3. Task success

Ukur apakah pekerjaan inti selesai, bukan sekadar apakah event terakhir terkirim. Untuk bulk import, task success dapat berarti file diproses tanpa error kritis dan sebagian besar baris dapat digunakan. Untuk approval flow, artinya permintaan mencapai keputusan oleh pihak yang tepat, bukan hanya tombol “submit” diklik.

Tambahkan waktu penyelesaian dan kebutuhan bantuan jika relevan. Sebuah tugas bisa selesai tetapi tetap mahal jika pengguna harus membuka tiga tiket support atau menunggu dua hari karena pesan error tidak jelas.

4. Outcome dan guardrail

Outcome menghubungkan keberhasilan tugas dengan alasan bisnis memakai fitur. Setelah import berhasil, apakah akun lebih cepat menyelesaikan konfigurasi awal? Setelah audit log digunakan, apakah investigasi insiden dapat ditutup tanpa ekspor manual dari tim support?

Pilih satu outcome yang dekat dengan pekerjaan tersebut. Jangan memaksa setiap fitur membuktikan dampak langsung pada retention atau revenue; jaraknya sering terlalu jauh dan dipengaruhi banyak faktor. Gunakan guardrail untuk menangkap biaya tersembunyi, seperti tiket support, rollback, data rusak, atau approval yang salah alamat.

Gunakan jendela waktu berbasis trigger

Calendar window sering menyesatkan untuk pekerjaan yang jarang. “Adopsi dalam 30 hari setelah peluncuran” tidak masuk akal jika sebagian besar akun baru membutuhkan fitur enam bulan kemudian.

Gunakan trigger-based window: ukur apakah akun menyelesaikan bulk import dalam tujuh hari setelah menambahkan lokasi, atau apakah admin menemukan audit log dalam satu sesi investigasi. Setiap akun dinilai ketika kesempatan penggunaan benar-benar muncul.

Pendekatan ini juga memperbaiki perbandingan cohort. Anda dapat membandingkan akun yang menghadapi trigger sebelum dan sesudah perubahan produk, bukan mencampur akun yang sedang membutuhkan fitur dengan akun yang tidak relevan.

Jika volume trigger sangat kecil, jangan memaksakan kesimpulan dari perubahan persentase. Baca setiap kegagalan secara individual, kelompokkan pola, dan gabungkan telemetry dengan user research atau tiket support. Seperti dibahas dalam artikel tentang kapan A/B test tidak tepat, metode evaluasi harus mengikuti jenis ketidakpastian dan volume bukti yang tersedia.

Contoh: menilai fitur approval diskon enterprise

Bayangkan tim meluncurkan approval untuk diskon di atas 20%. Fitur ini hanya relevan bagi akun yang memberi wewenang diskon kepada tim sales dan memiliki kebijakan persetujuan bertingkat. Weekly active usage pasti rendah karena diskon besar tidak terjadi setiap minggu.

Tim dapat menyusun metric seperti ini:

  • Eligible: akun enterprise yang mengaktifkan kebijakan diskon dan memiliki minimal dua peran persetujuan.
  • Trigger: sales mengajukan diskon di atas ambang yang ditetapkan.
  • Discovery: pengajuan masuk ke approval flow, bukan dikirim lewat chat atau email.
  • Setup success: approver dan batas kewenangan terkonfigurasi tanpa bantuan support.
  • Task success: pengajuan diputuskan sebelum batas waktu internal dan keputusan tercatat.
  • Outcome: lebih sedikit transaksi tertunda karena approver tidak jelas.
  • Guardrail: tidak ada persetujuan oleh peran yang salah dan jumlah override manual tidak meningkat.

Jika usage rendah karena trigger memang jarang, tidak ada masalah. Jika trigger terjadi tetapi pengajuan tetap pindah ke chat, tim perlu menyelidiki discovery atau kecocokan workflow. Jika pengajuan masuk tetapi sering terlambat, notifikasi, delegasi, atau aturan eskalasi mungkin lebih penting daripada menaikkan adoption.

Checklist sebelum menilai fitur low-frequency

Sebelum membawa angka ke review produk, periksa:

  • Apakah denominator hanya mencakup akun yang eligible?
  • Apakah Anda tahu kapan trigger penggunaan terjadi?
  • Apakah discovery, setup, dan task success diukur terpisah?
  • Apakah task success mencerminkan pekerjaan selesai, bukan sekadar klik?
  • Apakah jendela pengukuran dimulai dari trigger?
  • Apakah outcome cukup dekat dengan fungsi fitur?
  • Apakah guardrail menangkap error, bantuan manual, atau risiko operasional?
  • Jika volumenya kecil, apakah kegagalan ditinjau secara kualitatif?

Rekomendasi utama

Jangan menetapkan target adopsi sebelum mendefinisikan siapa yang semestinya memakai fitur dan kapan kebutuhannya muncul. Untuk fitur B2B yang jarang digunakan, bangun rantai metric dari eligibility, trigger, discovery, setup, task success, hingga outcome yang dekat.

Dashboard yang baik tidak harus membuat angka penggunaan terlihat besar. Dashboard harus membantu tim membedakan tiga kondisi: fitur tidak dibutuhkan, fitur dibutuhkan tetapi tidak ditemukan, atau fitur ditemukan tetapi gagal menyelesaikan pekerjaan. Perbedaan itu menentukan apakah keputusan berikutnya adalah mempertahankan, memperbaiki, mendukung, atau menghentikan fitur.