Stalled Support Requests: AI Reminders in Slack Before the Customer Asks Twice

A customer replies with the logs you asked for, then hears nothing for three days. A Runbear agent sweeps Zendesk, Slack, and Linear on a schedule, spots the silence, and nudges the owner with a drafted reply.

Sarah at Acme replies with the logs your engineer asked for. The reply lands in Zendesk on Monday morning. The engineer is deep in a sprint, the ticket sits in Open, and the Linear issue linked to the bug has not moved. Nobody does anything wrong, exactly. Nobody does anything at all.

Three days later the customer writes again: "Hi, just checking in on this?" That second message is the one that costs you. The first silence was a queue problem. The second is a trust problem: the customer now believes that what they send you can disappear.

TL;DR · What it does. Sweeps Zendesk, Slack, and Linear every weekday morning, finds requests where the customer is waiting on you, and nudges the owner in Slack, drafting the reply on request.

Setup. About 30 minutes. Connect Slack, Zendesk, and Linear, add a scheduled trigger, paste two short prompts. No engineering.

Why it works. A stalled request is a cross-tool fact. SLA timers watch one tool; the agent reads all three together.

Works with. Zendesk, Slack, and Linear here. Swap in Intercom, Jira, Teams, or 2,000+ other services.

Why support requests stall

Ask any support team where requests go to die and you get the same list:

Triage broke and the ticket never got an assignee.
The assignee asked for more information and forgot to come back.
The customer replied, and the reply sank while everyone was heads-down.
Two people each assumed the other one had it.

Every support manager knows the moment that follows. You open a week-old thread, see the customer's logs sitting there unanswered, and feel your stomach drop: "Oh no. That was me. I was going to reply right after standup."

The shape is always the same: the ball is in your court, and it is silent. Detecting that state is nobody's job. Zendesk shows one open ticket among two hundred. The Slack escalation thread scrolled away on Tuesday. The Linear issue looks like every other issue. The stall only exists when you line all three up, and no single tool does that.

The teammate that notices silence

Say the same Monday happens again, but this time a Runbear agent named NudgeBear is on the support rota. Every weekday at 9 AM it sweeps the three places a request can stall: open Zendesk tickets, the #support-eng channel in Slack, and the Linear issues linked from tickets. It looks for one pattern: the last message came from the customer, and nothing on our side has moved since.

It finds the Acme thread. The customer replied 72 hours ago, the engineer never responded, and the linked issue has not changed status. So it pings the assignee in Slack:

#support-eng18

NudgeBearAPP9:00 AM

NudgeBear sweeps Zendesk, Slack, and Linear every weekday morning.

The reminder carries everything needed to act: what the customer sent, when, which ticket, which issue, and an offer to draft the reply. One thread reply, a two-sentence edit, and the follow-up goes out the same morning.

One stall, three tools

Zendesk holds the customer's words and the clock. Slack holds the promise: the thread where an engineer said "send me the logs and I'll take a look". Linear holds whether the work actually moved. Read any one of them alone and everything looks fine. The stall only shows up when the agent reads them together.

The sweep also catches the inverse case, and it is a quiet favorite: the Linear fix shipped yesterday and nobody told the customer. A solved problem that keeps costing you goodwill until someone says so.

A reminder that arrives with the reply

An alert that says "SLA breached on ticket #4812" gives you a chore. NudgeBear's reminder gives you a head start: it has read the thread, so the draft already acknowledges the logs, states what was found, and gives the customer a real next step. Most follow-ups become a 30-second edit instead of a 15-minute context reload.

Reminders can stall too, so they escalate. If a nudge sits unanswered for another day, the short version goes to #support-leads: which customer, how long, who was pinged. Silence always stays someone's problem to break.

Why SLA timers miss this

Helpdesk SLA timers matter, but they are confined to one tool. Zendesk can say a ticket breached its response target. It cannot know the engineer promised a fix in Slack, or that the fix shipped and the ticket should have closed with good news two days ago.

Approach	What it sees	What you get	Where it breaks
Runbear agent (NudgeBear)	Zendesk, Slack, and Linear together	A reminder with context and a drafted reply	Needs a one-time setup
Helpdesk SLA alerts	Its own tickets and timers	A breach notification	Blind to Slack promises and Linear status
Weekly ticket-review meeting	Whatever the team remembers	A cleanup once a week	Six days too late for a customer waiting since Monday
"Anyone on this?" in Slack	One thread at a time	An answer if the right person is online	Depends on someone noticing first

Setting it up

Sign up at Runbear and open your workspace.
Create an agent named NudgeBear and paste the agent instruction below, adjusting the 48-hour threshold to your SLA.
Connect Zendesk and Linear under Agents > NudgeBear > Tools.
Deploy the agent to Slack under Agents > NudgeBear > Chatbots > Slack.
Add a weekday morning schedule under Agents > NudgeBear > Event Triggers > Schedule > On Schedule, and paste the trigger prompt below.
Run it once manually and watch the first sweep land in Slack.

Two prompts do the work. The agent instruction defines how NudgeBear behaves everywhere; the trigger prompt is the task that runs on the schedule.

nudgebear-instruction.txt
You are NudgeBear, the follow-up watchdog for our support team.

A conversation is stalled when the last message came from the customer
more than 48 hours ago, or when we promised a follow-up (a fix, an
update, an answer) that has not happened. Conversations waiting on the
customer are not stalled.

When you remind an assignee, keep it to a few lines: what the customer
sent, when, and links to the ticket and the Linear issue. No lectures.

When someone asks you to draft a reply, write it ready to send:
acknowledge what the customer provided, state what we found or what we
are checking, and give a concrete next step.

If a linked Linear issue was completed but the ticket is still open,
tell the assignee the fix shipped and offer to draft the good-news reply.

nudgebear-trigger-prompt.txt
Review open Zendesk tickets, the #support-eng channel in Slack, and the
Linear issues linked from tickets. Find stalled conversations and send
each assignee a Slack reminder with an offer to draft the reply. If you
flagged the same conversation yesterday and nothing has changed, post a
short summary to #support-leads instead.

What changes

For the team. The morning sweep replaces the guilt-driven scroll through old tickets. Nobody keeps a spreadsheet of things to chase. Follow-ups leave the same day, and the awkward ones, where the fix shipped days ago, stop happening.

For the customer. They send logs once and someone answers. They stop writing "just checking in", because they never need to. That is the difference between support that responds and support that remembers.

Runbear is used by 600+ companies, from agencies to product teams, to put AI teammates inside the channels where work already happens. Turn NudgeBear on for one support channel and count how many "just checking in" messages you get next month.

Get Started