प्रत्येक pricing model value कुठून येते याबद्दल दावा करते. Per-seat pricing म्हणते value म्हणजे access. Per-message किंवा per-token pricing म्हणते value म्हणजे activity. दोन्ही मोजायला सोपे आहेत, पण दोन्ही चुकीच्या गोष्टीला बक्षीस देतात - login करणारी seat काहीही resolve करत नसली तरी पैसे येतात; आणि case बंद न करणारी chatty integration bill वाढवत राहते.
Threada मोजते अशी गोष्ट जी game करणे कठीण आणि मुद्द्याच्या जवळ आहे: automated resolution.
ते काय मोजते
Automated resolution म्हणजे मानवी takeover किंवा manual operator replies शिवाय पूर्ण झालेला WorkItem किंवा runtime outcome. काम आले, system ने ते defensible conclusion पर्यंत नेले, आणि पूर्ण करायला कोणालाही मध्ये पडावे लागले नाही. Billing आणि usage dashboards मध्ये आम्ही report करणारे unit हेच आहे, आणि enterprise meter हेच मोजते.
व्याख्या मुद्दाम कडक आहे. Operator ला takeover करून हाताने reply करावा लागला तर ते automated resolution नाही - ते assisted work आहे, आणि platform ने ते बंद केले असे मोजू नये. Platform ने प्रत्यक्ष काम केले तेव्हाच meter tick होते.
Outcomes साठी शुल्क घेणे प्रामाणिक का आहे
Pricing unit customer च्या success definition शी जुळले पाहिजे. Governed operations मध्ये success म्हणजे “लोकांनी tool वापरले” किंवा “model ने खूप text generate केला” नाही. Success म्हणजे routine work बरोबर झाले आणि फक्त खरे exceptions माणसापर्यंत पोचले. Product अस्तित्वात असण्याचे कारण routine automate करणे आणि खरोखर कठीण cases लोकांकडे route करणे हेच आहे.
Automated resolution वर charging केल्याने आमचा incentive त्याच goal सोबत राहतो:
- Work फक्त churn होत असताना नाही, तर close होताना आम्हाला reward मिळते. दहा drafts देणारे model काहीच earn करत नाही; review मध्ये टिकणारे एक resolution आपले value कमावते.
- Customer honest math करू शकतो. Cost per resolved item हा operations leader प्रत्यक्ष manual resolution च्या fully loaded cost सोबत compare करू शकतो.
- Vanity metrics ला प्रतिकार होतो. जास्त messages पाठवून किंवा seats वाढवून meter inflate करता येत नाही. Number फक्त अधिक काम खरंच resolved झाले तरच वाढतो.
Honest metering म्हणजे honest counting
Meter त्याच्या counting इतकाच प्रामाणिक असतो. आमचे दोन commitments हे सरळ ठेवतात.
पहिले, आम्ही outcomes मोजतो, optimism नाही. WorkItem governed path ने completed terminal state ला पोचतो तेव्हा resolution record होते - receipt intact असते. Connector वर fail झालेली proposal किंवा operator ने rescue केलेला item resolved column मध्ये शांतपणे rounded up होत नाही.
दुसरे, transition बद्दल आम्ही स्पष्ट आहोत. Platform mature होत असताना usage historically message caps वरून meter झाले. आम्ही स्पष्ट सांगतो की ते caps automated-resolution meter शी map होतात, आणि usage dashboards मध्ये resolutions report करतो. खरे unit नावाने दाखवणे हे product च्या records-and-receipts posture चाच भाग आहे.
Free tier model बद्दल काय सांगते
Free tier दर महिन्याला 1,000 automated resolutions आणि 100 knowledge assets पर्यंत capped आहे; daily document caps monthly limit वरून derived आहेत. त्या cap चा आकारच statement आहे: free tier resolutions मध्ये generous आहे कारण prove करायची गोष्ट resolutions आहे. Platform तुमचे काम बंद करते का हे तुम्ही शोधावे, seats मोठ्या संख्येने धरते का हे नाही.
Volume पलीकडे plans capability bundles म्हणून वाचायचे आहेत - governance depth, approval आणि policy controls, automation scope, connector classes, compliance posture - फक्त मोठे numbers म्हणून नाही. Meter किती काम झाले ते सांगतो. Plan ते करताना तुमच्याकडे किती control आणि reach आहे ते सांगतो.
Outcomes मोजणे messages मोजण्यापेक्षा कठीण आहे. Platform ला “resolved” म्हणजे काय ते define, track, आणि defend करावे लागते. आम्हाला वाटते हीच कठीण गोष्ट मुद्दा आहे. Line-item level वर ज्यावर चर्चा करता येते असा meter buyer चा आदर करतो - आणि automated resolution हा operations team defend करू शकेल असा number आहे.