Auto-close stale support tickets

01/The build

How to build it

1. 01

   Define 'stale' precisely — and only ever close tickets waiting on the customer

   Needs a human

   Settle this on paper before you build anything, because one rule carries the whole automation: you only auto-close tickets where your team sent the last message. A ticket whose last message is from the customer is waiting on YOU — closing that is the one outcome you can't have, because to the customer it looks like you ignored them. So 'stale' means: status open, last message was from an agent, and no customer reply for N days. Pick N in business days (most DTC inboxes land at 5-7), and write your exclusion list now too: VIP tags, anything tagged with an open return / refund / replacement, snoozed tickets, and any view you want left alone.

2. 02

   Run it as a daily scheduled sweep, not a webhook

   Runs itself

   There is no 'ticket went stale' event to subscribe to — staleness is the absence of activity, which only a clock can detect. So in n8n use a Schedule (cron) trigger that fires once a day at an off-peak hour. A single daily pass is the right cadence: frequent enough that nothing rots for long, infrequent enough that a customer who replies overnight is never racing your automation. Avoid running it hourly; you gain nothing and multiply your API calls and the chance of a same-day close on a ticket someone's still typing into.

3. 03

   Pull the candidate tickets from Gorgias

   Runs itself

   Call the Gorgias List Tickets API for status = open, and page through the results — the queue is usually bigger than one page. For each ticket you need enough to judge it: the ticket ID, its tags, whether it's snoozed, the last message's datetime and direction (agent vs. customer), and the customer email. If the list payload doesn't include message direction, fetch the ticket's latest message to get it. Filter the list to tickets whose last activity is older than your window so you're only carrying forward the ones worth evaluating.

4. 04

   Keep only the ones genuinely waiting on the customer

   Runs itself

   This is the guardrail that makes the whole thing safe to run unattended. Drop every ticket whose last message came from the customer — those are waiting on your team and must never be auto-closed. Drop snoozed tickets, because a snooze is a human deliberately deferring a ticket to a date; auto-closing it overrides that decision. What survives this filter is the real target: tickets your team has already answered, that the customer simply never came back to.

5. 05

   Apply the exclusion list so in-flight cases survive

   Runs itself

   Run the survivors against the exclusions you wrote in step 1. Skip anything tagged VIP or otherwise marked hands-off. Critically, skip tickets tied to an open return, refund, exchange, or replacement — a customer who's quiet because they're waiting on a refund to land is not a resolved ticket, and closing it is how a fixable silence turns into a chargeback. If the order or RMA state lives outside Gorgias, this is the one place a quick lookup (Shopify order status, your returns tool) earns its keep before you touch the ticket.

6. 06

   Warn before you close — one short nudge, then a pending tag

   Runs itself

   Don't close on first contact. The first time a ticket clears every filter, post one brief public reply in the customer's voice-of-brand — something like 'We think this one's sorted! Just reply here if you still need anything and we'll jump right back in. Otherwise we'll close it out in a few days.' — and add a tag like 'auto-close-pending' with the date. This gives a customer who genuinely still needs help an obvious, low-effort way back in, and it's the difference between an automation that feels considerate and one that feels like a door slamming.

7. 07

   Close the ones that stay silent — and tag them for audit

   Runs itself

   On a later sweep (give the nudge 2-3 days to breathe), take the tickets still carrying 'auto-close-pending' that have had no new customer reply since the nudge, and set their status to closed via the Gorgias API. Add an internal note and a permanent tag — 'auto-closed-stale' — so anyone reviewing the ticket later knows a customer didn't get hand-waved off by an agent, and so your reporting and any CSAT flow can exclude these from agent-resolution stats. Before closing, re-check the last message direction one final time; if the customer slipped a reply in since the nudge, abort the close.

8. 08

   Reopen on reply — and strip the pending tag

   Runs itself

   Gorgias reopens a closed ticket automatically when a new inbound message arrives, so a customer who resurfaces a week later lands back in the live queue without you doing anything. The piece you do have to build is on the pending side: add a Gorgias Rule that, on any new customer message, removes the 'auto-close-pending' tag. Without it, a customer who replies to your nudge could get swept up and closed on the next pass anyway — exactly the mistake the warning step exists to prevent.

9. 09

   Watch the reopen rate and tune the window

   Needs a human

   The honest health check for this automation is how often auto-closed tickets get reopened by a customer reply. A few is normal. A lot means you're closing tickets that weren't actually resolved — your window is too short, or your 'waiting on customer' filter is missing a case — so lengthen N and look at the reopened threads for the pattern. Spend ten minutes a week on it at first. Once the reopen rate settles low, the sweep just runs, and your open count stays honest on its own.

02/The stack

What it’s built on

Gorgias

The helpdesk the whole sweep reads from and writes to. It's the source of the open-ticket list, the message history that tells you who replied last, and the snooze and tag state the filters depend on. It's also where the nudge reply gets posted, where the close happens, and where a Rule strips the pending tag when a customer writes back — and it reopens closed tickets on a new inbound message for free.Gorgias Rules can auto-close inactive tickets natively, and if a plain time-based close covers you, use it — no need for this build. The recipe is worth it when you want the safety layer Rules alone don't give you cleanly: closing only tickets that are waiting on the customer, a warning nudge before the close, audit tags so these never count as agent resolutions, and untag-on-reply — logic that lives in your own flow rather than locked inside one helpdesk's settings.

n8n

The scheduler and the brain. Its cron trigger runs the daily sweep, and it does the work Gorgias Rules can't: paging the ticket list, checking last-message direction, running the exclusion lookups (including any Shopify or returns-tool check), and managing the two-stage warn-then-close over separate runs.n8n is open-source and self-hostable for free, so the schedule and the close logic stay under your control; their cloud tier just saves you running the server. Zapier can fire a simple version, but the paginated list pull plus the two-stage pending-then-close state is awkward to hold together there.

03/Questions

Before you build