Model harga untuk solusi multitenant

Model harga yang baik memastikan bahwa Anda tetap untung seiring bertambahnya jumlah penyewa dan saat Anda menambahkan fitur baru. Pertimbangan penting saat mengembangkan solusi multitenant komersial adalah cara merancang model harga untuk produk Anda. Di halaman ini, kami memberikan panduan bagi pembuat keputusan teknis tentang model harga yang dapat Anda pertimbangkan dan pengorbanan yang terlibat.

Saat menentukan model harga untuk produk, Anda harus menyeimbangkan nilai laba (ROV) untuk pelanggan Anda dengan biaya barang yang dijual (COGS) untuk memberikan layanan. Menawarkan model komersial yang lebih fleksibel (untuk solusi) dapat meningkatkan ROV untuk pelanggan, tetapi juga dapat meningkatkan kompleksitas arsitektur dan komersial dari solusi (dan oleh karena itu juga meningkatkan COGS Anda).

Beberapa pertimbangan penting yang harus Anda pertimbangkan, ketika mengembangkan model harga untuk solusi, adalah sebagai berikut:

• Apakah COGS akan lebih tinggi dari keuntungan yang Anda dapatkan dari solusi?
• Dapatkah COGS berubah dari waktu ke waktu, berdasarkan pertumbuhan pengguna atau perubahan pola penggunaan?
• Seberapa sulit mengukur dan mencatat informasi yang diperlukan untuk mengoperasikan model harga? Misalnya, jika Anda berencana untuk menagih pelanggan berdasarkan jumlah panggilan API yang mereka lakukan, apakah Anda telah mengidentifikasi bagaimana Anda mengukur panggilan API yang dilakukan oleh setiap pelanggan?
• Apakah profitabilitas Anda bergantung pada memastikan pelanggan menggunakan solusi Anda secara terbatas?
• Jika pelanggan menggunakan solusi secara berlebihan, apakah itu berarti Anda tidak lagi mendapatkan keuntungan?

Ada beberapa faktor utama yang mempengaruhi profitabilitas Anda:

• Model harga layanan Azure. Model harga layanan Azure atau pihak ketiga yang membentuk solusi Anda dapat memengaruhi model mana yang menguntungkan.
• Pola penggunaan layanan. Pengguna mungkin hanya perlu mengakses solusi Anda selama jam kerja mereka atau mungkin hanya memiliki sebagian kecil pengguna dengan volume tinggi. Dapatkah Anda mengurangi COGS Anda dengan mengurangi kapasitas yang tidak digunakan saat penggunaan Anda rendah?
• Pertumbuhan penyimpanan. Sebagian besar solusi mengakumulasi data dari waktu ke waktu. Lebih banyak data berarti biaya yang lebih tinggi untuk menyimpan dan melindungi data, mengurangi profitabilitas Anda per penyewa. Dapatkah Anda menetapkan kuota penyimpanan atau menerapkan periode retensi data?
• Isolasi penyewa. Model penyewaan yang digunakan memengaruhi tingkat isolasi yang Anda miliki di antara penyewa Anda. Jika membagikan sumber daya, apakah Anda perlu mempertimbangkan cara penyewa dapat menggunakan atau menyalahgunakan layanan secara berlebihan? Bagaimana tingkat isolasi penyewa akan memengaruhi COGS dan performa Anda untuk semua orang? Beberapa model harga tidak menguntungkan tanpa kontrol tambahan sekeliling alokasi sumber daya. Misalnya, Anda mungkin perlu menerapkan pembatasan layanan untuk membuat model harga tetap berkelanjutan.
• Siklus hidup penyewa. Misalnya, solusi dengan tingkat churn pelanggan yang tinggi, atau layanan yang memerlukan upaya on-boarding yang lebih besar, dapat mengalami profitabilitas yang lebih rendah --terutama jika mereka dihargai menggunakan model berbasis konsumsi.
• Persyaratan tingkat layanan. Penyewa yang membutuhkan tingkat layanan yang lebih tinggi dapat berarti solusi Anda tidak lagi menguntungkan. Sangat penting bagi Anda mengetahui tentang harapan tingkat layanan pelanggan dan kewajiban apa pun yang Anda miliki, sehingga Anda dapat merencanakan model harga yang sesuai.

Model harga umum

Ada banyak model harga umum yang sering digunakan dengan solusi multipenyewa. Masing-masing model harga ini memiliki keuntungan dan risiko komersial yang terkait, dan memerlukan pertimbangan arsitektur tambahan. Penting untuk memahami perbedaan antara model harga ini, sehingga Anda dapat memastikan solusi tetap menguntungkan seiring perkembangannya.

Catatan

Anda dapat menawarkan beberapa model untuk solusi atau menggabungkan model bersama-sama. Misalnya, Anda dapat memberikan model per pengguna untuk pelanggan yang memiliki jumlah pengguna yang cukup stabil, dan Anda juga dapat menawarkan model konsumsi untuk pelanggan yang memiliki pola penggunaan yang berfluktuasi.

Harga berdasarkan konsumsi

Model konsumsi terkadang disebut sebagai pay-as-you-go, atau PAYG. Saat penggunaan layanan Anda meningkat, pendapatan Anda meningkat:

Saat mengukur konsumsi, Anda dapat mempertimbangkan faktor sederhana, seperti jumlah data yang ditambahkan ke solusi. Atau, Anda dapat mempertimbangkan kombinasi atribut penggunaan bersama-sama. Model konsumsi menawarkan banyak manfaat, tetapi bisa sulit diterapkan dalam solusi multipenyewa.

Keuntungan: Dari perspektif pelanggan Anda, ada investasi di muka minimal yang diperlukan untuk menggunakan solusi Anda, sehingga model ini memiliki hambatan rendah untuk masuk. Dari perspektif Anda sebagai operator layanan, biaya hosting dan manajemen Anda meningkat seiring penggunaan pelanggan dan pendapatan Anda meningkat. Peningkatan ini dapat menjadikannya model harga yang dapat diskalakan dengan mudah. Model harga konsumsi bekerja dengan sangat baik saat layanan Azure yang digunakan dalam solusi juga berbasis konsumsi.

Kompleksitas dan biaya operasional: Model konsumsi bergantung pada pengukuran penggunaan yang akurat dan pemisahan penggunaan ini oleh penyewa. Hal ini dapat menjadi tantangan, terutama dalam solusi dengan banyak komponen terdistribusi. Anda perlu menyimpan catatan konsumsi terperinci untuk penagihan dan audit serta menyediakan metode bagi pelanggan untuk mendapatkan akses ke data konsumsi mereka.

Risiko: Harga konsumsi dapat memotivasi pelanggan untuk mengurangi penggunaan sistem Anda, untuk mengurangi biaya mereka. Selain itu, model konsumsi menghasilkan aliran pendapatan yang tidak terduga. Anda dapat menguranginya dengan menawarkan reservasi kapasitas, di mana pelanggan membayar beberapa tingkat konsumsi di awal. Anda, sebagai penyedia layanan, dapat menggunakan pendapatan ini untuk berinvestasi dalam peningkatan solusi, mengurangi biaya operasional, atau meningkatkan nilai laba dengan menambahkan fitur.

Catatan

Menerapkan dan mendukung reservasi kapasitas dapat meningkatkan kompleksitas proses tagihan dalam aplikasi Anda. Anda mungkin juga perlu mempertimbangkan cara pelanggan mendapatkan pengembalian uang atau menukar reservasi kapasitas mereka, dan proses ini juga dapat menambah tantangan komersial dan operasional.

Harga per pengguna

Model harga per pengguna melibatkan penagihan kepada pelanggan Anda berdasarkan jumlah orang yang menggunakan layanan Anda, seperti yang ditunjukkan dalam diagram berikut.

Model harga setiap pengguna sangat umum, karena kesederhanaannya untuk diterapkan dalam solusi multitenant. Namun, mereka dikaitkan dengan beberapa risiko komersial.

Keuntungan: Saat Anda menagih pelanggan untuk setiap pengguna, mudah untuk menghitung dan memperkirakan aliran pendapatan Anda. Selain itu, dengan asumsi bahwa Anda memiliki pola penggunaan yang cukup konsisten untuk setiap pengguna, maka pendapatan meningkat pada tingkat yang sama dengan adopsi layanan, menjadikannya model yang dapat diskalakan.

Kompleksitas dan biaya operasional: Model per pengguna cenderung mudah diterapkan. Tetapi, dalam beberapa situasi, Anda perlu mengukur konsumsi per pengguna, yang dapat membantu Anda memastikan bahwa COGS untuk satu pengguna tetap menguntungkan. Dengan mengukur konsumsi dan mengaitkannya dengan pengguna tertentu, Anda dapat meningkatkan kompleksitas operasional solusi.

Risiko: Pola konsumsi pengguna yang berbeda dapat mengakibatkan penurunan profitabilitas. Misalnya, pengguna berat solusi mungkin lebih mahal untuk dilayani daripada pengguna ringan. Selain itu, pengembalian nilai aktual (ROV) untuk solusi tidak tercermin oleh jumlah lisensi pengguna aktual yang dibeli.

Harga per pengguna aktif

Model ini mirip dengan harga per pengguna, tetapi daripada memerlukan komitmen di awal dari pelanggan mengenai jumlah pengguna yang diharapkan, pelanggan hanya dikenakan biaya untuk pengguna yang benar-benar masuk dan menggunakan solusi melalui periode (seperti yang ditunjukkan pada diagram berikut).

Anda dapat mengukur ini dalam periode apa pun yang masuk akal. Periode bulanan adalah hal biasa, dan metrik ini sering dicatat sebagai pengguna aktif bulanan atau MAU.

Manfaat: Dari perspektif pelanggan Anda, model ini memerlukan investasi dan risiko yang rendah, karena ada pembororan minimal; lisensi yang tidak digunakan tidak dapat ditagih. Hal ini membuatnya sangat menarik saat memasarkan solusi atau mengembangkan solusi untuk pelanggan perusahaan yang lebih besar. Dari perspektif Anda sebagai pemilik layanan, ROV Anda lebih akurat tercermin kepada pelanggan dengan jumlah pengguna aktif bulanan.

Kompleksitas dan biaya operasional: Model pengguna per aktif mengharuskan Anda merekam penggunaan aktual, dan membuatnya tersedia untuk pelanggan sebagai bagian dari faktur. Mengukur konsumsi per pengguna membantu memastikan profitabilitas dipertahankan dengan COGS untuk satu pengguna, tetapi sekali lagi hal ini membutuhkan pekerjaan tambahan untuk mengukur konsumsi untuk setiap pengguna.

Risiko: Seperti harga per pengguna, ada risiko bahwa pola konsumsi pengguna individu yang berbeda dapat memengaruhi profitabilitas Anda. Dibandingkan dengan harga per pengguna, model per pengguna aktif memiliki aliran pendapatan yang kurang dapat diprediksi. Selain itu, harga diskon tidak memberikan cara yang berguna untuk merangsang pertumbuhan.

Harga per unit

Di banyak sistem, jumlah pengguna bukan merupakan elemen yang memiliki efek terbesar pada COGS secara keseluruhan. Misalnya, dalam solusi berorientasi perangkat, juga disebut sebagai internet of things atau IoT, jumlah perangkat sering kali memiliki dampak terbesar pada COGS. Dalam sistem ini, model harga per unit dapat digunakan, tempat Anda menentukan apa itu unit, seperti perangkat. Lihat diagram berikut.

Selain itu, beberapa solusi memiliki pola penggunaan variabel yang tinggi, di mana sejumlah kecil pengguna memiliki dampak yang tidak proporsional pada COGS. Misalnya, dalam solusi yang dijual ke retailer fisik, model harga per toko mungkin sesuai.

Keuntungan: Dalam sistem di mana masing-masing pengguna tidak memiliki pengaruh yang signifikan terhadap COGS, harga per unit adalah cara yang lebih baik untuk mewakili kenyataan tentang cara penskalaan sistem dan dampak yang dihasilkan terhadap COGS. Hal ini juga dapat meningkatkan perataan dengan pola penggunaan aktual untuk pelanggan. Untuk banyak solusi IoT, di mana setiap perangkat menghasilkan jumlah konsumsi yang dapat diprediksi dan konstan, hal ini dapat menjadi model yang efektif untuk menskalakan pertumbuhan solusi Anda.

Kompleksitas dan biaya operasional: Umumnya, harga per unit mudah diterapkan dan memiliki biaya operasional yang cukup rendah. Tetapi, biaya operasional dapat menjadi lebih tinggi jika Anda perlu membedakan dan melacak penggunaan berdasarkan masing-masing unit, seperti perangkat atau toko ritel. Mengukur konsumsi per unit membantu memastikan profitabilitas Anda tetap terjaga, karena Anda dapat menentukan COGS untuk satu unit.

Risiko: Risiko model harga per unit mirip dengan harga per pengguna. Pola konsumsi yang berbeda oleh beberapa unit dapat berarti bahwa Anda telah mengurangi profitabilitas, seperti jika beberapa perangkat atau toko adalah pengguna solusi yang jauh lebih berat daripada yang lain.

Harga berdasarkan fitur dan tingkat layanan

Anda dapat memilih untuk menawarkan solusi dengan tingkat fungsionalitas yang berbeda pada titik harga yang berbeda. Misalnya, Anda dapat memberikan dua tarif tetap bulanan atau harga setiap unit, satu menjadi penawaran dasar dengan subset fitur yang tersedia, dan yang lainnya menyajikan kumpulan lengkap fitur solusi Anda. Lihat diagram berikut.

Model ini juga dapat menawarkan perjanjian tingkat layanan yang berbeda untuk tingkatan yang berbeda. Misalnya, tingkat dasar Anda mungkin menawarkan waktu aktif 99,9%, sedangkan tingkat premium mungkin menawarkan 99,99%. Perjanjian tingkat layanan (SLA) yang lebih tinggi dapat diterapkan dengan menggunakan layanan dan fitur yang memungkinkan target ketersediaan yang lebih tinggi.

Meskipun model ini dapat menguntungkan secara komersial, model ini membutuhkan praktik rekayasa yang matang agar berjalan dengan baik. Dengan pertimbangan yang cermat, model ini dapat menjadi sangat efektif.

Keuntungan: Harga berbasis fitur sering kali menarik bagi pelanggan, karena mereka dapat memilih tingkat berdasarkan kumpulan fitur atau tingkat layanan yang mereka butuhkan. Ini juga memberi Anda jalur yang jelas untuk meningkatkan pelanggan Anda dengan fitur tambahan atau ketahanan yang lebih tinggi bagi mereka yang membutuhkannya.

Kompleksitas dan biaya operasional: Model harga berbasis fitur dapat menjadi kompleks untuk diterapkan, karena model memerlukan solusi Anda untuk mengetahui fitur yang tersedia di setiap tingkat harga. Tombol alih fitur dapat menjadi cara yang efektif untuk menyediakan akses ke subset fungsionalitas tertentu, tetapi hal ini memerlukan pemeliharaan berkelanjutan. Selain itu, pengalih fitur meningkatkan overhead untuk memastikan kualitas tinggi, karena akan ada lebih banyak jalur kode untuk diuji. Mengaktifkan target ketersediaan layanan yang lebih tinggi di beberapa tingkatan mungkin memerlukan kompleksitas arsitektur tambahan, untuk memastikan rangkaian infrastruktur yang tepat digunakan untuk setiap tingkatan, dan proses ini dapat meningkatkan biaya operasional solusi.

Risiko: Model harga berbasis fitur dapat menjadi rumit dan membingungkan, jika ada terlalu banyak tingkat atau opsi. Selain itu, biaya yang terlibat dalam fitur yang berganti secara dinamis dapat memperlambat kecepatan saat Anda memberikan fitur tambahan.

Harga freemium

Anda dapat memilih untuk menawarkan tingkat layanan gratis, dengan fungsionalitas dasar dan tanpa jaminan tingkat layanan. Anda kemudian dapat menawarkan tingkat berbayar yang terpisah, dengan fitur tambahan dan perjanjian tingkat layanan formal (seperti yang ditunjukkan pada diagram berikut).

Tingkat gratis juga dapat ditawarkan sebagai percobaan berbatas waktu, dan selama percobaan pelanggan Anda mungkin memiliki fungsionalitas penuh atau terbatas yang tersedia. Hal ini disebut sebagai model freemium, yang secara efektif merupakan ekstensi dari model harga berbasis fitur.

Keuntungan: Sangat mudah untuk memasarkan solusi saat gratis.

Kompleksitas dan biaya operasional: Semua kompleksitas dan masalah biaya operasional berlaku dari model harga berbasis fitur. Tetapi, Anda juga harus mempertimbangkan biaya operasional yang terlibat dalam mengelola penyewa gratis. Anda mungkin perlu memastikan bahwa penyewa kedaluwarsa dikeluarkan atau dihapus, dan Anda harus memiliki kebijakan penyimpanan yang jelas, terutama untuk penyewa gratis. Saat mempromosikan penyewa ke tingkat berbayar, Anda mungkin perlu memindahkan penyewa di antara layanan Azure, untuk mendapatkan SLA yang lebih tinggi. Penting juga untuk menyimpan data dan konfigurasi penyewa, saat pindah ke tingkat berbayar.

Risiko: Anda perlu memastikan bahwa Anda memberikan ROV yang cukup tinggi bagi penyewa untuk mempertimbangkan beralih ke tingkat berbayar. Selain itu, biaya penyediaan solusi Anda kepada pelanggan di tingkat gratis harus ditanggung oleh margin keuntungan dari mereka yang berada di tingkat berbayar.

Harga jual barang

Anda dapat memilih untuk memberi harga solusi Anda sehingga setiap penyewa hanya membayar biaya pengoperasian bagian layanan Azure mereka, tanpa margin keuntungan tambahan. Model ini - juga disebut biaya pass through atau harga - terkadang digunakan untuk solusi multipenyewa yang tidak dimaksudkan untuk menjadi pusat keuntungan.

Biaya model barang yang dijual cocok untuk solusi multipenyewa yang dihadapi secara internal. Setiap unit organisasi sesuai dengan penyewa, dan biaya sumber daya Azure Anda perlu disebarkan di antara mereka. Mungkin juga sesuai di mana pendapatan berasal dari penjualan produk dan layanan lain yang mengonsumsi atau menambah solusi multipenyewa.

Manfaat: Karena model ini tidak menyertakan margin tambahan untuk keuntungan, biaya ke penyewa akan lebih rendah.

Kompleksitas dan biaya operasional: Mirip dengan model konsumsi, biaya barang yang dijual bergantung pada pengukuran penggunaan yang akurat dan pada pemisahan penggunaan ini oleh penyewa. Konsumsi pelacakan bisa menantang, terutama dalam solusi dengan banyak komponen terdistribusi. Anda perlu menyimpan catatan konsumsi terperinci untuk penagihan dan audit serta menyediakan metode bagi pelanggan untuk mendapatkan akses ke data konsumsi mereka.

Untuk solusi multipenyewa yang dihadapi secara internal, penyewa mungkin menerima perkiraan biaya perkiraan dan memiliki persyaratan audit penagihan yang lebih santai. Persyaratan santai ini mengurangi kompleksitas dan biaya pengoperasian solusi Anda.

Risiko: Biaya barang yang dijual harga dapat memotivasi penyewa Anda untuk mengurangi penggunaan sistem Anda, untuk mengurangi biaya mereka. Namun, karena model ini digunakan untuk aplikasi yang bukan pusat keuntungan, ini mungkin tidak menjadi perhatian.

Harga tetap

Dalam model ini, Anda membebankan tarif tetap kepada penyewa untuk akses ke solusi Anda, untuk jangka waktu tertentu. Harga yang sama berlaku terlepas dari seberapa banyak mereka menggunakan layanan, jumlah pengguna, jumlah perangkat yang mereka hubungkan, atau metrik lainnya. Lihat diagram berikut.

Ini adalah model paling sederhana untuk diterapkan dan dipahami oleh pelanggan, dan sering diminta oleh pelanggan perusahaan. Tetapi, model ini dapat dengan mudah menjadi tidak menguntungkan jika Anda perlu terus menambahkan fitur baru atau jika konsumsi penyewa meningkat tanpa pendapatan tambahan.

Keuntungan: Harga tetap mudah untuk dijual, dan mudah dipahami serta dianggarkan oleh pelanggan Anda.

Kompleksitas dan biaya operasional: Model harga tetap dapat dengan mudah diterapkan karena pelanggan tagihan tidak memerlukan pengukuran atau pelacakan konsumsi. Tetapi, meskipun tidak penting, disarankan untuk mengukur konsumsi per penyewa untuk memastikan bahwa Anda mengukur COGS secara akurat dan untuk memastikan bahwa profitabilitas tetap terjaga.

Risiko: Jika memiliki penyewa yang sangat memanfaatkan solusi Anda, maka model harga ini dengan cepat menjadi tidak menguntungkan.

Harga diskon

Setelah menentukan model harga, Anda dapat memilih untuk menerapkan strategi komersial untuk mendorong pertumbuhan melalui harga diskon. Harga diskon dapat digunakan dengan model harga konsumsi, per pengguna, dan per unit.

Catatan

Harga diskon biasanya tidak memerlukan pertimbangan arsitektur, selain menambahkan dukungan untuk struktur tagihan yang lebih kompleks. Diskusi lengkap tentang keuntungan komersial dari diskon berada di luar cakupan dokumen ini.

Pola harga diskon yang umum meliputi:

• Harga tetap. Anda memiliki biaya yang sama untuk setiap pengguna, unit, atau jumlah konsumsi, tidak peduli berapa banyak yang dibeli atau dikonsumsi. Ini adalah pendekatan yang paling sederhana. Tetapi, pelanggan yang sering menggunakan solusi Anda mungkin merasa bahwa mereka harus mendapatkan keuntungan dari skala ekonomi dengan mendapatkan diskon.
• Harga yang menyimpang. Saat pelanggan membeli atau mengonsumsi lebih banyak unit, Anda mengurangi biaya per unit. Hal ini lebih menarik secara komersial bagi pelanggan.
• Harga bertahap. Anda mengurangi biaya per unit, karena pelanggan membeli lebih banyak. Tetapi, Anda melakukannya dalam perubahan bertahap, berdasarkan rentang kuantitas yang telah ditentukan sebelumnya. Misalnya, Anda mungkin mengenakan harga yang lebih tinggi untuk 100 pengguna pertama, lalu harga yang lebih rendah untuk pengguna ke-101 hingga ke-200, lalu harga yang lebih rendah lagi setelah itu. Hal ini dapat menjadi lebih menguntungkan.

Diagram berikut menggambarkan pola harga ini.

Diskon lingkungan non-produksi

Dalam banyak kasus, pelanggan memerlukan akses ke lingkungan non-produksi yang dapat mereka gunakan untuk pengujian, pelatihan, atau untuk membuat dokumentasi internal mereka sendiri. Lingkungan non-produksi biasanya memiliki persyaratan konsumsi dan biaya yang lebih rendah untuk beroperasi. Misalnya, lingkungan non-produksi sering kali tidak tunduk pada perjanjian tingkat layanan (SLA), dan batas tarif mungkin ditetapkan pada nilai yang lebih rendah. Anda juga dapat mempertimbangkan penskalaan otomatis yang lebih agresif pada layanan Azure.

Selain itu, pelanggan sering mengharapkan lingkungan non-produksi secara signifikan lebih murah daripada lingkungan produksi mereka. Ada beberapa alternatif yang mungkin sesuai, ketika Anda menyediakan lingkungan non-produksi:

• Tawarkan tingkat freemium, seperti yang mungkin sudah Anda lakukan untuk pelanggan berbayar. Tingkat freemium harus dipantau dengan hati-hati, karena beberapa organisasi mungkin membuat banyak lingkungan pengujian dan pelatihan, yang akan menghabiskan sumber daya tambahan untuk beroperasi.

  Catatan

  Percobaan yang terbatas waktu yang menggunakan tingkat freemium biasanya tidak cocok untuk lingkungan pengujian dan pelatihan. Pelanggan biasanya membutuhkan lingkungan non-produksi mereka untuk tersedia selama masa layanan produksi.

• Tawarkan tingkat pengujian atau pelatihan layanan Anda, dengan batas penggunaan yang lebih rendah. Anda dapat memilih untuk membatasi ketersediaan tingkat ini untuk pelanggan yang sudah memiliki penyewa berbayar.
• Tawarkan harga diskon per pengguna, per pengguna aktif, atau per unit untuk penyewa non-produksi, dengan perjanjian tingkat layanan yang lebih rendah atau tidak sama sekali.
• Untuk penyewa yang menggunakan harga tetap, lingkungan non-produksi dapat dinegosiasikan sebagai bagian dari perjanjian.

Catatan

Harga berdasarkan fitur biasanya bukan merupakan opsi yang baik untuk lingkungan non-produksi, kecuali jika fitur yang ditawarkan sama dengan yang ditawarkan oleh lingkungan produksi. Ini karena penyewa biasanya ingin menguji dan memberikan pelatihan tentang semua fitur yang sama yang tersedia untuk mereka dalam produksi.

Model harga yang tidak menguntungkan

Model harga yang tidak menguntungkan membebani Anda lebih banyak untuk memberikan layanan daripada pendapatan yang Anda peroleh. Misalnya, Anda mungkin mengenakan tarif tetap per penyewa tanpa batasan apa pun untuk layanan, tetapi kemudian Anda akan membangun layanan dengan sumber daya Azure berbasis konsumsi dan tanpa batas penggunaan per penyewa. Dalam situasi ini, ada risiko penyewa Anda menggunakan layanan secara berlebihan dan, dengan demikian, membuatnya tidak menguntungkan untuk melayani mereka.

Umumnya, Anda perlu menghindari model harga yang tidak menguntungkan. Tetapi, ada situasi di mana Anda mungkin memilih untuk mengadopsi model harga yang tidak menguntungkan, termasuk:

• Layanan gratis sedang ditawarkan untuk memungkinkan pertumbuhan.
• Aliran pendapatan tambahan disediakan oleh layanan atau fitur add-on.
• Menghosting penyewa tertentu memberikan nilai komersial lain, seperti menggunakan penyewa sebagai penyewa utama di pasar baru.

Jika Anda secara tidak sengaja membuat model harga yang tidak menguntungkan, ada beberapa cara untuk mengurangi risiko yang terkait dengan model harga yang tidak menguntungkan, termasuk:

• Batasi penggunaan layanan melalui batas penggunaan.
• Mengharuskan penggunaan kapasitas reservasi.
• Minta penyewa pindah ke fitur atau tingkat layanan yang lebih tinggi.

Model harga yang berisiko

Saat menerapkan model harga untuk solusi, Anda biasanya harus membuat asumsi tentang bagaimana model tersebut akan digunakan. Jika asumsi ini ternyata salah atau pola penggunaan berubah dari waktu ke waktu, maka model harga Anda mungkin menjadi tidak menguntungkan. Model harga yang berisiko menjadi tidak menguntungkan dikenal sebagai model harga berisiko. Misalnya, jika mengadopsi model harga yang mengharapkan pengguna membatasi sendiri jumlah yang mereka gunakan untuk solusi Anda, maka Anda mungkin telah menerapkan model harga yang berisiko.

Sebagian besar solusi SaaS akan menambahkan fitur baru secara berkala. Hal ini meningkatkan ROV kepada pengguna, yang juga dapat menyebabkan peningkatan jumlah solusi yang digunakan. Hal ini dapat mengakibatkan solusi yang menjadi tidak menguntungkan, jika penggunaan fitur baru mendorong penggunaan, tetapi model harga tidak mempertimbangkan hal ini.

Misalnya, jika Anda memperkenalkan fitur unggah video baru ke solusi, yang menggunakan sumber daya berbasis konsumsi, dan penggunaan fitur oleh pengguna lebih tinggi dari yang diharapkan, maka pertimbangkan kombinasi batas penggunaan dan fitur dan harga tingkat layanan.

Batas penggunaan

Batas penggunaan memungkinkan Anda membatasi penggunaan layanan untuk mencegah model harga menjadi tidak menguntungkan, atau untuk mencegah penyewa tunggal menggunakan kapasitas layanan Anda dalam jumlah yang tidak proporsional. Hal ini dapat menjadi sangat penting dalam layanan multitenant, di mana satu penyewa dapat memengaruhi pengalaman penyewa lain dengan menghabiskan sumber daya secara berlebihan.

Catatan

Penting untuk membuat pelanggan sadar bahwa Anda menerapkan batas penggunaan. Jika menerapkan batasan penggunaan tanpa membuat pelanggan Anda mengetahui batasan tersebut, maka akan mengakibatkan ketidakpuasan pelanggan. Sehingga, penting untuk mengidentifikasi dan merencanakan batas penggunaan sebelumnya. Tujuannya adalah harus merencanakan batas, dan kemudian mengomunikasikan batas kepada pelanggan sebelum diterapkan.

Batas penggunaan sering digunakan bersama dengan fitur dan harga tingkat layanan, untuk memberikan jumlah penggunaan yang lebih tinggi pada tingkat yang lebih tinggi. Batasan juga umumnya digunakan untuk melindungi komponen inti yang akan menyebabkan penyempitan sistem atau masalah performa, jika terlalu banyak digunakan.

Batas tarif

Cara umum untuk menerapkan batas penggunaan adalah dengan menambahkan batas kecepatan ke API atau ke fungsi aplikasi tertentu. Ini juga disebut sebagai pembatasan. Batas kecepatan mencegah penggunaan yang berlebihan secara terus menerus. Mereka sering digunakan untuk membatasi jumlah panggilan ke API, selama periode waktu yang ditentukan. Misalnya, API hanya dapat dipanggil 20 kali per menit, dan akan menampilkan kesalahan HTTP 429, jika dipanggil lebih sering dari ini.

Beberapa situasi, di mana pembatasan tarif sering digunakan, termasuk yang berikut:

• REST API.
• Tugas asinkron.
• Tugas yang tidak sensitif terhadap waktu.
• Tindakan yang memerlukan biaya tinggi untuk dijalankan.
• Pembuatan laporan.

Menerapkan pembatasan tarif dapat meningkatkan kompleksitas solusi, tetapi layanan seperti Azure API Management dapat menyederhanakannya dengan menerapkan kebijakan batas tarif.

Siklus hidup model harga

Seperti bagian lain dari solusi Anda, model harga memiliki siklus hidup. Saat aplikasi berkembang dari waktu ke waktu, Anda mungkin perlu mengubah model harga. Hal ini mungkin didorong oleh perubahan kebutuhan pelanggan, persyaratan komersial, atau perubahan fungsionalitas dalam aplikasi Anda. Beberapa perubahan siklus hidup harga yang umum mencakup hal berikut:

• Menambahkan model harga yang benar-benar baru. Misalnya, menambahkan model harga konsumsi ke solusi yang saat ini menawarkan model tarif tetap.
• Menghentikan model harga yang ada.
• Menambahkan tingkat ke model harga yang ada.
• Menghentikan tingkat dalam model harga yang ada.
• Mengubah batas penggunaan pada fitur dalam model harga.
• Menambahkan atau menghapus fitur dari fitur dan model harga tingkat layanan.
• Berubah dari model komersial business-to-consumer (B2C), menjadi model komersial business-to-business (B2B). Perubahan ini kemudian memerlukan struktur harga baru untuk pelanggan bisnis Anda.

Biasanya rumit untuk menerapkan dan mengelola banyak model harga yang berbeda sekaligus. Hal ini juga membingungkan pelanggan Anda. Jadi, lebih baik menerapkan satu atau dua model saja, dengan jumlah tingkat yang sedikit. Hal ini membuat solusi Anda lebih mudah diakses dan dikelola.

Catatan

Model harga dan fungsi tagihan harus diuji, idealnya menggunakan pengujian otomatis, sama seperti bagian lain dari sistem Anda. Semakin kompleks model harga, semakin banyak pengujian yang diperlukan, sehingga biaya pengembangan dan fitur baru akan meningkat.

Saat mengubah model harga, Anda harus mempertimbangkan faktor-faktor berikut:

• Apakah penyewa ingin bermigrasi ke model baru?
• Apakah mudah bagi penyewa untuk bermigrasi ke model baru?
• Akankah model harga baru membuat layanan Anda berisiko? Misalnya, apakah Anda menghapus batas kecepatan yang saat ini melindungi sumber daya penting dari penggunaan yang berlebihan?
• Apakah penyewa memiliki jalur yang jelas untuk bermigrasi ke model harga baru?
• Bagaimana Anda mencegah penyewa menggunakan model harga yang lebih lama, sehingga Anda dapat menghentikannya?
• Apakah penyewa kemungkinan akan menerima kejutan tagihan (reaksi negatif terhadap tagihan yang tidak terduga) setelah mengubah model harga?
• Apakah Anda memantau performa dan pemanfaatan layanan Anda, untuk model harga baru atau yang diubah, sehingga Anda dapat memastikan profitabilitas yang berkelanjutan?
• Apakah Anda dapat dengan jelas mengomunikasikan ROV untuk model harga baru, kepada penyewa yang ada?

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Daniel Scott-Raynsford | Strategi Teknologi Mitra

Kontributor lain:

• Bohdan Cherchyk | Insinyur Pelanggan Senior, FastTrack untuk Azure
• John Downs | Insinyur Perangkat Lunak Utama
• Chad Kittel | Insinyur Perangkat Lunak Utama
• Paolo Salvatori | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Pertimbangkan cara Anda akan mengukur konsumsi oleh penyewa dalam solusi Anda.