ஒவ்வொரு pricing model-லும் value எங்கே இருந்து வருகிறது என்ற ஒரு கூற்று இருக்கிறது. Per-seat pricing value access-ல் இருக்கிறது என்கிறது. Per-message அல்லது per-token pricing value activity-ல் இருக்கிறது என்கிறது. இரண்டும் அளவிட எளிது; ஆனால் இரண்டும் தவறான விஷயத்தை reward செய்கின்றன. Login செய்த seat எதையும் resolve செய்யாவிட்டாலும் செலவு உண்டு; case-ஐ close செய்யாத chatty integration bill-ஐ உயர்த்தும்.
Threada அளவிடுவது ஏமாற்றுவதற்கு கடினமானதும், நோக்கத்துக்கு அருகிலானதும்: automated resolution.
அது என்ன அளவிடுகிறது
Automated resolution என்பது human takeover அல்லது manual operator reply இல்லாமல் முடிந்த WorkItem அல்லது runtime outcome. Work வந்தது, system அதை defensible conclusion வரை எடுத்துச் சென்றது, முடிக்க மனிதர் இறங்க வேண்டியிருக்கவில்லை. Billing மற்றும் usage dashboards-ல் நாம் report செய்யும் unit இதுதான்; enterprise meter எண்ணுவதும் இதையே.
Definition திட்டமிட்டு strict ஆக உள்ளது. Operator கையால் take over செய்து reply செய்ய வேண்டியிருந்தால் அது automated resolution அல்ல; அது assisted work. Platform உண்மையில் job-ஐ முடித்தபோது மட்டுமே meter நகரும்.
Outcomes அடிப்படையிலான charge ஏன் நேர்மையானது
Pricing unit customer success definition-க்கு பொருந்த வேண்டும். Governed operations-ல் success என்பது “people used the tool” அல்ல; “model நிறைய text எழுதியது” அல்ல. Routine work சரியாக முடிந்து, உண்மையான exceptions மட்டும் மனிதரிடம் சென்றதுதான் success.
Automated resolution அடிப்படையில் charge செய்தால் incentives அதே இலக்குடன் align ஆகின்றன:
- Work close ஆனபோது மட்டுமே நாம் reward பெறுகிறோம்; அது churn ஆனதற்காக அல்ல.
- Customer honest math செய்ய முடியும். Cost per resolved item-ஐ manual resolution-ன் fully loaded cost-க்கு நேரடியாக compare செய்யலாம்.
- Vanity metrics குறைகின்றன. Messages அல்லது seats அதிகரித்தால் meter inflate ஆகாது; உண்மையில் அதிக work resolve ஆனால்தான் number உயரும்.
Honest metering என்றால் honest counting
Meter எவ்வளவு honest என்பது counting எவ்வளவு honest என்பதில்தான் உள்ளது.
முதல், நாம் outcomes-ஐ count செய்கிறோம், optimism-ஐ அல்ல. WorkItem governed path வழியாக completed terminal state-ஐ, receipt intact-ஆக அடைந்தபோதுதான் resolution record ஆகிறது. Connector-ல் fail ஆன proposal அல்லது operator rescue செய்த item resolved column-ல் ஒளிந்து சேராது.
இரண்டாவது, transition பற்றி வெளிப்படையாக இருக்கிறோம். Platform mature ஆகும்போது usage message caps-இலிருந்து meter செய்யப்பட்ட வரலாறு உண்டு. அந்த caps automated-resolution meter-க்கு map ஆகின்றன என்பதை தெளிவாகச் சொல்கிறோம்; dashboards-ல் resolutions-ஐ report செய்கிறோம். உண்மையான unit-ஐ பெயரிட்டு காட்டுவது product-இன் records-and-receipts posture-இன் பகுதி.
Free tier model பற்றி சொல்வது
Free tier மாதத்திற்கு 1,000 automated resolutions மற்றும் 100 knowledge assets வரை capped. அந்த cap-ன் shape-ஐயே ஒரு statement ஆகப் பார்க்கலாம்: prove செய்ய வேண்டியது resolutions என்பதால் free tier அதில் generous. Platform உங்கள் work-ஐ close செய்கிறதா என்பதைக் கண்டறிவதே முக்கியம்; seats எண்ணிக்கையை வைத்துப் பரிசோதிப்பது அல்ல.
Plans governance depth, approval and policy controls, automation scope, connector classes, compliance posture ஆகிய capability bundles ஆக வாசிக்கப்பட வேண்டும். Meter எவ்வளவு work முடிந்தது என்று சொல்கிறது. Plan அந்த work செய்யும்போது உங்களிடம் எவ்வளவு control மற்றும் reach உள்ளது என்று சொல்கிறது.
Outcomes-ஐ meter செய்வது messages-ஐ meter செய்வதைவிட கடினம். “Resolved” என்பதன் அர்த்தத்தை platform define, track, defend செய்ய வேண்டும். அந்த difficulty-யே point. Line item அளவில் கேள்வி கேட்கக்கூடிய meter buyer-ஐ மதிக்கிறது; automated resolution என்பது operations team defend செய்யக்கூடிய number.