What Counts as One 'Resolution' in AI Support Pricing

What to Check in “$0.99 per Resolution”

Fin, the AI agent for customer support, charges based on outcomes. Its flagship billing unit—a “resolution”—costs $0.99 each. Even if a single conversation covers several questions, you’re billed only once.

What I checked first wasn’t the price but the definition of “resolution.” It covers not only cases where the customer explicitly says they were helped, but also cases where the customer simply doesn’t ask for further help after receiving Fin’s answer. The latter is called a “presumed resolution.”

Fin’s current help documentation states that if the customer doesn’t re-engage with the conversation within 24 hours of the last reply, it counts as a presumed resolution. However, exchanges consisting only of greetings, or cases where Fin asked a clarifying question the customer never answered, aren’t billable. And even after a resolution has been logged, if the customer returns to the same conversation and asks for more help, that resolution gets credited back—even if the billing period has already rolled over. Fin’s resolution and billing terms.

Even with these correction rules in place, it’s hard to know whether a customer who got an answer and left was actually satisfied. Maybe the issue was resolved—or maybe they were disappointed with the answer and went looking for help elsewhere. That’s why you need to check whether the outcome you can be billed for under the contract actually matches the business result your company wants.

What You Outsource Determines the Payoff

Fin’s price sheet has several distinct billable items.

Billing item	Meaning	Price per unit
Resolution	No further help requested after the final answer	$0.99
Handoff after completing a defined procedure	Completes a process the client designed to end in a human handoff	$0.99
Disqualified lead	Determined not to meet the client’s sales criteria	$0.99
Qualified lead	Determined to meet the client’s sales criteria and connected	$9.99

There’s a real difference between simply failing to resolve something and handing it off to a human, versus gathering the necessary information and completing a procedure specifically designed to end in a handoff. The latter can be billed as a completed task. You should also check what features come with your plan or connected support platform. Fin pricing.

Even at the same $0.99, the value a company captures can differ. Whether the customer’s issue was fully resolved, whether the agent is ready to pick up the case, and whether an unqualified prospect was filtered out — these need to be evaluated separately. The label “outcome-based pricing” doesn’t mean every cost of failure shifts to the vendor. The costs of human follow-up and customer churn can still land on the buyer.

Succeeding once and succeeding repeatedly aren’t the same thing

I think when we evaluate an agent’s results, we need to look at what “success rate” actually means. A one-shot consultation that has to nail it the first time and a task where you generate multiple answers and pick the best one demand different things.

Anthropic explains this with two metrics. pass@k is the probability of succeeding at least once across k attempts, and pass^k is the probability of succeeding on all k attempts. Which metric matters more depends on the job. If you can pick the correct result out of several attempts, the first metric is useful; if you need to deliver a stable result to a customer every single time, consistent repeat success is what counts. Anthropic’s explainer on evaluating agents.

Let’s say the probability of success on a given task is 90% each time, and each attempt is independent. The probability of succeeding at least once in 10 tries is nearly 100%, but the probability of succeeding all 10 times is only about 35%. That doesn’t mean the other outcomes involve failing all 10 times — it means there’s a substantial chance of failing at least once somewhere in those 10 tries.

There’s actual research measuring this kind of repeat reliability. In a 2024 retail-support experiment on τ-bench, a GPT-4o–based agent had a single-attempt success rate of around 61%, but the rate at which it succeeded on the same task all eight times in a row was under 25%. This reflects the specific model and test setup at the time, and shouldn’t be read as the current failure rate for all agents — it’s simply an example showing that average success rate alone can’t explain how stable an agent is at repeated tasks. τ-bench paper.

Well-designed retries and verification steps can narrow this kind of variance. But you also have to factor in the cost of extra calls, review time, and the delays that come with processing.

Splitting the model’s usage fee from the actual cost of doing the work

The numbers below aren’t measured data — they’re just illustrative, to show the calculation method. Let’s say a team processed 500 cases in a month, and when checked against a fixed standard, 350 of those cases were actually resolved.

Item	Monthly cost
Model/tool API calls	₩300,000 (~$216)
Monitoring, storage, integration	₩200,000
Human review, 40 hours × ₩40,000	₩1,600,000
Failure recovery, 10 hours × ₩40,000	₩400,000
Total	₩2,500,000

Divide the ₩300,000 model/tool cost by the 500 cases processed, and you get ₩600 per case. Divide the ₩2,500,000 total cost by the 350 cases actually resolved, and you get about ₩7,143.

The two calculations differ in both the scope of cost and what counts as a “case.” If you just change the denominator to successful cases, ₩300,000 ÷ 350 gives you about ₩857. Add in the rest of the operating costs on top of that, and you land at ₩7,143.

In this example, human review and recovery account for 80% of the total. So even if you cut the model/tool cost in half, total cost only drops from ₩2,500,000 to ₩2,350,000 — a 6% reduction. This doesn’t mean human cost is 80% of every AI workflow. But if your own workflow’s cost structure looks similar to this, it means negotiating a lower model unit price alone won’t get you very far.

To choose where to improve, you need to look at two things together: whether you can get more work properly finished for the same cost, and whether you can cut review and operating time without sacrificing quality. And if cutting review time leads to more follow-up inquiries and more recovery work, you have to add that cost back in too.

What the Shift to Outcome-Based Pricing Can Obscure

In issue 147, I covered the shift from seat-based pricing to outcome-based pricing. I still think that read holds up. But there’s something buyers need to look at more closely. Just because you’re paying for a unit closer to actual outcomes rather than the number of seats used doesn’t mean that unit automatically aligns with your own company’s definition of success.

Outcome metrics also get used to narrate corporate growth. On June 15, Salesforce announced a deal to acquire Fin for roughly $3.6 billion, citing cases where Fin resolved an average of 76% of support ticket volume start to finish. At the time of the announcement, the deal was expected to close in Salesforce’s fiscal 2027 Q4. Salesforce’s acquisition announcement.

To actually use that number in your own vendor evaluation, you need to check which client and which type of ticket produced it, and what counted as “resolved.” The announcement alone doesn’t tell you that your company would also see 76% resolution. Nor is there enough basis to conclude that a single billing metric or resolution rate determined the entire acquisition price.

If it were me, alongside the unit price, I’d examine how “outcome” is defined, the process for changing aggregation criteria, the conditions for deductions when a case gets re-escalated, and how much access you have to verify the underlying records. And for work where the handoff to a human is itself counted as the outcome, I’d separately calculate the time spent after that handoff.

Include operations and review costs in the estimate

When comparing AI adoption costs, I think it’s worth checking the following items.

1. Model and product licensing/usage fees
2. External tool and API call costs
3. Storage, search, and network costs
4. Retry and failed-call costs
5. Costs of building evaluation data and checking quality
6. Time spent on human review and approval
7. Time spent recovering from outages and errors
8. Costs of security, training, and process changes

There’s no need to add costs that are already baked into the product’s pricing. You should also separate the initial setup cost from the recurring monthly operating cost. What matters isn’t padding out the list of line items—it’s calculating the same scope of costs for every product you’re comparing.

The criteria for counting a “case” also need to fit the actual work. For customer support, you might define it as a case closed without a repeat inquiry on the same issue within a set period; for sales, a qualified lead actually taken on by a rep; for development, a change that passed the necessary review and testing and was merged. Not everything needs a full human inspection. You can combine automated checks with sample audits—but you need to know what kinds of errors that combination might miss.

Cost per token is useful when you’re improving the technology itself. Cost per task actually completed is useful when you’re deciding whether to keep the adoption going. Look at both metrics together, but make sure you clearly note what exactly each number is measuring.

What I Look at Before the Savings Number

When I look at a proposal for adopting AI, the first thing I check is what the team is counting as success, and who gets to make that call. Even if the math is correct, misreading the result changes what response you should take.

Say review time dropped from 40 hours to 10 hours. That could mean automated verification improved and less human review was needed — or it could mean a check step got skipped. If you only log the time, you can’t tell the two apart. What you need to look at alongside it is the actual error rate, repeat inquiries, and the time spent on rework and recovery.

Fin’s estimated resolution rate deserves the same scrutiny. Once you understand the vendor’s classification and its after-the-fact deduction rules, you can sample cases to see how well they match your customers’ actual experience. There’s a real choice to be made here — somewhere between simply trusting the vendor’s aggregated numbers and having a human re-read every single conversation.

This week, I’d suggest picking one AI tool you’re currently using and checking three things together: how many cases it processed last month, how many were resolved by your own defined criteria, and how much extra time humans had to put in. With those three numbers in hand, you can talk not just about whether the tool is cheap, but whether it’s actually lightening the load.

💬 Is there a task where checking AI output takes up a lot of your time? Tell me what you check, and why it’s necessary.

References & Further Reading

• Fin pricing page and detailed terms for outcome-based pricing
• Anthropic’s approach to evaluating agents, January 9, 2026
• The τ-bench study, June 2024
• Salesforce’s announcement of its definitive agreement to acquire Fin, June 15, 2026

Worth reading alongside this issue

• Issue 147: The shift from seat-based to outcome-based pricing
• Issue 180: The trouble with actual work time versus billed time

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.