How IT teams are handling support across Slack and Teams

We had a VPN outage on a Tuesday, and I got to watch two completely different companies respond to it.

In Slack, someone in engineering posted a screenshot at 9:04. By 9:13 a colleague had replied with the workaround, three other people had confirmed it worked, and the thread had turned into a low-grade group chat about whether the client certificate rotation had anything to do with it. Nobody filed anything. The problem was handled.

In Microsoft Teams, finance and legal were asking the same question in a general channel. One person got told to submit a ticket. Two others gave up and rebooted repeatedly, and somebody eventually called a technician's mobile.

Same outage. Same company. Same IT team. Two entirely different experiences of being an employee who could not get to a file share.

I did not have a view of both until the following afternoon, when I went looking for how many people had actually been affected and discovered that my ticket count for the incident was four.

Nobody chose this

If you run support across Slack and Teams, remember that nobody sat down and designed it that way. It accumulated.

The usual routes are boring. You acquired a company and it arrived with its own workspace and its own strongly held opinions. One business unit adopted a tool ahead of any central decision, got good at it, and quickly became the internal reference for how chat is supposed to work. Microsoft licensing bundled Teams into a thing you already paid for, so Teams appeared everywhere at once at zero incremental cost. And your engineering organization will not leave Slack. Ever.

The result is an organization with two chat platforms and, by accident, two front doors to IT.

I spent about a year trying to close one of them. I built the migration plan, priced the licensing, wrote a genuinely persuasive memo about cross platform communication overhead, and got as far as a pilot before the whole thing died in a meeting I was not invited to. At the time I thought I had lost to politics. Looking back, I was trying to win an argument about tooling when the actual problem was that my support process only knew how to exist in one place.

Where the requests actually go missing

Two front doors means two queues, and two queues with no shared view of backlog means you are managing by vibes in at least one of them.

The specific failure modes are worth naming, because each one has a different fix.

Duplicate questions, invisible to each other. The person answering in Teams has no idea the identical question was asked in Slack forty minutes earlier and already answered. Two technicians, two investigations, one problem. Occasionally two different answers, which is the version that generates a follow-up ticket about why IT contradicted itself.

Escalation dead-ends. A thread in one platform cannot be escalated into a workflow that lives in the other. So the escalation becomes a copy-paste, a summary written by whoever has the least context, and a loss of everything the original thread contained. Screenshots do not survive that trip. Neither does tone.

Direct messages, in both tools. This is the one that makes your numbers fiction. If a meaningful share of your support happens in DMs across two platforms, your ticket volume is a work of imagination, your metrics are decorative, and the person carrying the heaviest load has the least evidence of it at review time.

Backlog with no owner. A request in the platform you did not designate as official sits there looking answered because someone reacted to it with an emoji. Nobody owns it. It ages. Three days later the requester assumes IT does not care, which is a reasonable conclusion from where they are sitting.

The part that shows up as slower tickets

There is a finding from the device management world that transfers directly here, and I think it is underrated.

When technicians work across multiple management tools with different navigation and different terminology, the heaviest cost lands on new hires, who face a complicated workflow just to get their bearings on how the place is arranged. That complexity then transfers straight to the end user as slower resolution. The same mechanism runs in support intake. A technician who has to context-switch between two intake surfaces, two notification models, and two mental maps of where requests live is a slower technician, and the person waiting feels every bit of that.

Nobody logs it that way. It shows up as a ticket that took a day instead of an afternoon.

Three options, honestly

Force everyone onto one tool. Cleanest outcome, rarely politically possible. If you genuinely have executive backing and an acquisition still in its first year, do it, and do it fast before habits set. Most of us do not have that window. Attempting it without the backing costs you a year and whatever credibility you were spending.

Pick one as the official support front door and accept leakage from the other. This is what most organizations do by default, and it works better than nothing. The honest version of this option includes admitting out loud that a percentage of requests will be born in the wrong place and will arrive late, secondhand, or never.

Run a support layer that spans both and normalizes requests into one queue. Requests can start in either platform, both get structured intake, and both land in the same backlog with the same metrics and the same record behind them.

I would pick the third one, and I would pick it even in an organization that fully intends to consolidate chat tools eventually. Centralized communication and centralized support are separate projects with separate timelines. You can have one queue long before you have one chat platform, and the queue is the part your colleagues actually feel. The unified communication project can take three years. Your backlog needs to be unified by next quarter.

What has to be true for the spanning approach to work

It falls apart if you treat it as a pair of chatbots wearing the same logo. Four things have to hold.

1. One backlog. Not two views that a person reconciles. One list, sorted by age, that a lead can look at and see everything owed to anyone.
2. One set of metrics. Time to first response, time to resolution, volume by category, measured identically regardless of origin. If Slack requests and Teams requests are counted differently, you will accidentally optimize for whichever tool reports more flatteringly.
3. Structured intake in both places. A form in one and a free-text channel in the other gives you two incompatible data sets.
4. A record that outlives the conversation. More on that below, because it is the part people skip.

Structured intake is the highest-leverage thing on this list

A K-12 team supporting several thousand devices replaced their free-text "describe your problem" box with categorized buttons. Their reason was earned rather than theoretical: free-text requests got miscategorized, then sat in the wrong queue for weeks, because people do not pay close attention to queues that are not theirs.

The second-order effect mattered more than the routing fix. Selecting a category now generates more than one linked record automatically. One category creates both the billing record and the replacement-shipping record, in one action, with no human needing to remember step two on a Friday afternoon.

I would go so far as to say every automation ambition your team has is sitting downstream of this one decision. You cannot auto-route, auto-answer, or auto-resolve a request you cannot classify, and prose does not classify. Two chat platforms doubles the value of getting this right, because structured intake is what makes support requests in Teams and questions dropped into a Slack channel look identical by the time a technician picks them up.

Tone, and the colleagues who answer before you do

Two behaviors matter more than any workflow diagram, and both come from teams doing IT support in Slack well.

The first is acknowledgment. A canned auto-response confirms that a person is in a queue, which is a courteous way of saying they are somebody's problem later. A human acknowledgment carries identical information and lands completely differently. Same latency, same backlog, wildly different experience of asking for help. Rewriting that message takes eleven minutes and will change how your team is perceived more than any dashboard you ship this quarter.

The second is peer answering. One team watched colleagues start answering each other in a shared channel before IT even saw the question, then deliberately reinforced it by publicly thanking the peer-helpers. That works in both platforms, and it is one of the few support mechanisms that gets cheaper as it gets more popular. The best tier-one responder in your company is often the person two desks over who solved the identical thing on Tuesday.

Related, and easy to get wrong: when a request lands with you that belongs to another team, avoid "I can't help with that." Say what is possible, then connect them to the right group by name. You did not solve the technical problem and you still built trust, which is a strange trade that works out in your favor every time.

The compliance thing I will keep repeating

Chat search history should not be your system of record.

A lot of organizations are running exactly that way, and it holds up fine until somebody asks who approved a permission grant fourteen months ago and your only artifact is a thread in a channel that has since been archived, in a workspace that came from an acquisition, under a retention policy nobody set deliberately. Conversation is the front door. The filing cabinet is a separate object, and it needs to live outside both chat platforms.

What does not transfer

I would be doing you a disservice if I implied the two platforms are interchangeable behind a common layer.

Notification behavior differs, so an interaction that reliably gets noticed in one platform gets missed in the other. Threading models differ too. A conversation shape that feels natural in Slack reads as chaos in Teams, the reverse holds as well, and that means the same structured intake flow can land beautifully on one side and feel like bureaucracy on the other. Permission models differ in ways that matter for guest access, external collaborators, and who can see what in a shared channel.

Design once, then design again. An experience that feels good in one tool needs separate work in the other, and the teams that skip that step end up with one great support surface and one that technically exists.

Zooming out

Support across Slack and Teams looks like a tooling problem and behaves like an organizational one. Two chat platforms is the visible symptom of a company that grew by acquisition, or by autonomy, or by a licensing accident, and those are all normal ways for companies to grow.

What I have stopped expecting is a tidy end state. I used to think the goal was one tool everywhere, and I now think the goal is one queue everywhere, which is a much smaller thing to ask for and a much more useful thing to have.

The people asking for help do not care where your queue lives. They care that somebody knows they are waiting.