AI customer support prompts for Shopify: returns, refunds, order status and FAQs

You can get an AI to write a polite return reply in ten seconds. The expensive part is the reply that says "Sure, we'll refund you in full" to someone who is 40 days past your 7-day window. Once that sentence is in writing, you either honour it or argue about it.

So this post is built around one idea: the model writes, your rules decide. Below are prompts for the five jobs a Shopify support inbox actually has (macros, returns, refunds, order status, escalation), plus the guardrails that keep the model from inventing policy. Every prompt here is an untested template unless I say otherwise. I did not run these against a live store, and the example outputs are illustrative, not captured.

If you want the engineering version (retrieval, tool calls, evals), read how to build a support agent that doesn't hallucinate. This post is the prompt layer a store owner can use today in a chat window or a helpdesk macro.

What should an AI support prompt contain?

Five blocks, in this order. Skip one and you will see it in the replies.

1. Role and voice. Two sentences. Who you are, how you sound.
2. Policy as rules. Numbered, short, with numbers. Not a pasted policy page.
3. Facts for this ticket. Variables filled in by you or your helpdesk: order date, delivery date, item, price, condition, payment method.
4. Allowed actions. What the model may offer. Anything not on the list is forbidden.
5. Output format. A verdict first, then the draft.

Here is the base prompt. Everything else in this post is a variation.

You write customer support replies for [STORE NAME], a small online store.
Voice: warm, plain, brief. No exclamation marks. No more than one apology.

POLICY (these rules are the only source of truth; do not infer anything else):
1. Returns accepted within [7] days of delivery.
2. Accepted reasons: wrong item, damaged item, size exchange.
3. Not accepted: change of mind, used items, items without original tags.
4. Refunds go to the original payment method after we receive and inspect the item.
5. Shipping fees are refunded only if we sent the wrong or damaged item.
6. Anything not covered above: do not decide. Mark NEEDS_HUMAN.

TICKET FACTS:
Order number: [ORDER_NUMBER]
Item: [ITEM]
Delivered on: [DELIVERY_DATE]
Today: [TODAY]
Customer reason: [REASON]
Item condition per customer: [CONDITION]

ALLOWED ACTIONS: explain policy, ask for photos, send return instructions,
mark NEEDS_HUMAN. You may NOT promise a refund amount, a refund date,
store credit, a free replacement, or any exception.

OUTPUT:
VERDICT: one of ELIGIBLE, NOT_ELIGIBLE, NEEDS_HUMAN
REASON: one sentence citing the rule number
DRAFT: the customer reply, under 90 words

Why a verdict line? It forces the model to commit to a decision you can read in two seconds, and it lets you check the verdict against your own rules before the draft goes anywhere.

Prompt for return and exchange replies

The base prompt handles most returns. Add this when the reason is vague ("it doesn't fit", "not what I expected"), because that is where models get generous.

If the customer's reason does not clearly match rule 2, do not guess.
Ask exactly one clarifying question, such as whether the item arrived
damaged or whether they want a size exchange. Do not mention that
change-of-mind returns are not accepted unless the customer has
stated that as the reason.

That last sentence matters. Models love to pre-emptively list every exclusion, and a customer who wrote "doesn't fit" reads a "no returns for change of mind" lecture as an accusation.

An illustrative output for a delivery 3 days ago, reason "wrong size", condition "unworn, tags on":

VERDICT: ELIGIBLE
REASON: Rule 2 covers size exchanges and the item is inside the 7-day window.
DRAFT: Hi Asha, thanks for letting us know. A size exchange is fine here.
Reply with the size you'd like and a photo of the tags still attached,
and I'll send exchange instructions. The exchange ships once we've
received and inspected the original.

Notice what it does not say: no delivery date for the new item, no "free", no refund. Those are the lines a looser prompt would add.

Prompt for refund replies that can't overpromise

Refunds are where the money leaves, so tighten further. Two additions to the base prompt:

REFUND LANGUAGE RULES:
- Never state a refund amount unless it appears in TICKET FACTS as REFUND_AMOUNT.
- Never state a refund timeline in days. Say: "Once the refund is issued,
  the time it takes to appear depends on your bank or payment provider."
- If REFUND_AMOUNT is not provided, say a team member will confirm the amount.
- Never use the words "guarantee", "definitely", "full refund" or "immediately".

The timeline rule is deliberate. When you issue a refund from the Shopify admin, how long it takes to show up is decided by the payment provider and the customer's bank, not by you. I checked Shopify's help page on refunding and cancelling orders on 2026-10-09 and it gives no timeframe for when the customer sees the money (it only says a customer whose original payment method is gone must contact their bank to claim the funds), so I would not put a number of days in a prompt unless your payment provider's documentation gives you one. Check your provider's page and paste that sentence into your policy rules yourself.

For COD orders the refund path is different (there is no card to reverse), and models will not know that. If you sell cash on delivery, add a rule stating exactly how you refund those, for example bank transfer after the customer shares account details through a secure channel you control. Never ask the model to collect bank details in chat.

Prompt for order-status triage

Order status is the highest-volume ticket and the lowest-risk, which makes it the best first thing to automate. The trick is to separate classifying the message from answering it.

Classify the customer message into exactly one category:
WHERE_IS_ORDER, CHANGE_ADDRESS, CANCEL_ORDER, DAMAGED, WRONG_ITEM,
RETURN_REQUEST, REFUND_STATUS, PRODUCT_QUESTION, COMPLAINT_OR_THREAT, OTHER.

Also extract: order_number (or null), language of the message.
Return JSON only:
{"category": "...", "order_number": "...", "language": "...", "confidence": "high|medium|low"}

If the message contains more than one category, return the one that
costs the customer the most if we get it wrong (priority:
COMPLAINT_OR_THREAT > DAMAGED > WRONG_ITEM > CANCEL_ORDER > the rest).

Run that first. Then route: WHERE_IS_ORDER with a found order number goes to a reply prompt that receives the tracking status as a variable. The model never invents a courier status because it never has to; you hand it the status.

Write a 2-3 sentence reply. Use ONLY the tracking facts below.
If TRACKING_STATUS is empty, say the order has not been scanned yet
and that you'll check again, and do not estimate a delivery date.

Order: [ORDER_NUMBER]
TRACKING_STATUS: [LAST_SCAN_TEXT]
LAST_SCAN_TIME: [TIMESTAMP]

"Do not estimate a delivery date" is the line that saves you. Without it, a model asked "when will it arrive?" produces a confident date from nowhere.

CANCEL_ORDER deserves its own rule: cancellation depends on whether the parcel has shipped, and only your system knows that. Make the prompt require a FULFILLMENT_STATUS variable and refuse to promise a cancellation if it is fulfilled.

Macros: turning the prompts into saved replies

Not every store needs a live AI in the loop. A cheaper pattern: use the model once to write a macro library, then review it by hand.

Write 8 reply macros for a Shopify store. For each: a name, when to use
it, and a reply of under 80 words with placeholders in square brackets.
Macros: order delayed, address change after shipping, wrong item received,
damaged item (ask for photos), size exchange, return window passed,
discount code not working, product back in stock question.
Rules: no promises of timelines, refunds or exceptions. Each macro must
end with the next step the customer should take.

Then edit every macro against your actual policy. The model's first draft will contain a timeline or a "we'll make it right" somewhere. Delete it. Five minutes of editing here replaces hundreds of future one-off replies.

Escalation rules the model can't talk itself out of

Escalation should be a hard rule, not a judgement call. Put these in the prompt as an override that runs before anything else:

ESCALATE TO A HUMAN (set VERDICT: NEEDS_HUMAN, draft a holding reply only) IF:
- The customer mentions a lawyer, consumer court, police, chargeback,
  dispute with their bank, or posting publicly.
- The order total is above [ORDER_VALUE_LIMIT].
- The customer reports an allergic reaction, injury, burn or safety issue.
- The same customer has contacted us [3] or more times about this order.
- The customer asks for something outside the policy rules.
- You are not sure.

The holding reply must only say: we've received your message, a team
member will review it personally, and we'll reply by [HOURS] hours.
It must not mention refunds, fault or compensation.

The final bullet, "You are not sure," is doing real work. Models rarely volunteer uncertainty unless you give them a named exit.

Pick ORDER_VALUE_LIMIT from your own numbers. A store with a ₹800 average order has a very different threshold from one selling ₹15,000 items. I'm not going to hand you a universal figure because there isn't one.

Guardrails: test the prompt before customers do

A prompt that works on the happy path proves nothing. Build ten test tickets and run all of them through the prompt after every edit. Include:

Run them, read every output, and fix the prompt where it fails. If you want to automate this, prompt regression tests with promptfoo are the same idea in CI. For the underlying failure mode, the hallucinations lesson explains why a model fills policy gaps with plausible rules.

Two more guardrails worth adding outside the prompt:

• Draft mode first. For the first weeks, nothing the model writes goes out unedited. Track how often a human changes the draft. Categories with near-zero edits can be automated later.
• Log the verdict. Store the VERDICT and REASON line next to the ticket. When a customer disputes a reply, you can see which rule the model cited.

If your team handles support in India across languages and tones, AI prompts for customer support in Indian BPOs covers tone and language handling in more depth, and the e-commerce agents post shows a tool-calling build for order lookups.

Privacy: what not to paste

Send the model what it needs and nothing else. Order number, item, dates and the customer's message are enough. Leave out phone numbers, full addresses, email addresses and anything payment related. Consumer chat tools and APIs have different data terms, so read the terms of the one you use rather than assuming. Rules on handling customer personal data vary by country, so check with a professional about your own obligations. The privacy guide on what not to paste into ChatGPT is a good checklist for the team.

A one-hour setup plan

1. Write your policy as 6 to 10 numbered rules with numbers in them (days, amounts, conditions).
2. Paste the base prompt, fill in the rules, and save it as a custom GPT, a Claude project, or a helpdesk snippet.
3. Add the refund language rules and the escalation override.
4. Run the eight test tickets above plus two real tickets from last month.
5. Fix failures, then use it in draft mode for two weeks.
6. Keep a list of tickets where a human rewrote the draft. That list is your next prompt edit.

What this will not do

It will not make a bad policy good. If your return rules are vague, the model will be vague, and customers will find the gap. It will not replace a human for money decisions. And the prompts above are untested templates, so treat the first two weeks as your test run, not as a finished system.