Skip to content

Customer Return and RMA Authorisation

Example prompt: "When a customer emails returns@ourdomain.com asking to return goods, look up their original sales order in our Google Sheet, check it's within our return window, draft an RMA email with a unique reference and return instructions, and log it on the 'Returns Log' tab so the warehouse expects the parcel."

The Problem

A return request from a customer arrives as a sentence in an email, sometimes with the order number, sometimes with a description of the item, sometimes with neither and the assumption that we will remember. The returns inbox has the same conversation every week: open the email, search the sales orders sheet for the customer's address, find the order, look at the dispatched_at to see if the return window has expired, type out the RMA number on a sticky note next to the screen, compose a reply, write the case into the returns log when there is a quiet moment. Half the cases land in the log the same day; the other half are reconstructed on a Friday from sent items and memory, and the warehouse cannot tell which incoming parcel belongs to which RMA when the box arrives on Wednesday.

How GloriaMundo Solves It

We build a workflow that watches the returns inbox and turns each request into a structured RMA case. An integration step reads inbound Gmail; an LLM step extracts the customer's claimed order, SKUs, quantity, and reason from the email body without making anything up about details the customer did not give. A code step dedupes on the inbound Gmail message-id first (so a webhook retry never burns an RMA number), matches the request against the sales orders sheet using the customer's email and any quoted order number, and then routes the case: unshipped (the matched order has no dispatched_at and the customer is really asking for a cancellation or a hold), in-window, out-of-window, or needs manual matching. The RMA number is allocated only on the in-window-matched branch. For in-window cases, an integration step drafts the customer acknowledgement with our return address and the return instructions paragraph, and logs the case to the Returns Log so the warehouse knows what to expect. Out-of-window cases go to the returns owner for a judgement call before any customer reply leaves the building, and unshipped cases get a hold-or-cancel confirmation draft asking the customer which they want. Glass Box preview shows the extracted claim, the matched SO, the proposed RMA number, and the draft email before anything is sent or logged — the operator can correct a wrong match before the customer reads it.

Example Workflow Steps

  1. Trigger (inbound email): Any Gmail to returns@ourdomain.com matching the return-related keywords and not an auto-reply.
  2. Step 1 (integration): Pull the inbound gmail_message_id and the sender's email, then read the 'Returns Log' tab. If any row already carries this gmail_message_id, exit immediately — no order-history reads, no LLM extraction, no rma_number allocation, no new log row.
  3. Step 2 (llm): Read the email body and extract claimed_so_number, claimed_skus, claimed_quantity, and claimed_reason — null where the customer was not specific.
  4. Step 3 (integration): Read the customer's order history from the Sales Orders and Sales Order Lines tabs and the Returns Settings tab.
  5. Step 4 (code): Match the request against the order history (quoted SO number if present, otherwise the unique-order-containing-every-claimed-SKU rule) and compute the return route — Unshipped (matched_so has no dispatched_at), In-window, Out-of-window (matched and shipped), or Needs manual match (no matched_so) — against return_window_days.
  6. Step 5 (conditional): Branch on return route — In-window matched allocates the next rma_number and drafts the customer acknowledgement; Out-of-window drafts the explanatory reply with the returns owner copied; Unshipped drafts a hold-or-cancellation confirmation to the customer with the returns owner copied; Needs-manual-match drafts only to the returns owner with the original message quoted. The rma_number allocator is called only on the In-window matched branch, so out-of-window, unshipped, and needs-manual-match cases can never burn an RMA number.
  7. Step 6 (integration): Append a row to the 'Returns Log' tab with the rma_number (or empty for non-RMA routes), the matched_so, the gmail_message_id, the draft link, the rma_expires_at where applicable, and the rma_status.
  8. Step 7 (integration): On send-detection from the Gmail Sent folder, update the matching log row's rma_status to 'Sent' with rma_sent_at.
  9. Step 8 (integration): At 17:00 every working day, post the returns summary in #returns on Slack — drafted today, out-of-window awaiting decision, unshipped awaiting customer confirmation, needs-manual-match, and RMAs expiring in the next three working days with no goods received.

Integrations Used

  • Gmail — watches returns@ourdomain.com for inbound requests, drafts the customer reply, and provides send-detection from the Sent folder
  • Google Sheets — the Sales Orders, Sales Order Lines, Returns Settings, Returns Log, and Company Settings tabs
  • Slack — the #returns end-of-day summary

Who This Is For

The returns owner at a small manufacturer or distributor selling either direct to consumers or to trade — somewhere with one inbox, a few RMAs a week, and a warehouse that needs to know what to expect when a parcel comes back. This is for the team that knows what their returns policy is but does not have the tooling to enforce it consistently when the inbox is busy.

Time & Cost Saved

The manual version is between five and fifteen minutes per request — most of that spent matching the customer email to the order and copying the right values into the reply and the returns log. The workflow brings it down to a minute of reviewing the matched SO and the draft, and the returns log row writes itself with the right keys. The bigger gain is in the cases that would otherwise have been forgotten: an RMA acknowledged but never logged, a parcel that arrives with an RMA number nobody recognises, an out-of-window case that gets a sympathetic reply from the inbox owner because they could not face checking the dispatched_at on the order.