Draft refunds without giving away the shop

Refund requests are stressful for a predictable reason: the answer depends on a policy that either does not exist in writing or exists in a document nobody has read since it was written. So each one becomes a judgement call, made under mild pressure, by whoever happens to pick it up.

Consistency is the thing worth automating here. Not generosity, and not refusal.

Write the policy down, properly

This is most of the work and it happens before you open Tenfold.

A usable policy answers four questions: what window applies, who can approve what size of credit, what is never refundable, and what happens when the answer is no. If you cannot write those four down, your team has been improvising, and that is worth knowing on its own.

Put it in Documents. One page is plenty.

Give the employee the bounds and the escape hatch

You handle refund and credit requests using our refunds policy in
Documents.

Always find the specific clause that applies and quote it.

Draft a response when the request clearly falls inside policy. Hold every
draft for my approval; do not send.

Hand it straight to a human, without drafting, when any of these are true:
  the amount is above what an account lead can approve
  they are asking for cash back rather than a credit
  they mention legal action, a chargeback, or a regulator
  they are angry
  the policy does not clearly cover the situation

When you hand off, say which of those triggered it.

"The policy does not clearly cover the situation" is the most important line here. Everything else is a threshold, and thresholds are easy. The dangerous case is a request that is nearly covered, where a confident reading produces a defensible-sounding answer to a question your policy never actually decided. You want that in front of a person every time.

Watch the handoffs, not the drafts

The drafts will be fine. They are quoting a document you wrote.

The handoff list is where the value is: it is a weekly report of the situations your policy does not handle. Most teams find two or three recurring cases that have been decided ad hoc for years.

Let it send only the smallest band

If you get to a point where it is worth letting some send unattended, take the smallest possible slice: requests inside the window, below a modest amount, from customers in good standing. Everything else stays held.

That is a smaller change than it feels, and it is the one that removes the most 2am delay.

What good looks like

Every refund answer cites a clause, similar requests get similar answers, and the exceptions arrive on your desk already labelled with why they are exceptions.

The real payoff is the second-order one: within a month you will have rewritten your policy to cover the three cases that kept turning up as handoffs.

Also covers

Verifying account details before answering anything sensitive. The refund rules above assume you know who you are talking to, and that assumption is worth making explicit, because it is the one that turns a helpful policy into a disclosure.

Before answering anything about a specific account — its balance, its
plan, its invoices, its refund history — check that the sender's email
matches a contact on that account in the CRM.

If it does not match, do not answer and do not confirm or deny that the
account exists. Say the request needs to come from an address on the
account, and hand it to a human.

A close match is not a match. Someone writing from a personal address about
a company account is exactly the case to hand over.

The instruction not to confirm the account exists is the part that is easy to miss. "I can't discuss the Northwind account with this address" has already told an outsider that Northwind is a customer, which is sometimes the only thing they were fishing for.

This check belongs in front of every sensitive answer, not just refunds. It is listed here because refunds are where money and identity meet, and where the cost of getting it wrong is highest.