AI Ticket Routing in Slack: Who Owns This Request?

A refund request lands in #support: "A customer says they were charged twice after switching to the annual plan, and they want a refund." Nobody replies. Everyone assumes it's someone else's job. Is a billing dispute Finance? Success? Does support handle it? Someone half-remembers that @dana used to own refunds. An hour later the ticket is still sitting there, now with a "customer's waiting, anyone?" bump on top.

AI ticket routing in Slack is simple to describe: an agent reads each incoming request and tags the right owner in the thread, using live Slack and Notion signals instead of a static queue. The routing that matters is getting each request to the person who actually owns it, not a shared queue where it stalls. "Who owns this?" repeats ten times a day, and each time it taxes your most experienced people: they get pulled in just to point at the person who can. New hires can't route anything, so everything flows to the loudest name they know, and that person becomes a bottleneck. The org's knowledge of itself lives in a few overloaded heads, and it walks out the door when they do.

How does AI ticket routing in Slack work?

Say the same ticket comes in again. This time it doesn't sit.

Runbear's roster teammate reads the thread and, instead of answering, finds the owner. The old wiki page still lists @dana, but @dana changed teams back in January. Slack tells a different story: one teammate handled the last two billing disputes in this channel, and the current Billing Ops doc names her as the owner. Two live signals agree; the stale page is the outlier.

So the roster tags the current owner right in the thread, with its reasoning attached:

"Routing to @maria. She handled the last two billing disputes here and is named on the Billing Ops doc. The old wiki still lists @dana, who changed teams in January."

No hop through a senior lead. No "let me find out who handles this." The right person is on it, and everyone can see why, so a wrong guess is easy to fix.

And when ownership changes (it does, constantly), you don't file a config ticket. You correct it in the thread, once, and the correction becomes the signal it reads next time.

A roster earns its keep over an org chart here. An org chart draws reporting lines; routing needs ownership and coverage. Two people under the same manager can own completely different surfaces, and the person named in a doc isn't always the real go-to this week. A good roster captures how the team actually operates and redraws itself as the team moves.

Slack and Notion already know who owns what

The roster can answer like this because it doesn't wait to be told who owns what. It reads from where the answer is already written.

Slack is the primary signal. Who answers refund and billing questions in the support channel, who jumps on every chargeback: ownership is already visible in the conversations that happen anyway. Notion adds team pages, project docs, RACI ownership tables, and Billing Ops guides. If your org has written down who owns what, the roster takes it as one source among several.

Because both update as a byproduct of the work itself, nobody has to keep a roster current on the side. Reading them together, the roster reasons past a stale doc: a name with no recent activity in the channel is a weaker signal than the person actually answering today. When the two signals genuinely disagree, or a channel is too new to have a clear owner, the roster says so in the thread and asks instead of guessing. It also accounts for who's on call and how an urgent request should escalate before it breaches an SLA, not just who owns the area on paper.

Ask it, or let it catch what nobody asked

There are two ways to use the roster.

First, you ask when you're stuck: @Runbear who owns refunds over $500? It answers in the thread with the owner, a one-line reason, and where it looked, and there's nothing to set up first.

The other way needs no one to ask. The roster watches designated channels, and automated ticket routing kicks in. When it spots a message that needs routing, it tags the owner before anyone thinks to. A customer threatening a chargeback gets the same treatment: a thread that would have drifted without an owner is caught on the spot. It's the same ambient approach behind nudging stalled support requests before they go cold.

Most teams start with the low-commitment side, letting people ask "who owns X?", then turn on ambient routing for the busiest channels once they trust it. Together they close both gaps: the questions people raise, and the ones they never do.

Setting it up takes one conversation

You don't configure this in a dashboard. You tell the teammate, right in the channel, where to look and how to decide: read recent billing threads here in Slack, read the Billing Ops doc in Notion, and tag whoever's most current. It connects what it needs and registers the trigger for you.

Slack is already connected once the teammate is in the channel. Point it at your Notion so it can read ownership docs, and it registers a trigger that watches the channel and routes on its own. No admin console, no config files.

Why wikis and rules bots fall short

Plenty of tools promise to answer "who owns this." Most need someone to keep them current by hand, and that's exactly where they go stale. A static wiki is right the day it's written and wrong a month later. Round-robin and rules bots fit simple queues with fixed ownership, but stall on anything outside the rules. The roster's edge is that it stays accurate with nobody maintaining it.

Runbear is used by 600+ companies, including Matillion, who run these AI teammates inside the channels where work already happens. Pointing one at the "who owns this?" question is a small start. Add a roster teammate to one Slack channel and watch the requests find their owner.