How to Write a Refund Policy an AI Can Actually Answer From

A customer asks whether they can return something they bought three weeks ago. You have a refund policy, it is uploaded, it is sitting right there in the knowledge base, and the AI still hedges. The policy is present. The answer is not findable inside it. That gap is almost always the same problem: the refund policy was written to protect the business in a dispute, and that is a completely different document from one an AI can answer a customer from. This post is about writing the second kind, with before and after examples you can copy the shape of.

Why the refund policy is the worst doc in your knowledge base

Of all the documents a small team uploads, the refund policy is the one I see cause the most trouble. The reason is in its origin. Most refund policies were drafted once, early, often half-copied from a template, with the goal of being defensible. The language hedges on purpose. It says things like at our discretion and subject to the conditions herein and we reserve the right, because that phrasing is useful if a customer ever disputes a charge and you need to point at the terms you agreed on.

That instinct is reasonable for a legal document. It is poison for retrieval. An AI support tool does not read your whole policy and summarize it. It pulls the small passage that best matches the question and answers from that passage alone. If the passage it pulls is a hedge, the customer gets a hedge. The mechanics behind this are covered in detail at /blog/how-ai-reads-your-docs-chunking-retrieval, but the short version is that every sentence in your refund policy is a candidate answer, and a sentence written to avoid committing to anything makes a terrible answer.

So the fix is not to delete the defensible policy. Keep that for your terms of service and your disputes. The fix is to write a second, plain document whose entire job is to answer the refund questions customers actually ask. Those two documents can coexist. Only the plain one goes in the knowledge base.

The questions a refund policy actually has to answer

Before rewriting anything, it helps to know what you are writing for. Across almost any product, refund questions collapse into a short list. If your document answers these cleanly, it covers the large majority of what comes in.

• How long do I have? The window, counted from a specific event (purchase, delivery, or first use), not a vague duration.
• What condition does the item have to be in? Unused, unopened, original packaging, tags attached, or none of those.
• What is not refundable at all? Final sale items, digital goods, gift cards, personalized products, anything you never take back.
• Who pays return shipping? You, the customer, or it depends on the reason for the return.
• How do I actually start one? The concrete first step, not a promise that someone will help.
• When do I get my money back, and to where? The processing time and the destination (original payment method, store credit).

Notice that none of these is answered by we want you to be happy. Every one of them wants a fact: a number, a condition, a yes or a no. The rewrite is mostly the work of replacing sentiment with facts, in an order the AI can pull cleanly.

Before and after: the return window

Start with the single most asked refund question: how long do I have. Here is the kind of sentence that tends to be in the original policy.

Read that as a chunk pulled out on its own, which is exactly how the AI sees it. It contains no window, no condition, no number. A customer asking can I still return this after three weeks gets back a warm sentence that does not answer the question, and now the AI either hedges or, if your confidence routing is doing its job, flags the message for a human because it could not find a real answer. The rewrite puts the fact first.

The second version answers the question by itself, no matter what surrounded it in the original document. It commits to a number, it defines when the clock starts, which heads off the follow-up that otherwise generates a second email, and it handles the after-the-window case honestly rather than pretending the window does not exist. The warmth you lost is not gone. It moves to your tone settings and your actual replies, where it belongs, instead of living inside a policy fact where it blocks the answer.

Before and after: conditions and what is not refundable

The second cluster of questions is about eligibility. What condition does the item need to be in, and what can never be returned at all. This is where vague policies cause the most expensive misunderstandings, because a customer who believes something is refundable and then learns it is not is a customer who is now upset about two things.

This passage is three sentences of pointing at conditions without stating any of them. The AI cannot answer is my opened blender returnable from it, because the conditions it refers to are not in the text. The result is either a non-answer or, worse, the AI guessing a condition you never wrote down. The rewrite names the conditions and the exclusions in plain terms.

Now the AI can answer three distinct questions from one passage: the general condition, the used-item case, and the specific exclusions. Listing the non-refundable categories explicitly is the highest-value edit in the whole document. A customer who asks can I return this gift card should get a clean no with a reason, not a hopeful maybe that you then have to walk back.

Before and after: return shipping and refund timing

Two more facts round out most of the volume: who pays to send the item back, and when the money actually lands. Both are frequently missing entirely, because the original policy author knew the answer and never thought to write it down.

Standard procedures is not a procedure. Will be communicated is not a timeframe. Both sentences promise that an answer exists somewhere else, which is the opposite of what a retrievable document does. The rewrite states the actual rule, including the common case where it depends on the reason.

This covers the branch most policies skip: shipping cost depends on fault. Writing both branches in one passage lets the AI answer who pays correctly without guessing, and it gives the customer the refund timing in the same breath, which is usually their very next question. Use a real number for the processing time. If you are not certain of it, that uncertainty is a thing to resolve before you upload, not to paper over with within a reasonable timeframe.

The exceptions trap

There is one place where a plainer, more confident document can backfire. When you write the window as a hard 30 days, you make the AI very good at enforcing it. But some refund requests are not questions, they are appeals: the loyal customer on day 34, the person whose item broke on day 31, the case where you would quietly bend the rule if a human read it. A document that answers refund questions crisply will also deny those appeals crisply, and a crisp denial to a good customer is exactly the reply you did not want automated.

The fix is not to make the policy vaguer again. It is to write the document so the AI answers the standard case and routes the exception. You can say so directly in the doc.

A line like that does two things. It tells the AI what to do with an appeal, which is to hand it off instead of enforcing the rule like a vending machine. And it documents, for your own team, that exceptions are a human decision. This connects to a bigger point I have made before: anything that is a judgment call rather than a lookup should route to a person, and refund exceptions are the textbook judgment call. The full version of that argument is at /blog/support-questions-never-let-ai-answer. The short version is that the AI should know your policy cold and also know when not to apply it alone.

The shape of a good refund doc

Put the pieces together and the finished document is short, which surprises people who expected a rewrite to mean more words. A refund doc that answers the real questions is usually under 300 words. Here is the shape.

1. Lead with the window and when it starts. The most asked question gets the first, cleanest sentence.
2. State the condition the item must be in, as its own sentence.
3. List what is never refundable, explicitly, as its own short list.
4. Say who pays return shipping, including the depends-on-fault branch if you have one.
5. Give the refund timing and destination with a real number and a real place.
6. Name the exception path and point it at a human.

Write every item as a plain declarative sentence that would still make sense if someone read it with nothing above or below it. Repeat the subject instead of leaning on it and the above. Keep one topic in this file: refunds and returns only. Shipping speeds, order changes, and warranty claims each get their own document, because mixing topics produces blurry passages that lose retrieval to focused ones. If you want the fuller reasoning on why one topic per file matters, it is in /blog/build-ai-support-knowledge-base.

Test it in ten minutes

A rewrite is a guess until you check it, and checking is fast. Take the six questions from near the top of this post, phrase each one the way a customer would actually type it, and send them to your AI. How long do I have to return this. Can I get a refund on an opened item. Who pays to ship it back. Do not grade on whether the reply sounds pleasant. Grade on one thing: does the specific fact in the answer match the specific fact in your new document.

Then run the two tests that matter most. Ask something the document deliberately excludes, like a refund on a gift card, and confirm the AI gives the clean no rather than a hopeful maybe. And ask for an exception, like a return a week past the window as a one-time favor, and confirm the AI routes it to a human instead of either granting it or coldly refusing. If both of those behave, your refund doc is doing its job. Each miss is a sentence to tighten, and the fix is almost always to make the passage that should have answered more self-contained.

How this works in Trigli, and what it does not do

Trigli answers from the documents you upload and nothing else. A refund doc you paste in or upload as a PDF gets chunked and retrieved the same way every other source does, so the rewrite advice here is what makes the difference between a refund answer that lands and one that hedges. The exception path has real teeth: you can route refund and chargeback keywords straight to human review so an appeal never gets an automated denial, and a confidence floor catches the phrasings your keyword list did not anticipate. Draft-and-approve is the default while you calibrate, so you see the refund replies before they go out and can tighten the doc behind any that miss.

What Trigli does not do is move the money. The AI can quote your refund window, explain the conditions, and tell a customer how to start a return, but it does not reach into Shopify or your payment processor to issue the refund itself. That stays a human step, which for refunds is arguably the right boundary anyway. There is also no phone or SMS channel, and no skill-based routing that auto-assigns refund tickets to one specific person by expertise yet. If you need the AI to process returns inside your store backend, that is a different tool. None of the writing advice here is specific to Trigli, though: a clean, answer-first refund document improves retrieval on any grounded AI support tool, so the document is portable even if the tool is not.

The short version

Your refund policy probably reads like it was written to win a dispute, because it was. That document is the wrong source for an AI to answer customers from. Write a second, plain one: lead with the window and when it starts, state the condition, list what is never refundable, say who pays shipping, give the refund timing with a real number, and point exceptions at a human. Replace every hedge with a fact. Then test it with the questions customers actually ask, and tighten the sentences that miss. A refund doc under 300 words that answers the real questions beats a two-page policy that answers none of them cleanly.