Seat-Based Pricing Akan Mati. Inilah yang Menggantikannya

Seat-based pricing masuk akal ketika perangkat lunak berbasis desktop. Anda memiliki pengguna. Anda menghitung mereka. Anda membayar per lisensi. Hubungan antara nilai yang diberikan dan biaya cukup transparan.

Di dunia otomasi AI, orkestrasi workflow, dan alat yang menjalankan proses tanpa manusia dalam loop, membebani per kursi manusia semakin terputus dari cara nilai sebenarnya diberikan. CRM yang secara otomatis memperkaya catatan, merangkum panggilan, dan menghasilkan email tindak lanjut melakukan pekerjaan yang berarti apakah seorang salesperson duduk di meja mereka atau tidak. Platform otomasi workflow dapat memproses 10.000 catatan pelanggan semalam tanpa ada yang menyentuh keyboard. Model per-seat tidak menetapkan harga untuk salah satu dari outcome tersebut.

Vendor menggeser arsitektur penetapan harga lebih cepat dari yang sebagian besar pembeli menyesuaikan model pengadaan mereka. Ketidakselarasan ini menciptakan kejutan anggaran yang tidak diantisipasi CFO mana pun ketika mereka menandatangani perjanjian enterprise tiga tahun terakhir mereka.

Mengapa Seat-Based Pricing Berada di Bawah Tekanan Struktural

Tiga kekuatan independen secara bersamaan menekan model seat-based.

AI menggantikan seats, bukan hanya menambahnya. Janji asli dari alat produktivitas perangkat lunak enterprise adalah bahwa mereka akan membuat setiap seat lebih produktif. Realita yang muncul adalah beberapa fungsi ditangani oleh AI agents yang tidak memiliki seats. Tim pengembangan penjualan yang dulunya membutuhkan 15 SDR yang menjalankan sequence outbound kini dapat menjalankan volume yang sebanding dengan lima SDR dan lapisan orkestrasi AI, pergeseran yang dieksplorasi secara mendalam dalam AI agents dalam sales pipeline. Jika Anda membayar per seat dan jumlah seat menyusut, vendor membutuhkan tuas penetapan harga yang berbeda, dan usage-based pricing atas tindakan AI atau panggilan API adalah pilihan yang paling jelas.

Otomasi workflow mengubah pola penggunaan. Alat seat-based tradisional mengasumsikan bahwa konsumsi fitur berkorelasi dengan headcount. Satu orang pemasaran menggunakan platform pemasaran, dan penggunaan mereka berskala dengan waktu kerja mereka. Otomasi workflow memecah asumsi itu. Satu orang dapat mengonfigurasi workflow yang berjalan seribu kali per hari tanpa keterlibatan mereka. Nilai yang diberikan tidak ada hubungannya dengan jumlah seat.

Perusahaan menolak membayar untuk seats yang tidak aktif. Tekanan paling langsung pada seat-based pricing adalah sederhana: organisasi mengaudit lisensi mereka dan menemukan bahwa 30-40% seats yang dibayar jarang atau tidak pernah digunakan. Menurut riset manajemen SaaS Productiv, perusahaan rata-rata membuang 37% pengeluaran SaaS mereka untuk alat dan seats yang kurang dimanfaatkan. Tim procurement yang telah menjalankan analisis ini menekan keras dalam percakapan perpanjangan. Vendor yang bertahan dengan seat-based pricing kehilangan peluang dalam ekspansi aktif sambil memperjuangkan setiap seat saat perpanjangan.

Empat Model yang Muncul

Usage-based pricing. Anda membayar untuk apa yang Anda konsumsi: panggilan API, tindakan AI, catatan yang diproses, email yang dikirim, penyimpanan yang digunakan. Twilio adalah contoh kanonik dalam komunikasi. Snowflake dalam data. Tolok ukur SaaS tahunan OpenView melacak pergeseran ini: usage-based pricing telah berpindah dari pembeda yang ramah startup menjadi model dominan di perangkat lunak tahap pertumbuhan maupun enterprise. Vendor CRM dan produktivitas yang lebih baru menambahkan meter penggunaan pada kemampuan yang sebelumnya merupakan fitur seat tarif datar, terutama kemampuan AI yang struktur biayanya benar-benar variabel.

Risiko pembeli adalah bill shock. Usage-based pricing menggeser tanggung jawab perkiraan dari vendor (biaya seat tetap) ke pembeli (biaya konsumsi variabel). Perusahaan yang meremehkan perkiraan penggunaan menghadapi faktur yang melebihi anggaran tanpa jalan keluar yang mudah. Perusahaan yang melebihkan perkiraan membuang uang pada minimum yang dikomitmenkan.

Outcome-based pricing. Anda membayar ketika perangkat lunak memberikan hasil yang ditetapkan. Model ini paling matang dalam pemasaran berbasis kinerja tapi muncul dalam B2B SaaS. Beberapa platform intelijen pendapatan menagih berdasarkan pipeline yang dipengaruhi atau kesepakatan yang ditutup. Beberapa platform legal tech menagih berdasarkan kontrak yang diproses. Beberapa platform HR tech menagih berdasarkan perekrutan yang selesai.

Outcome-based pricing menyelaraskan insentif vendor dengan hasil pembeli, yang terdengar ideal. Tantangan negosiasinya adalah mendefinisikan apa arti "hasil", mengaitkannya dengan perangkat lunak dan bukan faktor lain, dan memastikan metodologi pengukuran akurat sekaligus tahan terhadap manipulasi.

Module-based pricing. Alih-alih per-seat, Anda membayar per modul kemampuan aktif terlepas dari berapa banyak pengguna yang mengaksesnya. Transisi HubSpot ke arah model ini instruksional: daripada menagih untuk seats di setiap hub, mereka telah menggeser sebagian penetapan harga mereka ke model di mana Anda membayar untuk akses ke kemampuan (Marketing Hub, Sales Hub, Service Hub) dengan akses pengguna yang lebih fleksibel di dalam setiap tier. Lihat perbandingan Rework vs. HubSpot CRM untuk cara struktur penetapan harga ini berperan dalam evaluasi nyata.

Module-based pricing cocok bagi pembeli yang membutuhkan penggunaan mendalam atas kemampuan tertentu di banyak pengguna kasual. Model ini tidak berjalan baik ketika Anda hanya membutuhkan sebagian kemampuan modul tetapi harga mengharuskan modul penuh.

Model hybrid. Sebagian besar perangkat lunak enterprise menetap ke struktur hybrid: tagihan seat dasar untuk pengguna inti dengan usage-based pricing pada fitur konsumsi tinggi. Einstein AI Salesforce, Operations Hub HubSpot, dan add-on AI enterprise Monday.com semua mengikuti pola ini: komitmen dasar ditambah konsumsi variabel untuk kemampuan bertenaga AI di atas.

Model hybrid adalah yang paling umum dan paling membingungkan. CFO yang menyetujui kontrak Salesforce $180.000/tahun mungkin tidak mengantisipasi bahwa fitur AI akan menambah $40.000 biaya penggunaan pada kuartal ketiga. Kontrak mengizinkannya. Percakapan anggaran tidak mengantisipasinya.

Masalah Bill Shock

Bill shock adalah risiko pembeli utama dalam usage-based pricing. Ini bukan teori. Ini pola yang terdokumentasi. Subscription Economy Index Zuora menemukan bahwa pendapatan berbasis penggunaan tumbuh lebih cepat dari kategori model penetapan harga lainnya, dan keluhan pembeli tentang faktur yang tidak terduga tumbuh seiring itu.

Mekanismenya sederhana: pembeli tidak memiliki model yang baik untuk memperkirakan penggunaan kemampuan baru. Ketika perusahaan pertama kali mengadopsi fitur AI usage-based, mereka membuat tebakan terpelajar tentang tingkat konsumsi. Tebakan itu sering salah, dan vendor diuntungkan oleh variansnya. Biaya mereka dibatasi oleh unit economics mereka, sementara biaya Anda dibatasi oleh konsumsi Anda.

Tiga klausul kontrak melindungi terhadap bill shock dalam kesepakatan usage-based:

Batas penggunaan dengan pemicu notifikasi. Sebelum tagihan Anda mencapai ambang batas yang ditetapkan, vendor memberi tahu Anda dan menjeda konsumsi kecuali Anda secara eksplisit mengotorisasi kelanjutan. Banyak vendor menolak batas keras (mereka lebih suka peringatan lunak) tetapi pemicu notifikasi dapat dinegosiasikan. Batas konsumsi rata-rata 90 hari dengan peringatan email pada 75% adalah titik awal yang wajar.

Floor tarif dan minimum yang berkomitmen dengan rollover. Jika Anda berkomitmen untuk konsumsi bulanan minimum, negosiasikan hak rollover untuk kapasitas yang tidak digunakan. Tanpa rollover, minimum yang tidak terpakai hangus dan biaya kelebihan berlaku terpisah. Dengan rollover, bulan dengan konsumsi berlebih menarik dari kapasitas yang tersimpan terlebih dahulu. Ini secara signifikan mengurangi varians bersih.

Frekuensi true-up. True-up tahunan menguntungkan pembeli: Anda merekonsiliasi konsumsi di akhir tahun. True-up bulanan berarti tagihan Anda berfluktuasi setiap siklus, menciptakan kerumitan arus kas dan pengelolaan anggaran. Dorong true-up kuartalan atau tahunan dengan batas bulanan, bukan penagihan true-up bulanan.

Apa yang Berubah dalam Pengadaan

Penganggaran untuk perangkat lunak seat-based itu lugas: headcount dikalikan biaya per seat, dengan change order jika headcount tumbuh signifikan. Keuangan dapat memodelkan skenario itu dengan percaya diri.

Penganggaran untuk perangkat lunak usage-based memerlukan pendekatan analitis yang berbeda. Anda memerlukan model konsumsi, bukan model headcount. Artinya:

Membangun baseline penggunaan. Sebelum menandatangani kontrak usage-based, habiskan 30-60 hari dalam uji coba atau deployment terbatas melacak tingkat konsumsi aktual. Jangan menerima estimasi vendor. Pola penggunaan Anda spesifik pada workflow dan volume data Anda. Estimasi vendor didasarkan pada rata-rata yang mungkin tidak berlaku bagi Anda.

Memmodel skenario varians. Daripada satu angka anggaran, bangun perkiraan konsumsi dengan tiga skenario: baseline, pertumbuhan (20% di atas baseline jika adopsi berjalan baik), dan lonjakan (skenario konsumsi tinggi tertentu seperti kampanye besar atau migrasi database). Anggaran Anda harus mampu menampung skenario pertumbuhan tanpa memerlukan persetujuan darurat.

Memisahkan anggaran fitur AI. Kemampuan AI memiliki struktur biaya yang pada dasarnya berbeda dari fitur perangkat lunak tradisional. Konsumsinya dapat melonjak tak terduga seiring meningkatnya adopsi tim atau kasus penggunaan baru. Perlakukan anggaran add-on AI sebagai lini terpisah dari biaya platform dasar, dengan tinjauan kuartalan yang tertanam dalam siklus anggaran.

Menegosiasikan tarif penggunaan multi-tahun. Jika Anda berkomitmen pada kontrak multi-tahun, negosiasikan penetapan harga konsumsi yang terkunci, bukan hanya penetapan harga seat yang terkunci. Kesepakatan tiga tahun yang mengunci biaya seat tetapi mengizinkan vendor mengubah harga API setiap tahun memberi perlindungan lebih kecil dari kelihatannya. Disiplin forecasting yang dikembangkan CRO berlaku langsung di sini: pemodelan konsumsi adalah masalah forecasting, dan tim dengan kadens forecast yang kuat menanganinya lebih baik.

Penilaian Risiko Model Penetapan Harga

Gunakan framework ini untuk mengevaluasi struktur penetapan harga apa pun di tiga dimensi sebelum menandatangani.

Skor Prediktabilitas Anggaran (1-5). Seberapa dapat diprediksi tagihan bulanan Anda di bawah struktur penetapan harga ini? Biaya seat datar adalah 5. Usage-based murni tanpa batas adalah 1. Hybrid dengan batas dan pemicu notifikasi adalah 3-4. Beri skor dan tentukan apakah proses manajemen anggaran organisasi Anda dapat menyerap tingkat varians yang dibawa struktur penetapan harga tersebut.

Skor Keselarasan Vendor (1-5). Apakah vendor menghasilkan lebih banyak uang ketika Anda mendapatkan lebih banyak nilai? Dalam outcome-based pricing, pendapatan vendor berskala dengan hasil Anda (skor: 5). Dalam seat-based pricing murni dengan perpanjangan tahunan, insentif vendor adalah mengunci Anda saat perpanjangan, bukan memaksimalkan nilai Anda di tahun pertama (skor: 2-3). Usage-based pricing berada di tengah: pendapatan vendor berskala dengan konsumsi Anda, yang berkorelasi dengan nilai tetapi tidak mengukurnya secara langsung. Beri skor dan pertimbangkan apakah struktur penetapan harga menciptakan insentif yang Anda inginkan dimiliki vendor Anda.

Skor Leverage Perpanjangan (1-5). Berapa banyak daya tawar negosiasi yang Anda miliki saat perpanjangan? Kesepakatan seat-based dengan biaya peralihan tinggi membuat Anda rentan saat perpanjangan. Daya tawar Anda terbatas kecuali Anda bersedia menanggung biaya migrasi. Kesepakatan usage-based memberi Anda data: Anda dapat menunjukkan tepat apa yang Anda konsumsi, membandingkannya dengan perkiraan Anda, dan bernegosiasi dari dasar bukti. Kesepakatan outcome-based memberi daya tawar terkuat jika hasilnya terukur dan Anda dapat mengaitkannya secara kredibel. Beri skor setiap kesepakatan berdasarkan seperti apa percakapan perpanjangan Anda dalam tiga tahun.

Tambahkan tiga skor. Total 10-15 adalah struktur penetapan harga yang dapat dikelola. Di bawah 8 memerlukan negosiasi yang lebih keras sebelum menandatangani. Ini bukan alat lulus/gagal. Ini adalah profil risiko yang menunjukkan di mana Anda harus menghabiskan modal negosiasi.

Apa yang Harus Dilakukan Pembeli Sekarang

Jika kontrak Anda saat ini seat-based dan akan diperbarui dalam 12 bulan ke depan, percakapan perpanjangan telah berubah. Vendor yang bergeser ke penetapan harga usage-based atau hybrid akan mencoba menggunakan perpanjangan sebagai titik transisi, sering dengan harga awal yang tampak sebanding dengan biaya seat Anda saat ini tetapi dengan tier penggunaan yang dapat menaikkan tagihan Anda secara signifikan jika adopsi meningkat.

Tanyakan pertanyaan-pertanyaan ini sebelum Anda menandatangani:

"Apa yang terjadi pada penetapan harga kami jika kami menerapkan fitur AI Anda ke semua pengguna?" Dapatkan angka spesifik, bukan "itu berskala dengan penggunaan Anda" yang kabur. Anda ingin mengetahui biaya all-in pada adopsi penuh.

"Seperti apa tagihan pelanggan yang tumbuh paling cepat dalam tahun kedua dibandingkan tahun pertama di bawah model penetapan harga ini?" Ini mengungkap pola varians yang sebenarnya, bukan perilaku teoretis model.

"Batas dan perlindungan apa yang tersedia untuk komponen usage-based?" Perlakukan vendor yang tidak dapat menjawab ini secara spesifik sebagai indikator risiko.

Pergeseran dari seat-based pricing bukan secara inheren tidak menguntungkan pembeli. Outcome-based pricing, dilakukan dengan baik, lebih selaras dengan cara pembeli memikirkan nilai perangkat lunak. Usage-based pricing, dengan batas dan pemodelan yang tepat, menghargai deployment yang efisien dan tidak menghukum Anda untuk seat yang tidak aktif. Untuk tim yang mengevaluasi apakah pergantian platform masuk akal mengingat perubahan model penetapan harga, perbandingan head-to-head seperti Rework vs. Salesforce adalah titik awal yang berguna untuk memodelkan TCO nyata di bawah struktur penetapan harga yang berbeda.

Tetapi masa transisi menciptakan risiko asimetris. Vendor berpindah ke model baru lebih cepat daripada kebanyakan pembeli menyesuaikan kerangka evaluasi mereka. Pembeli yang menandatangani kesepakatan usage-based tanpa model konsumsi dan batas yang dinegosiasikan menerima risiko yang belum mereka hargai. Pembeli yang membangun kerangka analitis sebelum percakapan dimulai bernegosiasi dari posisi yang setara.

Pelajari Lebih Lanjut

• Biaya Sebenarnya Software Sprawl di Perusahaan Mid-Market, bagaimana fragmentasi model penetapan harga melipatgandakan biaya menjalankan terlalu banyak alat
• Komite Pembelian B2B Baru: Siapa yang Benar-Benar Ada di Ruangan, siapa di organisasi Anda yang perlu menyetujui pergeseran model penetapan harga
• POC yang Memprediksi Keberhasilan, dan POC yang Membuang Waktu Semua Orang, cara mengevaluasi alat usage-based sebelum berkomitmen pada model konsumsi