모든 가격 모델은 가치가 어디서 나오는지에 대한 주장입니다. 좌석별 가격은 가치가 접근권이라고 주장합니다. 메시지별 또는 token별 가격은 가치가 활동이라고 주장합니다. 둘 다 계량하기 쉽지만 둘 다 조용히 잘못된 것을 보상합니다. 로그인하지만 아무것도 해결하지 않는 좌석도 비용을 내고, 사건을 닫지 못하는 수다스러운 integration도 청구서를 키웁니다.
Threada는 조작하기 더 어렵고 핵심에 더 가까운 것을 측정합니다. 바로 자동화된 해결입니다.
무엇을 측정하는가
자동화된 해결은 사람의 takeover나 operator의 수동 reply 없이 완료된 WorkItem 또는 runtime outcome입니다. 작업이 들어왔고, 시스템이 방어 가능한 결론까지 운반했으며, 끝내기 위해 사람이 개입할 필요가 없었습니다. 이것이 billing과 usage dashboard에 보고하는 단위이고, enterprise meter가 세는 단위입니다.
정의는 의도적으로 엄격합니다. operator가 takeover해 손으로 답해야 했다면 그것은 자동화된 해결이 아닙니다. 보조된 작업이며, 플랫폼이 그것을 닫은 것처럼 세어서는 안 됩니다. 미터는 플랫폼이 실제로 일을 했을 때만 움직입니다.
결과가 과금하기에 정직한 이유
가격 단위는 고객의 성공 정의와 맞아야 합니다. 거버넌스 운영에서 성공은 “사람들이 도구를 썼다”거나 “모델이 많은 텍스트를 생성했다”가 아닙니다. 성공은 routine work가 정확히 처리되고, 진짜 예외만 사람에게 도달하는 것입니다. 제품의 존재 이유는 routine을 자동화하고 정말 어려운 사례를 사람에게 라우팅하는 데 있습니다.
자동화된 해결별 과금은 우리의 인센티브를 그 목표와 같은 쪽에 둡니다.
- 우리는 작업이 단지 돌아다닐 때가 아니라 닫힐 때 보상받습니다. 아무도 행동할 수 없는 초안 열 개를 만드는 모델은 아무것도 벌지 못합니다. 검토를 견디는 하나의 해결은 제 몫을 합니다.
- 고객은 정직한 계산을 할 수 있습니다. 해결된 항목당 비용은 operations leader가 그 항목을 손으로 해결하는 fully loaded cost와 비교할 수 있는 숫자입니다. “우리가 과금하는 것”과 “우리가 절감하려는 것” 사이에 번역 계층이 없습니다.
- vanity metric에 강합니다. 메시지를 더 보내거나 좌석을 더해 미터를 부풀릴 수 없습니다. 숫자가 올라가는 유일한 방법은 더 많은 작업이 실제로 해결되는 것입니다.
정직한 계량은 정직한 집계를 뜻한다
미터는 그 집계만큼만 정직합니다. 두 가지 약속이 우리의 집계를 바로 세웁니다.
첫째, 우리는 낙관이 아니라 결과를 셉니다. 해결은 WorkItem이 governed path를 통해 완료 terminal state에 도달하고 receipt가 온전할 때 기록됩니다. connector에서 실패한 proposal이나 operator가 구조해야 했던 item은 resolved column으로 조용히 반올림되지 않습니다. lifecycle state는 명시적이고, 미터는 그것을 정직하게 읽습니다.
둘째, 우리는 전환에 대해 솔직합니다. 내부적으로 사용량은 플랫폼이 성숙하는 동안 message cap에서 계량되어 왔습니다. 우리는 그 cap이 자동화된 해결 미터에 매핑된다는 점을 명시하고, 그 단위를 proxy 뒤에 숨기지 않고 usage dashboard에 resolution으로 보고합니다. 실제 단위의 이름을 붙이고 보여주는 것은 제품 나머지를 지배하는 records-and-receipts 자세의 일부입니다.
무료 tier가 모델에 대해 말하는 것
무료 tier는 월 1,000건의 자동화된 해결과 100개의 knowledge asset으로 제한되며, 월 한도에서 파생된 일일 document cap을 가집니다. 그 cap의 형태 자체가 선언입니다. 무료 tier는 해결에 관대합니다. 해결이야말로 사용자가 검증해 볼 가치가 있는 것이기 때문입니다. 우리는 플랫폼이 많은 좌석을 견딜 수 있는지보다, 당신의 작업을 닫을 수 있는지 발견하길 바랍니다.
볼륨을 넘어 plan은 단순히 더 큰 숫자가 아니라 capability bundle로 읽혀야 합니다. governance depth, approval과 policy control, automation scope, connector class, compliance posture가 plan의 의미입니다. 미터는 얼마나 많은 작업이 완료되었는지 알려 줍니다. plan은 그 작업을 하면서 얼마나 많은 통제와 범위를 갖는지 알려 줍니다.
결과를 계량하는 일은 메시지를 계량하는 것보다 어렵습니다. 플랫폼이 “resolved”의 의미를 정의하고, 추적하고, 책임져야 합니다. 우리는 그 어려움이 핵심이라고 봅니다. line-item 수준에서 따져볼 수 있는 미터는 구매자를 존중하는 미터이고, 자동화된 해결은 operations team이 실제로 방어할 수 있는 숫자입니다.