Guide
Who grades the outcome? Six ways to decide what counted, and where acceptance infrastructure fits
Every team paying for outcomes answers the same question somewhere: who decides what counted, and can the answer travel? Here are the six shapes the market has settled into, what each is good at, where each stops, and where Spoolis fits. Some are alternatives. Most are systems Spoolis is built to feed.
A support vendor charges per resolution. Their dashboard says 12,483 this month. Finance asks the only question that matters: says who? The vendor's own meter, your ticketing system, a third party, or a rule both sides wrote down before the month started?
Every approach below is an answer to that question. Each one is good at something, and each one stops somewhere. Some are alternatives to Spoolis. Most are systems Spoolis is designed to feed.
The six shapes
| Approach | Who grades | What the record is | Sufficient when | Where it stops |
|---|---|---|---|---|
| Build it yourself | You | Whatever you log | One system, one counterparty, small money, nobody outside your team needs to trust the answer | The moment a second party, a finance review, or a second vendor needs the same answer |
| The platform grades its own agent | The seller | A line in the seller's ledger | Small tickets and a definition of done you are willing to accept as given | The definition can widen, corrections stay inside the seller's system, nothing portable exists for an audit |
| Billing and metering layers | The seller's rule, run by the billing tool over the seller's events | An invoice line item | You are the seller and want outcome pricing without building a meter | The buyer still trusts the seller's events; partial and uncertain usually round to billed or not |
| Evidence and audit layers | Independent readback against a system of record | An evidence record per action | The question is governance: did the agent do what policy allowed | No agreement about what counts, no earned amount, no per-unit acceptance, no counterparty |
| Full-service outcome platforms | The platform's rules engine and its human adjudicators | A final determination with reason codes | Deals large enough for weeks of setup and a custom quote, with one vendor owning measurement, judgment, and settlement | Nothing portable leaves the platform; judge, meter, and bank are one company |
| Acceptance infrastructure (Spoolis) | Whoever the agreement names | A signed, portable Outcome Receipt | Money or an irreversible step depends on the answer and more than one system needs to trust it | Spoolis records and carries the result; your billing, payment, and workflow systems act on it |
1. Build it yourself
A script, a test suite, a check in your orchestrator. This is the right answer more often than vendors admit. It stops working the day someone outside your team has to trust the result: a counterparty, an auditor, a second vendor whose numbers disagree with the first.
2. The platform grades its own agent
Intercom Fin counts an outcome when the customer confirms the answer or leaves without asking for more, and deducts it if the customer comes back to the same conversation, even across billing periods. Zendesk bills only a verified resolution: its agent resolved the ticket and a second model confirmed it inside a 72-hour window. HubSpot moved its Customer Agent to a price per resolved conversation. These are well-built meters, and for small tickets they are enough.
They are also meters owned by the company selling the metered thing. Fin's billable unit widened from "resolution" to "outcome", which now includes procedure handoffs and disqualifications. The reopen deduction lives inside the vendor's ledger. Buy from three such vendors and you hold three definitions of done and three correction policies, none of which you wrote and none of which you can replay. That is what any meter looks like when the meter's owner is the seller.
3. Billing and metering layers
Usage billing platforms such as Orb and Metronome, now part of Stripe, and outcome-native billing tools such as Paid, rate an event the seller sends into a price and an invoice line. Several now support outcome units, settlement periods, and refund rules. If you are the seller and you want outcome pricing without building a meter, this is where you start.
The event is still the seller's event, and the rule is still the seller's rule. The buyer trusts both. Results are usually billed or not billed, so partial and uncertain outcomes get rounded, and the outcome object lives inside the billing tool rather than traveling with the work.
4. Evidence and audit layers
Some tools record what an agent saw, which policy applied, what it did, and what the system of record confirms afterward, as an append-only evidence record with independent readback. Advertising built the same layer twenty years ago when buyers wanted assurance the platform's own measurement could not give them.
The question these answer is governance: did the agent do what policy allowed, and can we prove it later? There is no agreement about what counts as delivered, no earned amount, no per-unit acceptance, and no counterparty. It is a proof of action, not a record of what was owed.
5. Full-service outcome platforms
At the enterprise end, a platform can own the whole deal: design the terms, measure from source systems, verify with a rules engine and human adjudicators, settle with caps, floors, holdbacks, and true-ups, then invoice, with a launch engagement measured in weeks and pricing by quote.
If your deal is large enough to justify that, and you want one vendor to own measurement, judgment, and settlement, this is the shape to buy. The tradeoff is that nothing portable leaves it: the judge, the meter, and the bank are the same company, and the record is theirs.
6. Acceptance infrastructure
This is where Spoolis sits. The agreement is frozen before the work: criteria, evidence, earning rule, who judges, who may dispute. The judge can be a deterministic check, an AI-assisted check, a human, or your own evaluator. The result is a signed Outcome Receipt: per unit accepted, rejected, or uncertain, earned against committed, a review window, and a correction chain that never rewrites history. Any system verifies it offline, and the same record feeds billing, payment, finance, retries, and the next agent.
It is the one shape built for the case where more than one system, or more than one company, has to trust the same answer. Spoolis records and carries the result. Your billing, payment, and workflow systems act on it under their own authorization, with the evidence and the rule behind every line.
How they fit together
- A billing layer consumes a Spoolis Outcome as its verified input. The booking record and meter-event payload exist for exactly that.
- An evidence record can be evidence in a Spool, with its provenance recorded on the receipt.
- A platform's own verifier can be the named judge in a Spool. Bring your own judge exists so you keep your evaluator and still get a portable record.
- The full-service platform is the substitute, not a complement. It answers the same question for large deals by owning all of it.
How Spoolis is built for this
- The rule is the customer's, evaluated as written. Criteria are frozen behind an agreement hash before the work, and the record shows the exact version that governed.
- Expected, claimed, and shown are kept apart. What the agreement expected, what the provider claimed, and what the evidence showed are three statements with three provenances, never blended.
- Finance vocabulary is native. A holdback is a provisional Outcome inside its review window. A true-up is a superseding receipt. A reconciliation statement shows claimed, accepted, rejected, needs review, and the difference.
- The review window is on the record. Provisional and final are facts on the receipt, not a vendor's grace policy.
Start with one outcome
Pick the outcome you already bill or already pay for. Write down what counts, what evidence proves it, and who decides. Run it through the sandbox and read the receipt. If that record is one a second system could act on without learning your vendor's private definition of done, you have found the shape that scales.
Notes
- Fin outcome definition and reopen deduction: Intercom help center, September 2026.
- Zendesk resolution tiers and the 72-hour verification window: Zendesk help center, September 2026.
- HubSpot Customer Agent pricing change: HubSpot company news, April 2026.
- Metronome acquisition: Stripe newsroom, January 2026.
- Descriptions of other categories are general and name no early-stage companies.