IT support in Slack starts as a channel and works well for about forty people. What breaks after that is not the tool. It is that a channel has no memory, no ownership and no way to tell a finished request from an abandoned one.
TL;DR
- A plain channel is genuinely fine below about forty people and fails predictably above it.
- Three things break in order: nothing is tracked, the same questions recur, and requests get silently dropped.
- The fix for the first is a queue behind the channel, not a portal in front of it.
- The fix for the second is an answering layer, because tracking a repeat question does not stop it recurring.
- Keeping the entry point in chat is the part worth preserving, since that is why adoption was good.
- Jira Service Management includes conversational ticketing and publishes a free tier to three agents.
Why IT support in Slack works at first
It removes every step between having a problem and asking about it. No portal, no form, no category dropdown that does not contain your situation.
That single property produces adoption no self-service portal achieves, which is why teams that start this way are reluctant to leave. The instinct is right: the entry point is the thing worth keeping.
It also gives you something a ticketing system does not, which is other people reading the answer. A question answered in a shared channel is answered for everybody watching, and a surprising amount of informal knowledge transfer happens that way.
The three things that break, in order
First, nothing is tracked. Around forty to sixty people, somebody asks how many requests came in last month and there is no answer. More painfully, a request scrolls past during a busy afternoon and nobody notices it was never handled. The requester assumes it is in hand.
Second, the same questions recur. By a hundred people you are answering the same six things weekly. The channel history technically contains every answer and nobody searches it, because searching a channel is harder than asking again.
Third, ownership is ambiguous. With two or three people watching the channel, everybody assumes somebody else picked it up. This produces the worst failure of the three, which is a request that everybody saw and nobody owned.
Those three need different fixes, and conflating them is how teams end up buying a portal that nobody uses.
What to do at each stage
| Stage | Symptom | Fix |
|---|---|---|
| Under 40 people | Nothing yet | A channel and a naming convention |
| 40 to 100 | Requests get dropped | Conversational ticketing behind the channel |
| 100 to 300 | Same questions weekly | An answering layer over your documentation |
| 300 plus | Approvals and assets matter | A full service desk, entry still in chat |
The thing to notice is that the entry point never changes. At every stage people still ask in chat, and what changes is what happens behind it.
What to do: establish which stage you are in by counting dropped requests over a fortnight rather than by headcount. If nothing is getting lost, you are earlier than your headcount suggests.
Keeping chat as the front door
Conversational ticketing is the capability that lets a request start as a message and become a tracked item without the requester filling in anything. It is the bridge between the channel you have and the accountability you need.
Jira Service Management includes this and publishes a free tier covering up to three agents, then Standard at $21.50 and Premium at $55.28 per agent per month. It is also where a well-regarded Slack-first help desk ended up after Atlassian acquired it and retired the brand, which is why the capability is native rather than bolted on.
Freshservice publishes Starter at $19, Growth at $49 and Pro at $99 per agent per month on annual billing, and reaches chat through an integration rather than natively, which is a meaningful difference in feel if not in function.
Checklist before you add anything:
- Confirm your workspace will approve the app, which can take longer than the purchase
- Count resolvers, not requesters, since pricing is per agent
- Check whether a request can start without the requester opening anything
- Check that agents can triage without leaving chat
- Decide what happens to the existing channel, because two front doors confuse people
The repeat-question problem a queue will not fix
Tracking a question does not stop it recurring. If your second failure is the same six things weekly, a ticketing system will give you six well-documented recurring tickets.
Matram publishes $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats and a 30-day trial that takes no card. Disclosure that should shape how you read this: Matram is owned by the same people who publish this site.
Where it struggles, stated plainly: there is no free tier; it answers questions but does not action tickets, so nothing is provisioned or closed; and it is not an ITSM platform, so there is no asset register and no change management. WhatsApp support is coming soon rather than available today.
Used in a chat-first setup it answers the documented questions in the channel and leaves the real work to whatever queue sits behind it. The two together preserve the thing that made the channel work while fixing both of the things that broke.
Verify the figures against the source before committing: Atlassian, Freshservice and Matram all publish openly.
Final thoughts
The mistake teams make when IT support in Slack stops scaling is to conclude that chat was the problem and a portal is the answer. The adoption you have is the asset, and a portal trades it for accountability you could have had anyway.
Keep the front door, put a queue behind it when things start getting dropped, and add an answering layer when the same questions keep arriving. Those are two different problems and they want two different purchases, bought in that order rather than together. Teams who try to solve both at once generally end up with a well-instrumented channel that still produces the same six questions every week.
Is running IT support in Slack a bad idea?
Not at all below about forty people, where a channel plus a naming convention genuinely works and produces better adoption than any portal. It breaks predictably above that, as requests start getting scrolled past and nobody can say who owned what. The right response is to keep chat as the entry point and add tracking behind it rather than to move people to a portal.
What breaks first?
Tracking, usually somewhere between forty and sixty people. A request scrolls past during a busy afternoon, nobody notices it was never handled, and the requester assumes it is in hand. That silent drop is more damaging than the reporting gap, because it costs trust rather than visibility, and it is the signal to put a queue behind the channel.
Should we move people to a portal instead?
Generally no, because the adoption you have is the thing worth protecting and a portal trades it away. Conversational ticketing lets a request start as an ordinary message and become a tracked item without the requester opening anything, which gives you the accountability without losing the entry point. Portals tend to produce people messaging IT directly anyway.
Will a ticketing system stop the repeat questions?
No. It will give you well-documented recurring tickets, which is better for reporting and identical for workload. Repeat questions are a documentation and delivery problem, so the fix is something that answers from your own written material in the channel. Tracking and reducing are different jobs and they need different tools, which is why conflating them leads to disappointment.
What should we check before installing a chat app?
Whether your organisation will approve it at workspace level, because that review is sometimes longer than the purchase decision and it is easy to leave until last. Then confirm two behaviours in a trial: that a request can begin without the requester opening anything, and that agents can triage and reply without leaving chat. Losing either removes the reason for choosing this shape.
What happens to our existing channel?
Decide deliberately, because two front doors confuse people more than one imperfect one. The usual answer is to keep the same channel and let the tooling work inside it, so nothing changes for requesters. If you do create a new entry point, close or clearly redirect the old one, since a channel that still gets answered will keep getting used indefinitely.
