Slack dispatch: routing 100 to 200 messages a day without a human sorting them

Many teams run a shared Slack channel where everything lands: requests from support, notes from operations, questions from managers, customer problems pasted in by whoever saw them first. Somewhere between 100 and 200 messages a day, the channel stops working. The right person never sees the message meant for them. I built a dispatcher for exactly this, and this post explains how it behaves.

The problem in plain words

A single catch-all channel has one advantage, which is that everyone can post. Its cost is that nobody can read it all. Three failures follow:

• Urgent items are buried under routine ones.
• People answer the same question twice, or nobody answers it.
• The few people who do read everything become a human router, and that is their whole job.

The goal was not to make people post less. It was to let them keep posting in one place while every message still lands where it belongs.

How the dispatcher works

The dispatcher is a small service that reads every message in the shared channel on a set schedule, labels it, and posts it onward. Four parts:

1. Read. On a schedule, collect new messages since the last run, including thread replies that change the meaning of the original.
2. Classify. Claude assigns a team and an urgency to each message, and writes a one-line summary.
3. Gate. Messages the classifier is unsure about are held. Personal data is masked in the forwarded summary.
4. Post. Each message goes to the right team channel with its summary, a link back to the original, and an urgency marker.

A schedule, not a real-time stream, was a deliberate choice. Batching lets the dispatcher see a thread in full, avoids reacting to half a thought, and keeps the volume of bot posts predictable.

The morning digest

Overnight messages are the ones that cause damage, because nobody is watching. So the first run of the day produces a digest: what came in overnight, which team owns each item, and what is urgent. Each team lead gets their own section. They start the day with a list instead of a scroll.

A worked example

Three illustrative messages arrive in a ten-minute window:

"Customer says her jacket came back with a stain, she wants to speak to someone today"

"Is anyone updating the pricing sheet this week?"

"ok thanks"

The first is classified as a complaint, team customer care, urgency high, confidence 0.96. It is posted to the customer care channel with the summary "Stain complaint, customer wants a call today," and the original link.

The second is classified as an internal question, team operations, urgency low, confidence 0.91. It goes to operations, and into the digest.

The third has no content. The dispatcher marks it as noise attached to the thread above it and does not forward it. If it had been unclear, it would have been held for a person to read instead of guessed.

The gate in a dispatcher

The rule I care most about: a message the system cannot classify is never forced into a category. It goes to a held list that one person clears. The cost of a held message is a short delay. The cost of a wrong guess is a customer problem that sits in the wrong channel for hours.

Other checks:

• A duplicate check, so the same customer issue pasted by two people becomes one routed item.
• A rule that anything mentioning a VIP customer is never held below a human-visible marker, even at lower confidence.
• A daily QA sample of twenty routed items, scored by a person, which shows me where the classifier is quietly wrong. This sample caught problems the confidence score never would.

What went wrong the first time

The first version posted a long summary of every message. Team channels became noisy and people muted the bot, which defeated the purpose. I cut it to one line plus a link, and posted nothing at all for messages that were only acknowledgements.

The second problem was that the team list went stale. When a team was renamed and nobody updated the dispatcher, messages routed to a channel nobody read. Now the list of teams and channels is a single configuration file with a named owner, and a check fails loudly if a target channel no longer exists.

Trade-offs

• A schedule introduces a small delay. For items where minutes matter, I add a separate fast path for specific keywords or VIP senders.
• Summaries lose nuance. The link to the original is not optional.
• A dispatcher does not fix a team that has no clear owners. If two teams both think they own an issue, it will route to one of them, and you need a rule for that. I cover this in escalations with an owner and a clock.

The same classify, gate and route pattern is used for customer messages, described in how I cut handling time.

What I would build for your team

I would read a week of your shared channel with you and write down every kind of message that appears. That list becomes the label set, and the people who answer each kind become the owners. I would build the dispatcher with the held list and the morning digest from day one, then review the daily sample with you for the first couple of weeks. You end up with a channel people can still post in freely and a team that sees only what is theirs.

Email: kodirovrukhillo@gmail.com