build.allanninal.dev

Part 4 of 7 · Refund handler series ~5 min read

How a refund reply gets drafted

The checker picked an outcome — in policy, out of policy, high-value, or not covered. Now the drafter has to turn that into something a real person would be glad to receive: kind, clear, in your voice, and honest about the “why.” Get the tone wrong and a fair decision still lands badly. Get the facts wrong and you’ve promised a refund the policy didn’t. Four small guardrails sit between the raw outcome and the draft that reaches a person to approve.

Key takeaways

  • The draft is written from the voice doc — your tone, your phrases, one template per outcome.
  • The reply quotes the exact policy line the checker cited, so the customer sees the “why.”
  • A safety check makes sure the draft doesn’t promise more than the outcome allows.
  • The draft is never sent on its own — it’s attached to a card for a person to approve.
  • Out-of-policy and high-value drafts are written with extra care and the reason up front.

Four guardrails on every draft

Four guardrails between the chosen outcome and the drafted reply A horizontal flow diagram. On the far left, an "Outcome chosen" box: the checker decided one of four outcomes — in policy, out of policy, high-value, or not covered — and carried the cited policy line. Four guardrail gates sit in a row to the right, each drawn as a vertical bar. Gate 1: Voice — pulls the reply template and tone for this outcome from the voice doc, so the draft sounds like the business, not like a model. Gate 2: Citation — drops the exact policy line the checker cited into the reply, so the customer sees the reason, not just the answer. Gate 3: Safety — a deterministic check that the draft doesn't promise a refund amount higher than the request, doesn't approve something the outcome marked disallowed, and doesn't invent an order number or a date; if any check fails, the draft is rewritten or flagged. Gate 4: Package — attaches the draft to an approval card with the original request, the amount, the cited line, and an Approve button, ready for a person. After all four gates pass, the card is routed for human approval via Slack or email. A note at the bottom: the draft is never sent on its own — it always waits for a human tap. Outcome in, out, high-value, not covered Gate 1 Voice & tone template for this outcome your phrases sounds like you, not a model Gate 2 Cite the policy line drop the exact rule into the reply customer sees the why, not just the answer Gate 3 Safety check amount, dates, order all match? if not, rewrite or flag it Gate 4 Package the card draft + request + amount + cited line, Approve button, for a person Route for approval — Slack card (preferred) or SES outbound email (fallback) in-policy → one-tap lane · out-of-policy or high-value → named approver the draft is never sent on its own — it waits for a human tap Each gate is a deterministic check — and the draft never leaves without a person approving it.
Fig 4. Four guardrails between the outcome and the drafted reply. Write in your voice. Quote the policy line. Check the facts. Package the card. Then route it to a person — the draft is never sent on its own.

Gate 1: write in your voice

The voice doc in your Drive folder has one short reply template per outcome and a few notes on tone — how warm, how formal, whether you sign off with a first name. A “yes” template opens with a quick acknowledgment of the problem and lands on the good news. A “no” template leads with empathy and explains the rule plainly. The drafter fills the template with this request’s details and rewrites lightly so it reads like a person wrote it, not a form. The point of the template is that the structure is yours; the model only fills and smooths.

This is where a generic system fails. A reply that says “We regret to inform you that your request does not meet our criteria” is technically correct and completely cold. The voice doc is how you make sure the “no” still sounds like your shop.

Gate 2: quote the policy line

Every draft includes the exact policy line the checker cited, in plain words the customer can read. A “yes” says which rule covers them (“our policy covers faulty items within 30 days”). A “no” quotes the rule that applies (“final-sale items can’t be returned, which is noted on the product page”). Showing the reason does two things: it makes the answer feel fair rather than arbitrary, and it heads off the follow-up email asking “why?” before it’s sent. The reason is the same line that’s in the audit log, so the customer, the approver, and the record all agree.

Gate 3: the safety check

This gate is plain code, not a model. It re-reads the finished draft against the request and the outcome and checks a short list of things that must be true. The refund amount in the draft matches the request and doesn’t exceed it. A draft for an “out of policy” outcome doesn’t accidentally say “yes.” No order number, date, or dollar figure appears that wasn’t in the request. If any check fails, the draft is sent back for one rewrite, and if it fails again it’s flagged for a human with a note about what looked off. Models are good writers and occasionally careless with numbers; this gate is the seatbelt.

Gate 4: package the card

The last gate assembles the approval card: the drafted reply, the original request, the amount, the cited policy line, and the buttons a person uses to act. In-policy, under-cap cases get the simple one-tap card — Approve or Edit. Out-of-policy and high-value cases get the same card but routed to the named approver in the policy, with the reason up front so the harder decision is easy to make. Not-covered cases get a card with no draft — just the request and a note that the policy doesn’t address it, so a person can decide from scratch.

The card goes to Slack by default (a Slack message with action buttons is faster to act on than an email) and falls back to email if Slack isn’t set up. Either way, the draft sits on the card and waits. It is never sent on its own — which is the whole point of the system, and the subject of the next post.

Why the guardrails exist

None of these gates are clever. They’re the small care a thoughtful support lead would take writing the reply themselves — sound like us, explain the reason, double-check the numbers, and never hit send without a second look. Putting them in code as four small steps makes that care part of every reply, instead of something you’re trusting a busy person to remember at 4:55pm on a Friday.

Next post: how a refund gets approved — what the Approve and Edit buttons actually do, how the money only moves after a human tap, and how every action is logged.

All posts