خودکار حل: ایماندار میٹر

ہر pricing model یہ دعویٰ کرتا ہے کہ قدر کہاں سے آتی ہے۔ Per-seat pricing کہتی ہے کہ قدر رسائی ہے۔ Per-message یا per-token pricing کہتی ہے کہ قدر سرگرمی ہے۔ دونوں کو ناپنا آسان ہے، اور دونوں خاموشی سے غلط چیز کو انعام دیتی ہیں: جو سیٹ لاگ اِن ہو مگر کچھ حل نہ کرے وہ بھی ادائیگی کرتی ہے؛ جو chatty integration کبھی کیس بند نہ کرے وہ بھی بل بڑھاتی ہے۔

Threada ایسی چیز ناپتا ہے جسے کھیل بنانا مشکل ہے اور جو اصل مقصد کے زیادہ قریب ہے: خودکار حل۔

یہ کیا ناپتا ہے

خودکار حل ایسا WorkItem یا runtime outcome ہے جو انسان کے سنبھالے یا آپریٹر کے دستی جواب کے بغیر مکمل ہو۔ کام آیا، نظام اسے ایک قابل دفاع نتیجے تک لے گیا، اور کسی شخص کو اسے ختم کرنے کے لیے بیچ میں نہیں آنا پڑا۔ یہی اکائی billing اور usage dashboards میں رپورٹ ہوتی ہے، اور یہی انٹرپرائز میٹر گنتا ہے۔

تعریف جان بوجھ کر سخت ہے۔ اگر آپریٹر کو کام سنبھال کر ہاتھ سے جواب دینا پڑا تو یہ خودکار حل نہیں۔ یہ assisted work ہے، اور اسے ایسے نہیں گننا چاہیے جیسے platform نے کام بند کیا ہو۔ میٹر صرف تب چلتا ہے جب platform واقعی کام کر دے۔

نتائج پر چارج کرنا ایماندار کیوں ہے

قیمت کی اکائی کو customer کی کامیابی کی تعریف سے ملنا چاہیے۔ زیر حکمرانی operations میں کامیابی یہ نہیں کہ “لوگوں نے tool استعمال کیا” یا “model نے بہت سا متن بنایا”۔ کامیابی یہ ہے کہ معمول کا کام درست ہو گیا اور صرف حقیقی exceptions انسان تک پہنچیں۔ product کے وجود کی وجہ یہی ہے: routine کو automate کرنا اور واقعی مشکل cases لوگوں تک route کرنا۔

خودکار حل کے حساب سے چارج کرنا ہماری ترغیب کو اسی مقصد کے ساتھ جوڑتا ہے:

• ہمیں انعام تب ملتا ہے جب کام بند ہو، صرف گھومتا نہ رہے۔ ایسا model جو دس drafts بنائے جن پر کوئی عمل نہ کر سکے کچھ نہیں کماتا؛ ایک resolution جو review میں قائم رہے اپنی قیمت بناتا ہے۔
• customer صاف حساب لگا سکتا ہے۔ Cost per resolved item وہ عدد ہے جسے operations leader ہاتھ سے اسی item کو حل کرنے کی مکمل لاگت کے ساتھ ملا سکتا ہے۔ “ہم کس چیز کا چارج لیتے ہیں” اور “ہم آپ کے لیے کیا بچانا چاہتے ہیں” کے درمیان کوئی translation layer نہیں۔
• یہ vanity metrics کی مزاحمت کرتا ہے۔ زیادہ messages بھیج کر یا seats بڑھا کر میٹر نہیں بڑھایا جا سکتا۔ عدد صرف تب بڑھتا ہے جب زیادہ کام واقعی resolve ہو۔

ایماندار میٹرنگ کا مطلب ایماندار گنتی ہے

میٹر اتنا ہی ایماندار ہے جتنی اس کی گنتی۔ دو commitments ہماری گنتی سیدھی رکھتے ہیں۔

پہلا، ہم outcomes گنتے ہیں، امید نہیں۔ resolution تب record ہوتی ہے جب WorkItem حکمرانی والے path سے مکمل terminal state تک پہنچتا ہے، اپنی receipt کے ساتھ۔ connector پر fail ہونے والی proposal، یا ایسا item جسے operator نے بچایا، resolved column میں خاموشی سے نہیں ڈال دیا جاتا۔ lifecycle states واضح ہیں، اور میٹر انہیں ایمانداری سے پڑھتا ہے۔

دوسرا، ہم transition کے بارے میں صاف ہیں۔ اندرونی طور پر، platform کے mature ہونے کے دوران usage historically message caps سے metered رہا۔ ہم واضح کرتے ہیں کہ وہ caps automated-resolution meter پر map ہوتے ہیں، اور usage dashboards میں resolutions report کرتے ہیں بجائے اس کے کہ اکائی کو proxy کے پیچھے چھپا دیں۔ اصل اکائی کا نام لینا، اور اسے آپ کو دکھانا، اسی records-and-receipts posture کا حصہ ہے جو product کے باقی حصے کو govern کرتا ہے۔

فری ٹئیر model کے بارے میں کیا کہتا ہے

فری ٹئیر ہر ماہ 1,000 خودکار حل اور 100 knowledge assets تک محدود ہے، اور روزانہ document caps اسی monthly limit سے نکلتے ہیں۔ اس cap کی شکل خود ایک statement ہے: فری ٹئیر resolutions میں generous ہے کیونکہ resolutions ہی وہ چیز ہیں جسے آپ کو prove out کرنے دینا چاہیے۔ ہم چاہیں گے کہ آپ یہ جانیں کہ platform آپ کا کام بند کرتا ہے یا نہیں، نہ یہ کہ وہ کتنی seats رکھ سکتا ہے۔

volume کے علاوہ، plans کو capability bundles کے طور پر پڑھنا چاہیے: governance depth، approval اور policy controls، automation scope، connector classes، اور compliance posture؛ صرف بڑے numbers نہیں۔ میٹر بتاتا ہے کتنا کام ہوا۔ plan بتاتا ہے وہ کام کرتے ہوئے آپ کے پاس کتنا control اور reach ہے۔

outcomes کو meter کرنا messages کو meter کرنے سے مشکل ہے۔ اس کے لیے platform کو define، track، اور defend کرنا پڑتا ہے کہ “resolved” کا مطلب کیا ہے۔ ہمارے نزدیک یہی مشکل اصل بات ہے۔ ایسا میٹر جس پر آپ line-item level پر بحث کر سکیں buyer کا احترام کرتا ہے، اور automated resolution وہ عدد ہے جسے operations team واقعی defend کر سکتی ہے۔