## TL;DR
"Where is my refund" is the most automatable ticket in support because the answer lives in a system, not in anyone's judgment. Look up the refund record, read its state (pending, sent, failed), and reply with the concrete timeline for that state. Automate the 90 percent that are state lookups. Route the 10 percent that are exceptions (no refund issued, failed transfer) to humans.

## The query

```text
how to automate "where is my refund" tickets
```

## Use this when

- Refund or order-status tickets dominate ticket volume
- Agents copy-paste the same refund timeline daily
- You are scoping support automation or a bot use case
- Refund replies are inconsistent between agents

## Not for

- Building payment integrations
- Fraud or chargeback decisions
- Disputed charges needing investigation
- Refund policy design (whether to refund at all)

## Steps

### 1. Map every refund state to customer language

Pending, processing, sent, failed, reversed. For each, write the one-paragraph customer version: what it means and when the money arrives. This mapping is the whole automation. Get it approved by finance once.

Expected output: a state-to-language table, finance-approved.

### 2. Build the lookup

Input: order email or order ID from the ticket. Output: refund state, amount, and date issued. The automation queries the payment system and fills the reply template. No agent judgment involved.

Expected output: a working lookup returning state plus dates.

### 3. Write the timeline replies per state

Pending: "issued on [date], arrives by [date]." Sent: "sent on [date] to [last four], allow [N] business days." Failed: this one goes to a human, always. Vague timelines ("3 to 5 business days") are fine if they are the truth.

Expected output: one reply template per state.

### 4. Define the exception list

No refund record found. Refund amount differs from what the customer paid. Failed transfer. Customer says the money never arrived after the timeline passed. Exceptions skip automation and land with a human, with the lookup results attached.

Expected output: a written exception list wired into routing.

### 5. Measure containment and reopen rate

Track what share of these tickets resolve without a human (containment) and what share reopen within 7 days. A reopen rate climbing means the timelines are wrong, not that the automation is.

Expected output: weekly containment and reopen numbers.

## Template: the status reply

```text
Hi [Name], I checked your refund for order [ID].

Status: [sent on DATE to card ending in 1234]
What this means: the refund left our system on [date]. Banks usually post it within [N] business days, so you should see it by [date].

If it has not arrived by [date], reply here and I will trace it personally.
```

## Variant phrasings

### refund status automation

Steps 1 through 3. The state table is the project.

### automate order status tickets

Same pattern, different states: shipped, in transit, delivered. The lookup-then-timeline shape transfers directly.

### refund ticket deflection

Step 5. Deflection without reopen tracking is just deferred work.

## Why it works

Status questions need data, not empathy. Customers asking "where is my refund" want a date, and the date is in the system. Automation answers in seconds what takes an agent minutes, and it answers consistently. The human value-add is only in the exceptions, which is exactly where you route them.

## Edge cases

- Partial refunds: state the refunded amount explicitly. Customers compare against the full charge.
- Refunds to expired cards: the money usually follows to the new card, but the timeline stretches. Say so.
- Currency conversion: cross-border refunds arrive for slightly less than expected. Warn upfront.
- The customer disputes the timeline: that is an exception. Human, with the lookup attached.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pc2HsSt4pIkTuutAZ8whlQ