Refund request handling

The automation reads each refund request, pulls the matching order from Shopify, checks it against your refund policy, the window, the item's eligibility, the condition, and drafts a response that either approves it or explains the denial in plain, courteous terms. The drafts wait in Gmail for you.

Customers get a clear, timely answer, and your policy is applied the same way every time without you re-reading it for each request.

Scoped access

• Shopify, read orders
• Gmail, draft responses only

How it fails silently

Refund handling fails silently when the decision is right-sounding but cites the wrong basis. The automation approves a refund on an order that is actually past the window or marked final sale, because the request was sympathetic and the math looked routine, or it denies a valid request and quotes a policy clause that does not apply to that item. The reply reads clean and confident either way. Sent unattended, the first quietly leaks margin and sets a precedent, and the second hands an upset customer a clear case that you got your own policy wrong.

What the overseer catches

Once a reply is drafted, the overseer checks the decision against the order it is about and the policy it leans on. An approval on an order that is past the window or marked final sale, or a denial that quotes a clause which does not fit the item, is the contradiction it catches, flagging the response for you so a wrong call does not go out under your name.

Requests that clearly fall inside or outside policy get a correct, courteous draft prepared for your review.

What reaches you is the edge case: the request near the policy boundary, the item with special terms, the decision where the order details and the policy do not cleanly agree. Those come to you before a response is sent, so your policy is applied accurately, not just quickly.