tiqline is a process SLA monitoring tool: it turns events from Shopify and your own systems into one case per piece of work, gives every step a time limit and alerts you in Slack or by email when a step runs over.
Returns and refunds monitoring: from the return request to the money back
A return is a promise in reverse: the customer sends the item back and expects the money within the time your policy names. Between the request and the refund lie the parcel in transit, the arrival at the warehouse, the inspection and the refund itself. tiqline follows each return as a case, gives every step a limit and alerts when one of them waits too long.
Where returns stall
Returns cross more hands than orders. The customer requests the return, in the shop or a returns app. The parcel travels back. The warehouse receives it, often in a separate returns area with its own backlog. Someone inspects the item and decides on a refund, an exchange or a rejection. Finance or the shop issues the refund. Every hand-over can stall: parcels that arrive and sit unopened for a week, inspections that wait for a decision, refunds approved in the warehouse system but never issued in Shopify. For the customer, all of it looks the same: no money yet. Each of those customers is a likely support ticket, and the team answering it first has to find out where the return is.
How shops track returns today
In Shopify, returns, refunds and exchanges are managed from the Orders page, and shops can offer self-serve returns with return rules. Shopify Flow has a template that cancels inactive returns after a waiting period. Returns apps keep their own status lists, and warehouses report received returns in their own system. To see the whole chain, teams often export orders with their refunded amount from Shopify, combine them with the warehouse's list in Excel or Google Sheets and look for returns that are old and unrefunded. Zapier and n8n can react to a Shopify refund, but a check for a refund that did not happen needs a delay or a schedule and a place to keep the state of each return.
How tiqline monitors returns and refunds
1. The refund from Shopify
tiqline reads Shopify's refunds/create webhook and turns it into the event Order Refunded, with the refund ID and the order ID. That is the step most customers care about.
2. The return steps from your systems
tiqline does not read Shopify's returns/* webhooks. Steps such as Return Requested, Return Received and Return Inspected reach it through the track API, from your returns app, your warehouse system or a script, with the order ID and, if an order can have several returns, a return ID.
3. A process with a limit per step
A typical process: Return Requested opens the case, Return Received within 14d, Return Inspected within 2d, Order Refunded within 3d. Each limit is yours to set, for example to match the refund time your return policy names. If an order can have several returns, each return can be followed as its own sub-case.
4. Different paths for different outcomes
A branch on a property of the inspection event, such as the outcome, sends a return to a refund path or to an exchange path with its own steps. A rejected return can end the case early with an end rule, so it never alerts.
5. Next to the order process
Returns get their own process next to the one for orders. Both read the same stored events, so the refund from Shopify counts in the returns process without being sent twice. When you publish the returns process, tiqline builds cases from the events already stored, so returns that are already open show up at once.
6. Alerts and the overview
When returns pass a limit, tiqline opens one incident per step and alerts once in Slack, by email to up to 20 people or through a signed webhook. The process view shows how many returns are stuck on each step and the share of finished returns that kept every limit.
Example: returns received but never inspected
The shop, the returns and the times are made up to show the flow. The process: Return Requested opens the case, Return Received has 14 days, Return Inspected has 2 days, Order Refunded has 3 days.
Day 1: twenty returns are requested
After a sale, customers request returns in the returns app. Each request reaches tiqline as Return Requested and opens a case.
Day 6: the parcels arrive
The warehouse scans the parcels and its system sends Return Received. The cases move on, and inspection is due within two days.
Day 8: inspections are overdue
Stuck
The person who inspects returns is on holiday. Eighteen returns pass their limit on Return Inspected. tiqline opens one incident and emails the warehouse lead and the customer service lead.
Day 9: refunds go out
A colleague takes over the inspections, Return Inspected arrives, the shop issues the refunds, Shopify sends refunds/create and the cases reach Order Refunded. The incident is resolved.
What tiqline does not do
tiqline reads only the refund from Shopify, not returns/* webhooks, so every return step before the refund has to be sent through the track API. It has no connectors to returns apps. It does not issue refunds, approve returns or contact customers, and it does not track the return parcel at the carrier. Limits run on the clock, so a two-day inspection limit includes weekends. Each organisation has one Slack channel, one email list and one webhook for alerts.
Why returns are worth the same attention as orders
A late order is a disappointed customer. A late refund is a disappointed customer who has already paid and is waiting for money. Giving the return the same step-by-step limits as the order means you hear about the backlog in the returns area before your customers write about it. It also shows, per process, how long a return usually takes from request to refund, which is the number to check before you promise a refund time on your returns page.
tiqline monitors process SLAs and is not one of the classic product-analytics tools.
Questions about returns and refunds monitoring
Which return events does tiqline get from Shopify?
Only refunds/create, which becomes Order Refunded with the refund ID and the order ID. Shopify's returns/* webhooks are not read.
How do the return steps get in?
Through the track API in the Segment and RudderStack format, from your returns app, warehouse system or a script, with the order ID and, where needed, a return ID.
Can an order have more than one return?
Yes. If your events carry a return ID, each return can be followed as its own sub-case of the order with its own steps and limits.
What if a return is rejected?
An end rule on the rejection event closes the case early, and an ended case never alerts. Alternatively a branch sends it to a path with its own steps.
Can I match the limits to my return policy?
Yes. You set each limit yourself, for example the refund time your policy promises after inspection.
Do I need a separate process for returns?
Yes, returns get their own process. It reads the same stored events as your order process, so a Shopify refund is used by both without being sent twice.
Does tiqline issue the refund?
No. tiqline only watches the steps and alerts. Refunds are issued in Shopify or your returns app.
Start for free
The Free plan includes 5,000 events a month.