# Catch helpdesk tickets going stale before customers chase you > Twice every weekday, your team gets one Slack message listing the Re:amaze conversations that have been waiting too long. - Workflow type: code - Services: Re:amaze, Slack Bot - Categories: Customer Support, Operations - Published: 2026-08-09 ## What it does - Checks your Re:amaze helpdesk every weekday at 8am and again at 2pm for conversations still sitting open or unassigned - Works out how long each one has been waiting and keeps only the ones past your ageing limits, by default 4 hours unassigned or 24 hours with no reply - Splits the results into nobody has picked this up versus someone owns it but has gone quiet, oldest first - Posts one tidy Slack message with a count per group and a line per ticket showing the customer, the subject, the wait time, and a direct link - Posts a short all clear when nothing is overdue, so you know the check ran rather than wondering ## What you'll need - A Re:amaze account you can sign in to, plus the brand name in your Re:amaze web address - A Slack workspace and a channel where the alerts should land - A rough idea of your response targets, so you can set the waiting limits that count as too long ## Prompt Every weekday at 8am and again at 2pm, check my Re:amaze helpdesk for conversations that have been waiting too long and post one summary to Slack. The goal is to catch tickets that are slipping through the cracks before a customer has to complain a second time. Use the Re:amaze List Conversations operation to pull every conversation that is still in an open or unassigned state. This list is paginated, so page through all of it. The response carries page_size, page_count and total_count, and it defaults to 30 conversations per page, so advance with the page query parameter until you have collected every conversation. Do not skip this loop: a backlog alert that silently stops at the first 30 conversations is worse than no alert at all. Re:amaze reports conversation status as an integer, and status 5 specifically means On Hold and pairs with a hold_until timestamp. On Hold conversations are deliberately parked rather than neglected, so exclude them from the stale results entirely instead of reporting them as ignored. For each remaining conversation, work out how long it has been waiting from its creation timestamp and its last update timestamp. Keep only the ones that are past my ageing thresholds: unassigned for more than 4 hours, or open with no reply for more than 24 hours. Put both thresholds in one obvious settings block at the top of the workflow, because those two numbers are the first thing I will want to tune. Group whatever is left into two buckets: conversations that are unassigned, and conversations that are assigned but have gone stale. Sort each group oldest first so the worst offenders sit at the top. Post a single formatted message to Slack with the Slack Bot Send a Message operation. Lead each group with its name and count, then give one line per conversation showing the customer, the subject, how long it has been waiting in readable form such as 6h 20m or 2d 4h, and a direct link to the conversation. Re:amaze addresses conversations by slug rather than a numeric id, so build each link from the conversation slug and my brand subdomain. If nothing breaches the thresholds, post a short all clear message instead of staying silent, so the team can see the check actually ran and there is genuinely nothing waiting. ## How to customize - Change the ageing limits. The 4 hour unassigned and 24 hour no reply numbers sit at the top of the workflow and are the first thing most teams adjust - Change the schedule. Two checks a weekday suits most teams, but you can move the times, add a third check, or include weekends - Change where it lands. Send it to your support channel, a leads only channel, or a direct message to whoever is on duty ## Example output Helpdesk ageing check, Tuesday 2:00pm Unassigned longer than 4h (2) • Priya Raman: "Refund not showing on my statement", waiting 9h 12m, open in Re:amaze • Tom Beckett: "Cannot log in after password reset", waiting 5h 40m, open in Re:amaze Assigned but no reply in 24h (3) • Dana Whitfield: "Bulk order pricing question", waiting 3d 6h, open in Re:amaze • Marcus Lee: "Damaged item in order 40122", waiting 2d 1h, open in Re:amaze • Sofia Iglesias: "Change of billing address", waiting 1d 4h, open in Re:amaze ## FAQ ### What counts as a stale ticket? Two things, and you set both. A conversation nobody has been assigned to counts as stale after 4 hours by default. A conversation that has an owner but has not had a reply counts as stale after 24 hours. Anything under those limits is left alone so the alert stays worth reading. ### Will it spam our Slack channel? No. It posts once per check, so two messages on a normal weekday, and everything is grouped into a single message rather than one alert per ticket. ### Can I change the 4 hour and 24 hour limits? Yes, they are meant to be changed. They sit at the top of the workflow as plain settings, so you can tighten them for a fast moving queue or loosen them if your team works to a slower target. ### Does it flag tickets we deliberately put on hold? No. Conversations you have parked on hold are treated as intentional and left out of the counts, so waiting on a customer or a supplier does not show up as something your team has neglected. ### What if we have hundreds of open conversations? It works through your full list rather than stopping at the first page, so the counts reflect the whole backlog. That matters, because a backlog alert that quietly cuts off early is worse than no alert at all. Use this prompt in General Input: https://www.generalinput.com/prompts/catch-helpdesk-tickets-going-stale-before-customers-chase-you