Every pricing model dey make one claim about where value dey come from. Per-seat pricing talk say value na access. Per-message or per-token pricing talk say value na activity. Both easy to meter, and both dey quietly reward di wrong thing: seat wey login but no resolve anything still dey pay; chatty integration wey never close case still dey increase bill.
Threada dey meter something wey hard to game and closer to di real point: di automated resolution.
Wetin e dey measure
Automated resolution na WorkItem or runtime outcome wey complete without human takeover or manual operator replies. Di work enter, di system carry am reach defensible conclusion, and no person need step in to finish am. Na this unit we dey report for billing and usage dashboards, and na di unit di enterprise meter dey count.
Di definition strict by design. If operator need take over and reply by hand, dat one no be automated resolution. Na assisted work, and e no suppose count like say platform close am. Di meter only tick when di platform actually do di job.
Why outcomes na di honest thing to charge for
Pricing unit suppose line up with how customer dey define success. For governed operations, success no be “people use di tool” or “di model generate plenty text.” Success na routine work finish correctly and only true exceptions reach human. Di whole reason why di product exist na to automate routine work and route genuinely hard cases to people.
Charging per automated resolution put our incentive for di same side as dat goal:
- We dey get rewarded when work closes, no be when e just churns. Model wey produce ten drafts wey nobody fit act on earns nothing; one resolution wey stand under review earns im keep.
- Customer fit do honest math. Cost per resolved item na number operations leader fit compare against di full cost of resolving dat item by hand. No translation layer dey between “wetin we charge for” and “wetin we plan to save you.”
- E resist vanity metrics. You no fit inflate di meter by sending more messages or adding seats. Di only way di number go up na if more work genuinely resolve.
Honest metering mean honest counting
Meter na only as honest as how e dey count. Two commitments keep our own straight.
First, we count outcomes, no be optimism. Resolution dey recorded when di WorkItem reach completed terminal state through di governed path, with im receipt intact. Proposal wey fail for connector, or item wey operator need rescue, no dey quietly rounded up into resolved column. Lifecycle states dey explicit, and di meter read dem honestly.
Second, we dey candid about di transition. Internally, usage historically dey metered from message caps while platform mature. We dey explicit say those caps map onto automated-resolution meter, and we report resolutions inside usage dashboards instead of hiding di unit behind proxy. Naming di real unit, and showing am to you, na part of di same records-and-receipts posture wey govern di rest of di product.
Wetin di free tier talk about di model
Free tier get cap of 1,000 automated resolutions and 100 knowledge assets every month, with daily document caps wey come from di monthly limit. Di shape of dat cap na statement by itself: free tier generous for resolutions because resolutions na di thing worth letting you prove. We prefer make you discover whether di platform dey close your work, no be whether e fit hold plenty seats.
Beyond volume, plans suppose read as capability bundles: governance depth, approval and policy controls, automation scope, connector classes, and compliance posture; no be just bigger numbers. Di meter tell you how much work finish. Di plan tell you how much control and reach you get while e dey happen.
Metering outcomes hard pass metering messages. E require platform to define, track, and stand behind wetin “resolved” mean. We think dat difficulty na di point. Meter wey you fit challenge line by line na meter wey respect buyer, and automated resolution na number operations team fit actually defend.