Playbook, developer tools company
The units were consumed, and the customer still wants the money back
The characteristic refund request here is not about a product that disappointed anybody. It is about consumption: a retry loop with no backoff, a test suite pointed at the live environment, a backfill left running over a weekend. The meter did exactly what it was built to do and the charge is arithmetically correct. What is being asked is whether you will set that aside, which only a person can decide.
Why this is not the general answer
The handling pattern for refund requests holds across every trade. What follows is the part that does not.
- The charge is usually correct and both sides know it, so the request is for a discretionary act rather than a correction, which makes any encouraging noise from an assistant actively harmful to the person who has to answer next.
- The cause is nearly always a mistake in the customer's own code, which makes the exchange uncomfortable in a way it never is on a seat priced product, and the assistant must not assign that blame either.
- The prevention exists and is the more useful half of the reply: alert thresholds and a hard limit that stops traffic, which most accounts have never configured because nothing mentioned them at signup.
- Consumption cannot be handed back. A seat can be credited cleanly, but the work behind an overage was genuinely performed, so the goodwill decision carries a real cost and belongs to somebody who is allowed to spend it.
How it arrives
- our script looped and burned the whole allowance overnight
- can we get money back for usage we did not intend
- is there a hard spend cap we can set
- we were charged overage from a staging environment
- the free allowance ran out and we were billed with no warning
- can you put it on next month as a credit instead
What has to be indexed for this to work
| Your position on refunding delivered usage, stated plainly | Whether consumed units are ever returned, whether a credit against a later period is the usual route instead, and who decides. Publish the version you actually apply, because it will be quoted back at you by somebody holding a screenshot. |
|---|---|
| Alerts, thresholds and hard limits, and where each is configured | What exists, what each does when it triggers, and crucially whether it stops traffic or only sends a message. This is the page that prevents the next one of these, which is why it belongs in the reply rather than in a follow up. |
| How overage is calculated and when it settles | The rate, whether it accrues continuously or lands at the end of a period, and whether any grace applies. A customer who cannot tell when a charge lands assumes it already has and writes accordingly. |
| Whether environments can be separated for billing | A staging spike billed alongside live traffic is a specific and avoidable annoyance, and whether your product separates them is a plain yes or no that people spend a surprising amount of time hunting for. |
The reply
Usage that was delivered is charged, and whether anything is set aside in a case like this is decided by the team rather than by a rule I could apply, so I am not going to guess at the outcome [1]. What is worth doing straight away is the prevention: there are alert thresholds and a hard limit that stops traffic rather than only warning, and both are configured on that page [2]. If the spend came out of a non production environment, the billing separation options are described there too. I cannot see your usage, your charges or approve anything. Leave your name, the account email, the organisation and roughly when the spike happened, and it goes to whoever reviews these.
It refuses to predict the outcome in the same sentence that names who decides, which is the only wording that reads as neither a brush off nor a hint. Moving to prevention immediately gives the reader something to do while they wait, and it is the part that stops a second occurrence. Asking for the time of the spike is what lets a reviewer find it without another exchange.
Where it stops
The trigger. Any request for money back or for a charge to be waived, and any claim that a charge was produced by a fault rather than by usage.
Whether a charge is set aside is a decision somebody makes after looking at the account, and I can neither make it nor see the charge. Leave your name, the account email, the organisation and roughly when it happened, and they will come back to you.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say a refund or a credit is likely, usual, or something the company normally agrees to in cases like this.
- Never say a charge was caused by a fault on your side, since nothing here can see what generated it.
- Never tell a customer their own code caused the spike, however obvious that looks from the description.
- Never offer a credit, a waiver or a raised limit, because those belong to somebody with the authority to grant them.
Questions
- Is it cruel to answer with the caps page when somebody has just lost money?
- It would be if it arrived instead of the handover. Offered alongside it, it is the only part of the reply the reader can act on immediately, and it is the second occurrence rather than the first that ends a relationship.
- Can it tell whether the usage was real?
- No. It reads no meter, no log and no invoice. It can describe how the counter increments, which occasionally explains the figure by itself, and everything specific to the account has to reach a person who can open it.
- Should we publish the position if the answer is usually no?
- Especially then. An unpublished position gets renegotiated in every conversation, at whatever hour it arrives, and the outcome depends on who happened to reply. A published one is applied evenly and argued with far less often.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling refund requests in generalA refund question is really about eligibility and timing. What to index, what the reply may promise, and where it has to reach a person.
- The first sign of a billing problem is a status code at four in the morningA billing suspension ends up as a rejected call in somebody's alerting. The retry schedule and the error string are the whole answer.
- The interface is a terminal, so the usual accessibility answers do not applyColour as the only signal in output, a keyboard driven interface and code blocks read aloud. These arrive as defect reports, not form problems.
- Can we get into the beta is a request rather than a questionEarly access programmes, regions that are not open yet and a library for a language nobody has written. What can be said without committing anyone.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.