# Authentication (/docs/authentication) ## Overview [#overview] Every request to `/v1/*` must include an `Authorization` header with a valid API token: ```bash Authorization: Bearer ``` Requests without a valid token return [`TOKEN_INVALID`](/errors/token-invalid) (401). ## Creating a token [#creating-a-token] 1. Open the [dashboard](https://app.thewitn.com/dashboard/tokens) 2. Click **New token** 3. Copy the token, or come back and view it in the dashboard later. Generating a new token replaces the previous one. The old token stops working right away. ## Using your token [#using-your-token] Pass the token in the `Authorization` header on every request: ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer " ``` Never include your API token in client-side code or commit it to source control. Store it in an environment variable or a secrets manager. ## Example: environment variable [#example-environment-variable] ```bash # .env WITN_API_KEY=your_token_here ``` ```typescript const res = await fetch('https://api.thewitn.com/v1/events', { method: 'POST', headers: { Authorization: `Bearer ${process.env.WITN_API_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ outcome_key: 'support:ticket:1001', action: 'signed', }), }) ``` ## Token security model [#token-security-model] | Property | Detail | | --------- | ----------------------------------------------------------------------------------------- | | Format | Tokens are HMAC-signed and verified on every request without a database lookup. | | Retrieval | Your token stays viewable in the dashboard, so you can copy it again at any time. | | Scope | Tokens are scoped to your account. They can access all resources owned by your user. | | Rotation | Generate a new token to replace the old one. The previous token stops working right away. | ## Error responses [#error-responses] | Situation | Code | Status | | ------------------------------------ | --------------- | ------ | | `Authorization` header missing | `TOKEN_INVALID` | 401 | | Wrong scheme (not `Bearer`) | `TOKEN_INVALID` | 401 | | Token signature invalid or malformed | `TOKEN_INVALID` | 401 | See [`TOKEN_INVALID`](/errors/token-invalid) for the full error reference. # Introduction (/docs/introduction) ## What problem does this solve? [#what-problem-does-this-solve] Most software buyers pay for proxies. Seats. API calls. Usage. None of these are what the buyer actually wants. They are approximations of value that the industry settled on because measuring the real thing was too hard. witn is infrastructure for outcome-based billing. Instead of billing on seats or usage, you define exactly what a successful outcome looks like, send signals from your system as things happen, and the outcome is confirmed or rejected automatically. ## Why existing tools do not work [#why-existing-tools-do-not-work] Outcomes are not final when first observed. A resolved support ticket can be reopened. A signed document can be voided. A completed task may not pass review. Existing monetization platforms assume signals are final at the moment they are recorded. Outcome-based monetization breaks that assumption. Supporting it requires a system that evaluates state over time, handles reversals, waits for settlement, and resolves conflicting signals. That is a fundamentally different model from recording signals. ## Primitives [#primitives] The API introduces six primitives: * **Outcomes.** A potential outcome that moves through states (open, pending, confirmed, failed). * **Signals.** Events from your agent, your customer, or external systems that indicate progress toward an outcome. * **Billable conditions.** The boolean logic that determines when an outcome becomes billable. * **Settlement period.** How long witn waits after the latest event before finalizing the current result. Default 72 hours, maximum 180 days. * **Rate cards.** A reusable pricing template mapping tasks to per-unit prices. Assign one rate card to a customer to control what they pay per confirmed outcome. ## Outcome states [#outcome-states] | State | Meaning | | ----------- | --------------------------------------------------------------------------------- | | `OPEN` | Accepting signals. The billable condition is evaluated on every event. | | `CONFIRMED` | The condition locked true. Terminal. | | `FAILED` | The condition became impossible, or the settlement window closed unmet. Terminal. | ## API base URL [#api-base-url] ``` https://api.thewitn.com ``` All endpoints are versioned under `/v1`. # Quickstart (/docs/quickstart) ## Prerequisites [#prerequisites] * An API token ([get one here](https://app.thewitn.com/dashboard/tokens)) * A task (`task_key`) created in the dashboard * A customer (`customer_key`) created in the dashboard with a rate card that includes the task Set your token as an environment variable so the examples below work as-is: ```bash export WITN_API_KEY=your_token_here ``` ## The scenario [#the-scenario] A customer support outcome: a ticket is billable after the agent replies, as long as the ticket is not escalated, reopened, or followed by a low CSAT score. If the customer abandons the conversation after the agent reply, no bad signal has arrived, so the outcome can confirm after the settlement period. ## Step 1. Open the outcome [#step-1-open-the-outcome] Create the outcome. This binds it to a task (which contract to snapshot) and a customer (who to bill). ```bash curl -X POST https://api.thewitn.com/v1/outcomes \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "key": "support:ticket:1001", "task_key": "support", "customer_key": "acme" }' ``` Returns `202 Accepted`. `key` is your own identifier for this outcome. It must be globally unique and 8 to 255 characters. A repeated create for the same key is ignored. ## Step 2. Send signals [#step-2-send-signals] Send events against the outcome by `outcome_key`. Events for an outcome that does not exist are discarded, so open it first. ```bash # Agent replies: the condition becomes provisionally satisfied curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "agent_replied" }' # Optional bad signal: same outcome, can flip it to FAILED curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "reopened" }' ``` Both calls return `202 Accepted`. Events are processed asynchronously. After `agent_replied`, the outcome stays `OPEN` with its condition provisionally satisfied. If a later `reopened`, `escalated`, or low `csat` event arrives before settlement, it moves to `FAILED`; otherwise it moves to `CONFIRMED` when the settlement timer expires. # Conditions (/docs/concepts/billable-conditions) ## Overview [#overview] Every task has a `condition` in its contract. You write it as text, in a small language built for outcomes. When an outcome opens, it snapshots the condition. Each event for that outcome applies to the condition and witn re-evaluates it. A condition has one of three verdicts at any moment: true, false or unknown. An `OPEN` outcome becomes `CONFIRMED` the moment the condition locks true. It becomes `FAILED` the moment the condition becomes impossible, or when a time window closes without success. ## Facts [#facts] The building block is a fact. A fact is the `action` of an event you submit. Written on its own, a fact is true once that event has been seen at least once. ``` ticket_resolved ``` Fact names can contain letters, numbers, underscores and dots. ``` payment.captured ``` ## Boolean logic [#boolean-logic] Combine facts with `AND`, `OR` and `NOT`. Use parentheses to group. Keywords are case insensitive. ``` signed_by_buyer AND signed_by_seller ``` ``` ticket_resolved AND NOT reopened ``` `NOT` binds tighter than `AND`. `AND` binds tighter than `OR`. Parentheses override this. ``` paid AND (shipped OR picked_up) ``` ## Counting [#counting] `COUNT(fact)` counts every occurrence of an event, then compares it to a number. Use `>=`, `>`, `<=`, `<` or `==`. ``` COUNT(agent_reply) >= 2 ``` ## Comparisons [#comparisons] A comparison reads the latest `properties.value` for a fact and compares it to your value. Send the value on the event. ``` csat >= 4 ``` ```json { "outcome_key": "...", "action": "csat", "properties": { "value": 4.8 } } ``` | Operator | Meaning | Value type | | -------- | ------------ | ---------------- | | `==` | equals | string or number | | `>=` | at least | number | | `>` | greater than | number | | `<=` | at most | number | | `<` | less than | number | `==` works for text or numbers. The ordering operators need a number. A comparison is false when no value has been seen yet. ``` plan == "pro" ``` ## Sets [#sets] `IN` checks the latest value against a list. It is a shorthand for several `==` branches joined by `OR`. ``` call_outcome IN ["Resolved by Agent", "Partially Resolved by Agent", "Store Visit"] ``` The list holds quoted strings or numbers. ``` call_duration IN [15000, 30000] ``` ## Time windows [#time-windows] Two operators reason about time. Both take a window written as `(start, end]` in durations and a body that holds facts. `G(start, end](body)` is true when the body holds for the whole window. One violation fails it. Use it for "nothing bad happened". ``` G(0,24h](NOT customer_message AND NOT human_escalation) ``` `F(start, end](body)` is true when the body holds at some point in the window. Use it for "this eventually happened". ``` F(0,1h](goal_reached) ``` Windows are measured from the moment the outcome opens. A window cannot contain another window. Durations use `s`, `m`, `h` and `d`. A bare number is seconds. | Text | Meaning | | ----- | ---------- | | `30s` | 30 seconds | | `5m` | 5 minutes | | `24h` | 24 hours | | `7d` | 7 days | ## Settlement windows [#settlement-windows] `I` waits for a quiet gap, then settles the outcome. It is true once the window passes with no reset event. Each reset event pushes the deadline forward, so the outcome settles a fixed time after the last one. This is how you say "judge the outcome once things go quiet". Three forms control which events reset the clock. | Form | Resets on | | -------------------------------------- | -------------------- | | `I(5m]` | any event | | `I(5m] agent_turn` | one event | | `I(5m] [agent_turn, customer_message]` | any event in the set | Unlike `G`, a reset event does not fail an `I` window. It restarts the clock. The longest an `I` window can wait is 180 days. ## Examples [#examples] ### A single event [#a-single-event] ``` downloaded ``` ### Both parties sign, nobody revokes [#both-parties-sign-nobody-revokes] ``` signed_by_buyer AND signed_by_seller AND NOT revoked ``` ### A minimum score [#a-minimum-score] ``` csat >= 4 ``` ### Resolved and quiet for 24 hours [#resolved-and-quiet-for-24-hours] ``` ticket_resolved AND NOT reopened AND G(0,24h](NOT customer_message AND NOT human_escalation) ``` ### A resolved call, settled 5 minutes after the last turn [#a-resolved-call-settled-5-minutes-after-the-last-turn] ``` call_outcome IN ["Resolved by Agent", "Partially Resolved by Agent", "Store Visit"] AND call_duration >= 15000 AND COUNT(agent_turn) >= 2 AND I(5m] agent_turn ``` ## How evaluation works [#how-evaluation-works] On every `POST /v1/events`, witn validates the request, then queues the event. In the background it applies the event to the outcome and re-evaluates the condition. 1. The condition is checked against everything seen so far. 2. For comparisons and sets, only the latest value for each fact is used. For counts, every occurrence is counted. 3. If the condition locks true and the outcome is `OPEN`, it becomes `CONFIRMED`. 4. If the condition can never become true again, the outcome becomes `FAILED` right away. This happens when a `NOT` fact arrives or a count ceiling is passed. A comparison never causes this on its own, because a later event can change the value. 5. `G`, `F` and `I` windows set a deadline. When the deadline passes, witn evaluates the condition one last time. True confirms the outcome, anything else fails it. A condition with no window and no lock stays `OPEN`. Add a window or an `I` clause when you want the outcome to settle on its own. ## Validation [#validation] The condition is checked when a task contract is created or updated. Invalid text returns a `VALIDATION_ERROR` with the position of the problem. ``` // missing a value csat >= // valid csat >= 4 ``` # Outcome lifecycle (/docs/concepts/outcome-lifecycle) ## States [#states] An outcome is always in one of three states: | State | Description | | ----------- | ----------------------------------------------------------------------------------- | | `OPEN` | Accepting events. The success condition has not locked yet. | | `CONFIRMED` | The success condition locked true. Terminal state. | | `FAILED` | The condition became impossible or a window closed without success. Terminal state. | ## Transitions [#transitions]
All transitions happen in one of three ways: 1. **Create and events.** You open the outcome with `POST /v1/outcomes`, which snapshots the task contract. Then each `POST /v1/events` for that `outcome_key` is appended to the event log and the condition is re-evaluated. An outcome confirms as soon as its condition locks true. For a simple condition, that is the moment the event arrives. 2. **Settlement.** A scheduled job runs every minute and resolves outcomes whose deadline has passed. The condition is evaluated at the deadline: `OPEN` becomes `CONFIRMED` if the condition is true, otherwise `FAILED`. This is how time windows settle, for example "resolved and quiet for 24 hours". 3. **Early fail.** Some events make a condition impossible. A condition with `NOT escalated` can never be true again after an `escalated` event arrives. When that happens the outcome moves to `FAILED` right away instead of waiting for the deadline. ## When an outcome settles [#when-an-outcome-settles] A deadline comes from the condition itself. The `G`, `F` and `I` operators each set one. * `G` and `F` windows run from the moment the outcome opens. `G(0,24h](...)` sets a deadline 24 hours out. * `I` slides its deadline forward on every reset event, so the outcome settles a fixed time after the last one. `I(5m] agent_turn` settles 5 minutes after the final `agent_turn`. A condition with no window and no `I` never settles on its own. It stays `OPEN` until it locks true or becomes impossible. Add a window or an `I` clause when you want a deadline. The longest any window can run is 180 days. See [Conditions](/docs/concepts/billable-conditions) for the full language. ## Event submission rules [#event-submission-rules] * Only `OPEN` outcomes accept events. * Events for `CONFIRMED` or `FAILED` outcomes return `202` and are discarded. The outcome is not reopened. * For comparisons, the latest `properties.value` for each `action` is used. * The condition is re-evaluated on every accepted event. # Rate cards (/docs/concepts/rate-cards) ## What is a rate card? [#what-is-a-rate-card] A rate card is a named collection of task–price mappings. Each entry pairs a task with a `price_per_unit` — the amount billed when an outcome for that task resolves `CONFIRMED`. Rate cards are **shared across customers**. You define them once and assign the same card to many customers. A single customer is assigned at most one rate card at a time. ## Key [#key] Every rate card has a `key` — a lowercase slug that uniquely identifies it within your account: ``` standard enterprise-2024 agency_tier ``` Keys must start with a letter or digit and may contain lowercase letters, digits, hyphens (`-`), and underscores (`_`). The key is unique per account, not globally — two different accounts may each have a rate card keyed `standard`. ## Entries [#entries] A rate card contains zero or more entries. Each entry maps one task to a price: ```json { "id": "...", "key": "standard", "entries": [ { "task_id": "...", "price_per_unit": 10.00, "rate_type": "flat" }, { "task_id": "...", "price_per_unit": 12.00, "rate_type": "flat" } ] } ``` Each task may appear at most once per rate card. Only `flat` billing (fixed price per confirmed outcome) is supported today. ## Assigning to a customer [#assigning-to-a-customer] A rate card is assigned to a customer at the customer level. When an outcome for that customer resolves `CONFIRMED`, the price recorded on the outcome is read from the customer's rate card entry for that task at the time the outcome was created. **Changing a rate card after outcomes exist does not retroactively change the price of past outcomes.** Each outcome snapshots its `price_per_unit` at creation time. ## Archiving [#archiving] Deleting a rate card soft-deletes (archives) it. Archived rate cards are excluded from the default list response but remain accessible by id. Customers assigned to an archived rate card retain the assignment and historical outcomes are unaffected. ## Updating entries [#updating-entries] Rate cards and their entries are managed from the dashboard. Edits replace the full entry set on save. # Error codes (/docs/errors) ## Response envelope [#response-envelope] All errors return the same top-level shape. ```json { "error": { "type": "invalid_request_error", "code": "VALIDATION_ERROR", "message": "key is required", "status": 400, "doc_url": "https://docs.thewitn.com/docs/errors/validation-error" } } ``` Validation errors add a `details` array with the exact fields that failed. Server errors add a `request_id` you can share with support. ## Error types [#error-types] | Type | When | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `invalid_request_error` | The request was malformed or rejected. Fix the request before retrying. | | `authentication_error` | The `Authorization` header is missing, malformed, or the token is not recognised. | | `api_error` | An unexpected server-side failure. Retry with exponential back-off. If it persists, contact support with the `request_id`. | ## Error codes [#error-codes] | Code | Status | Type | Description | | ------------------------------------------------ | ------ | ----------------------- | -------------------------------------------- | | [`VALIDATION_ERROR`](/errors/validation-error) | 400 | `invalid_request_error` | Body or params failed schema validation. | | [`TOKEN_INVALID`](/errors/token-invalid) | 401 | `authentication_error` | Token missing, malformed, or not recognised. | | [`PAYLOAD_TOO_LARGE`](/errors/payload-too-large) | 413 | `invalid_request_error` | Event body exceeded the 256 KiB limit. | | [`INTERNAL_ERROR`](/errors/internal-error) | 500 | `api_error` | Unexpected server error. | # INTERNAL_ERROR (/docs/errors/internal-error) `api_error` `500` ## What happened [#what-happened] Something went wrong on the server that was not caused by your request. This is not a problem with your integration. It is a problem on our side. ```json { "error": { "type": "api_error", "code": "INTERNAL_ERROR", "message": "Unexpected error", "status": 500, "doc_url": "https://docs.thewitn.com/docs/errors/internal-error", "request_id": "550e8400-e29b-41d4-a716-446655440000" } } ``` ## The `request_id` field [#the-request_id-field] Every `INTERNAL_ERROR` response includes a `request_id` UUID. This ID is logged on our servers alongside the full error. If you contact support, include the `request_id` so we can find the exact failure in our logs. ## How to handle [#how-to-handle] Implement exponential back-off with jitter. A reasonable starting point: ```typescript async function withRetry(fn: () => Promise, maxAttempts = 4): Promise { for (let attempt = 1; attempt <= maxAttempts; attempt++) { try { return await fn() } catch (err) { if (attempt === maxAttempts) throw err const delay = Math.min(100 * 2 ** attempt + Math.random() * 100, 5000) await new Promise((resolve) => setTimeout(resolve, delay)) } } throw new Error('unreachable') } ``` If `INTERNAL_ERROR` persists after several retries, stop retrying and surface the error to the user. Continuing to hammer a failing endpoint will not help and may make things worse. ## Contacting support [#contacting-support] If the error persists, reach out with: 1. The `request_id` from the response 2. The endpoint and request body (redact any sensitive values) 3. The approximate time the error occurred # PAYLOAD_TOO_LARGE (/docs/errors/payload-too-large) `invalid_request_error` `413` ## What happened [#what-happened] `POST /v1/events` accepts a JSON body up to 256 KiB. The request you sent was larger, so it was rejected before it reached the queue. This is checked two ways: against the `Content-Length` header, and against the actual size of the parsed body. Events are placed whole onto a queue with a 1 MiB hard cap. The 256 KiB limit keeps every event well under that cap. ```json { "error": { "type": "invalid_request_error", "code": "PAYLOAD_TOO_LARGE", "message": "Event payload must be 262144 bytes or smaller", "status": 413, "doc_url": "https://docs.thewitn.com/docs/errors/payload-too-large" } } ``` ## How to fix [#how-to-fix] Send less data per event. Most oversized bodies come from large blobs inside `properties`. * Keep `properties` to the fields the evaluator and billing need: `value` and `settles_at`. * Move large metadata (full documents, transcripts, images) to your own storage and send only a reference, such as a URL or an id. * Split one large event into several smaller events if each part stands on its own. ## Limit [#limit] The default limit is 256 KiB. Self-hosted deployments can change it with the `EVENT_INGEST_MAX_BODY_BYTES` environment variable, but it must stay below the 1 MiB queue cap. # TOKEN_INVALID (/docs/errors/token-invalid) `authentication_error` `401` ## What happened [#what-happened] The API could not authenticate your request. This happens when the `Authorization` header is absent, does not use the `Bearer` scheme, or the token does not match any active token in the system. ```json { "error": { "type": "authentication_error", "code": "TOKEN_INVALID", "message": "Missing token", "status": 401, "doc_url": "https://docs.thewitn.com/docs/errors/token-invalid" } } ``` ## How to fix [#how-to-fix] Include a valid API token in every request using the `Bearer` scheme: ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer " ``` Your token stays viewable in the [dashboard](https://app.thewitn.com/dashboard/tokens), so you can copy it again at any time. Generating a new token replaces the old one. ## Common causes [#common-causes] Every request to `/v1/*` requires an `Authorization` header. Requests without one return `TOKEN_INVALID`. The API only accepts the `Bearer` scheme. Other schemes (e.g. `Basic`, `Token`) are rejected. ``` // ❌ invalid Authorization: Token abc123 // ✅ valid Authorization: Bearer abc123 ``` Generating a new token from the dashboard replaces the previous one. Requests using the old token return `TOKEN_INVALID`. Update your integration with the new token. Tokens are HMAC-signed. A truncated or modified token fails signature verification and returns `TOKEN_INVALID`. Copy the full token exactly as shown in the dashboard. # VALIDATION_ERROR (/docs/errors/validation-error) `invalid_request_error` `400` ## What happened [#what-happened] One or more fields in your request did not pass validation. The `details` array tells you exactly which fields failed and why. Fix them and retry. ```json { "error": { "type": "invalid_request_error", "code": "VALIDATION_ERROR", "message": "Invalid request", "status": 400, "doc_url": "https://docs.thewitn.com/docs/errors/validation-error", "details": [ { "path": "contract.price", "message": "Number must be greater than 0" } ] } } ``` ## The `details` array [#the-details-array] Each entry in `details` identifies one failing field: | Field | Type | Description | | --------- | ------ | ----------------------------------------------------------------------------------------------------------------- | | `path` | string | Dot-notation path to the field, e.g. `contract.price`. Array indices use bracket notation: `conditions[0].event`. | | `message` | string | Human-readable reason the field failed validation. | ## Common causes [#common-causes] `contract.price` must be a positive number greater than 0. ```json // ❌ invalid { "contract": { "price": 0 } } // ✅ valid { "contract": { "price": 50 } } ``` The condition must be a flat list of leaves. Each leaf is `{ "fact": "", "operator": "", "value": }`. Leaves are combined with implicit AND. Use `not seen` or one of the `not *` operators to require absence. ```json // invalid { "condition": { "type": "signed" } } // valid: one leaf { "condition": [{ "fact": "signed", "operator": "seen" }] } // valid: two leaves (AND) { "condition": [ { "fact": "signed_by_A", "operator": "seen" }, { "fact": "signed_by_B", "operator": "seen" } ] } ``` Event submissions require `outcome_key` and `action`. ``` // ❌ invalid POST /v1/events { "action": "signed" } // ✅ valid POST /v1/events { "outcome_key": "support:ticket:1001", "action": "signed" } ``` # Writing a condition (/docs/guides/billable-conditions) ## Overview [#overview] Every task has a `condition` in its contract. After each event, witn evaluates the condition against everything submitted for that outcome so far. When the condition locks true the outcome confirms. When it becomes impossible or a window closes without success, the outcome fails. You write the condition as text. This guide covers the common shapes. See [Conditions](/docs/concepts/billable-conditions) for the full reference. ## Facts [#facts] A fact is the `action` of an event. On its own it is true once that event has been seen. ``` ticket_resolved ``` ## Combine with AND, OR, NOT [#combine-with-and-or-not] ``` signed_by_buyer AND signed_by_seller ``` ``` ticket_resolved AND NOT reopened ``` Use parentheses to group. `NOT` binds tighter than `AND`. `AND` binds tighter than `OR`. ``` paid AND (shipped OR picked_up) ``` ## Count events [#count-events] `COUNT(fact)` counts every occurrence. ``` COUNT(agent_reply) >= 2 ``` ## Compare a value [#compare-a-value] A bare comparison reads the latest `properties.value` for a fact. `csat >= 4` is shorthand for `csat:value >= 4`. ``` csat >= 4 ``` Submit the value on the event. ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "...", "action": "csat", "properties": { "value": 4.8 } }' ``` ## Compare any property [#compare-any-property] Name a property after a colon to read something other than `value`. The part before the colon is the action, the part after is the property path. ``` booked_appointment:result == 5 ``` Reach into nested objects with dots in the path. ``` booked_appointment:meta.score >= 0.9 ``` Action names may contain dots, so a namespaced name still works. The colon marks where the path begins. ``` payment.captured:value == 5 ``` Submit the property on the event. ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "...", "action": "booked_appointment", "properties": { "result": 5 } }' ``` Use `==` to match text. ``` plan == "pro" ``` Match one of several values with `IN`. ``` call_outcome IN ["Resolved by Agent", "Store Visit"] ``` ## Wait for quiet [#wait-for-quiet] `G(0,24h](...)` is true when its body holds for the whole window. One violation fails it. ``` ticket_resolved AND NOT reopened AND G(0,24h](NOT customer_message AND NOT human_escalation) ``` `I` settles the outcome after a quiet gap. Each reset event pushes the deadline forward. ``` COUNT(agent_turn) >= 2 AND I(5m] agent_turn ``` The line above settles 5 minutes after the last `agent_turn`. ## Examples [#examples] ### A single event [#a-single-event] ``` downloaded ``` ### Both parties sign, nobody revokes [#both-parties-sign-nobody-revokes] ``` signed AND NOT revoked ``` ### A minimum score [#a-minimum-score] ``` csat >= 4 ``` ### Multi-step verification [#multi-step-verification] ``` identity_check == "verified" AND credit_score >= 700 AND document_signed ``` ## Validation [#validation] The condition is checked when the task is created or updated. Invalid text returns `VALIDATION_ERROR` with the position of the problem. # Create a customer (/docs/guides/create-a-customer) Customers are managed in the dashboard at [app.thewitn.com/dashboard/customers](https://app.thewitn.com/dashboard/customers). ## What is a customer? [#what-is-a-customer] A customer is a company or person you bill. Outcomes are always tied to a customer. You cannot create an outcome without specifying which customer it belongs to. ## The customer key [#the-customer-key] Every customer has a key. This is a string you choose. It must be unique within your account. You use the customer key when opening an outcome: the `customer_key` field on `POST /v1/outcomes`. Choose a key that matches your own system. A slug, a short string, or your internal customer ID all work. ``` acme stripe-cus-abc123 customer-42 ``` The customer key cannot be changed after the customer is created. Choose it carefully. ## Assigning a rate card [#assigning-a-rate-card] A customer can have one rate card assigned at a time. The rate card controls what price is used when an outcome confirms. When you open an outcome, witn looks up the customer's rate card and reads the price for that task. If the customer has no rate card, or the rate card has no entry for that task, the invoice line is left unpriced until you backfill the rate. You can change the rate card assignment at any time. Changing it does not affect outcomes that are already open. Each open outcome already recorded its price when it was created. ## Creating a customer [#creating-a-customer] Go to **Customers** in the dashboard and click **New customer**. Enter a name and a key. After creating the customer, assign a rate card from the customer detail page. Customers list with rate card badges and a customer detail panel showing key, email, address, and rate card # Create a task (/docs/guides/create-a-task) Tasks are created and managed in the dashboard at [app.thewitn.com/dashboard/tasks](https://app.thewitn.com/dashboard/tasks). ## What is a task? [#what-is-a-task] A task is a named template. It defines two things: * The **billable condition**: the boolean rule that must be satisfied for the outcome to confirm. * The **settlement window**: how long witn waits after the latest event before making the current result final. ## The snapshot model [#the-snapshot-model] When you open an outcome, witn copies the task's contract onto the outcome. After that, the outcome is independent. Changing the task does not affect open outcomes. This means you can update a task at any time without changing the behavior of existing outcomes. Each outcome uses the contract that was in effect when it was opened. If you need a different contract for new outcomes, update the task before opening them. ## Contract fields [#contract-fields] | Field | Type | Description | | ------------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `settlement_period` | integer (seconds) | How long witn waits after the latest event before the outcome resolves. Default: 259,200 (72 hours). Min 1, max 15,552,000 (180 days). | | `condition` | object | The billable condition. See [Billable conditions](/docs/guides/billable-conditions). | When the settlement window expires, if the condition was met the outcome confirms; if not, it is missed. ## Prices live on rate cards [#prices-live-on-rate-cards] Tasks do not have a price. The price is set on the rate card entry for that task. This means you can charge different customers different prices for the same task. To set a price, create or update a rate card and add an entry for the task. ## Creating a task [#creating-a-task] Go to **Tasks** in the dashboard and click **New task**. Enter a name and configure the contract fields. The condition builder lets you construct AND, OR, and NOT trees visually. # How witn works (/docs/guides/how-witn-works) This page explains the concepts. To start sending API calls right away, see the [Quickstart](/docs/quickstart). ## The problem with proxy billing [#the-problem-with-proxy-billing] Most billing systems charge for proxies: seats, API calls, storage. These are easy to measure but not what buyers want. A buyer wants the result, not the activity. witn lets you define exactly what a successful outcome looks like. You send events as things happen. witn evaluates the condition after each event and resolves the outcome automatically. ## The six building blocks [#the-six-building-blocks] | Block | What it is | | ---------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Customer** | A company or person you bill. Each customer has a key you choose. | | **Task** | A contract template. Defines the billable condition, the settlement window, and how billing units are counted. | | **Outcome** | A live instance of a task for one customer. Tracks whether the condition was met and resolves to confirmed or missed. | | **Event** | A signal from your system. The condition is evaluated after each event. | | **Billable condition** | The boolean rule that decides when an outcome confirms. | | **Rate card** | A pricing table. Maps tasks to prices for a customer. | ## How they connect [#how-they-connect] The typical flow: 1. Create a **customer** and a **task** in the dashboard. 2. Assign a **rate card** to the customer. 3. Open an **outcome** when something billable begins: a ticket opens, a document is sent, a job is posted. 4. Send **events** against that outcome as things happen. 5. witn evaluates the **billable condition** after each event. 6. Each event resets the settlement timer. When the condition is met and the timer expires, the outcome confirms. When the timer expires without the condition being met, the outcome is missed. 7. You receive a **notification** when the outcome confirms or is missed. ## What the settlement window means [#what-the-settlement-window-means] Every event resets a timer equal to the task's settlement period (default: 72 hours). When the timer expires: * Condition met → outcome **confirms**. You receive a notification and an invoice line is created. * Condition not met → outcome is **missed**. You receive a notification. If you send another event before the timer expires, the timer resets. An outcome cannot confirm or be missed while events are still arriving. # Notifications (/docs/guides/notifications) Notifications send a `POST` request to a URL you control each time an outcome confirms or is missed. You set up a rule in the dashboard, pick which task to watch, and witn delivers a signed payload. ## Setting up a rule [#setting-up-a-rule] Notification rule configuration 1. Open **Notifications** in the sidebar. 2. Click **New rule**. 3. Choose a source: **Outcome confirmed** or **Outcome missed**. 4. Select the task to watch. 5. Enter your endpoint URL. 6. Copy the signing secret and store it as an environment variable. 7. Enable the rule. Use **Send test** on the rule page to confirm your endpoint receives and verifies the payload correctly. ## Webhook payload [#webhook-payload] ```json { "id": "a3f1c2b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2", "type": "outcome_succeed", "createdAt": "2026-07-01T14:00:00.000Z", "data": { "rule": { "id": "550e8400-e29b-41d4-a716-446655440000", "name": "Support task success" }, "subjectKey": "support:ticket:1001", "facts": { "outcomeKey": "support:ticket:1001", "customerKey": "acme", "taskKey": "support", "taskName": "Support" } } } ``` | Field | Description | | ------------------------ | --------------------------------------------------------------- | | `id` | Unique event ID. Stable across retries. Deduplicate on it. | | `type` | `outcome_succeed` when confirmed, `outcome_failed` when missed. | | `data.subjectKey` | The outcome key you sent when opening the outcome. | | `data.facts.outcomeKey` | Same as `subjectKey`. | | `data.facts.customerKey` | The customer key on the outcome. | | `data.facts.taskKey` | The task key on the outcome. | ## Verifying signatures [#verifying-signatures] Every delivery is signed. Verify the signature before processing the payload. ```typescript import crypto from "node:crypto"; function verifyWebhook(req: Request, body: string, secret: string): unknown { const msgId = req.headers.get("svix-id")!; const timestamp = req.headers.get("svix-timestamp")!; const signatures = req.headers.get("svix-signature")!; const ts = parseInt(timestamp, 10); if (Math.abs(Date.now() / 1000 - ts) > 300) { throw new Error("Timestamp too old"); } const secretBytes = Buffer.from(secret.replace(/^whsec_/, ""), "base64"); const computed = crypto .createHmac("sha256", secretBytes) .update(`${msgId}.${timestamp}.${body}`) .digest("base64"); const valid = signatures.split(" ").some((s) => s === `v1,${computed}`); if (!valid) throw new Error("Invalid signature"); return JSON.parse(body); } export async function POST(req: Request) { const body = await req.text(); const event = verifyWebhook(req, body, process.env.WITN_WEBHOOK_SECRET!); // handle event } ``` Reject requests where the timestamp is more than 5 minutes old to prevent replay attacks. ## Rotating the signing secret [#rotating-the-signing-secret] Click **Rotate secret** on the rule page. The old secret stops working immediately. Update your environment variable before rotating. # Open an outcome (/docs/guides/open-an-outcome) Before creating an outcome, you need a customer and a task. The customer must have a rate card assigned with an entry for that task. ## What is an outcome? [#what-is-an-outcome] An outcome tracks whether a real-world event happened and whether it met the conditions for billing. You open it with a single create call, then send events against it. It resolves to **confirmed** or **missed** after the settlement window closes. Examples of when you open an outcome: a support ticket is created, a document is sent for signature, a job is posted, a task is started. ## The outcome key [#the-outcome-key] Every outcome has a `key`. You choose this string. It must be globally unique across all accounts and between 8 and 255 characters. You use the key on the create call and in every event you send for that outcome. Pick something that includes your own system identifiers: ``` support:ticket:1001 contract:acme:2024-01 job:hire:req-4821 ``` The key cannot be changed after the outcome is created. It must be globally unique across all accounts, not just your own. ## Opening an outcome [#opening-an-outcome] Create the outcome. This binds it to a task and a customer. ```bash curl -X POST https://api.thewitn.com/v1/outcomes \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "key": "support:ticket:1001", "task_key": "support", "customer_key": "acme" }' ``` Returns `202 Accepted`. witn snapshots the task contract for this customer and starts evaluating the billable condition. A repeated create for the same key is ignored. `task_key` is the key of the task. Find it in the dashboard. `customer_key` is the customer's key, not an ID. ## What happens next [#what-happens-next] Send events as things happen in your system. Each event names the outcome by `outcome_key`. witn evaluates the billable condition after each event and resets the settlement timer. Events for an outcome that does not exist are discarded, so create the outcome first. When the timer expires, the outcome resolves: * **Confirmed**: condition was met. You receive a notification and an invoice line is created. * **Missed**: condition was not met. You receive a notification. See [Notifications](/docs/guides/notifications) to set up a webhook for these events. ## Errors [#errors] | Code | Status | When | | ------------------ | ------ | ----------------------------------------------------------- | | `VALIDATION_ERROR` | 400 | `key`, `task_key`, or `customer_key` is missing or invalid. | | `TOKEN_INVALID` | 401 | Token missing or not recognised. | # Rate cards (/docs/guides/rate-cards) ## What is a rate card? [#what-is-a-rate-card] A rate card is a named pricing table. Each entry maps one task to a `price_per_unit`. When an outcome for that task confirms, the billed amount is `price_per_unit × unit`. Rate cards are separate from tasks. This means you can charge different customers different prices for the same task. Create one rate card per pricing tier. ## The key [#the-key] Every rate card has a `key`. It is a lowercase slug unique within your account: ``` standard enterprise-2024 agency_tier ``` Keys must start with a letter or digit. They may contain lowercase letters, digits, hyphens, and underscores. ## Entries [#entries] Rate card editor showing task-to-price entries A rate card holds zero or more entries. Each entry maps one task to one price. You set entries from the rate card editor in the dashboard. Each task may appear at most once per rate card. ## Assigning to a customer [#assigning-to-a-customer] A customer can have one rate card at a time. When you open an outcome, witn reads the customer's rate card and records the price for that task. Changing a rate card after outcomes have been opened does not change the price on those outcomes. Each outcome records its price when it is created. Only new outcomes use the updated price. ## Updating entries [#updating-entries] Open the rate card in the dashboard and edit its entries. Removing an entry deletes it from the rate card. ## Archiving [#archiving] Deleting a rate card archives it. Archived rate cards are hidden from the default list but remain accessible by ID. Customers assigned to an archived rate card keep the assignment. Historical outcomes are not affected. # Send events (/docs/guides/send-events) Events apply to an outcome you already opened. Each event names the outcome by `outcome_key`. [Create the outcome](/docs/guides/open-an-outcome) first; events for an outcome that does not exist are discarded. ## What is an event? [#what-is-an-event] An event is a signal from your system that something happened. You send events as things occur: a ticket is resolved, a document is signed, a score is submitted, a file is uploaded. After each event, witn evaluates the outcome's billable condition and resets the settlement timer. If the condition is satisfied, the outcome moves toward confirmation when the timer expires. ## Event structure [#event-structure] ```json { "outcome_key": "support:ticket:1001", "action": "agent_replied" } ``` ```json { "outcome_key": "support:ticket:1001", "action": "csat", "properties": { "value": 4.8, "settles_at": "2024-01-18T10:00:00Z" } } ``` | Field | Required | Description | | ----------------------- | -------- | ------------------------------------------------------------------------------------------------- | | `outcome_key` | Yes | The key of the outcome this event applies to. | | `action` | Yes | What happened. Matched against the billable condition. | | `properties.value` | No | A string, number, or boolean used for `match` and numeric comparisons. | | `properties.settles_at` | No | ISO datetime that pins when this outcome resolves. Overrides the settlement timer for this event. | `properties.value` and `properties.settles_at` are reserved by witn ## Sending an event [#sending-an-event] ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "agent_replied" }' ``` ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "csat", "properties": { "value": 4.8 } }' ``` Both return `202 Accepted`. The request is validated immediately. Condition evaluation and settlement happen asynchronously. In TypeScript: ```typescript await fetch('https://api.thewitn.com/v1/events', { method: 'POST', headers: { Authorization: `Bearer ${process.env.WITN_API_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ outcome_key: 'support:ticket:1001', action: 'csat', properties: { value: 4.8 }, }), }) ``` ## Multiple events with the same action [#multiple-events-with-the-same-action] When you submit more than one event with the same `action`, the latest `properties.value` for that `action` is used for condition evaluation. This lets you send corrections: if you submitted a CSAT score of 2 and the customer later updates it to 5, send the new event. witn uses 5 and re-evaluates the condition. ```bash # First submission: score of 2 (condition not met if gte 4) curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "csat", "properties": { "value": 2 } }' # Correction: score of 5 (condition now met) curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "csat", "properties": { "value": 5 } }' ``` ## Value and billing [#value-and-billing] Numeric comparators (`gt`, `gte`, `lt`, `lte`, `eq`) compare against `properties.value`. When the outcome confirms, the billed amount is the rate card entry's `price_per_unit`. ## Pinning the settlement time [#pinning-the-settlement-time] By default, every event resets the settlement timer to the event timestamp plus the task's settlement period. If an event knows the next business deadline, set `properties.settles_at`: ```json { "outcome_key": "appointment:123", "action": "appointment_booked", "properties": { "settles_at": "2024-02-01T17:00:00Z" } } ``` The outcome resolves at that time instead of the default settlement window. ## Errors [#errors] | Code | Status | When | | ------------------ | ------ | ------------------------------------------------ | | `VALIDATION_ERROR` | 400 | `outcome_key` or `action` is missing or invalid. | | `TOKEN_INVALID` | 401 | Token missing or not recognised. | # Submit a batch of events (/docs/api-reference/events/submit-event-batch) Submits many events in one request. Use this instead of many single calls when you have high volume. One request amortizes the cost of auth, parsing, and queueing across all the events, so throughput goes up and overhead goes down. Each item in `events` is a full event object. It follows the same schema as [Submit an event](/docs/api-reference/events/submit-event), so every per event field works here too, including `outcome_key`, `properties`, and `idempotency_key`. Every referenced outcome must already exist; events for an outcome that does not exist are discarded. You can send 1 to 500 events per request. ## Validation is atomic [#validation-is-atomic] The whole batch is validated before anything is enqueued. If any event is malformed, the request is rejected with `400 VALIDATION_ERROR` and nothing is sent. The error `details` point to the failing event by position, for example `events[12].action`. Fix that event and resend the batch. ## Response [#response] A `202 Accepted` returns a small body: ```json { "accepted": 48, "failed": [ { "index": 12, "reason": "rejected" }, { "index": 37, "reason": "unconfirmed" } ] } ``` `accepted` is how many events were confirmed enqueued. `failed` lists any events the queue rejected or could not confirm, by their zero based position in your `events` array. An empty `failed` array means every event was confirmed enqueued. The response is always `202`, even when some events fail, so you get a per event retry boundary instead of retrying the whole request. Each failure has a `reason`: | `reason` | Meaning | Safe to retry? | | ------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | `rejected` | The queue did not accept the event. It is not enqueued. | Yes. Retrying it cannot duplicate. | | `unconfirmed` | The enqueue call timed out or errored. The event may or may not be enqueued. | Only with `idempotency_key`. Without one, a retry can create a duplicate. | Retry only the events in `failed`. For `unconfirmed` failures, set an `idempotency_key` on the event so the retry is deduplicated instead of billed twice. ## Ordering [#ordering] Events keep their order per outcome. Two events with the same `outcome_key` are processed in the order you sent them, even when they land in different internal batches. Events for different outcomes process in parallel. Order holds across failures too. If an event is rejected or unconfirmed, any later event for the same outcome in the same request is also reported in `failed` and is not enqueued. So retrying the events in `failed` resends that outcome's tail in order. Failures never cascade between different outcomes. ## Idempotency [#idempotency] Set `idempotency_key` on any event in the batch to make a retry of that event safe. The same key on the same outcome always maps to the same event, so resending it does not create a second billable event. Keys are scoped to your account and `outcome_key`. See [Submit an event](/docs/api-reference/events/submit-event) for the full idempotency rules. ## Size limit [#size-limit] The batch request body is capped at 5 MiB. Larger bodies are rejected with `413 PAYLOAD_TOO_LARGE`. Keep `properties` small and store large metadata in your own storage, sending only a reference. ## Example [#example] ```bash curl -X POST https://api.thewitn.com/v1/events/batch \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "events": [ { "outcome_key": "support:ticket:1001", "action": "csat_received", "properties": { "value": 4 } }, { "outcome_key": "support:ticket:1002", "action": "csat_received", "properties": { "value": 5 } } ] }' ``` ## Errors [#errors] | Code | Status | When | | ------------------- | ------ | ----------------------------------------------------------------------------------------------------------- | | `VALIDATION_ERROR` | 400 | Any event in the batch is missing a required field or is invalid, or the array is empty or over 500 events. | | `TOKEN_INVALID` | 401 | The token is missing or not recognised. | | `PAYLOAD_TOO_LARGE` | 413 | The batch body exceeded the 5 MiB limit. | # Submit an event (/docs/api-reference/events/submit-event) Submits a signal to an existing outcome. The request body and token are validated immediately, then the event is enqueued for asynchronous processing. Identity checks, condition evaluation and state transitions happen in a background consumer with automatic retries. The event names its outcome by `outcome_key`. [Create the outcome](/docs/guides/open-an-outcome) first with `POST /v1/outcomes`: an event whose `outcome_key` has no outcome is discarded. Events for `CONFIRMED` or `FAILED` outcomes are rejected as `OUTCOME_NOT_OPEN`. Returns `202 Accepted` on success. The request body is capped at 256 KiB. Larger bodies are rejected with `413 PAYLOAD_TOO_LARGE`. Keep `properties` small and store large metadata (documents, transcripts, images) in your own storage, sending only a reference. ## Example [#example] ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "csat_received", "properties": { "value": 4, "settles_at": "2024-01-18T10:00:00Z" } }' ``` `properties` is an open object. Send whatever fields your workflow produces. The whole object is stored on the event log and any field is available to a condition. A comparison or match reads one property. By default that is `properties.value`: ```json { "fact": "csat_received", "operator": "gte", "value": 3 } ``` To read a different field, name it on the fact after a colon, `action:property`. So you can keep several values on one event and compare any of them: ```json { "outcome_key": "...", "action": "review", "properties": { "score": 0.92, "tier": "gold" } } ``` Reference them as `review:score` or `review:tier`. Reach nested fields with dots, `review:meta.overall`. `properties.settles_at` is reserved: it optionally overrides the next settlement timestamp. Use it when an event carries its own business deadline, such as an appointment time plus a grace period. It must be an ISO datetime string. ## Idempotency [#idempotency] `idempotency_key` is optional. Send one to make retries safe. The same key on the same outcome always maps to the same event, so if a request times out after the server already accepted it, you can retry with the same key and it will not create a second billable event. Keys are scoped to your account and outcome `key`, so two accounts or two outcomes can use the same idempotency key without clashing. Reusing an idempotency key on the same outcome with a different body keeps the first event and drops the later one. Leave the key out and every request is treated as a new event. ```bash curl -X POST https://api.thewitn.com/v1/events \ -H "Authorization: Bearer $WITN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "outcome_key": "support:ticket:1001", "action": "csat_received", "idempotency_key": "csat-1001-attempt-1" }' ``` ## Multiple events with the same action [#multiple-events-with-the-same-action] When you submit more than one event with the same `action`, there are two separate rules: | Field | Rule | | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | The property a condition reads (`value` by default, or the `action:property` you named) | A comparison uses the latest event for that `action`. A count tallies every occurrence. | | `properties.settles_at` | Overrides the next `settles_at` for the outcome. If omitted, witn uses the event timestamp plus the task's `settlement_period`. | ## Concurrent submissions [#concurrent-submissions] Concurrent submissions return `202 Accepted` once they are enqueued. If the first event advances the outcome before the second is processed, the background consumer discards the second event because the outcome is already terminal: ```typescript const res = await fetch('https://api.thewitn.com/v1/events', { method: 'POST', headers: { Authorization: `Bearer ${process.env.WITN_API_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ outcome_key: 'support:ticket:1001', action: 'csat_received', }), }) if (res.status === 202) { // The event was accepted for async processing. // Inspect the outcome later if you need the final state. } ``` ## Errors [#errors] | Code | Status | When | | ------------------- | ------ | ------------------------------------------------- | | `VALIDATION_ERROR` | 400 | `outcome_key` or `action` is missing or invalid. | | `TOKEN_INVALID` | 401 | The token is missing or not recognised. | | `PAYLOAD_TOO_LARGE` | 413 | The event body exceeded the 256 KiB ingest limit. | # A Buyer's Guide to Outcome-Based AI Pricing (/blog/a-buyer-s-guide-to-outcome-based-ai-pricing) ## The Promise and Pitfalls of Paying for Results [#the-promise-and-pitfalls-of-paying-for-results] In 2026, a growing share of AI agent vendors price on outcomes. This model is attractive because it promises to align your costs with the value you receive. Instead of paying for seats or minutes, you pay for successful results. For buyers tired of investing in technology with uncertain returns, this feels like a safer bet. It shifts the performance risk from you to the vendor. However, this safety is not automatic. The entire model hinges on a single, critical detail: **the definition of a "result"**. A vague or vendor-friendly definition can quickly turn a seemingly fair deal into a source of unpredictable and inflated invoices. The promise of paying for performance is only as good as the contract that defines it. Understanding this is the first step to making a smart purchase. The goal of outcome-based pricing is to pay for value, but you must first define what value means in clear, measurable terms. ## Defining the Billable Outcome [#defining-the-billable-outcome] When evaluating an AI agent, the first and most important question to ask a vendor is, "What exactly counts as a billable outcome?". Their answer reveals everything about the financial partnership you are about to enter. A "resolution" is not a universal standard. Its definition varies significantly from one vendor to another. This difference has a direct impact on your final bill. Vendors often define a successful resolution in one of several ways: * **Explicit confirmation.** The user must click a "My issue is resolved" button or give a similar positive confirmation. This is the most buyer-friendly definition. * **No user reply.** The conversation is considered resolved if the user does not reply within a set time frame, such as 48 or 72 hours. This can be problematic as users may simply get busy or give up. * **No reopen.** A ticket is marked resolved and is only billed if it is not reopened by the user within a specific window, like seven days. Consider the financial implications. Imagine your team handles 1,000 support tickets. A vendor using an "explicit confirmation" rule might find that 450 of those tickets are billable. Another vendor using a "no reply for 72 hours" rule might claim 700 resolutions from the exact same ticket volume. That is a 55 percent difference in cost for the same work. This is often why vendor-cited resolution rates of 70 percent or more rarely match the 40 to 50 percent rates buyers observe in practice. The gap comes from definitions, not just performance. For a deeper look into this, we have analyzed [what counts as a resolution in the fine print](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing) of these agreements. ## Normalizing Quotes to a Single Metric [#normalizing-quotes-to-a-single-metric] Comparing AI agent pricing models can feel like comparing apples to oranges. One vendor charges per conversation, another per resolution and a third uses a hybrid model with a platform fee. To make an informed decision, you must translate every quote into a single, universal metric: the **effective cost per successful outcome**. This calculation cuts through the marketing and reveals the true cost of getting a job done. Let's walk through an example. Assume you handle 10,000 conversations per month and your historical data suggests a realistic successful resolution rate of 45 percent. This means you expect 4,500 successful outcomes. Here is how to compare three common pricing structures: * **Vendor A (per conversation).** Charges $2.00 per conversation, like Salesforce Agentforce. Your total cost is 10,000 conversations × $2.00, which equals $20,000. To find the effective cost per successful outcome, you divide the total cost by the number of successful outcomes: $20,000 / 4,500 = **$4.44 per success**. * **Vendor B (per resolution).** Charges $0.99 per resolution, similar to Fin by Intercom. Here, the price per resolution is already the effective cost. Your total bill would be 4,500 successful outcomes × $0.99, which equals $4,455. The effective cost is **$0.99 per success**. * **Vendor C (hybrid).** Charges a $2,000 monthly platform fee plus $0.50 per resolved conversation, like HubSpot Customer Agent. Your cost is the platform fee plus the usage fee: $2,000 + (4,500 × $0.50) = $4,250. Your effective cost is $4,250 / 4,500 = **$0.94 per success**. | Model | Pricing structure | Total monthly cost | Effective cost per successful outcome | | --------------------------- | ------------------------------------------ | ------------------ | ------------------------------------- | | Vendor A (per conversation) | $2.00 per conversation | $20,000 | $4.44 | | Vendor B (per resolution) | $0.99 per resolution | $4,455 | $0.99 | | Vendor C (hybrid) | $2,000 platform fee + $0.50 per resolution | $4,250 | $0.94 | Calculations assume a 45 percent successful resolution rate. That is 4,500 successful outcomes out of 10,000 conversations. This normalization reveals the true cost of a successful result across different models. Diagram normalizing three vendor quotes into one metric. Vendor A at $2.00 per conversation, Vendor B at $0.99 per resolution and Vendor C at $2,000 per month plus $0.50 per resolution all flow into effective cost per successful outcome, yielding $4.44, $0.99 and $0.94 respectively This simple exercise is essential for any serious evaluation. It is the only way to see which model is truly the most cost effective for your specific needs. For more examples, see our breakdown of [AI agent pricing in 2026](/blog/ai-agent-pricing-in-2026-what-fin-sierra-decagon-and-agentforce-actually-charge) and what major vendors actually charge. ## Your Contract Fine Print Checklist [#your-contract-fine-print-checklist] Once you have normalized quotes, the next step is negotiating the contract. The sales deck is not the contract. You must ensure all verbal promises and definitions are written into the legal agreement. An experienced procurement leader would never sign a deal without clarifying these points. Use this checklist to protect your business from surprise invoices and unfair terms. * **Reopen windows.** The contract must clearly define the time period during which a customer reopening a ticket does not trigger a new billable event. Demand a window of at least 7 to 14 days. * **Verification and audit rights.** You must have the right to audit the vendor's billing data. This ensures you can independently verify that you are only being charged for valid outcomes. * **Dispute process.** What happens when you disagree with a charge? The contract needs a clear, simple process for disputing line items, including response timeframes from the vendor. * **Volume commitments.** Be wary of high minimum monthly commitments or steep penalties for falling below a certain volume. The contract should also specify pricing for overages. * **Human escalation.** The contract must state what happens when the agent fails and escalates to a human. Is there a charge for the failed attempt? Is the escalation itself a billable event? Get this in writing. ## How to Run a Fair Pilot Program [#how-to-run-a-fair-pilot-program] A pilot program is not just for testing the technology. It is your best opportunity to validate the vendor's pricing model and performance claims in a controlled environment. A well-structured pilot provides the data you need to make a final decision. First, **establish your baselines** before the pilot begins. You need to know your current metrics, including your human team's cost per resolution, average resolution time and customer satisfaction scores. Without this data, you have nothing to compare the agent's performance against. Second, **prevent cherry-picking**. Insist that the AI agent is tested on a representative sample of all incoming tickets, not just the easy, repetitive ones the vendor prefers. The agent must be exposed to the same complexity and variety your human team faces. Third, **set an adequate duration**. A one week pilot is not enough to generate meaningful data. A pilot should run for at least 30 to 60 days to account for fluctuations in ticket volume and complexity. Finally, **define pass criteria upfront**. Before the pilot starts, agree with the vendor on what success looks like. This should be a specific, measurable goal. For example, "The agent must achieve an effective cost per successful outcome below $1.50 while maintaining a CSAT score of 90 percent or higher". This removes ambiguity and makes the final evaluation straightforward. ## Red Flags to Watch For [#red-flags-to-watch-for] During your evaluation, certain practices should be considered serious red flags. These warning signs often indicate a lack of transparency that will lead to billing disputes and frustration down the line. If you encounter any of these, proceed with extreme caution. 1. **No per-outcome evidence.** If a vendor bills you for 500 "resolutions" but cannot provide a list of the 500 specific conversations that were resolved, their bill is unverifiable. You should be able to trace every single charge back to a source event. 2. **Opaque definitions.** Be wary if a billable outcome is defined by a proprietary, black-box metric that only the vendor can measure. If you cannot independently calculate or verify an outcome, you cannot audit your invoices. 3. **Aggregate invoices.** An invoice that arrives as a single number, like "$5,000 for services rendered", is unacceptable. It hides all the important details, making it impossible to check for accuracy or understand cost drivers. These issues are common, but they are also solvable. They are symptoms of an outdated billing system that is not designed for the nuance of outcome-based models. You can learn more about [how transparent invoicing stops AI billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes) and what to demand from your partners. ## What a Good Partnership Looks Like [#what-a-good-partnership-looks-like] A good vendor partnership is built on transparency and trust. It moves beyond sales claims and into shared, verifiable data. In an ideal relationship, the vendor's success is directly and transparently tied to your own. This is what good looks like in practice. Invoices are not just summaries. They are detailed reports where every single line item links back to a verifiable event, such as a conversation transcript or a completed action. The definitions for billable outcomes are not hidden in a sales deck. They are written clearly into the contract in plain language. The best vendors go a step further, offering shared dashboards that provide near real-time visibility into how outcomes are being measured and billed. This eliminates surprises at the end of the month. This level of detail and transparency is entirely possible with a modern billing layer. For example, platforms like [witn](/) are built to produce invoices with linked evidence for every charge, giving both the buyer and the seller a single source of truth. When you evaluate vendors, look for those who have invested in this level of clarity. It is the clearest sign of a partner you can trust. ### Questions to Ask Your AI Vendor [#questions-to-ask-your-ai-vendor] Copy this list into your notes for your next vendor call. 1. What is your precise definition of a billable "outcome" or "resolution"? 2. Can you show me where that definition is written in the contract? 3. What is the reopen window for a resolved ticket? 4. How do you handle conversations that are escalated to a human agent? 5. Can I get a sample invoice that shows line-item level detail for each charge? 6. How do I audit or dispute a specific charge on my invoice? 7. What are your minimum commitments and overage rates? 8. During a pilot, how will you ensure the agent is tested on a representative sample of tickets? 9. What baseline metrics do you recommend we capture before starting a pilot? 10. Can you provide a shared dashboard for tracking billable outcomes in real time? # AI Agent Monetization: The Complete Guide (/blog/ai-agent-monetization-the-complete-guide) Every AI agent team eventually hits the same wall. The agent works, customers want it and nobody can agree on what to charge for. AI agent monetization is harder than classic software pricing because you are no longer selling access to a tool. You are selling completed work, and work can fail, be reversed or be disputed. This guide covers the full journey: why the old models break, what the market charges today, how to define and price a billable outcome, how to test the model before launch and what it takes to operate it in production. Each section links to a deeper article or to the docs. Read it end to end for the full picture, or jump to the stage you are at. ## Why AI agents break traditional software pricing [#why-ai-agents-break-traditional-software-pricing] Traditional SaaS pricing rests on a quiet assumption: value scales with access. More users, more value, more seats. Agents break that assumption. An autonomous support agent handling thousands of conversations has no meaningful "seat". A coding agent that ships a fix at 3am was never licensed to a person. Usage pricing looks like the natural fallback, but it prices your cost, not your customer's value. Worse, it punishes improvement. When a better model resolves the same ticket with fewer tokens, your revenue per task shrinks. We call this the innovator's paradox and unpack it in [Why Your AI Product's Success Could Shrink Your Revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). There is a deeper technical mismatch too. Metering assumes each recorded event is final. Agent outcomes are not. A resolved ticket gets reopened. A booked meeting gets cancelled. A merged PR gets reverted. Billing for agent work means evaluating state over time, and traditional metering has no place to put that state. That gap is the subject of [The Missing Layer in AI Agent Monetization](/blog/the-missing-layer-in-ai-agent-monetization). ## The pricing models, compared [#the-pricing-models-compared] Six models cover the practical space. Most companies combine two of them. | Model | What you charge for | Value alignment | Best for | | -------- | -------------------------------------- | ---------------------------- | ---------------------------------------------------- | | Seat | Access per user | Low | Copilots tied to a human workflow | | Usage | Tokens, calls, minutes | Low | Developer APIs, early platforms | | Credits | Prepaid abstract units | Low to medium | Multi-feature products, enterprise procurement | | Workflow | A completed multi-step task | Medium | Tasks that finish but whose impact is hard to verify | | Outcome | A verified business result | High | Agents that can prove their impact | | Hybrid | Platform fee plus a variable component | Depends on the variable part | Most mature companies | Quadrant chart comparing AI agent pricing models on revenue predictability and value alignment. Seats are predictable but value-blind, usage sits near the worst of both, per-task is the pragmatic middle and outcomes offer maximum value alignment but are hard to forecast. Seats work for copilots and unravel for autonomous agents. Usage is transparent but misaligned. Credits smooth the buying experience, and roughly a third of software companies have adopted them, yet they remain a cost-plus workaround with a better interface. Workflow pricing charges for "one processed invoice" regardless of compute, a real step toward value that still bills activity rather than impact. Outcome pricing charges only when a predefined, verifiable result is achieved. It is the strongest alignment and the hardest to operate. The full decision framework, including the three questions that map you to a model, is in [Strategies for Monetizing AI Agents: From Seats to Outcomes](/blog/strategies-for-monetizing-ai-agents-from-seats-to-outcomes). The short version: if you cannot yet define or verify an outcome, start with usage or workflow pricing. If you can verify but cannot absorb revenue volatility, go hybrid. If you can do both, pure outcome pricing is the strongest position in the market. ## What the market actually charges in 2026 [#what-the-market-actually-charges-in-2026] Outcome pricing is not theoretical. In customer support it is already the reference model: * **Fin by Intercom** charges a flat $0.99 per resolution with no platform fee. It is the market's pure outcome benchmark and its price point has become a psychological anchor for the whole category. * **Salesforce Agentforce** charges around $2.00 per conversation, resolved or not, on its conversation model (it now also sells action-based Flex Credits and per-user licenses). At a 60 percent resolution rate that is an effective $3.33 per successful resolution, with the failure risk sitting on the buyer. * **Sierra** sells enterprise per-resolution contracts, reportedly around $150,000 annual commitments plus implementation fees from $50,000 to $200,000. * **Decagon** runs a hybrid: a platform fee around $50,000 plus a per-resolution rate, with one publicly discussed contract at $0.50 per resolution. The numbers are less interesting than the fine print. Intercom cites an average resolution rate around 71 percent while independent reports place it between 42 and 50 percent, a gap explained entirely by what counts as "resolved". Vendors now differentiate on resolution definitions, reopen windows and auditability rather than on the headline rate. We break down the normalization math in [AI Agent Pricing in 2026](/blog/ai-agent-pricing-in-2026-what-fin-sierra-decagon-and-agentforce-actually-charge) and the contract fine print in [What Counts as a Resolution?](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing). The same shift is starting in other verticals: voice AI is still stuck on per-minute rates that tax slow conversations, a trap we cover in [How Voice AI Companies Price Today](/blog/how-voice-ai-companies-price-today-and-why-per-minute-billing-is-a-trap). ## How to define a billable outcome [#how-to-define-a-billable-outcome] The best billable outcomes are boring. Not "revenue influenced" or "pipeline generated", which end in attribution debates, but the small repetitive chores the customer used to do manually. A ticket resolved. An appointment booked. An invoice processed. A defensible outcome has three properties: 1. **Observable.** Both sides can point to the event and agree it happened. 2. **Repetitive.** It occurs often enough that no single charge invites scrutiny. 3. **Hard to dispute.** If you need a slide deck to justify the charge, it is a value narrative, not a billable outcome. Then formalize it in one sentence: **we charge when \_\_\_ happens and remains true for \_\_\_.** The first blank is the smallest concrete event you can defend. The second is the time window that absorbs cancellations and reversals. "A support ticket is marked resolved" and "72 hours without a reopen" together form a complete billing specification. That sentence translates directly into a machine-checkable [billable condition](/docs/guides/billable-conditions): a boolean rule over the events your system already emits, with the time window as the [settlement period](/docs/concepts/outcome-lifecycle). The full discipline, including a worked comparison of weak and strong outcome definitions, is in [Defining Concrete Billable Outcomes for AI Agents](/blog/defining-concrete-billable-outcomes-for-ai-agents). ## Price the risk, not just the outcome [#price-the-risk-not-just-the-outcome] "Do you charge per outcome?" is the wrong question. The right question is "which outcome?". An outcome is a package of risk transferred from the customer to you, and every condition you add to its definition transfers more. Take an appointment-booking agent. "Appointment booked" is cheap because the customer still carries the no-show risk. "Appointment booked and occurred" costs more because you now absorb that risk. "Appointment occurred and the customer was satisfied" costs the most because you are also underwriting quality. One agent, three products: | Outcome definition | Risk holder | Example price | | ------------------------------- | ----------- | ------------- | | Appointment booked | Customer | $1 | | Booked and occurred | Shared | $5 | | Occurred and verified satisfied | Vendor | $12 | Instead of hunting for the one right price, build the ladder and let each customer choose how much certainty to buy. Every rung must be verifiable, because a promise you cannot verify is a promise you cannot bill. The method for structuring and pricing the tiers is in [Pricing AI Outcomes as Risk Contracts](/blog/pricing-ai-outcomes-as-risk-contracts). ## Test the model before you launch it [#test-the-model-before-you-launch-it] You do not have to guess what outcome pricing does to your revenue. You already have the data to know. Replay your historical events, the user actions and status changes already sitting in Segment, PostHog or your own event log, through the proposed outcome definition. The output is a line-by-line invoice showing what each customer would have paid last quarter under the new model. That backtest turns an abstract pricing debate into a financial document. It shows which customers get cheaper, which get more expensive and what happens to your revenue if the agent's resolution rate improves by ten points. Run it before every definition change, not just at launch. The full method, including how to validate the model with design partners, is in [How to Test Your Outcome Pricing Model Before Launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). Performance and value metrics dashboard for optimizing an AI agent. Crucial performance metrics: task completion rate, response accuracy, average response time, cost per task versus value delivered and model update frequency. Outcome-based success metrics: customer ROI, reduced time-to-value, adoption rate, error rate reduction pre versus post AI and value-driven customer retention ## Operating outcome billing in production [#operating-outcome-billing-in-production] This is where most teams underestimate the work. Between "the agent did the job" and "the customer was correctly charged" sits a pipeline that has to be right every time: * **Verification.** Every event is folded into the outcome's state and the billable condition is re-evaluated. Not a one-time check: state accumulates across events and time. * **Settlement.** A result stays provisional until a settlement window passes without contradiction. A reopened ticket inside the window means no charge. In witn the [outcome lifecycle](/docs/concepts/outcome-lifecycle) runs OPEN to CONFIRMED or missed, with a default 72-hour window extendable to 180 days, and every new event resets the timer. * **Exactly-once effects.** Duplicate events must not double-charge. Out-of-order events must not corrupt state. The engineering behind sub-10ms ingestion and idempotent billing effects is in [How We Built witn's Outcome Resolution Layer](/blog/how-we-built-witn-s-outcome-resolution-layer-for-low-latency-and-reliability). * **Explainable invoices.** Each line item should carry the outcome, the condition it satisfied, the triggering events and the settlement moment. When the invoice explains itself, disputes stop being support tickets. The anatomy of a self-explanatory line item is in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). * **Per-customer pricing.** The same outcome carries different prices for different customers via [rate cards](/docs/guides/rate-cards), without forking billing logic. ## Build or buy the resolution layer [#build-or-buy-the-resolution-layer] You can build this in-house. Teams that try usually discover they are building a second product: a stateful event pipeline with financial correctness requirements, exactly-once semantics and an audit trail, maintained forever next to the agent that actually makes money. The trade-offs are laid out in [The Missing Layer in AI Agent Monetization](/blog/the-missing-layer-in-ai-agent-monetization). If you buy, match the tool to your model. Usage metering platforms are excellent at what they do and stop at recorded consumption. We compare the landscape in [Metronome Alternatives After the Stripe Acquisition](/blog/metronome-alternatives-after-the-stripe-acquisition), [5 Paid.ai Alternatives for AI Agent Billing](/blog/paid-ai-alternatives-for-ai-agent-billing) and head-to-head in [witn vs Orb](/blog/witn-vs-orb). The dividing line is always the same: metering platforms answer "how much did the customer use?" while an outcome layer answers "what value did the customer receive?". ## A maturity path, not a one-time choice [#a-maturity-path-not-a-one-time-choice] Almost nobody starts at pure outcome pricing and that is fine. The realistic path: 1. **Launch on usage or workflow pricing** while the agent earns trust. 2. **Instrument outcome events from day one**, even though you are not billing on them yet. This is the single highest-leverage move in agent monetization. It turns a future pricing migration into a configuration change and gives you the historical data for backtesting. 3. **Move to hybrid** once the agent reliably delivers. A platform fee for the floor, an outcome component for the alignment. A common readiness benchmark is the agent returning at least 3x its cost to the customer. 4. **Shift weight to outcomes** as your verification confidence grows, using the risk ladder to price the guarantees you take on. ## Frequently asked questions [#frequently-asked-questions] ## Where witn fits [#where-witn-fits] witn is billing infrastructure for the outcome end of this guide. Define what a successful outcome looks like as a condition. Send events as the agent works. witn verifies the condition, waits out the settlement window, handles reversals and produces invoices where every line traces back to the result that earned it. Start with the [docs](/docs) or the [quickstart](/docs/quickstart). # AI Agent Pricing in 2026: Fin, Sierra, Decagon (/blog/ai-agent-pricing-in-2026-what-fin-sierra-decagon-and-agentforce-actually-charge) ## Understanding the AI Agent Pricing Maze [#understanding-the-ai-agent-pricing-maze] The 2026 market for AI customer support agents is crowded. Vendor pricing models are complex and often opaque. Headline rates per resolution, per conversation or per session rarely tell the whole story. A buyer comparing a pure outcome-based fee with a hybrid platform plus usage model is not comparing like for like. This creates significant challenges for businesses trying to forecast costs and evaluate return on investment. This article provides a practical, numbers-driven survey to help buyers and founders navigate this landscape. We will examine the reported pricing structures of major vendors. Then we will demonstrate how to normalize these different models into a single metric. The goal is to equip you to build a cost model for your own ticket volume and make a truly informed decision. Comparison of three AI support agent list prices: Fin at $0.99 per resolution, HubSpot at $0.50 per conversation and Agentforce at $2 per conversation ## A Survey of Current AI Agent Pricing Models [#a-survey-of-current-ai-agent-pricing-models] To understand the market, you must first understand the individual pricing shapes. Vendors structure their fees to align with their product strategy, whether that is pure performance, a platform defense or an enterprise service bundle. Here is a survey of the most common models and reported rates in 2026. ### Fin by Intercom: The Pure Outcome Benchmark [#fin-by-intercom-the-pure-outcome-benchmark] Fin is the market's reference point for pure outcome-based billing. The reported cost is a flat [$0.99 per resolution](https://fin.ai/learn/ai-customer-service-agent-pricing-comparison) with no accompanying platform fees or per-seat charges. It operates over an existing helpdesk. This simplicity is appealing but the definition of "resolution" is critical. Intercom has cited an average resolution rate around 71 percent across its customer base. However, independent reports often place the figure between 42 and 50 percent. This gap is not about performance but about what counts as a resolved ticket. ### HubSpot Customer Agent: The Aggressive Suite Play [#hubspot-customer-agent-the-aggressive-suite-play] HubSpot's strategy reflects its position as a platform giant. The Customer Agent price was cut to $0.50 per resolved conversation in April 2026. This aggressive price point is designed to defend and expand its ecosystem. HubSpot can afford to subsidize its AI agent as a feature that makes its core CRM and service platform stickier. For buyers already invested in the HubSpot suite, this pricing is highly compelling. For others, it highlights how platform vendors use AI agents as a strategic lever rather than a standalone profit center. ### Salesforce Agentforce: The Per-Conversation Model [#salesforce-agentforce-the-per-conversation-model] Agentforce charges a reported $2.00 per conversation, not per resolution. This means buyers pay for every interaction the agent handles regardless of the outcome. You pay for successful resolutions and you pay for failures that require human escalation. The financial risk shifts from the vendor to the buyer. To compare this model, you must calculate an effective resolution cost. Assuming a 60 percent resolution rate, that $2.00 per conversation becomes an effective $3.33 per successful resolution. ### Sierra: The Enterprise Outcome Contract [#sierra-the-enterprise-outcome-contract] Sierra targets large enterprises with custom per-resolution contracts. The pricing is not public but reported figures suggest annual commitments around $150,000. These contracts often include substantial implementation fees ranging from $50,000 to $200,000. Deployments are also significant projects running from three to seven months. This model bundles the software with extensive professional services, minimum commitments and bespoke success definitions. It represents outcome pricing at enterprise scale, where the contract is as important as the technology. ### Decagon: The Hybrid Platform Fee Model [#decagon-the-hybrid-platform-fee-model] Decagon represents a hybrid approach. Its structure reportedly combines a significant annual platform fee around $50,000 with a custom per-conversation or per-resolution rate. At least one publicly discussed contract used a rate of $0.50 per resolution on top of the platform fee. This model gives the vendor a stable revenue floor while still tying a portion of the cost to performance. For buyers, it means a higher upfront commitment but potentially lower variable costs at scale compared to pure per-conversation models. ### Other Usage-Based Models [#other-usage-based-models] Below the outcome-focused vendors sits a tier of usage-based pricing. Freshdesk, for example, offers session-based bots with costs that can work out to roughly $0.10 per session. This model anchors the low end of the market. It bills for activity, not results. While the unit cost is low, the total cost can be unpredictable and disconnected from the value delivered. These models are often a starting point for companies before they graduate to more sophisticated outcome-based AI agents. ## How to Normalize Costs for True Comparison [#how-to-normalize-costs-for-true-comparison] Headline rates are misleading. To compare these different models, you must convert them all to a single metric: the effective cost per successful resolution. This normalization requires you to model costs using your own operational data, specifically your monthly conversation volume and expected AI resolution rate. Let us walk through a concrete example. Imagine a business handles 10,000 support conversations per month and anticipates a 60 percent resolution rate from an AI agent. This means the agent is expected to successfully resolve 6,000 conversations each month. Using this scenario, we can calculate the effective monthly cost and cost per successful resolution for each pricing shape. The table below shows how the math works out. It reveals that the rank order of vendors by cost changes dramatically once you normalize their pricing to a common denominator. | Pricing Model | Unit Cost | Effective Resolution Cost (60% Rate) | Monthly Total (10k Conv) | | ---------------- | --------------- | ------------------------------------ | ------------------------ | | Per-Resolution | $0.99 | $0.99 | $5,940 | | Per-Conversation | $2.00 | $3.33 | $20,000 | | Hybrid | $0.50 + $50k/yr | $1.19 | $7,167 | | Per-Session | $0.10 | $0.17 | $1,000 | *Note: Calculations are based on a scenario of 10,000 monthly conversations and a 60% successful resolution rate. The Hybrid model's annual fee is amortized monthly ($4,167/mo). These figures illustrate how headline rates can be misleading without normalization.* The key insight is clear. The "cheapest" vendor depends entirely on your volume and performance assumptions. A per-session model looks inexpensive on a unit basis but a per-resolution model might offer more value predictability. You must run the numbers for your own business to see the true cost of each option. ## The Critical Caveat: Defining "Resolution" [#the-critical-caveat-defining-resolution] Even a perfectly normalized cost comparison has a major weakness. The calculation is only valid if every vendor defines "resolution" in the same way. They do not. The contractual and technical definition of the billable event is the single most important variable in your final cost. A seemingly small difference in this definition can swing your effective cost by 30 to 50 percent. When evaluating vendors, you must scrutinize the fine print. Pay close attention to the specific event that triggers a billable resolution, the length of the reopen window before a follow-up is considered a new ticket and how partial resolutions or escalations are handled. We took this fine print apart in [What Counts as a Resolution?](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing). Your financial model is only as accurate as these definitions. ## Market Pressures and the Future of Vendor Differentiation [#market-pressures-and-the-future-of-vendor-differentiation] The current AI agent pricing landscape is shaped by intense market pressures. The $0.99 per resolution price point is becoming a psychological anchor for the industry. Aggressive price cuts like HubSpot's signal commoditization pressure at the lower end of the market, where basic agent capabilities are becoming table stakes. In response, sophisticated vendors are shifting their differentiation from the rate card to the contract. As highlighted by industry analysis from [Corebee.ai](https://corebee.ai/blog/ai-support-pricing-2026-flat-vs-per-resolution-vs-per-seat), premium pricing is no longer justified by the AI model alone. Instead, it is justified by stricter resolution definitions, longer reopen windows and fully [auditable invoices](/blog/how-transparent-invoicing-stops-ai-billing-disputes) that give buyers confidence in what they are paying for. The future of competition is in the clarity and fairness of the billing logic. ## Building for an Outcome-Based World [#building-for-an-outcome-based-world] This shift toward auditable outcome-based billing creates new technical challenges for vendors. Defining what counts as a resolution, holding charges through settlement windows and producing invoices that buyers can trust requires specialized infrastructure. These benchmarks are one input into a bigger decision. We map the full journey from pricing model to production billing in [AI Agent Monetization: The Complete Guide](/blog/ai-agent-monetization-the-complete-guide). witn is billing infrastructure built for exactly this. Express your resolution definition as a condition over events. Hold charges through settlement windows until reversals clear. Give buyers invoices where every line traces back to its proof. [Read the docs](/docs) to see how it works. # Engineering Leader's Guide to Outcome-Based Pricing (/blog/an-engineering-leaders-guide-to-implementing-outcome-based-pricing) Blueprint of an outcome-based pricing system: an immutable event log feeds an outcome state machine that moves from pending to resolved to committed through a settlement window, with billable conditions as a rules tree and a full audit trail of committed charges ## The Hidden Complexity of Outcome-Based Pricing [#the-hidden-complexity-of-outcome-based-pricing] Outcome-based pricing starts as a commercial decision but lands on your desk as a distributed systems problem. Engineering teams often estimate the work as a simple change to a billing table. They soon discover it is a complex event-sourcing project. This guide is not about why you should adopt this model. It is a technical blueprint for the engineering leader who has been tasked with building it correctly. We will cover the data model, the common failure modes and the practical steps for a successful outcome-based pricing implementation. ## What Changes When Billing on Outcomes [#what-changes-when-billing-on-outcomes] Traditional billing models are deterministic. You count seats or meter API calls. The logic is straightforward because the billable unit is a simple counter. Outcome-based billing is fundamentally different. You are not counting activity. You are verifying a result. The billable moment is not a counter ticking up but a specific condition being met, often emerging from a complex sequence of events. For AI agents, value is non-deterministic. An agent might take ten steps to resolve a customer issue or it might take two. Metering the steps misses the point. The value is in the resolution. This requires billing infrastructure capable of interpreting context from a stream of events to identify when a valuable outcome has actually occurred. The primitive is different, so the system must be too. ## The Core Data Model: Events, Outcomes and Conditions [#the-core-data-model-events-outcomes-and-conditions] A robust system for outcome billing is built on three primitives. Understanding them is the first step in designing a correct architecture. **Events** are immutable, timestamped facts. An agent emits an event for every meaningful action: `ticket_created`, `user_responded`, `summary_generated`. These events form an ordered, append-only log that serves as the single source of truth for all activity. An **Outcome** is a state machine. It is uniquely identified by a key, such as a combination of customer and agent IDs. This state machine updates its state with every relevant event, ensuring the billable status is always current. This is a core principle of event sourcing for billing. **Billable Conditions** are the rules that define a successful outcome. These are best expressed as a logical tree of AND/OR clauses that operate on event properties and time windows. For example, a billable outcome might be defined as: a `ticket_created` event is seen AND an `escalated` event is not seen within seven days. You can learn more about structuring these rules by [exploring billable conditions](/docs/guides/billable-conditions) in detail. The process of [defining concrete billable outcomes for AI agents](/blog/defining-concrete-billable-outcomes-for-ai-agents) is a critical business and engineering exercise. A critical architectural rule is to never re-derive state by re-scanning the event log on a schedule. The outcome state machine must process events as they arrive, keeping the billable state live and accurate at all times. ## Four Failure Modes and How to Prevent Them [#four-failure-modes-and-how-to-prevent-them] Building a resilient billing system means anticipating where it will break. Many teams fall into common traps when they first approach this problem. Below are four frequent failure modes and the correct architectural patterns to avoid them. | Failure Mode | Naive Approach | Correct Approach | | ---------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Idempotency and retries | Trusting each client call, leading to double-billing on retries. | Deriving a deterministic event ID from a client idempotency key to deduplicate requests. Ingest is asynchronous. | | Out-of-order and late events | Processing events in arrival order, creating incorrect state. | Using the event's immutable timestamp to re-evaluate state, ensuring historical accuracy. | | Reversals and cancellations | Treating a met condition as a final, irreversible charge. | Using a settlement window where a "resolved" outcome is provisional and can be reversed by later events. | | Exactly-once charge effects | Calling a payment API directly from an event consumer, risking dual-writes. | Using a two-phase commit: settle the outcome first, then have a separate transactional process create the immutable charge. | For idempotency, it is vital that event ingestion is a fast, fire-and-forget process. Acknowledge the event in single-digit milliseconds and handle the evaluation asynchronously. This ensures your billing system never adds latency to your agent's critical path. ## Why the Settlement Window Is Crucial [#why-the-settlement-window-is-crucial] The settlement window is the core mechanism that makes outcome-based billing fair and trustworthy. It addresses the reality that an outcome that appears complete can be reversed by subsequent events. A customer might reopen a "resolved" support ticket or cancel a booked appointment. The lifecycle of a billable outcome should therefore be a multi-stage process: 1. A billable condition is met. 2. The outcome's state changes to **"Resolved"**. This is a provisional status. 3. The resolved outcome sits in a configurable settlement window, which can last from minutes to days. 4. If no reversing events occur during this window, the outcome's state changes to **"Committed"**. Only then does it become an immutable charge. This built-in delay for corrections is not a bug. It is a feature that provides a clear and defensible process for handling disputes before they even happen. ## Auditability Is a Non-Negotiable Requirement [#auditability-is-a-non-negotiable-requirement] You must design your system for auditability from day one. It is not a feature you can add later. Sooner or later, a customer will ask, "Why was I charged for this?". If your system cannot provide a clear, event-level answer, it is fundamentally broken. Every single charge must be traceable back to the exact sequence of events that triggered it. This is how [transparent invoicing stops AI billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes) before they start. A well-designed system also enables replayability. This is the ability to run historical event data against new or modified billable conditions. This allows you to forecast the revenue impact of a pricing change before it ever touches a production environment. This is a powerful tool for de-risking business decisions. Because the system state updates with every event, you can power real-time features that build trust. Spend caps, in-product usage meters and customer-facing dashboards can all run off this live state. This avoids the confusion that arises when a customer sees stale data from a nightly batch job. ## The Build vs Buy Calculation [#the-build-vs-buy-calculation] Now for the honest math. Building a correct, scalable and auditable outcome resolution layer is a significant undertaking. A conservative estimate is **3-4 senior engineers working for 2-3 quarters** just to generate the first correct invoice. That does not include the permanent operational cost of an on-call rotation and capacity planning for what is now a mission-critical financial system. The hard parts are not the happy path. They are correctness under failure conditions and operational excellence. The decision you face is strategic: is billing infrastructure your company's core differentiator or is it a tax on your product roadmap? For those considering the build path, understanding the [deep engineering challenges of a resolution layer](/blog/how-we-built-witn-s-outcome-resolution-layer-for-low-latency-and-reliability) is key. For those evaluating external solutions, [a buyer's guide to outcome-based AI pricing](/blog/a-buyer-s-guide-to-outcome-based-ai-pricing) can offer a complementary perspective. Infrastructure like [witn](/) provides this resolution layer as a service: you define the outcome as a condition, send events and the charge settles when the condition holds through the settlement window. ## A Phased Rollout Strategy [#a-phased-rollout-strategy] You should never test your billing system with a real charge. A phased, low-risk rollout is the only responsible path to production. 1. **Instrument and shadow.** Start by instrumenting your agents to emit events. Collect this data in a shadow mode without any billing logic attached. 2. **Define and replay.** Define your billable conditions and replay your historical event data against them. This validates your logic and gives you a baseline revenue forecast. This is where you can [test your outcome pricing model before launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). 3. **Dry-run and reconcile.** Run the full system, including the settlement window, in a dry-run mode. Generate mock invoices and reconcile them against your expected numbers. 4. **Launch with a segment.** Go live with a single, trusted customer or a small, well-defined customer segment. 5. **Monitor and expand.** Closely monitor the system's accuracy and performance before expanding the rollout to your entire customer base. ## Your Billing System Is Your Promise [#your-billing-system-is-your-promise] Outcome-based pricing is ultimately a contract of trust between you and your customers. That contract is not written in a legal document. It is enforced in your code. Getting the engineering right is not just a technical requirement. It is how you deliver on your core product promise of fairness and value. # Defining Concrete Billable Outcomes for AI Agents (/blog/defining-concrete-billable-outcomes-for-ai-agents) ## Focus on Simple, Tangible Agent Achievements [#focus-on-simple-tangible-agent-achievements] The first mistake teams make when they define billable outcomes is aiming for something profound. They reach for metrics like revenue influenced or pipeline generated. Those metrics sound impressive and end in attribution debates. The best billable outcomes are usually boring. They are the small, repetitive chores the customer used to handle manually. An appointment gets booked. A creative asset gets generated. A support ticket gets resolved. That is the right level of focus. These outcomes are concrete, countable and happen hundreds of times a week, not once a quarter. Shift your mindset from abstract value narratives to demonstrable, completed work and your billing model becomes clearer for everyone. The goal is to find the smallest tangible unit of work your agent completes that still provides undeniable value. That unit is the foundation of a billing system your customers will understand and trust, because it maps directly to tasks they no longer do themselves. ## The Three Core Properties of a Defensible Outcome [#the-three-core-properties-of-a-defensible-outcome] A billable outcome is a verifiable unit of completed work that an AI agent gets paid for. Moving from that general idea to a specific metric needs a clear test. A strong billable outcome is not just valuable. It is defensible. It has three properties that remove ambiguity and prevent disputes later. A defensible outcome is: 1. **Observable.** You and your customer can both point to the event and agree it happened. No subjective interpretation. A confirmed entry in a shared calendar is observable. A change in a CRM status might not be. 2. **Repetitive.** The event happens often. When an outcome occurs hundreds of times, billing normalizes and no single charge carries much financial weight or scrutiny. Rare, high-value events invite detailed inspection. 3. **Hard to dispute.** The outcome should be self-evident. If you need a slide deck to explain why a charge is valid, it is a value narrative, not a billable outcome. Keep the complex stories for your sales deck and the simple facts for your invoices. This is why "appointment booked" works so much better than "pipeline created". To make it robust, the definition must include a time window. For example, an appointment only becomes billable if it is not cancelled within 24 hours. This small addition handles the edge cases and turns a billing assumption into a concrete rule. | Property | Weak outcome: "Lead qualified" | Strong outcome: "Demo meeting booked" | | --------------- | -------------------------------------------------------------- | ---------------------------------------------------- | | Observability | Relies on subjective CRM status changes | Verifiable via calendar invite and acceptance | | Repetition | Variable, depends on campaign success | Occurs consistently as part of the sales process | | Indisputability | Attribution debates are common. Was it marketing or the agent? | The meeting is on the calendar or it is not | | Time window | Undefined. A lead can be disqualified later | Billable if not cancelled 24 hours before start time | ## Moving Beyond Usage Metrics and Credit Systems [#moving-beyond-usage-metrics-and-credit-systems] Many AI agent builders default to familiar billing models. Usage-based pricing. Credit systems. Both are common and both often fail to capture the value an agent delivers. Charging per API call or token measures infrastructure consumption, not customer success. Your customer does not care about tokens. They care about the completed task. Credit systems are a step in the right direction, but they are still an abstraction. They add an accounting layer between the customer and the job they hired your agent to do. A customer buys credits to generate slide decks, but what they want is finished slide decks. The credit is a unit of exchange, not the value itself. Most credit-based products already have a tangible outcome hiding just beneath the surface. The work is to name that outcome and check whether it is solid enough to price directly. Is the agent's output observable, repetitive and hard to dispute? Often the answer is yes. Switching from selling credits to selling completed outcomes is mostly a question of confidence in your agent's reliability. It signals belief in the value you deliver, not just the resources you consume. ## A Simple Framework for Defining Your Billable Event [#a-simple-framework-for-defining-your-billable-event] Once you have a simple, tangible outcome, formalize it. This does not need a long document or a meeting. It fits in one sentence that becomes the specification for your entire billing system: **We charge when \_\_\_ happens and remains true for \_\_\_.** The first blank takes the smallest concrete event you can defend. "A support ticket is marked as resolved". "A draft email is sent". The second blank is the time window that absorbs cancellations and reversals. "24 hours". "The start of the scheduled meeting". In witn this window is the settlement window: the outcome stays provisional until the window passes, then it settles and becomes a charge. This sentence is not a marketing slogan. It is the requirement for the billing logic that follows. Filling in the blanks forces you to resolve ambiguity upfront. The result translates directly into a [billable condition](/docs/guides/billable-conditions): Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 ## Is Your Agent Ready for Outcome Billing? [#is-your-agent-ready-for-outcome-billing] Outcome billing has one hard prerequisite: your agent must be good at its job. You cannot confidently charge for an outcome the agent delivers inconsistently. Before you can bill for success, you must reliably produce it. Set a minimum performance threshold and hold yourself to it. As a benchmark, some practitioners suggest the agent should return at least 3x its cost to the customer before the model becomes viable, a threshold discussed in [this guide on pricing AI agents](https://www.mikedelacruz.com/outcome-based-pricing-ai). If your agent is not there yet, outcome billing is not off the table forever. Use usage-based pricing as a bridge. Charge for usage first, gather the performance data and build confidence internally and with your customers. Then tie revenue to performance once you can prove the value empirically. ## Implementing the Outcome as an Engineering Requirement [#implementing-the-outcome-as-an-engineering-requirement] A billable outcome is not just a business agreement. It is an engineering requirement and it deserves the same rigor as any other part of your product. Pricing as code. That means explicit success criteria, clear attribution rules and specific exclusions to prevent false positives. Every charge must trace back to a verifiable event logged in your system. This rigor is what builds long-term trust. It aligns with what Zendesk calls a [results-driven framework](https://www.zendesk.com/blog/ai/agentic-ai/outcome-based-pricing/): the value exchange is explicit and verifiable. When a customer sees exactly what they paid for and why, the invoice stops being a point of contention and becomes a confirmation of value delivered. We covered what that looks like on the invoice itself in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). witn is built for exactly this. Define the outcome as a condition. Send events as the agent works. The outcome settles into a charge when the condition holds through the settlement window. [Read the docs](/docs) to see how it works. # Moving Existing Customers to Outcome-Based Pricing (/blog/how-to-move-existing-customers-to-outcome-based-pricing) Most advice on outcome-based pricing assumes you are starting from zero. It imagines a world without existing customers, contracts or revenue streams. This is a fantasy. For any real business, the central challenge is not designing a new model but migrating a paying customer base from an old one. The work involves careful sequencing, clear communication and robust tooling. It is a process of managing change, not just implementing a new pricing page. This guide provides a practical playbook for the mechanics of this transition, helping you align price with value without breaking the trust you have already built. Migration pathways from subscription or usage pricing to outcome-based pricing, showing grandfathering, hybrid bridge, parallel shadow-billing and hard cutover approaches sequenced across new customers, renewals and expansions ## The Unspoken Challenge of Outcome Pricing [#the-unspoken-challenge-of-outcome-pricing] The real difficulty in an outcome based pricing migration is managing risk. You have existing customers who are accustomed to a certain billing model, whether it is per seat or per API call. Your finance team has revenue forecasts built on that predictable model. A sudden shift introduces uncertainty for everyone. The core task is to de-risk this transition for both your customers and your own business. This is more than a simple repricing exercise. It is a fundamental saas pricing migration that touches contracts, product and customer success. Get it wrong, and you risk revenue shocks, customer churn or billing disputes. Get it right, and you create a stickier, more defensible partnership where your success is directly tied to the value your customers receive. The rest of this article focuses on the practical steps to achieve this alignment. ## Why Greenfield Adoption is a Myth [#why-greenfield-adoption-is-a-myth] No successful company starts with a blank slate. If you have product-market fit, you have paying customers. Those customers represent both your success and your legacy constraints. A hard cutover to a new pricing model is rarely feasible because it ignores the relationships and expectations you have already established. The goal is to evolve your pricing to better reflect the value your AI agent delivers, especially as it becomes more efficient. This is critical because under older models, your own success can work against you. As we have explored before, an AI agent that resolves issues faster or uses fewer actions could [perversely shrink your revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue) on a usage-based plan. A careful migration is the only way to fix this misalignment without alienating the customers who helped you grow. This methodical approach is a key part of the broader ai agent monetization journey. ## Comparing Your Migration Pathways [#comparing-your-migration-pathways] There is no single correct path for a customer pricing model transition. The right strategy depends on your risk tolerance, operational capacity and customer relationships. Most companies will use a combination of approaches for different segments. The four primary pathways are Grandfathering, creating a Hybrid Bridge, running Parallel Shadow-Billing or executing a Hard Cutover. Understanding the trade-offs is the first step in building your migration plan. | Approach | Revenue Risk | Customer Trust | Operational Effort | Best For | | --------------------------- | --------------- | -------------- | ------------------ | ----------------------------------------------------------------------------------------------- | | **Grandfathering** | Low (initially) | High | Low | Highly sensitive legacy customers or when the old model is simple to maintain. | | **Hybrid Bridge** | Medium | Medium | Medium | Easing customers into variable pricing by combining a fixed fee with a small outcome component. | | **Parallel Shadow-Billing** | Low | High | High | De-risking the switch by validating the new model's financial impact before it goes live. | | **Hard Cutover** | High | Low | Low | New product lines or when the entire customer base is ready for a fundamental change. | ## Building a Bridge with Hybrid Models [#building-a-bridge-with-hybrid-models] A hybrid model is an effective tool for easing the transition. It combines the predictability of a fixed subscription fee with the value alignment of a variable outcome-based component. For example, you might charge a base platform fee that grants access to your AI agent, plus a small metered charge for each qualified sales lead it generates or each support ticket it successfully resolves. This approach acts as a bridge between two different worlds. The key is to start with a low variable component and ramp it up over time, perhaps at each contract renewal. This strategy makes the change feel like a gradual and logical evolution, not an abrupt shock. It gives customers time to see the fairness of the new model in action while giving your team experience with variable billing. This is a practical step when moving across the different [strategies for monetizing AI agents, from seats to outcomes](/blog/strategies-for-monetizing-ai-agents-from-seats-to-outcomes). ## De-Risking the Switch with Shadow Billing [#de-risking-the-switch-with-shadow-billing] The shadow billing strategy, or dual-metering, is the most powerful way to remove uncertainty from a pricing migration. It involves running the new outcome-based model silently in the background while you continue to bill customers on their existing plan. You are essentially generating two invoices for every customer each month: the real one they pay and a "shadow" one they never see. This is not just a back-of-the-napkin calculation. It is a full simulation using live production data. The primary benefit is concrete data. Before you have a single conversation about repricing, you know exactly how the new model will affect every customer's bill. This data builds internal confidence with your finance and leadership teams. It also transforms the future customer conversation from a negotiation into a data-backed discussion about fairness. This is precisely how you can [test your outcome pricing model before launch](/blog/how-to-test-your-outcome-pricing-model-before-launch), but on your live customer base. ## Sequencing Your Customer Rollout [#sequencing-your-customer-rollout] A phased rollout is almost always better than a big-bang migration. By sequencing the transition across different customer segments, you minimize risk and create valuable learning loops. This playbook provides a logical order for how to change pricing model cohorts to protect revenue and build momentum. 1. **Start with all new customers.** This is the simplest cohort. They have no legacy expectations and can be onboarded directly onto the new outcome-based model. This builds a future-proof revenue base. 2. **Target contract renewals next.** A renewal is a natural point to discuss pricing. You can frame the new model as a more modern, aligned way to partner for the next term, using performance data from their previous contract to make the case. 3. **Use expansions as a trigger.** When a customer wants to upgrade, add new agent capabilities or expand usage, introduce the new pricing for the incremental value. This links the new model directly to new benefits. 4. **Decide on a grandfathering policy for the rest.** For long-term customers on stable contracts, it may be best to leave them on the legacy plan indefinitely or for a generous period. This protects your most stable relationships from unnecessary disruption. ## Framing the Repricing Conversation [#framing-the-repricing-conversation] Communication is everything. The goal is to frame the pricing change as a positive step toward a better partnership, not a disguised price increase. You must proactively address the primary customer fear: "will my bill go up?". Using the data from your shadow billing period is essential here. You can show customers exactly what their costs would have been on the new model, demonstrating transparency. For some, the bill may be higher. For others, it may be lower. In all cases, it will be fairer. Anchor the entire conversation on the value they receive by referencing the [concrete billable outcomes](/blog/defining-concrete-billable-outcomes-for-ai-agents) you have defined. For an SDR agent, this means paying for qualified meetings booked, not for the number of emails sent. This makes the value tangible and the price justifiable. ## How witn Enables a Smooth Migration [#how-witn-enables-a-smooth-migration] Managing this transition is complex, but the right infrastructure makes it manageable. witn was built for this exact scenario. Our platform allows you to run an old usage or hybrid model alongside a new outcome-based model for the same customer, using your existing event streams to shadow-compute outcomes without a heavy engineering lift. This provides the data to validate your model, build trust with customers and prepare your finance team. When you and your customer are ready, you can seamlessly transition the contract by adjusting its fixed and variable components. This capability is a core part of the [complete guide to AI agent monetization](/blog/ai-agent-monetization-the-complete-guide), and you can see how this works in [our documentation](/docs). # How to Test Your Outcome Pricing Model Before Launch (/blog/how-to-test-your-outcome-pricing-model-before-launch) ## The Financial Uncertainty of Value-Based Pricing [#the-financial-uncertainty-of-value-based-pricing] The idea behind outcome-based pricing for AI agents is simple and powerful. You charge for the value delivered. Instead of billing for inputs like seats or minutes, you invoice for a resolved support ticket, a qualified sales lead or a completed booking. The model aligns your success directly with your customer's success. Yet this is often where finance teams hesitate. We can all picture the meeting where the revenue forecast chart has more question marks than numbers. A fixed subscription is predictable. Outcome-based invoices are not. That uncertainty is what stalls the transition. How do you build a budget when you do not know what the invoices will look like? The fear is valid. The answer is not to abandon the model. It is to find out what those invoices would look like before committing. That is what a pricing simulation does. It is not guesswork. It uses the historical data you already have to model the new pricing before a single contract changes. It turns a leap of faith into a calculated business decision. Overview of how to test an outcome pricing model before launch: testing methods including pilot programs, customer interviews, scenario-based simulations and data-driven feedback loops, plus key metrics to track such as customer willingness to pay, perceived value alignment and engagement quality ## Backtesting Your Model with Historical Data [#backtesting-your-model-with-historical-data] The first step is to look at the data you already collect. Most companies building AI agents already track the necessary signals. User actions, API calls, status changes logged in tools like Segment, PostHog or Rudderstack. The data required to model your new pricing is almost certainly there, waiting to be used. The process is to replay this historical event data through your proposed outcome definition. Think of it like running a film of last quarter's activity through a new lens. Take all support interactions from the last three months and apply a new rule: "charge per ticket that receives a customer satisfaction score of 4 or higher". Suddenly an abstract pricing idea becomes a concrete calculation. The goal of this first backtest is a tangible, line-by-line invoice showing exactly what each customer would have paid under the new model. That moves the conversation from theoretical benefits to a financial document your team can analyze. It answers the most important question first: based on past activity, what would this change have meant for our revenue and for our customers' costs? ## Refining What Counts as Value [#refining-what-counts-as-value] The first backtested invoice is only a starting point. The real work is iteration. Change one condition at a time, re-run the simulation and watch how the invoice moves. This is where you decide what counts as value and what does not. Two examples show how much a single condition matters: 1. **A booked appointment** seems straightforward. Refine it to only count if the appointment is not cancelled within 24 hours. Rerunning the simulation shows precisely how much revenue that one condition protects. 2. **A resolved support ticket** could be any closed ticket. But users open tickets by accident and never reply. A customer-aligned definition requires a genuine two-way exchange and excludes single inbound messages with no follow-up. That keeps every charge tied to real value. This iterative loop is where you set exclusion criteria and measurement windows that prevent charges for false positives. It is fundamental to customer trust. The SaaS CFO makes the same point in its guide on [building an outcome-based pricing plan](https://www.thesaascfo.com/how-to-build-outcome-based-pricing/): the plan stands on clearly defined, measurable outcomes. We covered how to pick that definition in [Defining Concrete Billable Outcomes for AI Agents](/blog/defining-concrete-billable-outcomes-for-ai-agents). Each refinement translates directly into a [billable condition](/docs/guides/billable-conditions). Explicit rules you can test, one leaf at a time: Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 ## Comparing Financial Impact for Business and Customers [#comparing-financial-impact-for-business-and-customers] With a refined model, the next step is a direct comparison. The simulation should produce a report that places the new outcome-priced invoice next to the invoice the customer actually paid under the old model. Aggregate these comparisons across your customer base and your finance team sees exactly how total revenue would have shifted last month or last quarter. Two scenarios will emerge. If the new model produces a higher bill for a customer, the simulation must also show the corresponding increase in value they received. If the model produces a revenue drop for your business, that needs to be identified and planned for long before launch. | Metric | Current model (per-seat) | Simulated model (outcome-based) | Implication | | --------------------------- | ------------------------ | ------------------------------- | ---------------------------------------------------------- | | Customer A invoice | $500 (10 seats) | $620 (310 resolutions) | Customer pays more but received 310 verified outcomes | | Customer B invoice | $250 (5 seats) | $210 (105 resolutions) | Customer pays less due to lower usage, improving alignment | | Total monthly revenue | $25,000 | $23,500 | A projected 6% revenue dip to address before launch | | Effective price per outcome | N/A | $2.00 | A clear, value-based unit cost | The data here is hypothetical, replayed from a sample customer base with the outcome defined as a resolved support ticket. The shape of the analysis is the point. Assumptions become numbers. ## Validating the Model with Trusted Customers [#validating-the-model-with-trusted-customers] After internal analysis, run the simulation with a small group of trusted customers. This is not a sales meeting. It is a learning session. Present their real historical usage and walk them through the simulated invoice they would have received under the new model. The goal is to listen. Pay attention to the moments where a customer hesitates, questions a charge or feels the logic is unfair. Does their definition of a "qualified lead" match yours? Is the bill harder to predict than they expected? Every objection raised in this controlled setting is a billing dispute defused before it ever reaches a real invoice. Trust depends on every charge being explainable and tied to value the customer recognizes. We covered what that looks like on the invoice itself in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). When the numbers are this open, the transition becomes collaborative instead of unilateral. ## Future-Proofing Your Pricing Against Product Improvements [#future-proofing-your-pricing-against-product-improvements] Many input-based pricing models contain a hidden flaw: the efficiency trap. Consider a voice AI agent priced per minute. Your team ships an improvement that resolves calls 50% faster and revenue falls precisely because the product got better. You are penalized for innovation. We dug into this failure mode in [Why Your AI Product's Success Could Shrink Your Revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). Outcome pricing flips the dynamic. Bill per resolved call instead of per minute and revenue is protected. Getting faster improves your margins instead of compressing your revenue. Your simulation should test this directly, not just look backward: 1. **Establish a baseline.** Simulate revenue with your product's current performance. 2. **Create a future scenario.** Model a significant improvement, like your agent becoming twice as efficient at its core task. 3. **Run the simulation again.** Compare revenue and margins under the old input-based model and the new outcome-based model. Simulation is not just a launch tool. It is how you check that the model stays financially sound as your product improves. witn is billing infrastructure built for the model you just validated. Define the outcome as a condition. Send events as the agent works. The charge settles when the condition holds through the settlement window. [Read the docs](/docs) to see how it works. # How Transparent Invoicing Stops AI Billing Disputes (/blog/how-transparent-invoicing-stops-ai-billing-disputes) ## The Operational Cost of Vague AI Bills [#the-operational-cost-of-vague-ai-bills] For companies building with AI, billing disputes are more than a nuisance. They are a recurring operational tax. A monthly seat license is predictable. The value an AI agent delivers is not. It changes with every task. That makes a bare invoice line item feel abstract, disconnected from what the customer experienced inside the product. When a customer sees a charge that does not match the value they perceived, their confusion is justified. They are right to be angry. The customer does not care which internal system is technically correct. They care that the bill does not match the version of reality they were shown. Every one of these disputes costs you. Support investigates. Engineering digs through logs. Finance issues credits to keep the relationship. The most effective way to reduce billing disputes is to prevent them. Build the explanation into the invoice itself. ## Where Context Is Lost Between Action and Invoice [#where-context-is-lost-between-action-and-invoice] The path from a billable AI action to an invoice line item is where things go wrong. It works like a game of telephone. The context of the outcome gets lost at each handoff between product, operations and finance. The fastest way to manufacture a dispute is to let each team decide for itself what "done" means. Product counts a task as complete when the agent finishes. Operations counts it when the customer accepts it. Finance counts whatever lands in the usage export. Without [one shared definition](/blog/defining-concrete-billable-outcomes-for-ai-agents), inconsistencies are guaranteed. The deeper problem is timing. The context of an outcome usually disappears long before it reaches the billing system. When a customer questions an invoice, the teams downstream of billing cannot answer on their own. They escalate to product. One disputed line item becomes a multi-team investigation. Run that process every day and the margin you thought you had quietly leaks out as support cost. The profitability of outcome-based billing depends on closing this gap. ## A Resolution Ledger as the Single Source of Truth [#a-resolution-ledger-as-the-single-source-of-truth] The fix is to treat the outcome ledger as a core part of your billing infrastructure. Not an internal log. A customer-visible, verifiable record that everyone references. Customers, support, RevOps and product all read the same data. There are no conflicting versions of reality left to argue about. A resolution ledger records every billable outcome. It holds three things: the outcome that was resolved, the evidence that confirmed it and how it was classified for billing. Make this ledger the definitive record and the invoice changes character. It stops being a demand for payment. It becomes a defensible statement of value delivered. The test is simple. A question about the bill should be answerable from the line item itself. That works when the record the customer sees is the same record the billing system charged from. There is nothing left to reconcile after the fact. ## The Anatomy of a Self-Explanatory Line Item [#the-anatomy-of-a-self-explanatory-line-item] A dispute-proof invoice answers questions before they are asked. This is what transparent invoicing means in practice. Every charge carries its own explanation. Take a voice AI agent that books appointments over the phone. When a customer opens a line item, they should see a complete story with three parts: 1. **The triggering event.** The specific action that started the charge. An API call, a user action or a system process. For example, "Voice agent completed booking call #C-2847". 2. **The billable condition.** The explicit rule that made the event billable, as defined in the customer's contract. For example, "Appointment confirmed on the calendar and not cancelled within the settlement window". 3. **The settlement moment.** The exact timestamp when the outcome became final and turned into a charge. This gives you an unambiguous audit trail of when value was delivered and recorded. This is what a [billable condition](/docs/guides/billable-conditions) looks like when it is defined explicitly. Every rule is visible and every rule is checkable: Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 With this in place, support resolves inquiries on the spot. Nothing escalates to engineering. The difference is stark: | Component | Vague line item | Transparent line item | | ------------------ | --------------- | --------------------------------------------------------------------------------------- | | Description | AI Usage - Unit | Appointment booked by voice agent | | Triggering event | Not specified | Voice agent completed booking call #C-2847 with +1 555 013 2277 | | Billable condition | Not specified | Outcome met the `appointment_booked` condition: booking confirmed, no cancellation seen | | Settlement moment | Not specified | Settled and charged on 2026-10-26 at 15:30:05 UTC | Context turns an ambiguous charge into a verifiable record of value delivered. ## Architectural Principles for Deterministic Billing [#architectural-principles-for-deterministic-billing] Delivering this transparency reliably takes deliberate architecture. Two properties are non-negotiable in any billing pipeline: determinism and idempotency. They prevent double counting and missed events. Keep billable metadata separate from general operational logs. Give every event a unique ID so each invoice line item traces back to its source. That is your auditable path from action to charge. A sidecar pattern makes this practical. Emit billing events from your application and classify outcomes asynchronously, off the hot path. Your core product stays fast and free of billing logic. Stripe makes a similar point in [its guide on usage-based billing](https://stripe.com/resources/more/ai-companies-and-usage-based-billing): usage-based models are complex, which is exactly why billing best practices matter. A well-designed system also handles the ugly cases gracefully. Late-arriving events. Outcomes that need a human review. A settlement window absorbs both without breaking accuracy. ## Pricing Agility Without Chaos [#pricing-agility-without-chaos] A common worry is that a centralized billing system slows down pricing iteration. The opposite is true. When you monetize AI agents, outcome definitions change constantly. Custom contracts, pricing experiments, new features. That agility is a competitive advantage and it needs a safe place to live. The wrong answer is letting every team invent its own billing logic. That path ends in technical debt and inconsistent customer experiences. The right answer is centralizing the ability to change. Keep outcome definitions in one place. Teams reprice and redefine quickly. There is still only one version of the truth. You get per-customer pricing without forking your core billing logic. [Rate cards](/docs/guides/rate-cards) make this concrete. Each customer gets a card that maps agents to prices, so the same outcome can carry different prices for different customers: Rate card editor showing agent-to-price entries witn is billing infrastructure built on exactly these ideas. Define what a successful outcome looks like. Send signals as events. Charges settle automatically when outcomes are verified. [Read the docs](/docs) to see how it works. # Why Per-Minute Billing Is a Trap for Voice AI (/blog/how-voice-ai-companies-price-today-and-why-per-minute-billing-is-a-trap) Voice AI has delivered a genuine breakthrough for countless industries, making 24/7 multilingual phone support and outbound campaigns at scale a practical reality. This technological leap has unlocked immense value. Yet the way most companies charge for it is fundamentally broken, creating a trap that punishes innovation. Comparison of usage pricing and outcome pricing incentive loops. With usage pricing the product improves, fewer minutes are metered and revenue falls, a vicious cycle where the vendor loses when the product works. With outcome pricing the product improves, more outcomes are captured in fewer minutes and margin grows, a virtuous cycle where the vendor wins when the product works. ## The Genuine Breakthrough of Voice AI [#the-genuine-breakthrough-of-voice-ai] Before we examine the pricing dilemma, it is important to acknowledge what a significant achievement voice AI represents. It is not an incremental improvement. It is a technology that has made entirely new operational models possible for businesses. For the first time, companies can offer true 24/7 phone coverage without the complexities of overnight staffing. They can provide instant, scalable support in dozens of languages, a feat that was previously prohibitively expensive and logistically impossible for all but the largest global enterprises. This technology also dramatically improves accessibility, offering a vital channel for users who cannot or prefer not to type. From handling routine customer inquiries to running outbound sales campaigns at scale, voice AI has solved real, tangible problems. It has created enormous value for both businesses and their customers. The core issue is that current voice AI pricing models fail to reflect this value accurately. ## The Misalignment of Flat-Fee Licensing [#the-misalignment-of-flat-fee-licensing] A common starting point for pricing is the flat-fee license. Its appeal is its simplicity. A customer pays a fixed price for access to the platform for a set period. While predictable, this model is completely disconnected from the value the AI agent delivers. This creates a two-sided problem. A buyer with low call volume inevitably overpays, spending money on capacity they do not use. Conversely, a vendor with a high-usage customer is guaranteed to be underpaid, as their revenue is capped regardless of how much work their agent performs. The vendor's upside is severed from their customer's success. This value disconnect makes renewal conversations notoriously difficult. The vendor cannot point to specific outcomes to justify the fee and the buyer feels the price is arbitrary. The discussion becomes adversarial, centered on discounting the cost rather than celebrating the value created. It is a pricing structure that puts both parties on opposing sides of the table from day one. ## The Self-Defeating Logic of Per-Minute Billing [#the-self-defeating-logic-of-per-minute-billing] The most dominant model today is per-minute metering. On the surface, it seems like a fair, usage-based approach. The customer pays for what they use. The fatal flaw, however, is that it meters the wrong thing. It measures cost, not value. This creates a series of per-minute billing problems that actively undermine product improvement. Consider this scenario. Your engineering team works for months to improve your voice agent. They fine-tune the dialogue design, reduce system latency and deploy a faster language model. As a result, the average call resolution time drops from six minutes to three. You have just made your product twice as good for your customer. You have also just cut your revenue in half. This is the per-minute trap. Your product roadmap and your revenue goals are pulling in opposite directions. Every successful engineering sprint that makes your agent more efficient directly shrinks your top line. You are financially penalized for innovation. We covered this dynamic in depth in [Why Your AI Product's Success Could Shrink Your Revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). This problem is compounded by what can be called "revenue leakage". The underlying costs of AI, such as LLM inference and text-to-speech services, are constantly falling. This puts continuous downward pressure on per-minute rates across the industry. As an analysis from TCHB [highlights](https://tchbytes.substack.com/p/the-ai-agent-pricing-map-seven-models), this model essentially punishes vendors for their own engineering progress. Your revenue erodes even if your call volume remains steady, forcing you to run faster just to stand still. ## An Overview of Current Pricing Alternatives [#an-overview-of-current-pricing-alternatives] Recognizing these flaws, some companies have experimented with other models. However, most are simply variations on the same theme and carry their own trade-offs. They represent compromises, not solutions. Per-conversation flat rates offer predictability but fail to account for call complexity. A simple password reset is billed the same as a complex troubleshooting session, meaning price and value remain disconnected. Concurrency-based pricing, where customers pay for a set number of simultaneous lines, meters capacity instead of results. This is inefficient for businesses with fluctuating demand, forcing them to pay for idle capacity during off-peak hours. Hybrid models that combine a platform fee with usage charges attempt to find a middle ground. Yet they often inherit the weaknesses of both approaches, especially when the usage component is still metered per minute. The fundamental misalignment between efficiency and revenue persists. The table below summarizes how these common pricing models stack up when it comes to aligning vendor incentives with customer value. | Pricing Model | Incentive Alignment | Buyer Predictability | Value Capture | | ------------------- | --------------------------------- | --------------------------------- | ----------------------------- | | Flat-Fee License | Poor (Disconnected from value) | High (Fixed cost) | Poor (Caps vendor upside) | | Per-Minute Metering | Negative (Penalizes efficiency) | Low (Cost varies with duration) | Poor (Meters cost, not value) | | Concurrency-Based | Poor (Prices capacity, not usage) | Medium (Fixed for capacity) | Poor (Unrelated to results) | | Outcome-Based | High (Tied to business results) | Medium (Cost varies with success) | High (Directly maps to value) | ## The Customer Support Precedent for Outcome Pricing [#the-customer-support-precedent-for-outcome-pricing] The path forward for voice AI is not theoretical. It has already been paved by an adjacent industry: customer support software. For years, support tools were sold based on agent seats or ticket volume. This created familiar misalignments. Vendors were incentivized to encourage more seats or tickets, not better or faster resolutions. The market eventually shifted to outcome-based pricing, specifically "per-resolution" models. Buyers embraced this change because it mapped the price directly to the one thing they cared about: a solved customer problem. The incentive for the vendor became to resolve issues as efficiently as possible, perfectly aligning their success with their customer's goals. Voice AI sits right next to this market, often handling the very same support interactions. The migration path is clear. The future of voice AI pricing is charging for successful business outcomes. This model can be applied across every major use case: * **Support:** Charge per successfully resolved call. * **Sales:** Charge per qualified lead or booked meeting. * **Scheduling:** Charge per confirmed appointment. * **Collections:** Charge per completed payment. This is the only model where the vendor and the customer both win when the product gets better. ## The Operational Shift to Outcome-Based Billing [#the-operational-shift-to-outcome-based-billing] If outcome-based pricing is the obvious solution, why has it not been widely adopted? The answer is that it is operationally much harder than running a simple minutes meter. Making this shift requires real billing infrastructure, not a counter. Successfully implementing this model requires several key capabilities: 1. **Defining the outcome.** You need a precise, machine-readable definition of what constitutes a "booked appointment" or "resolved issue". Our guide on [billable conditions](/docs/guides/billable-conditions) shows how to express these definitions. 2. **Verifying the outcome.** This definition must be verifiable through event data from other systems, like a CRM update or a calendar API call, not subjective interpretation. 3. **Handling complexity.** The system must manage reversals and settlement windows. What happens if a booked appointment is cancelled a day later? We explored this in [Pricing AI Outcomes as Risk Contracts](/blog/pricing-ai-outcomes-as-risk-contracts). 4. **Ensuring auditability.** The buyer needs a clear, auditable trail that connects every single charge on their invoice back to the specific outcome that generated it. [Transparent invoicing](/blog/how-transparent-invoicing-stops-ai-billing-disputes) is what makes outcome pricing defensible. These requirements are not trivial, but they are essential for building a monetization strategy that scales with customer value. ## Align Revenue With Product Improvement [#align-revenue-with-product-improvement] Moving from per-minute metering to outcome-based billing aligns your revenue model with your product innovation. It ensures that as you make your voice agent better, faster and more efficient, your business grows alongside your customers' success. witn is billing infrastructure built for exactly this. Define the outcome as a condition. Send events as the agent works. The charge settles when the condition holds through the settlement window and every invoice line traces back to the calls that earned it. [Read the docs](/docs) to see how it works. # Building witn's Low-Latency Outcome Resolution Layer (/blog/how-we-built-witn-s-outcome-resolution-layer-for-low-latency-and-reliability) ## The Core Conflict in AI Agent Billing [#the-core-conflict-in-ai-agent-billing] Billing for AI agents presents a unique engineering challenge. Unlike traditional SaaS where value is tied to a predictable seat license, an agent's value is generated through a non-deterministic series of actions and outcomes. This creates a fundamental conflict for the underlying infrastructure. The system must provide the strict, auditable correctness that billing demands. It must also deliver the high throughput and low latency that real-time agent interactions require. These two goals pull in opposite directions. We built our outcome resolution layer to solve this conflict. This layer sits between an agent's raw event stream and the final invoice, interpreting complex event sequences to determine billable value. We made the case for why this layer exists in [The Missing Layer in AI Agent Monetization](/blog/the-missing-layer-in-ai-agent-monetization). This post is about how we engineered it. A simple approach, like a cron job that periodically scans a database, is guaranteed to fail. We knew from first principles that such a design collapses under real-world conditions. Its failure points are immediate and severe. * It cannot handle out-of-order or late-arriving events common in distributed systems. * It offers no clear path for handling reversals or cancellations during a settlement window. * It lacks a verifiable audit trail, making it impossible to defend a charge to a customer. * It does not scale to handle bursty, high-volume event streams from thousands of concurrent agents. This problem's gravity makes a serious infrastructure investment unavoidable. There are no shortcuts to correctness when revenue is on the line. ## Solving for Sub-10ms Ingestion Latency [#solving-for-sub-10ms-ingestion-latency] The first requirement for our system was clear. Billing infrastructure must never become a performance bottleneck for the AI agents it serves. This meant accepting and acknowledging events in single-digit milliseconds. From the agent's perspective, sending a billing event had to be a fire-and-forget operation. To achieve this, we completely decoupled event ingestion from processing. We chose Redpanda as our streaming backbone. When an event arrives at our API, we perform minimal validation, assign a deterministic ID and write it to a durable, ordered log. We then immediately return a success acknowledgment to the client. This keeps the agent's hot path clean and fast. All computationally expensive work, such as database writes, state evaluation and counter updates, happens asynchronously downstream. Idempotency is critical in any distributed billing system. Network clients will inevitably retry requests. To prevent a single agent action from being billed multiple times, every event must be uniquely identifiable. Clients can supply an idempotency key for each event. Our ingestion pipeline derives a deterministic event ID from it and deduplicates any retried events, ensuring each action is processed only once. Building this front door is a significant undertaking. Choosing, deploying, tuning and operating a high-throughput streaming platform requires specialized expertise. It represents the first major engineering investment where a simple in-house solution breaks down. This is not a weekend project. It is a core piece of production infrastructure that demands constant monitoring and operational readiness. ## Managing Stateful Evaluation at Scale [#managing-stateful-evaluation-at-scale] After an event is safely ingested, the real work begins. The core of our resolution layer is a stateful stream processing engine. Each potential billable outcome, for every customer, for every agent, is its own state machine. These are not simple counters. They are evaluators that process AND/OR condition trees, time windows and event properties to determine if a [billable condition](/docs/guides/billable-conditions) has been met: Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 At any given moment, we are managing millions of these state machines concurrently. Running this evaluation against a traditional transactional database would create an immediate performance bottleneck. Instead, we keep most of this computation in RAM. Each worker evaluates conditions and updates counters directly in process memory. We use Dragonfly for the parts of that state that must be shared across workers, such as outcome versions and settlement timers. This design allows for microsecond-latency updates and condition checks. When an event is consumed from the log, a worker loads the relevant outcome's state, evaluates the new event against its conditions and updates the state, all without touching a disk. We ensure data consistency in this high-velocity environment using optimistic concurrency control. Every state update uses a compare-and-swap operation on a state version number. This prevents race conditions between concurrent event processors without the overhead of expensive distributed locks. Our system is also designed to correctly handle late or out-of-order events. It re-evaluates an outcome's state based on immutable event timestamps, not the order in which events arrived in our system. The operational burden here is immense. Managing millions of in-memory state machines and their associated settlement timers is a classic, hard distributed systems problem. This is not a feature you enable with a library. It is a core competency that took our team quarters to build correctly and now requires a permanent on-call rotation to maintain service levels. This is where the theoretical cost of building in-house becomes a real, ongoing operational expense. ## Guaranteeing Exactly-Once Billing Effects [#guaranteeing-exactly-once-billing-effects] The most unforgiving requirement in any billing system is correctness. Specifically, this means guaranteeing exactly-once effects for any action that generates a charge. At-least-once delivery is a relatively solved problem in distributed systems. The truly difficult part is ensuring a resolved outcome generates a charge exactly one time, even in the face of worker crashes, message redeliveries or downstream API failures. Our solution is a multi-stage resolution process. An outcome that meets its billable conditions does not immediately become a charge. It first enters a "resolved" state within our system. It then sits in a configurable settlement window, which can be minutes or days long. During this period, the outcome can still be reversed by subsequent events, such as a user cancellation or a support-initiated credit. Only after this window closes without a reversal is the outcome committed as a permanent, immutable charge. Our stack is purpose-built for this workflow. While the hot, mutable state of an outcome lives in worker memory, with shared coordination state in Dragonfly, we use PostgreSQL as the final, transactional source of truth for all settled outcomes and charges. We leverage its ACID guarantees to ensure that the creation of a charge is an atomic, idempotent operation. This two-phase process prevents partial or duplicate charges entirely. This design avoids a common and critical failure mode. A naive system might call a payment processor's API directly from an event consumer. If the consumer crashes after the API call but before committing its stream offset, it will double-charge upon restart. This dual-write problem is well documented, for example in [this walkthrough of the transactional outbox pattern](https://dev.to/ovaiseq/building-reliable-agents-with-the-transactional-outbox-pattern-and-redis-streams-5c80). Our settlement layer and transactional commit process eliminate this entire class of errors. | Capability | Naive cron job approach | Purpose-built resolution layer | | ------------ | ------------------------------------------------ | ---------------------------------------------- | | Correctness | Prone to double-charging and missed events | Guarantees exactly-once effects via settlement | | Latency | High latency; batch-oriented | Single-digit millisecond event ingestion | | Scalability | Fails under bursty, high-volume load | Horizontally scalable to millions of outcomes | | Reversals | No native support; requires complex manual logic | Built-in settlement window for cancellations | | Auditability | Opaque; difficult to trace charges | Every charge is traceable to source events | ## Designing for Reliability and Auditability [#designing-for-reliability-and-auditability] The stakes in billing are absolute. Downtime is lost revenue. Data loss is a catastrophic breach of customer trust. We designed our system from the ground up with these realities in mind. We run a full multi-AZ deployment for every component in our stack, from the ingestion APIs to the final transactional database. The system is built to survive a zone failure without data loss or significant service interruption. Our durability and recovery strategy is anchored by the append-only event log in Redpanda. This log is the ultimate source of truth for every action an agent has ever taken. We continuously archive this log to Amazon S3 for long-term retention and disaster recovery. This architecture allows us to perform a point-in-time recovery, completely rebuilding the state of every outcome from scratch if necessary. All settled charges and contracts are transactionally secured in our multi-AZ PostgreSQL cluster. Auditability is a first-class design requirement, not an afterthought. A customer will inevitably ask, "Why was I charged for this?". The system must provide a definitive, verifiable answer. Our architecture links every single charge back to its settled outcome and from there to the exact sequence of events that triggered it. There is no ambiguity. We wrote about what that looks like on the invoice itself in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). We use ClickHouse to power this capability. Its ability to scan billions of events in milliseconds provides the fast query performance needed for the audit trail. This data also powers our simulation engine, which replays historical event streams against new or modified conditions and prices. Teams can accurately forecast the revenue impact of a pricing change before it ever touches a production customer, a process we covered in [How to Test Your Outcome Pricing Model Before Launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). Building this replay and audit capability is a massive project in itself, but it is essential for operating a billing system that earns and keeps customer trust. ## Infrastructure, Not a Project [#infrastructure-not-a-project] Building a correct, scalable and auditable outcome resolution layer is a multi-year infrastructure commitment. It requires three to four senior engineers working for over two quarters just to produce the first correct invoice, plus a permanent operational load for maintenance, on-call and capacity planning. This production system is what powers witn. Teams get the entire resolution layer as reliable infrastructure. Define the outcome as a condition. Send events as the agent works. The charge settles when the condition holds through the settlement window. [Read the docs](/docs) to see how it works. # Deloitte ASC 606 Guidance for Outcome-Based Pricing (/blog/implementing-the-deloitte-asc-606-guidance-for-outcome-based-ai-pricing) The arrival of formal guidance from a major accounting firm on outcome-based AI pricing signals that the model is now mainstream enough to have established rules. Translating the judgments in this guidance into auditable practice however reveals a significant gap that most existing billing systems were not designed to address. ## From theory to practice in AI revenue recognition [#from-theory-to-practice-in-ai-revenue-recognition] The release of [Deloitte's June 4, 2026 Technology Spotlight, "Accounting for Outcome-Based Pricing in an Agentic AI Software Product"](https://dart.deloitte.com/USDART/home/publications/deloitte/industry/technology/accounting-outcome-based-pricing-agentic-ai) provides a legitimate accounting framework for outcome-based pricing under ASC 606. For finance leaders, this document is a critical step forward. It offers a structured way to think about revenue recognition in a world where value is measured by results not seats. This article serves as a practical implementation guide. We will translate the accounting judgments in the Deloitte guidance into concrete system requirements. The core challenge is that most billing systems cannot produce the specific evidence this guidance assumes you have. This post is for informational purposes. You must finalize your revenue recognition policies with your own accountants and auditors. ## Know the nature of your promise [#know-the-nature-of-your-promise] A central judgment in the Deloitte guidance, discussed in its Q\&A 3, is determining the nature of your service promise. Are you providing a "stand-ready" obligation to make a service available over a term or are you promising a "specified quantity" of successful outcomes? The answer is set by your contract terms, but an auditor will want to see systemic evidence consistent with the promise you claim. The following table summarizes the indicators from Deloitte's Figure 3. | Indicator | Points to specified quantity | Points to stand-ready | | ---------------------- | ------------------------------------------------- | --------------------------------------------------- | | Volume limits | Contract specifies a fixed number of outcomes | Contract offers unlimited access | | Termination of service | Service ends upon reaching the specified volume | Service continues for the entire contract term | | Purchasing decision | Customer must make a new purchase to add volume | No new purchase is needed for continued use | | Rollover rights | Unused volume may be carried into a future period | Entitlement is time based and expires with the term | The evidence your system must produce depends on which promise you make. A stand-ready promise with per-outcome fees billed in arrears is evidenced by the outcome records themselves: the service was available all term and each fee traces to a confirmed outcome in a distinct period. A specified-quantity promise adds a second burden. You must also track a decrementing entitlement balance, block service at exhaustion and record the new purchase order that extends it. That is one reason many vendors structure contracts as stand-ready access with per-outcome fees, the pattern Deloitte's Examples 4, 7 and 8 analyze. It is the lighter promise to evidence and the simpler one to account for. **System requirement: your records must match your promise type. Stand-ready access with per-outcome fees needs complete outcome records. Fixed quantities also need entitlement tracking.** ## Translating contractual success into executable logic [#translating-contractual-success-into-executable-logic] Defining a successful outcome is the foundation of outcome-based billing. Deloitte's Q\&A 7, criterion (a) requires that the criteria for success be "clear, objective, and measurable". For auditable revenue recognition per successful outcome at scale, prose definitions in a contract are insufficient. They are open to interpretation and difficult to verify consistently across thousands or millions of transactions. This gap between legal language and operational reality creates significant audit risk. The system requirement is clear. Your billing platform must translate contractual language into machine-executable rules. For example, at witn, we define success using a condition tree that evaluates a stream of event data. This tree can apply operators like "event seen" or "count thresholds" to determine if a specific outcome has been achieved. This turns a subjective definition into a deterministic calculation. You can find more detail on how to determine [what counts as a resolution](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing) in practice. Immutability is just as important for auditability. The system must snapshot the exact contract conditions onto each outcome at the moment the outcome is created. This ensures that subsequent contract edits can never retroactively alter the basis for revenue that has already been recognized. The system must prove not just that an outcome was successful but that it was successful under the specific rules in effect when it was opened. **System requirement: your billing system must convert contractual success criteria into executable, machine-evaluated logic and snapshot the rules applied to every outcome.** ## Gating revenue recognition with a settlement period [#gating-revenue-recognition-with-a-settlement-period] Defining success is one part of the equation. Knowing when to recognize the revenue is another. The Deloitte guidance in Q\&A 7 introduces the concept of a reversal window, where an outcome is only considered final if it is "not reversed or challenged within a specified window". This directly impacts the timing of revenue recognition. Your billing infrastructure must enforce a formal settlement period to comply with this principle. This is not a manual process. The system must manage this automatically. In witn, an outcome that meets its initial success criteria stays in a provisional "OPEN" state. It only transitions to a "CONFIRMED" state after a configurable settlement window passes without any contrary events. If a new, relevant event occurs, such as a customer dispute or a data correction, the settlement window must reset. This system-enforced delay provides the auditable evidence needed to satisfy the ASC 606 constraint on variable consideration. It proves that a significant reversal is no longer probable. Our discussion on [revenue recognition for outcome-based AI billing](/blog/revenue-recognition-for-outcome-based-ai-billing) explores this policy choice further. **System requirement: your billing system must enforce a configurable settlement window that gates revenue recognition until an outcome is final.** ## Aligning invoicing with revenue recognition expedients [#aligning-invoicing-with-revenue-recognition-expedients] Your pricing structure has a direct impact on the complexity of your revenue recognition. The Deloitte guidance highlights two powerful simplifying tools: the "invoice practical expedient" (ASC 606-10-55-18) and the "variable consideration allocation exception" (ASC 606-10-32-40). As discussed in Q\&A 5 and Q\&A 6, these expedients are most accessible when you use straightforward pricing models. Deloitte's Examples 4, 7 and 8 all rely on a simple structure: a fixed rate per outcome, billed in arrears. This is not a coincidence. This model allows revenue to be recognized in the amount you have the right to invoice, avoiding complex estimations and allocations. The system requirement that emerges is that your billing system must be able to generate invoices where each line item corresponds to a single, confirmed outcome at a fixed price. This means only invoicing for outcomes that have passed their settlement window. The key insight here is that fixed per-outcome rates are not a limitation. They are a strategic choice that makes outcome-based pricing auditable and defensible. Your system must enforce this discipline by applying a simple rate card to confirmed outcomes, not to pending ones. **System requirement: your billing system must generate invoices from confirmed outcomes at a fixed rate per unit.** ## Building an immutable audit trail for every charge [#building-an-immutable-audit-trail-for-every-charge] Ultimately, your process will be tested during an audit. The auditor's core question for any invoiced charge will be simple: "Show me when the success criteria were met and when the settlement window closed". Answering this question requires more than a spreadsheet. It demands an append-only, immutable log of all events and system-driven status transitions. This is the foundation of an auditable billing system. This audit trail must contain several key components. First is an immutable history of all input events that influence an outcome. Second is a persisted record of the outcome's state transitions, for example from OPEN to CONFIRMED, with timestamps. Third is an archived record of the specific contract version and success criteria applied to that outcome. This is not about re-deriving state from logs after the fact. The system must persist the state of each outcome as it was determined. This provides irrefutable, point-in-time evidence that revenue was recognized correctly and in accordance with your stated policy. **System requirement: your billing system must maintain an immutable, append-only log of events, state transitions and applied contract rules for every outcome.** ## Issues handled outside the billing system [#issues-handled-outside-the-billing-system] It is also important to understand what your billing system is not responsible for. The Deloitte guidance addresses implementation services and customer data as noncash consideration in Q\&A 1 and Q\&A 2. These are primarily contract and legal questions, not billing system requirements. Your system does not determine if setup activities are a distinct performance obligation. The practical takeaway from the guidance, particularly Example 2, is that contractually limiting data rights to service delivery for a specific customer is a legal drafting issue, not a billing configuration. ## Pricing structures that complicate compliance [#pricing-structures-that-complicate-compliance] While simple pricing models are easier to manage, some businesses may choose more complex structures. The Deloitte guidance identifies several that require more careful handling. For instance, Example 6 shows how using cumulative success-rate tiers across periods can cause you to lose the variable consideration allocation exception. Similarly, Example 4, which uses a hybrid of a fixed fee plus outcomes, loses the invoice practical expedient. The message is clear: simpler, more direct pricing structures lead to simpler, more defensible revenue recognition. Complex models increase audit risk by requiring more extensive estimation and justification. ## A checklist for your billing infrastructure [#a-checklist-for-your-billing-infrastructure] To implement the Deloitte guidance effectively, your billing infrastructure must provide specific, auditable evidence. As you evaluate your systems, ensure they can meet these five core requirements. 1. **Promise evidence:** can the system show, for every charge, that it is consistent with the promise you made, whether stand-ready or specified quantity? 2. **Executable criteria:** can the system translate contractual success criteria into machine-evaluated logic? 3. **Settlement windows:** does the system gate revenue recognition with a configurable settlement period? 4. **Fixed-rate invoicing:** does the system support invoicing at a fixed rate per confirmed outcome? 5. **Immutable audit log:** does the system maintain an append-only log of events, state transitions and applied contract rules for every outcome? # Metronome Alternatives After the Stripe Acquisition (/blog/metronome-alternatives-after-the-stripe-acquisition) ## What the acquisition changes [#what-the-acquisition-changes] Stripe acquired Metronome in January 2026 for a reported figure around one billion dollars. For Metronome customers this is mostly good news. More resources, tighter Stripe integration, a long runway. It still changes the calculation. Teams that picked Metronome as a neutral metering layer now depend on Stripe's roadmap. Teams that use a different payment processor have a harder question to answer. And teams choosing billing infrastructure today are asking whether a usage meter is even the right primitive for an AI agent business. If your agent gets paid for results, metering activity is the wrong unit. [Your product improving should not shrink your revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). Full disclosure: we build [witn](/), so read our take with that in mind. ## 1. witn [#1-witn] witn is outcome-native billing infrastructure for AI agents. Instead of metering usage, you define a billable condition, send events as signals and witn verifies when an outcome is actually delivered. Confirmed outcomes become invoice line items priced by rate cards, with the full event trail attached to every charge. Pick witn if you are moving from usage pricing to outcome pricing. Metering tells you what your agent did. witn tells you what your agent achieved and bills for exactly that. See [how witn works](/docs/guides/how-witn-works). ## 2. Orb [#2-orb] Orb is the closest like-for-like replacement. Usage-based billing, revenue recognition, dunning and pricing simulation in one product, with customers like Vercel, Replit and Supabase. It stays payment-processor neutral, which matters more now. Pick Orb if you want Metronome-style metering plus finance workflows without the Stripe dependency. ## 3. Lago [#3-lago] Lago is open source usage-based billing you can self-host. No per-event pricing, no vendor roadmap risk, full data control. Pick Lago if neutrality is the whole point of leaving and you have the team to operate your own billing stack. ## 4. Paid.ai [#4-paidai] Paid.ai is a monetization platform built for AI agents. Pricing design, margin tracking and invoicing in a no-code dashboard, with credits, usage, outcome and hybrid models. Pick Paid.ai if you want a business team to own pricing end to end without engineering work. ## 5. Flexprice [#5-flexprice] Flexprice positions itself as a hybrid of real-time and invoice-based billing for AI companies. It is a younger product aimed squarely at agentic monetization. Pick Flexprice if you want an AI-focused metering layer and are comfortable with an earlier-stage vendor. ## How to choose [#how-to-choose] | You need | Best fit | | --------------------------------------- | --------- | | Outcome verification, not metering | witn | | Metronome-like scale, processor neutral | Orb | | Open source, self-hosted | Lago | | No-code monetization platform | Paid.ai | | Early-stage AI metering | Flexprice | One more thing before you migrate anywhere: decide what unit you actually sell. If the honest answer is outcomes, a better usage meter will not fix your billing. [Define the outcome first](/blog/defining-concrete-billable-outcomes-for-ai-agents), then pick the infrastructure that can verify it. # 5 Paid.ai Alternatives for AI Agent Billing in 2026 (/blog/paid-ai-alternatives-for-ai-agent-billing) ## Why teams look for alternatives [#why-teams-look-for-alternatives] Paid.ai popularized results-based billing for AI agents. It raised a large seed round in 2025 and built a strong brand around the idea that agents should be priced on outcomes, not seats. It is a good product. It is also a platform. You design pricing in a dashboard, track margins in a dashboard and send invoices from a dashboard. Not every team wants a platform. Some teams want infrastructure. They already have a product, a data pipeline and an invoicing flow. They need the missing piece: a reliable way to define what a billable outcome is, verify it happened and price it. Others need open source, enterprise-scale metering or agent-to-agent payments. Full disclosure: we build [witn](/), so we have a horse in this race. We will still be fair about where each option fits. ## 1. witn [#1-witn] witn is outcome-native billing infrastructure. You define a billable condition through the API, send events as your agent works and witn resolves those events into verified outcomes. Confirmed outcomes turn into invoice line items priced by rate cards. Every charge carries the full event trail that produced it, which is what [stops billing disputes before they start](/blog/how-transparent-invoicing-stops-ai-billing-disputes). Pick witn if you are an engineering team that wants outcome verification as an API primitive rather than a sales dashboard. Start with the [quickstart](/docs/quickstart) or read [how witn works](/docs/guides/how-witn-works). ## 2. Metronome [#2-metronome] Metronome is the heavyweight of usage metering. It processes billions of events daily and powers metered billing for some of the largest AI companies. Stripe acquired it in January 2026, so expect deep Stripe integration going forward. Pick Metronome if you bill on raw usage at very large scale and you are already committed to the Stripe ecosystem. It meters activity. It does not verify outcomes. ## 3. Orb [#3-orb] Orb calls itself the revenue design company. It combines usage-based billing with finance workflows: revenue recognition, dunning and pricing simulation. Customers include Vercel, Replit and Supabase. In 2026 it added support for agentic payments. Pick Orb if your finance team drives the billing roadmap and you want invoicing, rev rec and pricing experiments in one product. ## 4. Lago [#4-lago] Lago is open source billing. You self-host it, keep full control of your data and pay no per-event fees. It handles usage events, aggregation and invoice generation. Pick Lago if you have the infrastructure team to run it and open source is a requirement. Outcome logic stays your problem: Lago aggregates what you send, it does not decide what counts as delivered value. ## 5. Nevermined [#5-nevermined] Nevermined builds payment rails for the agent economy. Its focus is agent-to-agent transactions: one agent paying another for work, with instant settlement. Pick Nevermined if your agents transact with other agents. It solves a different problem than invoicing your human customers. ## How to choose [#how-to-choose] | You need | Best fit | | ------------------------------ | ---------- | | Outcome verification as an API | witn | | Massive-scale usage metering | Metronome | | Billing plus finance workflows | Orb | | Open source, self-hosted | Lago | | Agent-to-agent payments | Nevermined | | No-code pricing dashboard | Paid.ai | The real question is not which platform is best. It is what layer you are missing. If you already know how to meter usage but cannot prove an outcome happened, metering tools will not help. That is the gap witn exists to fill. [Defining concrete billable outcomes](/blog/defining-concrete-billable-outcomes-for-ai-agents) is where to start. # Pricing AI Outcomes as Risk Contracts (/blog/pricing-ai-outcomes-as-risk-contracts) The conversation about pricing for AI agents often presents a simple choice. You can bill per seat or you can bill per outcome. This framing is common, but it is incorrect. It overlooks the most important component of any outcome based model which is risk. ## Beyond Binary Outcome Pricing [#beyond-binary-outcome-pricing] Viewing pricing as a binary switch between usage and outcomes is a mistake. This perspective fails to address the underlying economics of delivering a result. An outcome is not a single, fixed unit of value. **It is a package of risk** transferred from the customer to the vendor. When a vendor agrees to bill only for a successful result, they are insuring the customer against failure. They absorb the technical risk that the agent fails and the operational risk that the process breaks. This is the core of **outcome based pricing for AI**. However, many builders treat all successful outcomes the same, regardless of the conditions attached. They carry unpriced risk. A vendor who promises a result without pricing the risk of failure is in a dangerous position. They are accountable for factors outside their direct control. If the cost of that risk is not reflected in the price, the business model is unsustainable. The vendor can easily fail under the weight of guarantees they did not properly account for. ## Every Outcome Is a Risk Contract [#every-outcome-is-a-risk-contract] An outcome definition is a contract. It specifies the conditions under which value is recognized and billed. Each condition you add to that definition shifts responsibility from the buyer to the seller. These are effectively **risk based pricing contracts**. Consider an AI agent that books appointments. A simple outcome could be "appointment booked". The agent finds a time and creates a calendar entry. The customer pays a small fee for this action. But what if the person does not show up? In this simple model, the customer bears that risk. The vendor gets paid for booking the appointment, not for ensuring it happens. Now consider a more complex outcome: "appointment booked AND occurred". To verify this, the vendor must wait and check if the appointment actually took place. By adding this condition, the vendor now absorbs the no show risk. The customer is protected from paying for an appointment that yields no value. This transfer of risk must have a cost. **More vendor skin in the game should mean more upside**. We can add more conditions. What if the appointment occurred but the customer was not satisfied? An even stronger guarantee would be "appointment occurred AND the customer was satisfied". Now the vendor is also taking on quality risk. Each added condition moves more risk from the customer to the vendor. This risk transfer must be priced into the outcome. ## Building a Ladder of Offers [#building-a-ladder-of-offers] Instead of a single price point, this model creates a ladder of offers. Each rung on the ladder represents a different package of risk and a corresponding price. This approach gives customers a choice. They can decide how much risk they want to offload and how much they are willing to pay for that guarantee. Some customers may prefer a lower price and be willing to manage the risk of no shows themselves. Others will gladly pay a premium for a stronger guarantee that they only pay for appointments that happen and meet a quality standard. This turns pricing into a strategic tool. You are no longer selling a single product. You are selling different levels of certainty. This is one of the most direct **AI agent monetization models**. It aligns your revenue directly with the value you create and the risk you absorb. The table below shows how this works for our appointment booking agent. | Outcome Definition | Risk Holder | Example Price | | ------------------------------------------- | ----------- | ------------- | | Appointment booked | Customer | $1 | | Appointment booked AND occurred | Shared | $5 | | Appointment occurred AND verified satisfied | Vendor | $12 | The price of an outcome increases as the vendor absorbs more of the execution and quality risk from the customer. This ladder clarifies **how to price AI outcomes**. You are not just charging for an action. You are charging for the volatility you absorb on behalf of your customer. This transforms a simple pricing decision into a source of competitive advantage. ## A Practical Method for Structuring Tiers [#a-practical-method-for-structuring-tiers] You can build your own pricing ladder with a systematic approach. First, identify the weakest verifiable signal of success. This is often an event fired by your agent, like an API call that initiates a process. This is your base outcome, where the customer holds most of the risk. If you have not yet pinned down what counts as success, start with [defining concrete billable outcomes](/blog/defining-concrete-billable-outcomes-for-ai-agents). Second, add conditions one at a time to create stronger guarantees. You might listen for a confirmation event from another system. You could implement a time window to ensure an action is not cancelled. You could integrate a satisfaction score from a post interaction survey. Each condition creates a new rung on your ladder. Third, price each rung. The price increase should reflect two factors. The first is the probability that the extra condition fails. The second is an assessment of who controls that failure. If the customer is largely responsible for the next step, the price increase might be small. If the vendor is taking on significant operational uncertainty, the price increase should be substantial. ## Sell Certainty, Not Actions [#sell-certainty-not-actions] The next time someone asks if you charge per outcome, the honest answer is another question. Which outcome? "Appointment booked" and "appointment booked AND occurred" are different products with different risk profiles and they deserve different prices. Stop looking for the one right price. Build the ladder. Let each customer pick how much certainty they want to buy and make sure that every guarantee you take on is paid for. More skin in the game should mean more upside. That is not a slogan. It is the only way an outcome based business stays solvent. Just remember that a promise you cannot verify is a promise you cannot bill. Each rung on the ladder only works if you can prove its conditions were met. That verification layer is [the missing piece in most AI agent billing stacks](/blog/the-missing-layer-in-ai-agent-monetization) and it is exactly what [witn](/) is built for. # Revenue Recognition for Outcome-Based AI Billing (/blog/revenue-recognition-for-outcome-based-ai-billing) ## Why finance teams resist outcome-based pricing [#why-finance-teams-resist-outcome-based-pricing] Commercial teams love outcome-based pricing. It aligns price with value and removes friction from the sale. Finance teams often see it differently. Subscriptions offer predictable, ratably recognized revenue that makes for a smooth quarterly close. Outcome-based models can look like a source of chaos. The revenue feels variable and disputable. It often arrives late and is subject to reversals. This creates legitimate anxiety around the financial close and potential audit problems. The fear is that this pricing model will make the books messy just as the company prepares for a fundraise or its first major audit where clean ASC 606 treatment is non-negotiable. This article is for informational purposes and does not constitute accounting advice. Finalize your revenue recognition policy with your accountants and auditors. These concerns are valid but they are also manageable. The perceived messiness of outcome-based billing is not a fundamental flaw in the model. It is an operational challenge that can be solved with a clear framework and the right systems. The key is to shift your thinking from billing for agent activity to recognizing revenue based on verified value delivered. With a disciplined approach you can enjoy the commercial benefits of outcome pricing without compromising the integrity of your financial reporting. ## The five-step ASC 606 model applied to an AI agent outcome [#the-five-step-asc-606-model-applied-to-an-ai-agent-outcome] The framework for managing this process already exists. It is the five-step model for revenue recognition outlined in ASC 606 and its international equivalent IFRS 15. The principles are the same whether you sell software licenses or AI agent outcomes. The difference is in the application. As detailed in resources like the KPMG handbook on [revenue recognition](https://kpmg.com/us/en/frv/reference-library/2025/handbook-revenue-recognition.html), the model provides the structure you need. Let's walk through it with a running example: an AI support agent that charges the customer $1.00 per resolved ticket. 1. **Identify the contract with a customer.** This is the signed master services agreement or online terms of service that establishes the commercial relationship and payment terms. 2. **Identify the performance obligations.** This is the most critical step. The performance obligation is not the agent's conversation or the tokens it consumes. It is the specific valuable result you promised to deliver. In our example the obligation is a "verified resolution", not the agent's activity. You can find more guidance on defining these terms in our post on [What Counts as a Resolution? The Fine Print of Per Resolution Pricing](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing). 3. **Determine the transaction price.** This is the amount of consideration you expect to be entitled to in exchange for satisfying the performance obligation. For our agent it is $1.00 per verified resolution. 4. **Allocate the transaction price.** When a contract has a single performance obligation this step is simple. The entire transaction price of $1.00 is allocated to the single outcome of a verified resolution. 5. **Recognize revenue when the performance obligation is satisfied.** Revenue is recognized when control of the promised good or service is transferred to the customer. This brings us to the central question that the rest of this article will explore. When exactly is that performance obligation satisfied? ## The core question: when is the performance obligation satisfied? [#the-core-question-when-is-the-performance-obligation-satisfied] For an AI agent delivering an outcome, the moment of satisfaction is not always obvious. There are three candidate moments we could choose as the trigger for revenue recognition. Choosing the right one is essential for a defensible accounting policy. Timeline of three revenue recognition triggers for an AI agent outcome. Trigger 1 at usage and trigger 2 at the outcome event are rejected because value is unconfirmed and clawback risk remains. Trigger 3 after the seven day verification window is ASC 606 defensible. Below, the conservative policy recognizes $9,200 after day 7 while the reserve policy recognizes $10,000 minus an $800 reserve at day 0 First is the moment the agent acts. For our support agent this might be when it closes a ticket in the help desk. This is the earliest possible trigger but it is also the weakest. The agent's action does not guarantee the customer received the value they paid for. The user might immediately reopen the ticket because their issue was not actually solved. Recognizing revenue at this stage is premature because the value has not been confirmed. A second and better option is the moment an outcome event fires. This could be a `ticket_resolved` event sent from your system. This is an improvement because it represents a specific milestone. However it still may not reflect the full contractual reality. Your customer agreement likely includes a window for reversals or disputes. For example a ticket might be considered resolved only if it is not reopened within seven days. Before that window closes the value is not final. This leads to the third and most defensible trigger: the moment the outcome survives its verification window. Revenue for our $1.00 resolution is recognized only after the seven day period passes without a reopen. This is the correct approach because until that point the consideration is still variable and subject to reversal. Under ASC 606, revenue cannot be recognized until it is "probable" that a significant reversal will not occur. Aligning revenue recognition with the delivery of confirmed value is the foundation of a clean, defensible process. ## Variable consideration and the constraint [#variable-consideration-and-the-constraint] Reopened tickets, cancelled bookings and reverted work are all forms of variable consideration under ASC 606. The standard requires you to estimate the amount of revenue you will ultimately receive and it includes a "constraint". You can only recognize revenue to the extent that it is probable a significant reversal will not occur later. This leaves you with two accepted treatments. The first is the conservative policy. You recognize revenue only after the outcome is fully confirmed and no longer subject to reversal. In our example the agent produces 10,000 resolutions in a month. Your contract has a seven day verification window and historical data shows an 8 percent reopen rate. Under this policy you recognize each resolution as its window closes. Of the 10,000 resolutions, 8 percent reopen and never become billable. You recognize the remaining 9,200 for a total of $9,200, with resolutions from the last week of the month confirming in the following month. The second option is the reserve policy. You recognize revenue at the initial outcome event but you simultaneously book a reserve for expected reversals. Using our example you would recognize the full $10,000 in revenue when the 10,000 tickets are resolved. At the same time you would book an $800 liability, 8 percent of $10,000, as a reserve for future reversals. This requires a reliable estimate of your reversal rate, which you can refine by following a structured process. You can learn more in our guide on [How to Test Your Outcome Pricing Model Before Launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). Both methods are valid under ASC 606 and the equivalent IFRS 15 rules. They arrive at the same economic result over time. The choice depends on your company's operational maturity and risk tolerance. | Metric | Conservative policy | Reserve policy | | --------------------- | ------------------------------- | --------------------------------------------------- | | Timing of recognition | At verification window close | At initial outcome event | | Audit burden | Lower. Evidence is binary | Higher. Requires estimation and defense of the rate | | Revenue smoothness | Lumpier. Follows settlement lag | Smoother. Aligns with activity | ## Hybrid models: platform fee plus outcomes [#hybrid-models-platform-fee-plus-outcomes] Many AI agent companies use a hybrid pricing model that combines a recurring platform fee with per outcome charges. This structure is fully compatible with ASC 606 but it requires you to treat the components correctly. The platform fee and the outcome charges are typically considered two distinct performance obligations. The revenue recognition for each follows a different path. The platform fee is straightforward. It is recognized ratably over the subscription term just like a standard SaaS contract. A $12,000 annual platform fee would be recognized at $1,000 per month. The outcome charges are treated as variable consideration and must follow the policy you chose in the previous section, either the conservative or the reserve method. The key complication arises when you offer a bundled discount on the entire contract. If a customer gets a discount for signing up for both the platform and the outcomes, that discount must be allocated across both performance obligations. This means you must allocate a portion of the discount to the platform fee and a portion to the estimated outcomes you expect to deliver over the contract term. This requires careful modeling at the contract's inception to avoid complex reallocations down the line. ## What auditors will ask for [#what-auditors-will-ask-for] When it comes time for an audit, your auditors will not accept aggregate usage numbers as sufficient evidence for recognized revenue. They will need to see proof that each dollar corresponds to a specific, contractually defined and verified performance obligation. To prepare for this you must be ready to provide a detailed evidence trail for every single outcome you bill for. Auditors will demand specific per outcome evidence including: * An immutable event log showing the entire lifecycle of each outcome. * Precise timestamps for when the outcome was initially triggered and when its verification window officially closed. * A clear and demonstrable link from every single invoice line item back to its source events. This level of granularity is non-negotiable for a clean audit. It is the only way to prove that your outcome accounting is accurate and defensible. An auditor should be able to pick any line item on any invoice and trace it back to the raw event data that proves a performance obligation was satisfied. This granular evidence trail is also your best defense against billing disputes. You can read more about this in our guide on [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). ## Operational requirements this puts on your billing system [#operational-requirements-this-puts-on-your-billing-system] Supporting this rigorous accounting framework places specific demands on your billing infrastructure. A simple subscription billing system is not equipped to handle the complexities of outcome-based models. Your billing layer must be able to track each individual outcome through a distinct lifecycle from a provisional state to a confirmed or failed state. It needs to timestamp every state transition and maintain an append only event history that can serve as an audit log. witn is designed for exactly this purpose. It models this outcome lifecycle natively, holds each outcome in a provisional state through a configurable settlement window and then confirms or fails it automatically, creating a complete auditable event log behind every invoice line. This capability is the missing piece we describe in [The Missing Layer in AI Agent Monetization](/blog/the-missing-layer-in-ai-agent-monetization). ## A closing checklist for your accountant [#a-closing-checklist-for-your-accountant] Outcome-based pricing does not have to create accounting headaches. With the right framework and systems you can achieve clean, auditable revenue recognition. Here is a simple checklist to bring to your next meeting with your accountant or auditor to structure the conversation and establish a clear policy. 1. **Define the performance obligation as the verified outcome.** Be explicit that revenue is earned on a confirmed result, not on agent activity. 2. **Write the verification window into the contract.** Your customer agreements must clearly state the criteria and time period for an outcome to be considered final. 3. **Pick a recognition policy and apply it consistently.** Decide whether you will use the conservative policy or the reserve policy for variable consideration and stick with it. 4. **Keep per outcome evidence.** Ensure your billing system can provide the granular, auditable evidence trail that auditors will require for every single charge. 5. **Review reversal rates quarterly.** If you use a reserve policy, plan to regularly review and update your estimates for reversal rates based on the latest historical data. By following these steps you can build a robust process for revenue recognition that satisfies your auditors and allows your company to scale its pricing model with confidence. # Monetizing AI Agents: From Seats to Outcomes (/blog/strategies-for-monetizing-ai-agents-from-seats-to-outcomes) ## The Spectrum of AI Monetization [#the-spectrum-of-ai-monetization] While recent analysis shows that a vast majority of AI companies use some form of hybrid pricing, the real strategic decision lies in designing the variable component of that model. For founders and product leads with a working agent, the path to effective monetization is an evolutionary process. It is not a static choice made once at launch. The journey is about maturing from pricing based on your internal costs to pricing based on the tangible value your agent delivers to the customer. Choosing the right strategy is not about picking the most popular model. It is about an honest assessment of your agent's current capabilities and your business's operational readiness. The correct approach depends on two fundamental factors. First, how precisely can you define and verify the outcome your agent produces? Second, how much delivery risk is your company prepared to absorb as the agent learns and improves? Answering these questions provides a clear path toward aligning your price with your agent's impact. Overview of AI agent monetization strategies moving from seats to outcomes, listing seat-based, usage or API call-based, feature-based tiers and outcome-based pricing alongside key metrics to track: goal achievement rate, reduction in task time, quality of AI output and perceived business value alignment ## Seat and License Pricing for Human Augmentation [#seat-and-license-pricing-for-human-augmentation] The most familiar model is seat-based pricing, often framed as a direct replacement or augmentation of a full-time employee (FTE). You price the agent against the human it assists. This approach works exceptionally well for copilots, where the agent is tethered to a specific human user. Think of a sales copilot that helps an account executive draft emails or a developer assistant that suggests code within an IDE. The value is contained within that user's workflow, making a per-seat license a logical and easy-to-sell metric. However, this model's logic quickly unravels when applied to autonomous agents. When an agent works independently across an entire organization, handling tasks 24/7 without a dedicated human operator, the concept of a "seat" becomes arbitrary. It no longer maps to value. Charging per seat for an autonomous customer service agent that handles thousands of conversations is like charging a factory per lightbulb instead of per widget produced. The metric fails to scale with the agent's true contribution. ## Usage and Consumption Based Pricing [#usage-and-consumption-based-pricing] Consumption pricing is the bedrock of many developer-facing APIs, charging per token, API call or minute of processing time. Its primary strength is its transparency and simplicity. Customers can clearly see the link between their activity and their bill, which builds trust and is easy to meter. For businesses, it directly ties revenue to infrastructure costs, creating a straightforward financial model. This is often the default starting point for new agent platforms. The fundamental flaw, however, is that this model prices your cost, not your customer's value. It creates a difficult misalignment between your product goals and your revenue goals. As your team works to make the agent more efficient, perhaps using a smarter model that requires fewer tokens to achieve the same result, you directly shrink your revenue per task. You are financially penalized for improving your product. We unpacked this dynamic in [Why Your AI Product's Success Could Shrink Your Revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). This inherent conflict makes pure consumption pricing an unsustainable long-term strategy for value-driven agents. ## The Role of Credit Systems [#the-role-of-credit-systems] Credit systems introduce an abstraction layer over raw consumption. Customers pre-purchase a block of credits, which are then burned based on various actions the agent performs. This model is gaining significant traction. According to a field report from [Metronome](https://metronome.com/blog/2026-trends-from-cataloging-50-ai-pricing-models), roughly a third of software companies have adopted credits, with another third planning to. For enterprise buyers, credits simplify complex, multi-vector usage into a single, predictable currency. For vendors, they improve cash flow and revenue predictability through upfront payments. While the user experience feels friendlier than a running meter of costs, it is important to be honest about what credits often are. They are a cost-plus workaround with a better interface. The underlying issue of pricing cost instead of value can remain. This can also create a new kind of buyer anxiety. Customers often struggle to predict their credit burn rate, making it difficult to budget accurately and leading to fears of a surprise overage or wasted, expiring credits. ## Pricing Completed Workflows and Tasks [#pricing-completed-workflows-and-tasks] A significant step up the value ladder is charging per completed workflow. Instead of billing for the granular inputs like tokens or API calls, you charge a flat fee for a finished multi-step task. This could be "one processed invoice" or "one generated social media post". The price is fixed regardless of the underlying compute resources or time taken. This model represents a strategic middle ground for many agent builders. It moves the pricing conversation closer to the customer's business logic and away from your internal costs. It is more aligned with value than raw usage but crucially, it avoids the heavy operational burden of verifying a final business result. The primary limitation of this approach is that it confirms the agent did something, but not that the action produced the desired impact. It prices the activity, not the outcome. An agent can successfully "run a lead qualification workflow" on a junk lead and the customer is still charged. ## Outcome Based Pricing Models [#outcome-based-pricing-models] The highest form of value alignment is found in outcome-based pricing. Here, the customer is charged only when a predefined and verifiable business result is achieved. This is the destination for agents that can prove their impact. Concrete examples include charging only for a successfully resolved support ticket, a sales appointment that is actually booked and attended, a payment that clears or a lead that meets specific qualification criteria and is accepted by the sales team. Writing these definitions well is its own discipline, one we covered in [Defining Concrete Billable Outcomes for AI Agents](/blog/defining-concrete-billable-outcomes-for-ai-agents). This model creates the strongest possible partnership with your customer. You only win when they win. However, this alignment comes with significant operational complexity. It is the hardest model to operate correctly. It demands robust systems for defining outcomes in machine-readable terms, verifying those outcomes from event data, managing settlement windows for reversals or adjustments and producing auditable invoices that clearly explain every charge. This complexity is precisely why a dedicated [resolution layer](/blog/the-missing-layer-in-ai-agent-monetization) becomes necessary. ## Building Hybrid Pricing Structures [#building-hybrid-pricing-structures] Most mature companies land on hybrid billing models. These structures typically combine a fixed component, such as a monthly or annual platform fee, with a variable component based on usage, workflows or outcomes. The appeal is clear. The fixed fee provides the vendor with a predictable revenue floor to cover base costs, while the buyer gets predictability in their core expenses. It solves the cold start problem for both sides. But simply calling a model "hybrid" is not a strategy. The critical insight is that the strategic value of any hybrid model is determined by its variable component. That is where the opportunity for true value alignment is either won or lost. A platform fee plus a per-token charge is a fundamentally different business than a platform fee plus a charge per qualified lead. The question for founders is not "should we be hybrid?" but rather "what should our variable component be aligned to?". ## A Framework for Your Decision [#a-framework-for-your-decision] Choosing the right strategy for your agent today requires answering three direct questions about your product and business. Your answers will map you to the appropriate model. 1. **Outcome definition.** Can you define the desired business result with enough precision for a machine to check it? If the outcome is ambiguous, like "improved customer satisfaction", you cannot yet build a pricing model around it. 2. **Outcome verification.** Can you verify this outcome using event data from systems you or your customer control? If you cannot see the event that confirms a "booked meeting", you cannot bill for it. 3. **Risk absorption.** Can your business absorb the revenue volatility if the agent's performance is inconsistent or takes time to ramp up? Pure outcome pricing means you earn nothing if the agent fails, which can be a risky proposition for an early-stage company. Structuring tiers around this risk is the subject of [Pricing AI Outcomes as Risk Contracts](/blog/pricing-ai-outcomes-as-risk-contracts). If you cannot yet define or verify an outcome, you must start with usage or workflow pricing. If you can verify an outcome but have low risk tolerance, a hybrid model with an outcome component is a safer path. If you can verify outcomes and can handle the performance risk, pure outcome-based pricing offers the strongest alignment. | Strategy | Outcome Verifiability Required | Value Alignment | Revenue Predictability (Vendor) | | ----------------- | ------------------------------ | --------------- | ------------------------------- | | Seat/License | Low | Low | High | | Usage/Consumption | Low | Low | Medium | | Credits | Low | Low-Medium | Medium-High | | Workflow/Task | Medium | Medium | Medium | | Outcome-Based | High | High | Medium | | Hybrid | Varies | Varies | High | ## Creating a Path to Pricing Maturity [#creating-a-path-to-pricing-maturity] These strategies form a clear maturity path. Most agents will begin with simpler models like seat or usage-based pricing. As the product proves its reliability and you build trust with customers, you can evolve toward workflow and eventually outcome-based models. The key is to plan for this evolution from the beginning. The single most important piece of advice is this: instrument for outcome events from day one, even if you are only charging for usage. Track the business results your agent is producing long before you bill for them. Doing this transforms a future pricing migration from a massive engineering project into a simple configuration change. It also allows you to [backtest a new pricing model against historical data](/blog/how-to-test-your-outcome-pricing-model-before-launch) to forecast its revenue impact before you make the switch. This framework is one stage of a longer journey. For the full path from model choice through outcome definitions, risk tiers, testing and production billing, see [AI Agent Monetization: The Complete Guide](/blog/ai-agent-monetization-the-complete-guide). witn is billing infrastructure built for the outcome end of this spectrum. Define outcomes as conditions, verify them from events, handle settlement and reversals and get invoices where every line traces back to the result that earned it, while running usage or hybrid models alongside as you migrate. [Read the docs](/docs) to see how it works. # The Missing Layer in AI Agent Monetization (/blog/the-missing-layer-in-ai-agent-monetization) ## The Limits of Traditional Metering for AI Value [#the-limits-of-traditional-metering-for-ai-value] Metered billing has long been the standard for counting clear, discrete units of consumption. Platforms like Metronome excel at this. They track foundational costs such as API calls, data storage or GPU cycles. The model works when the value delivered is proportional to the resources used. For infrastructure, it is. You pay for what you consume. A fundamental disconnect appears when the same model is applied to intelligent systems. The value of an AI agent is not in the compute it consumes but in the outcomes it achieves. An API call is an input, a single step in a longer process. A qualified sales lead delivered to a CRM is a business outcome. Counting the actions an agent takes is like paying a salesperson for the number of calls they make instead of the deals they close. As agents become more autonomous, the gap between activity and achievement widens. Even the usage-based billing platforms see the shift. Metronome itself notes that [AI companies will demand new approaches from their billing partners](https://metronome.com/blog/ai-company-billing-demands), approaches that go beyond simple metering. Monetization has to evolve from counting activities to validating achievements. ## Why AI Agents Behave Like State Machines [#why-ai-agents-behave-like-state-machines] To see why metering falls short, think of an AI agent not as a transaction processor but as a state machine. A billable outcome is the final, successful state in a sequence of actions, conditions and time constraints. It is not a single isolated event. In chess the value is in reaching checkmate, not in the individual moves. Each move changes the state of the game. Only the winning state has worth. An agent's path to an outcome is stateful in the same way. The outcome resolves only when a specific combination of conditions holds: 1. **Product events.** A sequence of user actions, API responses or internal calls. 2. **External signals.** An update from a third-party system, like a CRM marking a lead as "qualified". 3. **Time windows.** A constraint that something must happen or must not happen within a period. A lead converting within seven days. A booking staying uncancelled for 24 hours. This stateful structure is what breaks standard billing systems, which are designed to ingest and rate predefined, stateless events. An agent tasked with booking a meeting might send an email, wait for a reply, parse the response for intent, check calendar availability and finally receive a confirmation. The billable event is the confirmed meeting, not the five preceding steps. Intercom's [Fin](https://www.intercom.com/fin) prices this way in production: customers pay per resolution, a state the conversation reaches, not per message the agent sends. ## The In-House Resolution Layer Dilemma [#the-in-house-resolution-layer-dilemma] Faced with billing systems that cannot express this logic, engineering teams reach for a common workaround. They build a custom resolution layer in-house. The internal system listens to a stream of product events, manages the state of every potential outcome for every customer and idempotently emits a single billable charge when all success criteria are met. It solves the immediate problem and it introduces a permanent engineering burden. Worse, it creates a black box. By the time a charge reaches the billing platform, the context of why it became billable has been stripped away. The invoice shows "1 Unit of Outcome X", a line item that is nearly impossible to explain, audit or dispute. We can all picture the support ticket that follows. A customer asks what they paid for and support has no answer, because the evidence lives in a separate, disconnected system. We covered the cost of that gap in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). The loss of context cascades. Billing feels opaque, so customer trust erodes. Support carries manual investigations. Finance struggles to reconcile and forecast revenue. The quick fix becomes long-term operational friction. | Aspect | Short-term benefit | Long-term cost | | ------------ | --------------------------------- | ------------------------------------------------ | | Control | Full ownership of the logic | High maintenance and engineering overhead | | Data context | Solves the immediate billing need | Context is lost before it reaches the invoice | | Scalability | Works for the first few use cases | Brittle as products and contracts evolve | | Flexibility | Custom-built for one need | Hard to adapt to new pricing models or customers | ## Embracing an Outcome-Native Billing Approach [#embracing-an-outcome-native-billing-approach] The in-house dilemma points to a more integrated answer: outcome-native billing infrastructure. Not another metering system. A purpose-built resolution layer designed for the stateful, multi-event nature of AI agents. It tracks the agent's state machine end to end, evaluates signals against contract terms and carries the full story into every invoice line item. The black box problem disappears because context is preserved from event to charge. The approach starts with an explicit definition of success. Each outcome gets a [billable condition](/docs/guides/billable-conditions), a rule the outcome must satisfy before it becomes a charge. We covered how to choose that definition in [Defining Concrete Billable Outcomes for AI Agents](/blog/defining-concrete-billable-outcomes-for-ai-agents). The condition is data, not code: Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 Because the definition is configuration, pricing stays agile. Changing "lead generated" to "lead converted" for an enterprise client is a configuration update, not a code deployment. [Rate cards](/docs/guides/rate-cards) give each customer their own agent-to-price mapping without forking the core billing logic. And because conditions are explicit, you can test them before launch by replaying historical events, a process we walked through in [How to Test Your Outcome Pricing Model Before Launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). ## Decoupling Agent Logic from Billing State [#decoupling-agent-logic-from-billing-state] For developers building these agents, one architectural principle matters most: decouple agent logic from billing state. A common mistake is to inject billing checks into the agent's core operational path. That adds latency and tangles product logic with monetization logic, making both harder to maintain. The agent's performance should never depend on checking whether an action is billable. The clean separation runs asynchronously. Each component in the stack has one role: 1. **The AI agent.** Executes the task and emits a stream of events describing its activity. 2. **The event stream.** Tools like Segment or PostHog capture and route the activity data. 3. **The outcome resolution layer.** Interprets the event stream against conditions and contract terms and resolves billable outcomes. 4. **The payment processor.** A system like Stripe handles the final, context-rich transaction. With this architecture, monetization never touches the agent's hot path. Events are fire-and-forget. The resolution layer does the stateful work off to the side and every charge still traces back to the events that caused it. The resolution layer is one piece of a larger monetization stack. We map the whole journey in [AI Agent Monetization: The Complete Guide](/blog/ai-agent-monetization-the-complete-guide). witn is this resolution layer. Define the outcome as a condition. Send events as the agent works. The charge settles when the condition holds through the settlement window, with the full story attached. [Read the docs](/docs) to see how it works. # What Counts as a Resolution? Per-Resolution Pricing (/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing) ## The Illusion of a Standard Price [#the-illusion-of-a-standard-price] Per-resolution pricing has become the accepted model for AI customer support agents. Fin charges [$0.99 per resolution](https://fin.ai/learn/ai-customer-service-agent-pricing-comparison). HubSpot's customer agent dropped to $0.50 per resolved conversation. Salesforce Agentforce charges $2.00 per conversation. These headline numbers look comparable, but they are not. The real price is hidden in the contractual fine print, specifically in how each vendor defines a "resolution". The same volume of customer interactions can produce invoices that differ by 30 to 50 percent. The definition is the price. ## Resolution Versus Conversation: The First Cost Variable [#resolution-versus-conversation-the-first-cost-variable] The most basic distinction in these contracts is between paying per conversation and paying per resolution. A per-conversation price charges for every interaction, regardless of whether the AI agent succeeded or failed. This means you pay for the failures. Consider an agent with a 60 percent resolution rate. If you have 100 conversations at $1.00 each, your bill is $100. You paid for 40 unresolved issues. A true per-resolution model, however, should only charge for success. For those same 100 conversations, you would pay only for the 60 successful outcomes. At $1.00 per resolution, your bill would be $60. This simple difference highlights the importance of understanding what a resolved conversation means according to your contract. Paying for failures dramatically increases your effective cost per successful outcome. ## Defining the Billable Trigger Event [#defining-the-billable-trigger-event] Moving beyond the basic conversation versus resolution model, the core of the issue is the trigger event. What specific action or condition officially marks a conversation as resolved and therefore billable? This trigger is the contractual definition of success and it varies significantly between vendors. Each variant shifts the financial risk. A strict definition protects the buyer, while a loose one favors the vendor. | Definition Variant | How It Works | Impact on Buyer | | ------------------------------ | ----------------------------------------------------------------------------- | -------------------------------------------------------------- | | Explicit Customer Confirmation | Billable only when the user clicks "Yes, this helped" or similar. | Lowest risk. Pays only for confirmed value. | | CSAT Threshold Met | Billable if the user gives a high satisfaction score, for example 4 out of 5. | Low risk. Aligns cost with positive user sentiment. | | No Human Handoff | Billable if the conversation ends without agent escalation. | Medium risk. Does not guarantee the problem was solved. | | Silence-as-Resolution | Billable if the user stops responding for a set time. | Highest risk. Pays for user abandonment and unresolved issues. | The "silence-as-resolution" definition is particularly problematic. It is the most vendor-friendly option and can easily count a customer who gives up in frustration as a success. This approach frequently leads to billing disputes and customer dissatisfaction. ## The Reopen Window: A Safety Net for Charges [#the-reopen-window-a-safety-net-for-charges] A resolution trigger should not be the final word on a charge. A well-structured contract includes a "reopen window" or settlement period, which functions as a crucial safety net. This means a charge for a resolution is held provisionally for a defined period, such as 24, 48 or 72 hours. If the customer re-engages about the same issue within that window, the original charge is automatically reversed. The issue was clearly not resolved. This mechanism corrects for prematurely triggered charges and ensures you only pay for lasting solutions. The length of this window is a key negotiation point. A short window offers weak protection, while its complete absence is a major red flag for any buyer. The settlement window is also where the vendor's risk lives, a dynamic we explored in [Pricing AI Outcomes as Risk Contracts](/blog/pricing-ai-outcomes-as-risk-contracts). ## Billing for Complex and Partial Resolutions [#billing-for-complex-and-partial-resolutions] Customer conversations are rarely neat, single-issue interactions. This complexity is where many billing models break down and create ambiguity. If a user asks three distinct questions in one chat, is that one billable resolution or three? What happens if the agent answers two questions correctly but fails on the third? Another common scenario involves partial resolutions, where an AI agent performs most of the work before a necessary human handoff. The contract must specify how these situations are priced. Undefined edge cases are a primary source of billing disputes and can erode the trust between a vendor and buyer. Clear rules for these complex scenarios are essential for accurate billing. ## The Critical Need for Verification and Audit [#the-critical-need-for-verification-and-audit] A precise definition of a resolution is meaningless if it cannot be verified. Both the vendor and the buyer need a transparent, auditable system to maintain a healthy business relationship. Every single charge on an invoice must be traceable to a clear audit trail of events. This trail should include conversation transcripts, timestamps for trigger events, records of human handoffs and logs of any reopen events. A charge that cannot be traced back to the events that justify it is an error waiting to be disputed. We covered how this audit trail works in practice in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). ## For Vendors: Engineer Your Pricing for Clarity [#for-vendors-engineer-your-pricing-for-clarity] For vendors building AI agents, the lesson is to treat your pricing definition like code. Define "resolution" with a set of machine-checkable rules, not an ambiguous paragraph of legal text. This precision eliminates confusion for both your team and your customers. Our guide on [defining concrete billable outcomes](/blog/defining-concrete-billable-outcomes-for-ai-agents) shows what these definitions look like. You should price that definition honestly. A stricter, more buyer-friendly definition delivers more guaranteed value and can support a higher per-unit price. A loose definition invites disputes that will erode your margins and damage your reputation. From day one, instrument your product to capture every confirmation, handoff and reopen event. This data is the foundation of trustworthy pricing and a scalable business. ## For Buyers: A Pre-Signature Checklist [#for-buyers-a-pre-signature-checklist] For buyers evaluating AI solutions, the headline price is only the beginning of the conversation. Before signing any contract, you must ask these critical questions to understand what you are actually buying: * What specific event triggers a billable resolution? * What reverses a charge and how long is the reopen window? * How are partial or multi-issue conversations billed? * Can I access the raw event logs that justify each line item on my invoice? Never compare per-unit prices without first comparing the definitions behind them. This is the only way to accurately forecast your cost and ensure you are paying for real value. ## Building Billing on a Foundation of Proof [#building-billing-on-a-foundation-of-proof] Sustainable partnerships in the AI industry are built on precision and auditable proof. The contract must align with the invoice and the invoice must align with the underlying events that prove value was delivered. witn is billing infrastructure built for exactly this. Express resolution definitions as conditions over events. Hold charges through settlement windows until reversals clear. Get invoices where every line traces back to its proof. [Read the docs](/docs) to see how it works. # Why Selling AI Got Hard: Proof, Not Promises (/blog/why-selling-ai-got-hard-buyers-want-proof-not-promises) ## The Pattern Every AI Seller Recognizes [#the-pattern-every-ai-seller-recognizes] You know the feeling. The demo was perfect. Your champion was enthusiastic and saw the value immediately. You had a warm introduction and the initial calls went better than expected. They talked about budget and timelines. Then the communication slows down. Emails get shorter. Follow ups go unanswered. The deal is not dead. It is just stuck. This is the question echoing through sales communities right now. Why are my AI deals stalling? You are not alone in asking it. Founders and sales leaders everywhere are describing the same pattern. A prospect loves the technology but will not commit. The deal enters an endless evaluation cycle and eventually fades away. Your champion goes quiet or tells you they are waiting for internal alignment. This is not a reflection of your product or your sales skills. It is a market shift. The problem is not a lack of interest. The problem is a lack of trust. Buyers are no longer willing to sign a contract based on a promise. They need to see the value for themselves. They need proof that your AI will work on their data and solve their specific problems before they commit a single dollar of budget. ## Why Buyers Stopped Believing in Promises [#why-buyers-stopped-believing-in-promises] The current wave of buyer skepticism is not irrational. It is pattern recognition. For the past few years organizations have poured resources into AI initiatives. The results have been deeply disappointing. Every enterprise buyer you speak with has a story about a failed pilot or an expensive project that delivered no measurable return. They have been burned before and they have learned from it. The data confirms their experience. The gap between the promise of AI and the reality of its impact is wide. Consider the evidence from the last two years. * An MIT study found 95 percent of AI pilots deliver zero measurable P\&L impact. * S\&P Global reported that 42 percent of companies abandoned most of their AI projects in 2025. * A Deloitte survey showed that while 74 percent of organizations want AI to grow revenue, only 20 percent have actually seen it happen. * Morgan Stanley found that only 21 percent of S\&P 500 companies can cite a measurable AI benefit from their investments. These are not isolated incidents. They represent a widespread failure to translate AI potential into business results. These are the stories your buyers have in their heads when you present your slide deck. They are no longer buying a vision. They are buying a verifiable outcome. The trust deficit in numbers: 95 percent of AI pilots show no P&L impact per MIT, 42 percent of AI projects are abandoned per S&P, 13 stakeholders sign off on every deal and 78 percent demand trials on deals over $10M. The old pitch of $5k a month on trust is crossed out. The new pitch buyers expect is $2 per resolved ticket with every charge auditable ## The New Buying Process This Created [#the-new-buying-process-this-created] This trust deficit has fundamentally changed how enterprises buy AI. The old playbook of selling a vision and promising future ROI is broken. Buyers have built a new purchasing process designed to protect them from another failed investment. Resisting this new reality is a losing strategy. The sellers who win are the ones who design their sales process to accommodate it. A Forrester report from late 2025 put it plainly. B2B buyers now demand proof, not promises. This is not just a sentiment. It is a structural change in how decisions are made. More than 60 percent of business buyers now use a trial before committing to a purchase. That number jumps to 78 percent for investments over ten million dollars. The "try before you buy" model is now the standard for significant software purchases. At the same time the number of people involved in a decision has grown. The median B2B purchase now involves 13 internal stakeholders. Each of those stakeholders brings their own questions and their own skepticism from past projects. The burden of proof has shifted entirely onto the vendor. You must prove your value before a contract is ever signed. Your job is no longer to convince them it will work. Your job is to show them it works. ## Move the Proof into the Deal [#move-the-proof-into-the-deal] If buyers need proof, the only logical step is to build that proof directly into the deal itself. Instead of fighting for trust you can create a commercial structure that makes trust irrelevant. This approach aligns your success with your customer's success. It turns a contentious negotiation into a collaborative partnership. There are three core mechanisms to make this happen. First you need a **time-boxed pilot with clear pass criteria** agreed upon upfront. An open-ended pilot is not a trial. It is purgatory. Define the duration, perhaps 30 or 60 days. More importantly define what success looks like. This creates a clear finish line and a shared understanding of the goal. The pilot ends with a clear yes or no decision based on results, not feelings. Second you must [define the outcome you will be judged on](/blog/defining-concrete-billable-outcomes-for-ai-agents) as a **concrete, countable event**. Vague goals like "improved efficiency" or "better insights" are useless. They are impossible to measure and lead to disputes. A good outcome is specific and verifiable by both sides. It could be "customer support tickets resolved without human intervention" or "qualified sales leads generated". The key is that it is an observable event that leaves no room for interpretation. Third you should **price against that outcome**. This is the most powerful mechanism for building trust and closing deals. Instead of a fixed subscription fee you charge the customer based on the results you deliver. This effectively de-risks the purchase for the buyer. They only pay when they get confirmed value. This transforms the deal into one of [pricing AI outcomes as risk contracts](/blog/pricing-ai-outcomes-as-risk-contracts) where you share the performance burden. According to Futurum, 43 percent of enterprise buyers now consider this kind of risk sharing a significant purchase factor. It is no longer an exotic model. It is a closing tool. ## Why Sellers Resist and Why They Are Wrong [#why-sellers-resist-and-why-they-are-wrong] Many sellers are hesitant to adopt outcome-based models. The resistance usually comes from a few common fears. These fears are understandable but they are based on outdated assumptions about how billing has to work. The reality is that modern infrastructure solves these challenges. **Fear one is that revenue becomes unpredictable.** If you only get paid for outcomes, how can you forecast your business? The answer is to backtest your pricing model against historical data before you offer it. You can simulate how the model would have performed over the last six or twelve months. This gives you a clear picture of potential revenue and variability. It allows you to [test your outcome pricing model before you launch](/blog/how-to-test-your-outcome-pricing-model-before-launch) it into the market. **Fear two is that you will get into disputes over what counts as a billable outcome.** This is a valid concern if outcomes are poorly defined. The solution is to define them as observable events with a clear verification window written into the contract. For example a "resolved ticket" might be defined as a ticket that is closed and not reopened by the customer within seven days. This removes ambiguity. Every charge can be traced back to a specific verifiable event, which is the key to [how transparent invoicing stops AI billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). **Fear three is the operational overhead of tracking and billing for thousands of small events.** Managing this with spreadsheets would be a nightmare. This is not a process problem. It is an infrastructure problem. A modern billing layer like witn is designed to handle this complexity. It can ingest event streams from your existing systems, verify which events meet your outcome criteria and generate auditable per-outcome invoices automatically. ## What This Looks Like in a Sales Conversation [#what-this-looks-like-in-a-sales-conversation] This shift from selling promises to proving value changes the entire dynamic of a sales conversation. It moves the focus from your product's features to the customer's business results. Compare the old pitch with the new one. The old pitch sounds like this. "Our platform is five thousand dollars per month. It will deliver significant ROI by improving your team's efficiency". This pitch asks the buyer for a leap of faith. It forces the buying committee to debate the potential ROI and trust your claims. In today's market this is an invitation for the deal to stall. The new pitch sounds very different. "You will pay two dollars for every support ticket our agent resolves. A resolved ticket is one that is closed and not reopened for seven days. You can audit every single charge against the event that generated it. We can start with a 60 day pilot on these exact terms". This second pitch is almost impossible to say no to. It removes every reason the committee had to stall. There is no debate about ROI because the price is tied directly to it. There is no risk because they only pay for confirmed results. You have made it easy for them to say yes. The proof is not in your slide deck. The proof is built into the contract itself. ## The Market Grew Up [#the-market-grew-up] It is easy to look at stalled deals and skeptical buyers and think the market for AI has soured. That is the wrong conclusion. The market did not get worse. It grew up. The era of hype and easy money is over. It has been replaced by a more mature market that demands real, tangible value. This is good news for companies with products that actually work. A market that demands proof is a market that rewards substance over style. It filters out the noise and the vaporware. When buyers demand to see results before they buy, it creates an opportunity for the best products to win. Your ability to prove your agent's value is a competitive moat that your rivals cannot fake. While they are stuck trying to sell a vision you are closing deals based on verified performance. This new era is not a threat. It is an opportunity to build a more durable and honest business. The tools to build these deals exist. [Read the docs](/docs). # Why Your AI Product's Success Can Shrink Revenue (/blog/why-your-ai-product-s-success-could-shrink-your-revenue) ## The Innovator's Paradox in AI Monetization [#the-innovators-paradox-in-ai-monetization] The primary goal for any product team is to make their product better, faster and more efficient. Yet for many AI agent builders, achieving this goal can paradoxically lead to a decline in revenue. This happens when your pricing is tied to the resources your agent consumes, like compute time or tokens, rather than the value it creates. We have all seen it. A brilliant update makes an agent solve a problem in half the time and suddenly the invoice for that job is also cut in half. This conflict creates what we can call the innovator's paradox. You are incentivized to improve your product, but your business model punishes you for doing so. This article looks at this fundamental flaw in traditional AI monetization and shows a path toward models that reward innovation instead of penalizing it. ## The Hidden Flaw of Input-Based Pricing [#the-hidden-flaw-of-input-based-pricing] The problem with input-based pricing models is that they bill for effort, not results. This misalignment can quietly wreck a business as its technology matures. Take voice AI, where much of the category is still anchored around per-minute pricing. If an agent starts resolving the same customer issue in less time, revenue falls precisely because the product got better. That is the trap of pricing the input. Token-based pricing for language models presents the same efficiency trap. As you refine your prompts or switch to a more capable base model, your agent accomplishes its task using fewer tokens. The customer receives the same or even better outcome, but your revenue per task diminishes. The dynamic looks like this: 1. **Product improvement.** Your team ships a more efficient model that solves a user's problem with 50% fewer tokens. 2. **Customer value.** The user gets the same successful outcome, but faster or cheaper. 3. **Revenue impact.** Your revenue for that same successful outcome is cut in half. This is not just theoretical. Buyers are shifting their focus from effort to results. Industry analyses like [Bessemer's AI pricing playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook) point the same direction: pure usage-based pricing is losing ground in enterprise AI contracts as buyers prioritize results over resources. Input-based models force developers to choose between product excellence and revenue stability. That is not a real choice. ## Aligning Revenue with Results Through Outcome Pricing [#aligning-revenue-with-results-through-outcome-pricing] The solution to this paradox is to tie billing to the value delivered. This is the core idea behind outcome-based pricing. Charges are triggered by a predefined, successful result, not the resources consumed along the way. Instead of billing per minute or per token, you bill per resolved support ticket, per qualified lead generated or per completed transaction. This approach turns the efficiency trap into a strategic advantage. When your agent becomes more efficient, the cost to deliver a successful outcome decreases, which directly improves your profit margin. The vendor effectively becomes an insurer of performance, absorbing the cost of failed or inefficient attempts. That makes the model most viable for mature agents with predictable success rates. The prerequisite is a [concrete, defensible definition of the billable outcome](/blog/defining-concrete-billable-outcomes-for-ai-agents). In witn that definition is a [billable condition](/docs/guides/billable-conditions), an explicit rule the outcome must satisfy before it becomes a charge: Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 The contrast with input-based pricing is stark: | Factor | Input-based pricing (usage/tokens) | Outcome-based pricing | | -------------------------- | ------------------------------------------------ | ---------------------------------------------------- | | Billing trigger | Resources consumed (API calls, tokens, minutes) | Successful, predefined result (a resolved ticket) | | Impact of efficiency gains | Revenue per task decreases | Profit margin per task increases | | Value alignment | Aligned with resource consumption | Aligned with the customer's success | | Vendor risk | Low. The customer bears the cost of inefficiency | High. The vendor absorbs the cost of failed attempts | | Ideal for | Infrastructure, APIs, early-stage products | Mature agents delivering tangible business results | ## Navigating Implementation with Hybrid Models [#navigating-implementation-with-hybrid-models] While pure outcome pricing offers perfect alignment, it introduces operational challenges. The primary hurdle is verification. Defining a successful outcome requires binary, unambiguous metrics that leave no room for dispute. Was the lead truly qualified? Was the customer's issue fully resolved? Any ambiguity turns into [a billing dispute later](/blog/how-transparent-invoicing-stops-ai-billing-disputes). This is where hybrid pricing offers a pragmatic path forward. A hybrid approach combines a stable, recurring base fee with a variable component tied to successful outcomes. The base fee covers foundational costs and provides predictable revenue, absorbing the variance in compute costs. The outcome-based portion ensures you are still rewarded for delivering tangible value. This balanced structure is quickly becoming the default for builders who need both predictability and value alignment. Hybrid pricing also means different customers get different terms. [Rate cards](/docs/guides/rate-cards) make that manageable. Each customer gets a card that maps agents to prices, so the same outcome can carry a different price per customer without forking your billing logic: Rate card editor showing agent-to-price entries ## Model Your Roadmap Before You Price It [#model-your-roadmap-before-you-price-it] Deciding how to price an AI product should not be a guess. Before committing to a model, project how your revenue changes as your agent improves. Take your roadmap and model a scenario where the product becomes twice as efficient at its job. Under a usage-based model, revenue declines. Under an outcome-based model, margins improve. The exercise takes an afternoon in a spreadsheet and it settles the argument with data. It also does more than validate a pricing strategy. We have all been in meetings where a product improvement is questioned because of its potential impact on short-term revenue. A clear projection turns that conversation around by showing that efficiency gains strengthen the business instead of weakening it. ## Building a Future-Proof Monetization Strategy [#building-a-future-proof-monetization-strategy] For AI agents that deliver tangible business results, pricing the input is a flawed model that punishes efficiency. As your product improves, your revenue should not shrink. The solution is outcome-based and hybrid models that align your revenue directly with your customer's success. This shift turns product improvements into margin gains and creates a business model that rewards innovation. Treat pricing as a core part of product design, not a commercial afterthought. Your billing should reflect and capture the value your agent creates, so that as your product gets better, so does your business. For the complete picture, from choosing a model to operating outcome billing in production, see [AI Agent Monetization: The Complete Guide](/blog/ai-agent-monetization-the-complete-guide). witn is billing infrastructure built for exactly this. Define the outcome as a condition. Send events as the agent works. The charge settles when the condition holds through the settlement window. [Read the docs](/docs) to see how it works. # witn vs Building In-House (/blog/witn-vs-building-in-house) Your engineering team has a new feature request: bill customers for AI agent outcomes. The initial scope seems manageable. A new `resolutions` table in the database and a scheduled job to scan it should do the trick. This approach, however, often overlooks the true complexity of a reliable outcome-based billing system. ## The True Scope of an Outcome-Based Billing System [#the-true-scope-of-an-outcome-based-billing-system] The resolutions table is the visible 10 percent of the project. The submerged 90 percent is a stateful stream-processing and correctness problem that can consume quarters of senior engineering time. This is not a question of whether a competent team can build it. The question is whether it is worth the opportunity cost. The hidden work involves challenges that a simple database scan cannot solve: settlement windows, idempotency, out-of-order events, audit trails and rerating. These are not edge cases. They are fundamental requirements for a system that customers and finance teams can trust. Building this layer correctly is a significant engineering investment. In fact, it is a product in itself. We know because we built it. Our technical deep dive on the resolution layer details [exactly what you would be rebuilding](/blog/how-we-built-witn-s-outcome-resolution-layer-for-low-latency-and-reliability), from the state machines to the concurrency controls. ## Ensuring Correctness with Settlement and Idempotency [#ensuring-correctness-with-settlement-and-idempotency] A resolved outcome is not yet a charge. It first enters a configurable settlement window, a period during which a cancellation credit or reopen event can reverse it. Only after the window closes cleanly does the outcome commit to an invoice. A simple cron job has no native concept of this waiting period. Adding it introduces significant state management complexity, turning a straightforward scan into a web of timers and conditional logic that is difficult to test and maintain. Beyond settlement, there is the problem of idempotency. Client applications retry, workers crash and message queues redeliver. An idempotent billing system must guarantee that a customer is charged exactly once for an outcome. A naive consumer that calls a payment API directly can easily double-charge on restart, a classic dual-write problem. Correctness requires deterministic event IDs for deduplication and a transactional commit process, not a simple boolean `billed` column. Failures here directly damage revenue and customer trust, which is a high price to pay for what seemed like a small feature. This is a core part of [the missing layer in AI agent monetization](/blog/the-missing-layer-in-ai-agent-monetization). ## Data Integrity for Out-of-Order Events and Audits [#data-integrity-for-out-of-order-events-and-audits] Distributed event streams rarely arrive in perfect chronological order. A system that processes events based on their arrival time, such as a cron job scanning records by `created_at`, will silently produce incorrect results. For example, a cancellation event might arrive before the creation event it corresponds to, leading to a missed reversal. Correct evaluation must key off immutable event timestamps and be prepared to re-evaluate an outcome's state whenever a late-arriving event is received. This requires a more sophisticated model than a simple sequential process. This historical accuracy becomes critical when a customer asks "why was I charged for this?". Your system must be able to answer with a complete audit trail. This means tracing every charge back to the specific outcome and the exact sequence of events that triggered its resolution. Retrofitting this capability onto a mutable table after the fact is exceptionally difficult. An audit trail must be an immutable, foundational part of the system's design from day one. As we've discussed before, [transparent invoicing is essential for preventing billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes) and maintaining customer confidence. ## Future-Proofing with Simulation and Scale [#future-proofing-with-simulation-and-scale] Your pricing models and outcome definitions will evolve. Before deploying a change, you must understand its impact on revenue. This requires the ability to simulate the new rules against historical data. A proper rerating and simulation engine is a whole second system, typically an event archive paired with a fast columnar query engine. Most teams building in-house never budget for this, leaving them blind to the financial impact of their pricing adjustments. This makes it impossible to [test an outcome pricing model before it goes live](/blog/how-to-test-your-outcome-pricing-model-before-launch). As your business grows, your billing system for AI agents must scale with it. This means handling potentially millions of concurrent outcome evaluations, each its own state machine, without race conditions or performance degradation. This is a classic distributed systems problem that requires techniques like compare-and-swap versioning to avoid slow, expensive distributed locks. A simple database table with row-level locking will not suffice at scale. Instead of hand-coding this logic, a platform approach allows you to define complex conditions in simple terms. ## In-House Build vs witn at a Glance [#in-house-build-vs-witn-at-a-glance] The following table summarizes the trade-offs between a typical in-house build and using a managed platform. | Concern | In-house resolutions table + cron | witn | | ----------------------------- | ------------------------------------------------- | --------------------------------------------- | | Settlement windows | Manual logic, complex state management | Built-in, configurable per outcome | | Idempotency/exactly-once | Requires deterministic IDs, transactional commits | Handled automatically by the platform | | Out-of-order events | Prone to silent errors if using arrival time | Correctly evaluates based on event timestamps | | Audit trail | Difficult to retrofit, often incomplete | Immutable log of all events for every charge | | Rerating/simulation | Requires a separate, unbudgeted system | Built-in tools for forecasting and analysis | | Time to first correct invoice | 2+ quarters with 3-4 senior engineers | Hours to days | | Ongoing operational load | Permanent on-call, maintenance, capacity planning | Managed by witn as infrastructure | ## The Real Cost is Opportunity [#the-real-cost-is-opportunity] Building this system correctly requires three to four senior engineers for at least two quarters to produce the first correct invoice. This does not include the permanent on-call load for maintenance and capacity planning. The real cost is the opportunity cost. Those are the same senior engineers who should be improving your core AI agent, which is the product your customers are actually buying. The build vs buy billing software decision is a strategic one. Before dedicating a team to this project, engineering leaders should ask a few critical questions: 1. Is billing correctness a core competency we want to own and maintain? 2. Who carries the on-call pager for a double-charge incident at 2am on a weekend? 3. What features in our core product will not get built while we are building and maintaining this billing system? ## Frequently asked questions [#frequently-asked-questions] ## Billing as Infrastructure Not a Project [#billing-as-infrastructure-not-a-project] A correct and reliable outcome resolution layer is not a feature to be shipped and forgotten. It is critical infrastructure that underpins your revenue and customer trust. witn provides this layer as managed infrastructure. Your team defines what a billable outcome looks like and sends the corresponding events. Our platform handles the complex work of resolving that outcome into a correct, settled and fully auditable charge. Focus your engineering talent on building a better agent, not a billing system. [Read the docs](/docs). # witn vs Chargebee (/blog/witn-vs-chargebee) ## The AI Agent Monetization Challenge [#the-ai-agent-monetization-challenge] The rise of autonomous AI agents is reshaping how software creates value. Yet many billing models have not adapted. This creates a critical gap between the results an agent delivers and the revenue it generates. Traditional SaaS billing, designed for human users and monthly access, is often a poor fit for agents that operate independently. An agent's value is not measured in screen time or clicks but in the outcomes it produces. When you bill per action or API call, you create an efficiency penalty. A smarter, more efficient agent that solves a problem in fewer steps ends up earning less revenue. This fundamental misalignment discourages innovation and misrepresents the agent's true worth. This article explores the witn vs [Chargebee](https://www.chargebee.com) decision by comparing two distinct philosophies. One is built for selling access, the other for selling results. Choosing the right model is essential for successful AI agent monetization. ## Subscription vs Outcome-Native Billing [#subscription-vs-outcome-native-billing] The core difference between Chargebee and witn lies in what they are designed to measure. Chargebee is a powerful platform for subscription management, built to answer the question, "What is the customer subscribed to?". It excels at managing recurring plans, upgrades, trials and usage-based add-ons. Its logic is centered on time and access. In contrast, witn provides an outcome-based billing layer built specifically for AI agents. It answers a different question: "What valuable results did the agent deliver?". Instead of charging for activity, witn charges only when a predefined, successful outcome is achieved. This aligns cost directly with value, ensuring that a more effective agent generates more revenue, not less. The two approaches represent fundamentally different ways of thinking about value. One sells a subscription to a tool, while the other sells the tangible results that tool produces. The table below outlines this philosophical divide. | Factor | Subscription Billing (e.g. Chargebee) | Outcome-Native Billing (e.g. witn) | | ----------------- | ---------------------------------------------------- | --------------------------------------------------------- | | Core question | What is the customer subscribed to? | What valuable results did the agent deliver? | | Billing trigger | Time period (e.g. monthly) or activity count | A predefined, verified successful outcome | | Value measurement | Access to features or usage metrics (e.g. API calls) | Achievement of a specific success criterion | | Ideal use case | Predictable SaaS products with recurring user access | Autonomous agents delivering discrete, verifiable results | | Invoice example | "Monthly plan + 10,000 API calls" | "15 support tickets resolved" | ## Which Model Fits Your Business? [#which-model-fits-your-business] Choosing between these models is like deciding between a gym membership and a personal trainer. A gym membership, like Chargebee, gives you access to the facilities for a flat fee. A personal trainer, like witn, is paid for achieving specific results. Neither is better, but they serve different goals. To figure out how to bill for AI agents in your business, ask yourself these questions: **1. Is your agent's value tied to discrete, verifiable results?** If your agent performs specific tasks like resolving support tickets, booking appointments or qualifying leads, its value is in the outcome. An outcome-native model captures this value directly. If you sell general access to a platform, a subscription model may be a better fit. **2. Does your agent's efficiency improve over time?** As your models get smarter, they will achieve results with fewer actions. If you bill per action, your revenue will decrease as your product improves. An outcome-native model ensures your revenue scales with your agent's effectiveness. We wrote about this in [why your AI product's success could shrink your revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). **3. Do outcomes sometimes reverse?** Consider a support ticket that a customer reopens. In a traditional system, this requires a manual credit note, creating operational overhead. An outcome-native model can automatically void the charge if the result reverses within a set window, eliminating manual adjustments. ## How witn Prices and Measures Success [#how-witn-prices-and-measures-success] The witn platform is built around a few core concepts that enable flexible AI billing. It moves beyond simply counting events to understanding the context behind them. First, success is defined through human-readable [billable conditions](/docs/guides/billable-conditions). For example, you can set a rule that a support ticket is only considered "resolved" if it remains closed for 72 hours. This ensures you only bill for outcomes that stick, aligning your revenue with real customer satisfaction. Second, pricing is managed with per-customer [rate cards](/docs/guides/rate-cards). This lets you set different prices for the same outcome for different customers without forking your billing logic. An enterprise client can pay a different rate for a "qualified lead" than a startup client, all managed from a single system. Finally, witn includes a powerful simulation feature. Before deploying a change to your pricing or success criteria, you can model its impact on historical data. This provides a clear preview of how adjustments would affect recognized outcomes and revenue, removing guesswork from pricing strategy. We covered the method in [how to test your outcome pricing model before launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). ## From Event to Invoice [#from-event-to-invoice] The difference between these two models becomes clearest on the final invoice. A traditional invoice might show a line item like "10,000 API calls @ $0.001/call". This tells the customer what they used, but not what they achieved. It forces them to connect activity to value on their own. An invoice powered by witn is fundamentally different. It presents line items that communicate value directly, such as "15 support tickets resolved @ $5/ticket". The customer sees exactly what they paid for in terms they understand. This clarity builds trust and reinforces the value of your agent, which is [how transparent invoicing stops AI billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). This is made possible by settlement windows. When an agent achieves a goal, the outcome is marked as provisional. If the result reverses within the defined window, like a customer reopening a support ticket, the charge is automatically voided. There are no credit notes to issue or manual reconciliations to perform. The system handles the complexity, ensuring the final invoice is always accurate. witn acts as a specialized billing logic layer that integrates with payment gateways like Stripe to manage collections. ## Frequently asked questions [#frequently-asked-questions] ## Billing for Access or Results? [#billing-for-access-or-results] Chargebee is a robust and mature platform that excels at managing subscription lifecycles for standard SaaS businesses. For companies selling predictable, recurring access to software, it is an excellent choice. It provides the tools needed to handle plans, trials, dunning and revenue recognition with precision. However, autonomous AI agents represent a new paradigm. Their value is not in access but in the results they deliver. For these products, an outcome-native model is a more natural fit. witn was purpose-built to bridge the gap between agent performance and revenue, ensuring that as your agent gets better, your business grows with it. This is [the missing layer in AI agent monetization](/blog/the-missing-layer-in-ai-agent-monetization). The choice comes down to what you are selling. Are you selling predictable access to a tool, or are you selling verifiable results generated by an autonomous agent? [Read the docs](/docs) to see how it works. # witn vs Lago (/blog/witn-vs-lago) ## The Shift from Activity to Outcomes in AI Monetization [#the-shift-from-activity-to-outcomes-in-ai-monetization] Billing for AI agents presents a unique challenge. Traditional software billing is built on metering activity. We count user seats, API calls or compute hours. These models work well when value is tied directly to consumption. AI agents, however, are different. Their value is not in the resources they consume but in the outcomes they achieve. They solve support tickets, book appointments or write code. This distinction forces a fundamental question for builders: are you selling activity or achievement? The choice of a billing system reflects the answer to that question. It defines the product's core unit of value and shapes the entire business model. As developers explore monetization models for their agents, they find that simply counting events can misrepresent the value delivered. An agent that solves a complex problem in a single step is more valuable than one that takes a hundred steps, yet activity-based billing would reward the latter. This is not a metering problem. It is a value definition problem. ## Lago's Strengths in Usage-Based Metering [#lagos-strengths-in-usage-based-metering] Lago is a powerful open source platform for usage-based billing. It is API-first and can be self-hosted or used as a cloud service. This gives engineering teams significant control over their billing infrastructure and data. For companies that prioritize data sovereignty and want to avoid vendor lock-in, the self-hosting option is a compelling advantage. The platform is designed to ingest high volumes of raw usage events. It aggregates these events into meters and applies pricing plans, subscriptions, prepaid credits and coupons. Lago does not process payments directly. Instead, it integrates with payment processors like Stripe or GoCardless to handle collection. The platform is built to handle the high-throughput event streams common in AI applications. Its core strength lies in metering products where value scales predictably with consumption. This makes it an excellent fit for infrastructure products like APIs, data pipelines or raw compute services. ## The Structural Mismatch for Agent Billing [#the-structural-mismatch-for-agent-billing] The problem with using a traditional metering system for AI agents is a structural one. A usage meter records an event and treats it as final. The moment an API call is logged, it contributes to the bill. Agent outcomes, however, are often provisional. A support ticket marked "resolved" might be reopened by the customer an hour later. A travel booking can be cancelled. A code commit might be reverted. A simple meter has no native concept of an outcome that is later invalidated. This forces teams into manual workarounds like issuing credit notes, which complicates revenue recognition and creates a poor customer experience. More importantly, it creates an efficiency penalty. Billing for activity means a more efficient agent, one that solves problems in fewer steps, generates less revenue. This misalignment is a serious concern, as it explains [why your AI product's success could shrink your revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). You are punished for improving your product. This is not a missing feature in metering tools. It is a fundamental mismatch between how they work and what AI agents sell. ## How witn Aligns Billing with Outcomes [#how-witn-aligns-billing-with-outcomes] witn is an outcome-native billing layer designed to resolve this mismatch. It sits between your product's event stream and your payment processor, interpreting events to identify billable achievements. Instead of just counting activity, witn evaluates it against success criteria defined by your team. These are not code but simple, human-readable [billable conditions](/docs/guides/billable-conditions). For example, you can define a "resolved ticket" as a ticket that remains closed for 72 hours. Each potential outcome is held in a provisional state during a settlement window. If the ticket is reopened within that 72 hour window, the potential charge is automatically voided. No manual credit notes are needed. This ensures you only bill for value that is truly delivered and sustained. The resulting invoices list achievements, not activity. A customer sees "15 support issues resolved" instead of "10,000 API calls". This clarity is key to [how transparent invoicing stops AI billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes) because each line item is backed by the specific events that prove the outcome. With witn, pricing is managed through per-customer contracts and [rate cards](/docs/guides/rate-cards), allowing for flexible and custom deals without forking your billing logic. You can also simulate the revenue impact of any changes to your pricing or billable conditions. This lets you [test your outcome pricing model before launch](/blog/how-to-test-your-outcome-pricing-model-before-launch) and gives you confidence in your monetization strategy. ## A Direct Comparison [#a-direct-comparison] The comparison highlights two different philosophies. One is built for metering infrastructure, the other for selling outcomes. The table below offers a direct comparison of the two approaches. | Factor | Lago | witn | | ------------------ | ------------------------------------ | ------------------------------- | | Core job | Metering infrastructure usage | Selling AI agent outcomes | | Billing trigger | Technical events (tokens, API calls) | Validated billable conditions | | Handling reversals | Manual credit notes | Automatic settlement windows | | Invoice example | 10,000 tokens consumed | 15 resolved support tickets | | Hosting model | Cloud or self-hosted | Managed service | | Payment collection | Integrates with Stripe/GoCardless | Integrates with Stripe | | Best fit | Compute, APIs, data pipelines | AI agents, autonomous workflows | ## Frequently asked questions [#frequently-asked-questions] ## Choosing Your Billing Path [#choosing-your-billing-path] The choice between witn and Lago is a strategic one that depends on your product's core value proposition. It is not about which tool is better, but which tool is right for your business model. If you are selling access to infrastructure where value scales with consumption, a metering platform like Lago is a strong foundation. Its open source nature and focus on usage tracking provide the control and transparency needed for that model. If you are selling an AI agent that delivers business results, your billing system must be able to understand and quantify those results. An outcome-native model is a better fit. It aligns your revenue directly with the value your customers receive, creating a healthier and more scalable business. This is [the missing layer in AI agent monetization](/blog/the-missing-layer-in-ai-agent-monetization) that connects product performance to revenue. The two are not mutually exclusive. A business could use witn to resolve billable outcomes and then pass the finalized charges to a system like Lago or Stripe Billing for rating, invoicing and collections. The most important step is to decide what you are selling. Define your unit of value first. Everything else follows from that. [Read the docs](/docs) to see how it works. # witn vs Orb (/blog/witn-vs-orb) ## The New Monetization Challenge for AI Agents [#the-new-monetization-challenge-for-ai-agents] AI agents have moved past the experimental phase. They handle complex, multi-step tasks autonomously and that shift has exposed a monetization problem. Traditional billing models, flat subscriptions or simple usage metrics like API calls, were not designed for this. They measure activity, not achievement. The disconnect cuts both ways. Builders fail to capture the value their agents create and leave revenue on the table. Customers pay for processes that failed or delivered nothing. The challenge is no longer tracking usage. It is quantifying value. Two distinct answers have emerged, embodied by witn and [Orb](https://www.withorb.com). They are not just two billing tools. They are two different philosophies. ## Foundational Billing Philosophies: Usage vs Outcome [#foundational-billing-philosophies-usage-vs-outcome] Orb built its expertise around usage-based billing. It meticulously tracks and charges for the consumption of resources or the volume of events. Data processed, features accessed, seats used. It is an effective and transparent model for platforms where value scales predictably with consumption. The core question it answers: "How much did the customer use?" witn is outcome-native. It looks past raw events to identify and charge for successful results. Instead of counting activities, it evaluates signals from your existing event streams to determine whether the agent achieved a predefined goal, like resolving a support ticket or qualifying a sales lead. The question witn answers is different: "What value did the customer receive?" Usage-based billing is a robust solution for general SaaS. Applied to the goal-oriented work of AI agents, it becomes a blunt instrument. Charging for every action an agent takes, regardless of success, means billing customers for failed attempts and incomplete tasks. Outcome-native billing aligns cost with delivered value, so invoices reflect achievements, not effort. | Aspect | Orb (usage-based) | witn (outcome-native) | | ----------------- | -------------------------------------------- | ----------------------------------------------- | | Core question | How much did the customer use? | What value did the customer receive? | | Billing trigger | Resources consumed (API calls, data stored) | Predefined goal achieved (ticket resolved) | | Value measurement | Quantifies activity and volume | Qualifies success and results | | Ideal for | Products where value scales with consumption | Products where value is tied to task completion | | Invoice example | 10,000 API calls used | 15 support issues resolved | ## Aligning Infrastructure with Your Business Model [#aligning-infrastructure-with-your-business-model] Orb is an excellent fit for high-growth SaaS and AI companies whose value proposition is tied to quantifiable usage. If your product is a data API, a cloud infrastructure service or a platform where more activity directly means more customer value, a usage-based model gives you a clear and scalable path. witn is purpose-built for AI agent builders. For them, value is not the number of steps an agent takes. It is the objectives the agent completes. An analogy makes the difference concrete. Orb operates like a utility meter, precisely tracking every kilowatt-hour consumed. witn functions like a performance contract, where payment depends on achieving an agreed result. Four questions point you to the right model: 1. Is your product's value defined by consumption or by achievement? 2. Do your customers care more about the resources they used or the problems they solved? 3. Does your pricing need to account for failed or incomplete agent tasks? 4. Is your goal to bill for activity or to prove delivered value? If your answers lean toward achievement, you need what we call a resolution layer. We wrote about why that layer is missing from traditional billing stacks in [The Missing Layer in AI Agent Monetization](/blog/the-missing-layer-in-ai-agent-monetization). ## Flexibility in Pricing and Implementation [#flexibility-in-pricing-and-implementation] Both platforms are flexible. They apply flexibility in different dimensions. Orb's strength is decoupling product logic from billing logic. Commercial teams can experiment with tiered plans, per-seat pricing or credit systems without engineering work. That is the right setup for companies iterating on packaging across a broad user base. witn's flexibility is focused on value definition. Success criteria are explicit [billable conditions](/docs/guides/billable-conditions), rules an outcome must satisfy before it becomes a charge: Agent editor showing a billable condition with four leaves: agent_replied is seen, escalated is not seen, reopened is not seen, csat is missing or has value above 3 Per-customer contracts come from [rate cards](/docs/guides/rate-cards). Each customer gets their own agent-to-price mapping, so the same outcome carries different prices for different customers without forking your billing logic. That matters for enterprise clients whose definition of a "successful outcome" is their own: Rate card editor showing agent-to-price entries A key differentiator is simulation. witn lets you model the financial impact of a pricing or condition change before deploying it, previewing how the change affects resolved outcomes and revenue. We covered the method in [How to Test Your Outcome Pricing Model Before Launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). Orb's flexibility is geared toward broad pricing iteration. witn's is geared toward defining and proving value at a granular, per-customer level. ## From Raw Event Data to Contextual Invoices [#from-raw-event-data-to-contextual-invoices] The journey from raw data to invoice shows the practical difference. Orb ingests raw event-level data at scale and creates a comprehensive, auditable record of usage. The invoice reflects that activity: "10,000 API calls used" or "500 GB of data processed". Precise, auditable and ideal for showing resource consumption. witn uses the same event streams differently. It evaluates them for signals, interpreting the context behind the events to resolve billable outcomes. The invoice reads as results: "15 support issues resolved", with each line item backed by the triggering event, the condition it satisfied and the settlement moment. We broke down that anatomy in [How Transparent Invoicing Stops AI Billing Disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes). This is more than cost justification. An invoice that tells a story of success builds trust and reinforces the value of your product with every billing cycle. ## Frequently asked questions [#frequently-asked-questions] ## Selecting the Right Billing Partner for Growth [#selecting-the-right-billing-partner-for-growth] The choice comes down to what you are selling. Orb is a powerful general-purpose usage-based billing engine that serves a wide range of SaaS and AI models well. If your business needs a scalable, flexible meter for quantifiable consumption, Orb is a strong contender. witn occupies a different position. For builders whose entire value proposition is the results their agents achieve, witn is the most direct and transparent path to monetization. It was designed from the ground up on one conviction: billing should align with the fundamental promise of AI, which is to achieve goals. If your product is built to deliver outcomes, your billing system should be too. [Read the docs](/docs) to see how it works. # witn vs Stigg (/blog/witn-vs-stigg) Traditional software billing measures activity like API calls or user seats. This model fails when applied to AI agents that deliver specific results, as it measures effort instead of achievement. This gap creates a new challenge for **AI agent monetization**: how to charge for value delivered, not resources consumed. This decision leads to two distinct philosophies embodied by two platforms. This article explores the choice between witn, a platform for outcome-native billing, and [Stigg](https://www.stigg.io), a platform for pricing and entitlement management. This is not a simple tool comparison. It is a strategic decision about how to align your billing infrastructure with the value your AI agent creates. ## Foundational Philosophies: Packaging vs Outcome [#foundational-philosophies-packaging-vs-outcome] Stigg provides a pricing and packaging control plane. Its purpose is to decouple your commercial logic from your codebase. This allows product and growth teams to create and iterate on plans, feature entitlements and usage limits without requiring engineering work. Stigg's model focuses on **entitlement management**, answering the question "What is the customer entitled to?". As Stigg's own materials highlight, its entitlements layer determines if a customer has access to a feature and on what terms, typically before consumption occurs. In contrast, witn offers **outcome-native billing**. It does not track raw activity. Instead, it evaluates signals from your existing event streams to determine if an AI agent achieved a predefined business goal, such as resolving a support ticket or qualifying a sales lead. witn is built to answer a different question: "What value did the customer receive?". It confirms and prices this value after the agent's work is complete, aligning the charge directly with the successful result. ## Core Differences at a Glance [#core-differences-at-a-glance] The choice between these platforms reflects a fundamental difference in business models. Stigg is designed to manage access and consumption, while witn is built to measure and bill for performance. Stigg's billing trigger is usage against a predefined limit. A customer is charged for using a certain number of API calls or activating a set number of features. This is ideal for businesses that package their product into distinct tiers. witn's trigger is the successful resolution of a billable outcome. A customer is only charged when the agent achieves a specific, agreed-upon goal. This approach measures the achievement of business objectives, not the consumption of resources. This direct link between charge and result allows for the kind of [transparent invoicing that stops billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes) before they start. The table below summarizes these core distinctions. | Aspect | Stigg (packaging & entitlements) | witn (outcome-native) | | --------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------- | | Core question | "What is the customer entitled to?" | "What value did the customer receive?" | | Billing/enforcement trigger | Usage against a predefined plan, feature or credit limit | Successful resolution of a billable outcome based on defined conditions | | What it measures | Consumption of resources and access to features | Achievement of specific, predefined business goals | | Ideal for | SaaS businesses iterating on feature-gated packaging and plans | AI agent builders selling tangible results and performance | | Invoice/example | 10,000 API calls used; 5 seats activated | 12 support tickets resolved; 3 sales leads qualified | ## Aligning Infrastructure with Your Business Model [#aligning-infrastructure-with-your-business-model] Stigg is an excellent fit for businesses with established feature tiers that need to experiment with packaging and pricing. It allows non-technical teams to quickly adjust commercial offers. Think of it like a building manager who can issue different keycards for different floors. The value is access to the floors, and Stigg manages who gets which keycard. witn is designed for AI agent builders whose value proposition is task completion. The customer is not buying access to the agent. They are buying the result the agent produces. This is similar to a performance marketing agency that charges for qualified leads, not for the number of ad impressions it served. The value is the lead, and witn measures and bills for each one. To determine which model fits your business, consider these questions: 1. Is your value defined by access to features or by the results your product achieves? 2. Do your customers need to see proof of performance on their invoices? 3. How often do you need to create **custom pricing models** for individual customers? ## Two Approaches to Pricing Flexibility [#two-approaches-to-pricing-flexibility] Both platforms offer flexibility, but they define it differently. For Stigg, flexibility means iterating on pricing, plans and entitlements through a user interface. This separates the commercial offer from the code, enabling rapid experimentation with packaging. For witn, flexibility is the ability to define what "value" means for each customer. This is done by setting up specific [billable conditions that reflect success](/docs/guides/billable-conditions) in plain language. This granular control extends to pricing, which is managed through per-customer [rate cards](/docs/guides/rate-cards). You can charge different rates for the same outcome without forking your billing logic. Furthermore, witn allows you to simulate the financial impact of any changes to pricing or outcome definitions before deployment. This ability to model changes is crucial if you want to [test your outcome pricing model before launch](/blog/how-to-test-your-outcome-pricing-model-before-launch). ## From Entitlements to Contextual Invoices [#from-entitlements-to-contextual-invoices] The platforms also differ in how they interact with downstream systems. Stigg's model typically passes metered usage data, such as "10,000 API calls", to a separate billing engine like Stripe for invoicing. The context of what those calls accomplished is often lost. The comparison of **witn vs Stigg** is clearest here. witn analyzes event streams to resolve billable outcomes internally. It then generates invoice line items that are inherently contextual. Each charge on a witn invoice is backed by a clear record of the outcome achieved, the conditions it satisfied and the moment it was confirmed. This provides the [missing layer in AI agent monetization](/blog/the-missing-layer-in-ai-agent-monetization) by connecting every charge to a delivered result. This creates an auditable trail of value that justifies every dollar on the invoice. ## Frequently asked questions [#frequently-asked-questions] ## Selecting the Right Partner for AI Growth [#selecting-the-right-partner-for-ai-growth] The choice between these models is a strategic decision about how your business defines and communicates value. For AI agents that deliver measurable results, an outcome-native billing model aligns your revenue directly with your customers' success. To see how to build your own outcome-native model, [read the docs](/docs). # witn vs Stripe (/blog/witn-vs-stripe) ## Why Billing for AI Agents Is More Than Payments [#why-billing-for-ai-agents-is-more-than-payments] If you are building an AI agent product you likely have a Stripe account. For most online businesses this means the billing problem is solved. You have a way to create subscriptions and charge credit cards. The conversation ends there. For AI agents however this is just the beginning. The core challenge in agent billing is not how to collect money. It is deciding what is worth charging for in the first place. An agent's value comes from its achievements, not just its actions. Stripe is an excellent tool for processing payments. It does not help you define what a successful outcome looks like or determine if your agent actually delivered it. This distinction is the difference between billing for activity and billing for results. ## What Stripe and Its Metering Engine Do Well [#what-stripe-and-its-metering-engine-do-well] Stripe is the default payment infrastructure for the internet for good reason. It provides a robust and reliable foundation for commerce. Its APIs handle payment processing, subscriptions, global tax compliance and invoicing with precision. For any business that needs to collect money online it is an essential part of the stack. In recent years Stripe has also invested heavily in usage metering. Its acquisition of Metronome in January 2026 was a clear signal of this commitment to consumption-based billing at scale. It solidified Stripe's position in high volume metering and led many teams to look for [Metronome alternatives after the Stripe acquisition](/blog/metronome-alternatives-after-the-stripe-acquisition). The combined Stripe and Metronome stack is powerful. If your product's value scales directly with consumption this is a strong solution. For businesses selling API calls, data storage or compute hours the model is a natural fit. You measure what the customer uses and you send a bill. For these use cases Stripe can seem like a complete answer. It provides the tools to meter activity at scale and collect payment reliably. ## The Gap Between Metering Activity and Selling Achievement [#the-gap-between-metering-activity-and-selling-achievement] The problem is that AI agents do not sell activity. They sell achievement. This creates a fundamental gap between what a usage meter measures and what your customer values. The difference is not a missing feature. It is a structural mismatch. A metered event is final the moment it is recorded. An API call is made. A gigabyte is transferred. The event is logged and the meter ticks up. Agent outcomes do not work this way. They are often provisional and can change over time. A support ticket your agent "resolves" might be reopened by the customer an hour later. A flight booking it makes could be cancelled the next day. A code block it writes might be reverted during review. A usage meter has no native concept of an outcome that is disputed, fails or is reversed. This creates a gap between the value created and the value billed, which is [the missing layer in AI agent monetization](/blog/the-missing-layer-in-ai-agent-monetization). Billing for activity also creates a dangerous business incentive. If your agent becomes more efficient and resolves a customer's problem with fewer steps your revenue goes down. You are punished for improving your product. This is how [your AI product's success could shrink your revenue](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). Your goals become misaligned with your customers' goals. They want results with minimal friction. Your billing model wants more friction to generate more billable events. ## How witn Fills the Outcome Resolution Gap [#how-witn-fills-the-outcome-resolution-gap] witn is a billing layer designed specifically for outcome-based billing. It sits between your application's event stream and your payment processor to resolve what is worth charging for. It works with your existing event tracking from tools like Segment or PostHog, so you do not need to build new instrumentation. You define what counts as a success using simple, human readable [billable conditions](/docs/guides/billable-conditions). For example a support ticket is considered "resolved" only if it remains closed for 72 hours. A sales lead is "qualified" only if it converts to a meeting. These conditions turn raw event data into meaningful business outcomes. witn holds each potential outcome in a provisional state during a settlement window. This allows it to automatically handle changes like cancellations or reversals. If a ticket is reopened within the 72 hour window the "resolved" outcome is voided. No manual credit note is needed. The system ensures you only bill for confirmed value. The result is an invoice where every line item is an achievement. Instead of charging for "10,000 API calls" you charge for "15 support issues resolved". Each line links back to the specific events that prove the outcome was delivered. This level of detail is [how transparent invoicing stops AI billing disputes](/blog/how-transparent-invoicing-stops-ai-billing-disputes) before they start. You can also create unique per-customer [rate cards](/docs/guides/rate-cards) and simulate the revenue impact of any changes before you deploy them. ## A Direct Comparison [#a-direct-comparison] The choice between Stripe's metering and witn's outcome resolution depends on what you sell. This table summarizes the functional differences between a usage metering stack and an outcome resolution layer. | Factor | Stripe (with Metronome) | witn | | -------------------- | --------------------------------- | ------------------------------------------------------------- | | Core job | Meter usage and process payments | Resolve billable outcomes | | Billing trigger | An event occurs, like an API call | Conditions are met, like a ticket staying closed for 72 hours | | Handling reversals | Manual credit notes | Automatic during the settlement window | | Invoice line example | 10,000 tokens used | 15 support issues resolved | | Payment collection | Yes | Pairs with a payment processor | | Best fit | Products that sell consumption | Products that sell results | ## Using Stripe and witn Together [#using-stripe-and-witn-together] For many teams building on AI this is not a binary choice. The most effective monetization stack uses both systems for what they do best. The architecture is straightforward. Your application generates events as your agent performs actions. witn ingests these events and applies your billable conditions to resolve outcomes. At the end of a billing period witn generates a detailed invoice based on the confirmed achievements. This invoice is then passed to a payment processor like Stripe for collection. In this model witn acts as the brain that decides what to bill. Stripe acts as the wallet that collects the money. The question is not which vendor to choose. The question is what is your unit of value. Once you answer that the right architecture becomes clear. ## Frequently asked questions [#frequently-asked-questions] ## Choose Your Stack Based on Your Value [#choose-your-stack-based-on-your-value] If your agent is paid for results a usage meter alone is the wrong tool. It will create billing disputes and misalign you with your customers. Decide your unit of value first, then pick the stack to match. If you are building for outcomes, start here. [Read the docs](/docs). # Billable condition (/glossary/billable-condition) **A billable condition is the machine-checkable rule that decides when an outcome becomes billable.** It is a boolean expression evaluated against the events your system emits. When the condition is satisfied, the outcome is provisionally successful. When it still holds at the end of the [settlement period](/glossary/settlement-period), the outcome confirms and becomes a charge. ## How it works [#how-it-works] A condition is built from leaves. Each leaf checks one fact about the event stream: an event was seen, an event was not seen, an event occurred at least N times, or the latest value carried by an event compares against a threshold. Leaves combine with boolean logic into a complete definition of success. A support agent example: `agent_replied` is seen, `escalated` is not seen, `reopened` is not seen and `csat` is missing or above 3. All four must hold for the resolution to bill. ## Why it matters [#why-it-matters] The billable condition is pricing as code. It forces the ambiguity out of "we charge per resolution" and replaces it with explicit criteria both sides can inspect. It is also what makes an invoice defensible: every line item can point at the condition it satisfied and the events that satisfied it, which is [how disputes get prevented](/blog/how-transparent-invoicing-stops-ai-billing-disputes) rather than argued. The condition is evaluated from scratch on every accepted event, so late reversals like a reopen flip the result before it ever settles into a charge. ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [Billable conditions in the docs](/docs/guides/billable-conditions), including all operators * [Defining Concrete Billable Outcomes for AI Agents](/blog/defining-concrete-billable-outcomes-for-ai-agents) * [Outcome-based pricing](/glossary/outcome-based-pricing) # Glossary (/glossary) Short, precise definitions of the terms used across AI agent monetization and outcome-based billing. Each entry defines the term first, then explains how it works in practice. ## Terms [#terms] * [Outcome-based pricing](/glossary/outcome-based-pricing): charging only when a verified business result is achieved * [Billable condition](/glossary/billable-condition): the machine-checkable rule that decides when an outcome becomes billable * [Settlement period](/glossary/settlement-period): the waiting window that lets provisional results become final * [Per-resolution pricing](/glossary/per-resolution-pricing): the support-industry form of outcome pricing and its fine print * [Resolution layer](/glossary/resolution-layer): the infrastructure that turns event streams into settled billable outcomes * [Usage-based pricing](/glossary/usage-based-pricing): charging for measured consumption and where that breaks for agents * [Rate card](/glossary/rate-card): the pricing table that maps each task to a price per unit New entries are added regularly. For the full picture of how these pieces fit together, read [AI Agent Monetization: The Complete Guide](/blog/ai-agent-monetization-the-complete-guide). # Outcome-based pricing (/glossary/outcome-based-pricing) **Outcome-based pricing is a billing model where the customer is charged only when a predefined, verifiable business result is achieved.** The vendor does not charge for access, seats, tokens or time. It charges for the result itself: a resolved support ticket, a booked appointment that happens, a payment that clears. ## How it differs from other models [#how-it-differs-from-other-models] Seat pricing charges for access per user. Usage pricing charges for consumption such as tokens, API calls or minutes. Both price the vendor's inputs. Outcome-based pricing prices the customer's result. The vendor only earns when the customer receives the value they were promised. This alignment has a cost: the vendor absorbs the risk of failure. If the agent does not deliver, the vendor earns nothing. Because of that, an outcome definition acts as a [risk contract](/blog/pricing-ai-outcomes-as-risk-contracts), and stronger guarantees justify higher prices. ## What it requires [#what-it-requires] Outcome-based pricing only works when the outcome is defensible: observable by both sides, repetitive enough that no single charge invites scrutiny and hard to dispute. The definition must be machine-checkable, expressed as a [billable condition](/glossary/billable-condition) over events, and the result must stay provisional through a [settlement period](/glossary/settlement-period) so reversals like a reopened ticket never turn into a charge. ## Example [#example] Fin by Intercom charges $0.99 per resolution with no platform fee, the best-known outcome-priced product in customer support. The market benchmarks are covered in [AI Agent Pricing in 2026](/blog/ai-agent-pricing-in-2026-what-fin-sierra-decagon-and-agentforce-actually-charge). ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [Strategies for Monetizing AI Agents](/blog/strategies-for-monetizing-ai-agents-from-seats-to-outcomes) * [Defining Concrete Billable Outcomes for AI Agents](/blog/defining-concrete-billable-outcomes-for-ai-agents) * [How witn works](/docs/guides/how-witn-works) # Per-resolution pricing (/glossary/per-resolution-pricing) **Per-resolution pricing charges the customer for each support issue an AI agent successfully resolves.** It is the support industry's form of [outcome-based pricing](/glossary/outcome-based-pricing) and the most mature outcome market today, anchored by Fin's $0.99 per resolution. ## The definition problem [#the-definition-problem] There is no standard definition of a resolution. Intercom counts a conversation where the customer confirms the answer helped or leaves without asking for more. A customer abandoning a chat is not the same as a customer being helped, which is why Intercom cites an average resolution rate around 71 percent while independent reports place it between 42 and 50 percent. Same product, same customers, different definition. When comparing vendors, always normalize to the effective cost per successful resolution: total spend divided by outcomes actually delivered. A $2.00 per-conversation rate at a 60 percent resolution rate is an effective $3.33 per resolution, with the failure risk on the buyer. ## The fine print that moves the price [#the-fine-print-that-moves-the-price] * **What triggers the charge**: customer confirmation, silence, a closed ticket status or an agent's own claim of success. * **The reopen window**: how long a resolution must survive before it bills. The support-contract equivalent of a [settlement period](/glossary/settlement-period). * **Partial and complex resolutions**: whether a hand-off to a human after substantial agent work bills, and at what rate. Vendors increasingly compete on the strictness and auditability of these definitions rather than on the headline rate. ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [What Counts as a Resolution? The Fine Print of Per Resolution Pricing](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing) * [AI Agent Pricing in 2026](/blog/ai-agent-pricing-in-2026-what-fin-sierra-decagon-and-agentforce-actually-charge) * [Billable condition](/glossary/billable-condition) # Rate card (/glossary/rate-card) **A rate card is a named pricing table that maps each task to a price per unit.** It is the layer that answers "what is this outcome worth for this customer". The [billable condition](/glossary/billable-condition) decides whether a charge happens and the rate card decides what the outcome costs. ## How it works [#how-it-works] A rate card holds zero or more entries. Each entry maps one task to one `price_per_unit`, and each task appears at most once per card. Cards are identified by a lowercase `key` that is unique within an account, so `standard`, `enterprise-2024` and `agency_tier` can coexist as pricing tiers. Rate cards are defined once and shared. A customer is assigned at most one card at a time, which is what lets the same task be sold at different prices to different customers without duplicating the task itself. When an outcome confirms, the invoiced amount is the entry's `price_per_unit`. Each confirmed outcome bills one unit, so the entry price is the charge. ## Prices are snapshotted [#prices-are-snapshotted] The price is read from the customer's rate card when the outcome is created, and recorded on that outcome. Editing a card later does not reprice outcomes that already exist; only new ones pick up the change. Deleting a card archives it rather than removing it, so assignments and historical outcomes stay intact. That snapshot is what makes a repricing safe to do mid-period. An outcome still working its way through its [settlement period](/glossary/settlement-period) keeps the price it was opened with, and an invoice never moves under a customer who has already been told what a result would cost. ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [Rate cards in the docs](/docs/concepts/rate-cards) * [Outcome-based pricing](/glossary/outcome-based-pricing) # Resolution layer (/glossary/resolution-layer) **A resolution layer is the infrastructure that turns a stream of agent events into settled, billable outcomes.** It sits between the agent and the payment processor. The agent does the work and emits events. The resolution layer interprets those events against [billable conditions](/glossary/billable-condition) and contract terms, manages [settlement](/glossary/settlement-period), handles reversals and resolves what actually became billable. The payment processor then charges for it. ## Why it exists [#why-it-exists] Traditional metering records consumption and assumes every recorded event is final. Agent outcomes behave differently: they accumulate state across many events and can be reversed before they are real. Billing them correctly requires a stateful system that evaluates conditions over time, waits out reversal windows and resolves conflicting signals. That system is [the missing layer in most AI agent billing stacks](/blog/the-missing-layer-in-ai-agent-monetization). ## What it must guarantee [#what-it-must-guarantee] * **Determinism.** The same events in the same order always produce the same charges. * **Exactly-once effects.** Duplicate, late or out-of-order events never double-charge or corrupt state. * **Separation from the hot path.** The agent emits fire-and-forget events and never blocks on billing logic. * **Auditability.** Every charge traces back to the triggering events, the condition it satisfied and the settlement moment. Teams that build this in-house discover they are maintaining a second product with financial correctness requirements. The engineering trade-offs are covered in [How We Built witn's Outcome Resolution Layer](/blog/how-we-built-witn-s-outcome-resolution-layer-for-low-latency-and-reliability). ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [Outcome lifecycle in the docs](/docs/concepts/outcome-lifecycle) * [Outcome-based pricing](/glossary/outcome-based-pricing) * [How witn works](/docs/guides/how-witn-works) # Settlement period (/glossary/settlement-period) **A settlement period is the time a billing system waits after the latest event before making a provisional result final.** It exists because agent outcomes are not final when first observed. A resolved ticket can be reopened. A booked meeting can be cancelled. A signed document can be voided. The settlement period absorbs those reversals before anything reaches an invoice. ## How it works [#how-it-works] Every accepted event resets the settlement timer. An outcome cannot confirm or fail while signals are still arriving. When the timer finally expires, the outcome finalizes based on whether the [billable condition](/glossary/billable-condition) holds at that moment: * Condition met: the outcome confirms and becomes a charge. * Condition not met: the outcome is missed and nothing is billed. A reopening event inside the window flips the condition, resets the timer and prevents the charge. That is the mechanism behind the one-sentence outcome specification: we charge when something happens **and remains true for** the settlement period. ## Typical values [#typical-values] In witn the settlement period defaults to 72 hours and is set per agent contract, from 1 second up to 180 days. Longer windows fit outcomes with long reversal horizons, like a code change that must hold in production or an incident that must not recur. The equivalent concept in per-resolution support contracts is the reopen window, part of the fine print that [moves effective prices more than headline rates do](/blog/what-counts-as-a-resolution-the-fine-print-of-per-resolution-pricing). ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [Outcome lifecycle in the docs](/docs/concepts/outcome-lifecycle) * [Outcome-based pricing](/glossary/outcome-based-pricing) * [Resolution layer](/glossary/resolution-layer) # Usage-based pricing (/glossary/usage-based-pricing) **Usage-based pricing is a billing model where the customer is charged for measured consumption of the vendor's service.** The meter counts tokens, API calls, minutes, messages or compute time. The customer pays for what they consume, whether or not that consumption produced a result. ## How it differs from other models [#how-it-differs-from-other-models] Seat pricing charges for access. Usage pricing charges for activity. [Outcome-based pricing](/glossary/outcome-based-pricing) charges for results. The first two price the vendor's inputs; only the last prices the customer's value. Usage pricing sits in the middle: fairer than seats because idle customers pay less, but the customer still carries the risk of paying for activity that delivers nothing. A long, unhelpful conversation costs more than a short, successful one. ## Where it breaks for AI agents [#where-it-breaks-for-ai-agents] For AI agents the meter often points the wrong way. Voice agents billed per minute earn more when calls run long, which is [the opposite of what the customer wants](/blog/how-voice-ai-companies-price-today-and-why-per-minute-billing-is-a-trap). And when a vendor makes its agent more efficient, measured usage drops and [revenue shrinks as the product improves](/blog/why-your-ai-product-s-success-could-shrink-your-revenue). That is why agent vendors move toward hybrid models: a usage or platform floor for predictable revenue, plus outcome pricing for the results that matter. The market's current mix is covered in [AI Agent Pricing in 2026](/blog/ai-agent-pricing-in-2026-what-fin-sierra-decagon-and-agentforce-actually-charge). ## Frequently asked questions [#frequently-asked-questions] ## Related [#related] * [Strategies for Monetizing AI Agents](/blog/strategies-for-monetizing-ai-agents-from-seats-to-outcomes) * [Per-resolution pricing](/glossary/per-resolution-pricing) * [Outcome-based pricing](/glossary/outcome-based-pricing)