هر مدل قیمتگذاری ادعایی درباره سرچشمه ارزش است. قیمتگذاری بهازای seat میگوید ارزش در access است. قیمتگذاری بهازای پیام یا token میگوید ارزش در activity است. هر دو آسان meter میشوند و هر دو بیسروصدا چیز اشتباه را پاداش میدهند: seatی که login میکند اما چیزی را resolve نمیکند هنوز هزینه دارد؛ integration پرحرفی که هرگز case را نمیبندد هنوز bill را بالا میبرد.
Threada چیزی را meter میکند که بازی دادن آن سختتر و به اصل موضوع نزدیکتر است: حل خودکار.
چه چیزی را میسنجد
حل خودکار یک WorkItem یا outcome runtime است که بدون takeover انسانی یا پاسخ دستی operator کامل شده است. کار وارد شد، سامانه آن را به نتیجهای دفاعپذیر رساند و هیچ انسانی لازم نبود برای تمام کردنش وارد شود. این همان واحدی است که در dashboardهای billing و usage گزارش میکنیم و همان واحدی است که meter enterprise میشمارد.
تعریف عمداً سختگیرانه است. اگر operator مجبور شده takeover کند و دستی reply بدهد، آن حل خودکار نیست؛ کار assisted است و نباید طوری شمرده شود که انگار platform آن را بسته است. meter فقط وقتی tick میزند که platform واقعاً کار را انجام داده باشد.
چرا outcomeها چیز صادقانهای برای charging هستند
واحد قیمتگذاری باید با تعریف موفقیت مشتری همراستا باشد. در operations govern شده، موفقیت این نیست که مردم ابزار را استفاده کردهاند یا مدل متن زیادی generated کرده است. موفقیت این است که کار routine درست انجام شده و فقط exceptionهای واقعی به انسان رسیدهاند. کل دلیل وجود محصول این است که routine را automate کند و caseهای واقعاً دشوار را به انسانها route کند.
charging بهازای حل خودکار incentive ما را در همان سمت هدف قرار میدهد:
- وقتی کار بسته میشود پاداش میگیریم، نه وقتی فقط میچرخد. مدلی که ده draft تولید میکند و هیچکس نمیتواند بر آن act کند چیزی بهدست نمیآورد؛ یک resolution که زیر review دوام میآورد ارزش خود را دارد.
- مشتری میتواند محاسبه صادقانه انجام دهد. cost per resolved item عددی است که یک operations leader میتواند با fully loaded cost حل دستی همان item مقایسه کند. میان اینکه «برای چه هزینه میگیریم» و «قرار است چه چیزی برای شما save کنیم» لایه ترجمهای نیست.
- در برابر vanity metrics مقاوم است. نمیتوانید با ارسال پیام بیشتر یا افزودن seat، meter را inflate کنید. تنها راه بالا رفتن عدد این است که کار بیشتری واقعاً resolved شود.
metering صادقانه یعنی counting صادقانه
meter فقط به اندازه counting خودش صادق است. دو تعهد ما را درست نگه میدارد.
اول، ما outcomeها را میشماریم، نه خوشبینی را. resolution وقتی record میشود که WorkItem از مسیر govern شده به state terminal کامل برسد، با receipt سالم. proposalی که در connector fail شده، یا itemی که operator مجبور شده rescue کند، بیصدا به ستون resolved گرد نمیشود. lifecycle stateها صریحاند و meter آنها را صادقانه میخواند.
دوم، درباره گذار صریح هستیم. internally، usage از لحاظ تاریخی از message capها meter شده، تا زمانی که platform بالغتر شود. ما صریح میگوییم این capها به meter حل خودکار map میشوند و resolutionها را در usage dashboard گزارش میکنیم، نه اینکه unit را پشت proxy پنهان کنیم. نامیدن unit واقعی و نشان دادن آن بخشی از همان posture records-and-receipts است که بقیه product را govern میکند.
free tier درباره مدل چه میگوید
free tier به 1,000 حل خودکار و 100 knowledge asset در ماه محدود است، با سقفهای روزانه document که از حد ماهانه مشتق میشوند. شکل همین cap خودش یک statement است: free tier در resolution سخاوتمند است چون resolution همان چیزی است که ارزش دارد آن را ثابت کنید. ترجیح میدهیم کشف کنید آیا platform کار شما را میبندد، نه اینکه آیا میتواند تعداد زیادی seat را نگه دارد.
فراتر از volume، planها باید بهعنوان capability bundle خوانده شوند: عمق governance، کنترلهای approval و policy، دامنه automation، کلاسهای connector و posture compliance؛ نه فقط عددهای بزرگتر. meter میگوید چقدر کار انجام شده است. plan میگوید هنگام انجام آن چقدر control و reach دارید.
meter کردن outcomeها سختتر از meter کردن messageهاست. platform باید تعریف کند، track کند و پشت معنای resolved بایستد. ما فکر میکنیم همین سختی point است. meterی که میتوانید در سطح line-item دربارهاش بحث کنید، meterی است که به خریدار احترام میگذارد؛ و حل خودکار عددی است که یک operations team واقعاً میتواند از آن دفاع کند.