โมเดล pricing ทุกแบบคือข้ออ้างว่า value มาจากที่ใด Per-seat pricing อ้างว่าคุณค่าคือ access ส่วน per-message หรือ per-token pricing อ้างว่าคุณค่าคือ activity ทั้งสองวัดง่าย และทั้งสองให้รางวัลผิดที่อย่างเงียบ ๆ: seat ที่ล็อกอินแต่ไม่แก้อะไรเลยยังจ่ายเงิน; integration ที่พูดเยอะแต่ไม่เคยปิด case ก็ยังเพิ่มค่าใช้จ่าย
Threada วัดสิ่งที่เล่นเกมยากกว่าและใกล้จุดประสงค์มากกว่า: automated resolution
สิ่งที่มันวัด
Automated resolution คือ WorkItem หรือผลลัพธ์ runtime ที่เสร็จสมบูรณ์โดยไม่มีมนุษย์ takeover หรือคำตอบด้วยมือจาก operator งานเข้ามา ระบบพาไปถึงข้อสรุปที่ปกป้องได้ และไม่มีคนต้องเข้ามาปิดงานให้ นี่คือหน่วยที่เรารายงานใน billing และ usage dashboards และเป็นหน่วยที่ enterprise meter นับ
นิยามนี้ตั้งใจให้เข้มงวด หาก operator ต้อง takeover และตอบด้วยมือ นั่นไม่ใช่ automated resolution แต่เป็น assisted work และไม่ควรถูกนับราวกับแพลตฟอร์มปิดงานได้ meter จะขยับเฉพาะเมื่อแพลตฟอร์มทำงานนั้นจริง
ทำไมผลลัพธ์คือสิ่งที่ควรคิดเงินอย่างซื่อตรง
หน่วย pricing ควรตรงกับนิยามความสำเร็จของลูกค้า สำหรับ governed operations ความสำเร็จไม่ใช่ “คนใช้เครื่องมือ” หรือ “โมเดลสร้างข้อความจำนวนมาก” ความสำเร็จคือ routine work ถูกทำอย่างถูกต้อง และมีเฉพาะข้อยกเว้นจริงเท่านั้นที่ถึงมนุษย์ เหตุผลทั้งหมดที่ผลิตภัณฑ์นี้มีอยู่คือการทำ routine ให้เป็นอัตโนมัติ และ route กรณีที่ยากจริงให้คน
การคิดเงินต่อ automated resolution ทำให้แรงจูงใจของเราอยู่ฝั่งเดียวกับเป้าหมายนั้น:
- เราได้รางวัลเมื่อ work ปิดได้ ไม่ใช่เมื่อแค่ หมุนวน โมเดลที่สร้าง draft สิบชิ้นแต่ไม่มีใครใช้ได้ไม่สร้างรายได้ ส่วน resolution เดียวที่ยืนได้ในการ review คือสิ่งที่มีคุณค่า
- ลูกค้าคำนวณได้อย่างซื่อตรง ค่าใช้จ่ายต่อ item ที่แก้ได้เป็นตัวเลขที่ operations leader เปรียบเทียบกับต้นทุนเต็มของการแก้ item นั้นด้วยมือได้ ไม่มีชั้นแปลความหมายระหว่าง “สิ่งที่เราเก็บเงิน” กับ “สิ่งที่เราตั้งใจประหยัดให้คุณ”
- มันทนต่อ vanity metrics คุณไม่สามารถปั่น meter ด้วยการส่ง message เพิ่มหรือเพิ่ม seats ได้ ตัวเลขขึ้นได้ทางเดียวคือมีงานถูกแก้จริงมากขึ้น
การวัดที่ซื่อตรงต้องนับอย่างซื่อตรง
meter จะซื่อตรงได้เท่ากับวิธีนับเท่านั้น สองคำมั่นทำให้ของเราตรงไปตรงมา
ข้อแรก เรานับผลลัพธ์ ไม่ใช่ความหวังดีเกินจริง Resolution จะถูกบันทึกเมื่อ WorkItem ไปถึง terminal state ที่ completed ผ่านเส้นทาง governance พร้อม receipt ครบถ้วน Proposal ที่ล้มเหลวที่ connector หรือ item ที่ operator ต้องช่วยกู้ ไม่ถูกปัดขึ้นเข้าคอลัมน์ resolved แบบเงียบ ๆ Lifecycle states ชัดเจน และ meter อ่านมันอย่างซื่อตรง
ข้อสอง เราตรงไปตรงมากับช่วงเปลี่ยนผ่าน ภายในเราเคยวัด usage จาก message caps ขณะที่แพลตฟอร์มกำลังเติบโต เราระบุชัดว่า caps เหล่านั้นแมปกับ automated-resolution meter และรายงาน resolutions ใน usage dashboards แทนที่จะซ่อนหน่วยจริงไว้หลัง proxy การเรียกชื่อหน่วยจริงและแสดงให้คุณเห็นเป็นส่วนหนึ่งของท่าที records-and-receipts เดียวกับที่กำกับส่วนอื่นของผลิตภัณฑ์
free tier บอกอะไรเกี่ยวกับโมเดลนี้
Free tier จำกัดที่ 1,000 automated resolutions และ 100 knowledge assets ต่อเดือน โดย daily document caps มาจากขีดจำกัดรายเดือน รูปทรงของ cap นี้เป็นคำประกาศในตัวเอง: free tier ใจกว้างใน resolutions เพราะ resolutions คือสิ่งที่ควรให้คุณพิสูจน์ เราอยากให้คุณค้นพบว่าแพลตฟอร์มปิดงานของคุณได้หรือไม่ มากกว่าค้นพบว่ามันรองรับ seats จำนวนมากได้หรือเปล่า
พ้นจากปริมาณแล้ว แผนต่าง ๆ ควรถูกอ่านเป็น capability bundles เช่นความลึกของ governance, approval และ policy controls, ขอบเขต automation, ชั้น connector และ compliance posture ไม่ใช่แค่ตัวเลขที่ใหญ่ขึ้น meter บอกว่างานถูกทำไปเท่าไร แผนบอกว่าคุณมี control และ reach แค่ไหนระหว่างทำงานนั้น
การวัดผลลัพธ์ยากกว่าการวัด messages มันบังคับให้แพลตฟอร์มนิยาม ติดตาม และยืนอยู่ข้างหลังความหมายของคำว่า “resolved” เราคิดว่าความยากนั้นคือประเด็น meter ที่คุณโต้แย้งได้ถึงระดับ line item คือ meter ที่เคารพผู้ซื้อ และ automated resolution เป็นตัวเลขที่ทีม operations ปกป้องได้จริง