From Startup Fortune · · 3m
How to Structure AI Agent Refund Policy Without Bad Precedent
Write a usage-based refund policy with three fixed elements before launch to avoid setting bad precedent.
In brief
Write a usage-based refund policy with three fixed elements before launch to avoid setting bad precedent. Founders should define failed runs, pick credit or cash default, and cap claim windows to prevent inconsistent refunds. Originally reported by Startup Fortune.
First refund sets future expectations
The first refund you approve becomes the refund every future customer expects.
Usage-based refunds need three fixed elements
A written usage based refund policy needs three fixed elements before launch: a defined failed-run threshold, a credit-versus-cash default, and a cap on how far back a claim can reach.
Vercel and Zapier publish SLA credit tables
Vercel and Zapier both publish SLA credit tables rather than negotiate refunds case by case, which keeps each claim a lookup instead of a conversation.
Verbal refund promises create precedent
Verbal or Slack-thread refund promises create precedent because procurement teams screenshot them and bring them back at renewal.
Partial-run billing disputes are common
Partial-run billing disputes are the most common AI agent complaint because customers get charged for a task that errored out after consuming tokens.
30-to-60-day claim window stops audits
A 30-to-60-day claim window, stated in the contract, stops customers from auditing six months of logs after a surprise price increase.
Usage-based AI agents fail differently
Usage-based AI agents fail in ways flat-rate SaaS never did: a run burns 40,000 tokens, errors out at step nine of ten, and the customer gets billed for the whole thing.
Refund isn't a one-time transaction
A refund isn't a one-time transaction. It's a data point the customer's procurement team files away.
Define failed run in billing terms
First: define a failed run in billing terms, not product terms. Your engineering team already has a definition of failure, probably an error code or a timeout threshold.
Pick credit or cash default
Second: pick credit or cash, and pick it as a default, not a case-by-case call. Account credit protects your cash position and keeps the customer inside your product.
Cap how far back a claim can reach
Third: cap how far back a claim can reach. Without a stated window, a customer who gets surprised by a price increase at renewal will go digging through three months of logs.
No policy leads to inconsistent refunds
Here's the sequence, and it's not hypothetical. A customer runs your agent for a month, hits a rough patch where the model you're calling underneath has a bad week.
Policy survives renewal fights
Put the policy in the contract, not in a help center article you can quietly edit later. A help center page is the kind of thing a procurement team treats as non-binding.
What happens next
The customer's procurement team keeps records specifically so that the next negotiation starts from the most generous thing you've ever done.
What matters most
Founders should define failed runs, pick credit or cash default, and cap claim windows to prevent inconsistent refunds.
