چگونه برای هر صندلی کاربریِ عامل هوش مصنوعی با مصرف متغیر قیمت‌گذاری کنیم تا حاشیه سود حفظ شود
قیمت‌گذاری به‌ازای هر کاربر برای Salesforce جواب می‌داد، چون هر کارشناس فروش تقریباً به یک اندازه روی دکمه‌ها کلیک می‌کرد. اما عامل هوش مصنوعی که مستقلاً پیش‌نویس تهیه می‌کند، تحقیق انجام می‌دهد و وظایف را به اجرا درمی‌آورد، از این قاعده پیروی نمی‌کند. تقلید از مدل قدیمی، بی‌سروصدا حاشیه سود بنیان‌گذاران را کاهش می‌دهد.
محاسباتی وجود دارد که دیر یا زود هر مدل قیمت‌گذاری مبتنی بر تعداد کاربران را برای ابزارهای هوش مصنوعی با مشکل روبه‌رو می‌کند. فرض کنید برای یک عامل هوش مصنوعی برنامه‌نویسی، ماهانه ۴۰ دلار به‌ازای هر کاربر دریافت می‌کنید. یک توسعه‌دهنده هفته‌ای چند بار از آن برای تکمیل خودکار چند تابع استفاده می‌کند. توسعه‌دهنده دیگری آن را به‌صورت یک عامل خودمختار به کار می‌گیرد که روزانه ۱۵ درخواست ادغام کد (Pull Request) باز می‌کند، حجم عظیمی از متن را در پنجره زمینه پردازش می‌کند و برای انجام هر وظیفه به سه ابزار مختلف متصل می‌شود. هر دو ۴۰ دلار می‌پردازند؛ اما هزینه پردازش کاربر اول شاید فقط ۲ دلار باشد، درحالی‌که هزینه کاربر دوم به ۱۰۰ دلار یا بیشتر می‌رسد. در نتیجه، برای حفظ مشتری دوم، ماهانه دست‌کم ۶۰ دلار زیان می‌کنید.
این اختلاف، مسئله اصلی قیمت‌گذاری صندلی‌های کاربری عامل‌های هوش مصنوعی با میزان مصرف متغیر است؛ مسئله‌ای که صرفاً فرضی نیست. وقتی یک عامل هوش مصنوعی را مانند حساب کاربری یک نرم‌افزار به‌عنوان خدمت (SaaS) قیمت‌گذاری می‌کنید، چنین نتیجه‌ای دور از انتظار نیست.
قیمت‌گذاری به‌ازای هر کاربر بر فرضی استوار بود که حدود دو دهه اعتبار داشت: میزان استفاده هر کاربر تقریباً یکسان است. کارشناس فروش در Salesforce وارد سامانه می‌شود، چند رکورد را به‌روزرسانی می‌کند و خارج می‌شود. کاربر Slack هم با سرعت معمول انسان پیام می‌فرستد. تفاوت مصرف پرمصرف‌ترین و کم‌مصرف‌ترین کاربران شاید سه برابر باشد و در شرایط نامعمول به پنج برابر برسد. شرکت بر اساس میانگین قیمت تعیین می‌کند و با افزایش تعداد کاربران، قانون اعداد بزرگ به هموار شدن این تفاوت‌ها کمک می‌کند.
اما عامل هوش مصنوعی مانند انسانی نیست که روی دکمه‌ها کلیک می‌کند؛ رفتار آن بیشتر به یک منبع محاسباتی شباهت دارد و میزان مصرف این منبع به پیچیدگی وظیفه وابسته است، نه تعداد کارکنان. برای مثال، عامل هوش مصنوعی پشتیبانی ممکن است هنگام عرضه یک محصول جدید با افزایش ناگهانی تقاضا روبه‌رو شود و ده برابر یک هفته عادی درخواست دریافت کند. یک عامل برنامه‌نویسی نیز ممکن است برای بازآرایی یک ماژول قدیمی، صدها هزار توکن مصرف کند؛ کاری که شاید یک برنامه‌نویس انسانی اساساً از انجام آن صرف‌نظر می‌کرد. تعداد کاربران ثابت می‌ماند، اما هزینه‌ای که پشت هر کاربر قرار دارد تغییر می‌کند.
به همین دلیل است که اینترکام برای عامل هوش مصنوعی Fin خود هزینه را بر اساس تعداد کاربران دریافت نمی‌کند. این شرکت به‌ازای هر مورد حل‌شده هزینه ثابتی می‌گیرد؛ یعنی هر بار که Fin بدون دخالت نیروی انسانی یک گفت‌وگوی مشتری را حل‌وفصل می‌کند، مبلغی دریافت می‌شود. دلیل این تصمیم آن است که حجم درخواست‌های پشتیبانی با رشد شرکت و تغییرات فصلی ارتباط دارد، نه با تعداد کارشناسانی که وارد پنل مدیریتی شده‌اند. شرکتی با پنج کارشناس پشتیبانی ممکن است در جمعه سیاه با جهش چشمگیر تقاضا روبه‌رو شود و به مدلی نیاز داشته باشد که هزینه را متناسب با این افزایش تنظیم کند. تعداد کاربران چنین تغییری را منعکس نمی‌کند.
مدل ترکیبی که در عمل موفق‌تر است
جایگزین قیمت‌گذاری صرفاً مبتنی بر تعداد کاربران، قیمت‌گذاری صرفاً مبتنی بر مصرف هم نیست؛ بلکه مدلی ترکیبی است: هزینه پایه هر کاربر، که دسترسی به سرویس و سهمیه‌ای از مصرف را فراهم می‌کند، به‌علاوه هزینه‌های محاسبه‌شده بر اساس مصرف واقعی پس از پایان سهمیه. طرح‌های سازمانی ChatGPT از OpenAI به همین شکل عمل می‌کنند. سرویس Claude for Work شرکت آنتروپیک نیز دسترسی هر کاربر را با یک سهمیه مصرف همراه می‌کند و برای تیم‌هایی که از این سهمیه فراتر می‌روند، هزینه اضافی جداگانه در نظر می‌گیرد.
منطق این مدل وقتی روشن می‌شود که کارکرد هر بخش را در نظر بگیریم. هزینه پایه هر کاربر همان وظایف همیشگی خود را انجام می‌دهد: برای تیم مالی یک ردیف هزینه قابل پیش‌بینی ایجاد می‌کند، به تیم فروش امکان می‌دهد مبلغی روشن اعلام کند و برای خریدار رقمی آشنا فراهم می‌آورد که در کنار سایر هزینه‌های نرم‌افزاری شرکت قابل بودجه‌بندی باشد. بخش مبتنی بر مصرف نیز محدودیت قیمت‌گذاری ثابت را جبران می‌کند: کاربری که منابع بیشتری مصرف می‌کند، هزینه متناسب با مصرف خود را می‌پردازد و بار مالی او بر دوش دیگر کاربران طرح نمی‌افتد.
اگر سهمیه پایه را اشتباه تعیین کنید، مدل ترکیبی دقیقاً به همان مشکلی دچار می‌شود که قیمت‌گذاری صرفاً بر اساس تعداد کاربران دارد. اگر سهمیه همراه با اشتراک آن‌قدر سخاوتمندانه باشد که پرمصرف‌ترین کاربران هم بدون پرداخت هزینه اضافی از آن استفاده کنند، در واقع همان اشتراک ۴۰ دلاری را با چند مرحله اضافی بازسازی کرده‌اید. سهمیه باید بر اساس توزیع واقعی مصرف کاربران تعیین شود، نه مصرف کاربر متوسط و قطعاً نه مصرف کم‌مصرف‌ترین کاربر. داده‌های خود را بررسی کنید: کاربری که در صدک ۹۰ مصرف قرار دارد، واقعاً در طول یک ماه چقدر مصرف می‌کند؟ بهتر است سهمیه گنجانده‌شده در اشتراک را نزدیک به میانه مصرف تنظیم کنید، نه میانگین؛ زیرا تعداد اندکی از کاربران بسیار پرمصرف، میانگین را به سطحی می‌برند که نماینده رفتار مشتریان معمولی نیست.
چرا تقریباً هیچ‌کس فقط قیمت‌گذاری مبتنی بر مصرف را عرضه نمی‌کند؟
اگر دریافت هزینه بر اساس مصرف، روش دقیق‌تری است، چرا همه هزینه‌ها را بر مبنای مصرف محاسبه نمی‌کنند و هزینه پایه هر کاربر را کنار نمی‌گذارند؟ دلیلش این است که واحدهای تدارکات و خرید سازمانی بیش از هر چیز به پیش‌بینی‌پذیری نیاز دارند. تیم مالی که باید قراردادی شش‌رقمی برای هوش مصنوعی را تأیید کند، به رقمی نیاز دارد که بتواند در بودجه ثبت کند و در فصل بعد در برابر مدیر ارشد مالی از آن دفاع کند. عبارت «هزینه به میزان استفاده تیم شما بستگی دارد» عدد مشخصی نیست؛ بلکه ریسکی است که تیم خرید ممکن است در برابر آن مقاومت کند. بدتر از آن، ممکن است برای کنترل هزینه، مصرف را میان کارکنان سهمیه‌بندی کند و در نتیجه، همان میزان استفاده گسترده‌ای را که شرکت فروشنده می‌خواهد افزایش دهد، محدود سازد.
استدلال اصلی علیه قیمت‌گذاری کاملاً مبتنی بر مصرف همین است: این مدل فقط پیش‌بینی‌ناپذیری هزینه‌ها را به صورت سود و زیان تیم خرید منتقل می‌کند.
این مدل در عمل چگونه باید اجرا شود؟
طراحی درست مدل ترکیبی به چند تصمیم بستگی دارد که هیچ‌کدام را نمی‌توان بدون توجه به شرایط کسب‌وکار به‌طور یکسان برای همه شرکت‌ها اتخاذ کرد.
واحد اندازه‌گیری هزینه را بر اساس عاملی انتخاب کنید که واقعاً هزینه را تعیین می‌کند، نه صرفاً بر اساس معیاری که توضیح آن در یک ارائه فروش آسان‌تر است. تعداد توکن‌ها عامل مستقیم هزینه پردازش است، اما برای خریدار معنای روشنی ندارد. در مقابل، تعداد موارد حل‌شده، وظایف تکمیل‌شده یا اقدامات موفق، ارزش قابل درک‌تری برای مشتری دارند؛ حتی اگر در پشت صحنه، هزینه آن‌ها را بر اساس تعداد توکن‌های مصرف‌شده محاسبه کنید. مدل اینترکام که بر اساس موارد حل‌شده هزینه دریافت می‌کند، از این جهت کارآمد است که مدیر پشتیبانی دقیقاً می‌داند حل شدن یک درخواست برای تیمش چه ارزشی دارد. در مقابل، سنجش حجم پردازش توکن‌ها معمولاً معیار داخلی و آشنایی برای مشتریان نیست.
هزینه مصرف مازاد را طوری تعیین کنید که از سوءاستفاده جلوگیری کند، اما موفقیت مشتری را جریمه نکند. اگر مصرف مشتری به دلیل رشد کسب‌وکارش افزایش یافت، باید این اتفاق را نشانه‌ای برای پیشنهاد طرح کاربری بزرگ‌تر با سهمیه بیشتر بدانید، نه فرصتی برای دریافت هزینه‌های اضافی سنگین تا جایی که مشتری اشتراکش را لغو کند. هزینه مصرف مازاد را شاخصی برای بررسی و تنظیم قیمت‌گذاری در هر ماه در نظر بگیرید، نه جریمه‌ای که یک بار تعیین شود و دیگر به آن توجه نکنید.
دسترسی مدیریتی را از ظرفیت مصرف عامل هوش مصنوعی جدا کنید. بسیاری از ابزارهای عامل هوش مصنوعی به واحدی از سازمان فروخته می‌شوند که در آن سه نفر عامل را پیکربندی و نظارت می‌کنند، اما عملکرد آن بر ۲۰۰ نفر دیگر تأثیر می‌گذارد. در چنین شرایطی، دریافت هزینه به‌ازای هر «کاربر» اشتباه در تعریف مسئله است. دسترسی به پنل مدیریتی می‌تواند هزینه ثابتی داشته باشد؛ اما کار واقعی عامل، یعنی بخشی که برای ۲۰۰ نفر ارزش ایجاد می‌کند، باید بر اساس نتایج و خروجی‌ها قیمت‌گذاری شود، نه اینکه دسترسی به آن را به ایجاد ۲۰۰ حساب کاربری محدود کنید؛ حساب‌هایی که احتمالاً هیچ‌کس از آن‌ها استفاده نخواهد کرد.
پیش از طراحی صفحه قیمت‌گذاری، داشبورد مصرف را بسازید. مشتریانی که از مدل ترکیبی استفاده می‌کنند، هزینه‌های اضافی غیرمنتظره را نمی‌پذیرند و یکی از سریع‌ترین راه‌ها برای از دست دادن یک مشتری سازمانی این است که تیم مالی با صورت‌حسابی روبه‌رو شود که انتظارش را نداشته است. باید امکان مشاهده لحظه‌ای میزان مصرف و فاصله آن تا سقف سهمیه اشتراک را فراهم کنید؛ درست مانند AWS که پیش از صدور صورت‌حساب، برآورد هزینه در حال افزایش را نمایش می‌دهد. همین شفافیت است که اساساً پذیرش قیمت‌گذاری متغیر را برای مشتری امکان‌پذیر می‌کند.
هیچ‌یک از این مسائل با برداشتن یک فرمول آماده از صفحه قیمت‌گذاری شرکتی دیگر حل نمی‌شود. مدل اینترکام که بر اساس موارد حل‌شده هزینه دریافت می‌کند، برای پشتیبانی مناسب است، زیرا حل‌وفصل درخواست‌ها معیاری طبیعی و قابل شمارش برای سنجش ارزش محسوب می‌شود. اما عامل برنامه‌نویسی یا عامل پژوهشی به واحد سنجش مخصوص خود نیاز دارد؛ واحدی که کار انجام‌شده توسط عامل را اندازه بگیرد، نه تعداد دفعاتی که فردی برنامه را باز کرده است. ابتدا این واحد را پیدا کنید؛ ساختار قیمت‌گذاری باید بر مبنای آن شکل بگیرد، نه برعکس.