Most MSPs say they offer self-service. What they actually offer is a portal that doesn't get the adoption they expected.
It's one of the most consistent patterns we see across managed service providers, from small operations running ten technicians to mature MSPs serving hundreds of clients. Self-service has been on the roadmap for years. Portals have been built. Knowledge bases have been written. And yet, the volume of routine requests hitting the service desk hasn't dropped.
The problem is where self-service has been built.
Why MSP self-service portals underdeliver
Portals are a sound foundation for self-service. The problem is that most end users bypass them entirely when something breaks. Instead of navigating to a portal, they open Microsoft Teams, the channel they already use throughout the day, and message someone on the service desk. When that fails, they call.
In both cases, a technician gets pulled in to triage a request that, in most cases, could have been resolved at the point of intake. Password resets, MFA resets, account unlocks, group access changes, status updates on open tickets, all of it lands on the same service desk queue.
The root cause is behavioral, not technical. End users won't change channels for a tool they use occasionally. They'll only engage where they already are. A portal deployed without a channel-native layer loses to the path of least resistance every time. The path of least resistance is messaging a technician directly. The portal isn't the problem. The missing layer is.
Endsight's analysis of more than 10,900 users across 400 plus companies, published by Unthread, found the average ticket takes 63 minutes of technician time. Only 54.3% of tickets are resolved on the first entry. Those numbers aren't a productivity problem. They're a structural one. Self-service has been pointing end users to the wrong place, in the wrong channel, with the wrong tools.
What self-service should actually look like
Self-service is an intake problem.
The shift is about meeting end users in the channel they already use and rebuilding intake around Microsoft Teams, resolving routine requests at the point of intake, before they become tickets.
When portals are enhanced with Microsoft Teams as the intake layer, three things change:
- Requests get captured properly the first time. Instead of a vague message asking a technician for help, requests arrive structured, with the information needed to action them already attached.
- Routine issues get resolved without a technician. Password resets, MFA resets, account unlocks, and access requests are inherently conversational. They can be handled inside Teams, with the appropriate approvals and audit trails, without ever creating a ticket that requires technician time.
- Your team stops being a switchboard. When routine intake is handled at the source, technicians spend their time on technical work rather than triage and reformatting.
That's what self-service should mean: Resolution at the point of intake.
What this looks like in practice
Intalex, a UK MSP working across financial services, insurance, and accountancy, restructured the way requests came into its service desk. James Hunter-Patterson, their Managing Director, calls what changed "a step change in sophistication for our service desk operations."
What that looked like in numbers:
- Onboarding reduced from around two hours to under ten minutes
- A 215 to 1 endpoint-to-engineer ratio
- Twenty to thirty minutes saved per engineer daily
The change didn't come from hiring more staff or replacing the PSA. It came from restructuring where requests started. Structured intake became the single source of truth. Routine resolution happened inside Teams. The technician layer stopped being the first line of contact and became what it should have been all along, a place for technical work that actually requires technical judgment.
Other MSPs are seeing the same pattern. Ramsac, a mature UK MSP serving more than 250 clients, collapsed the new starter SLA from three days to the same morning, with around 25% of their support tickets now involving Pia.
The MSPs pulling ahead aren't the ones who abandoned their portals. They're the ones who enhanced them, adding a channel-native intake layer that meets end users where they already are. They've made self-service work by bringing it to the channel end users actually use.
How to think about your next step
If your service desk is still fielding routine requests that shouldn't reach a technician, the real question is whether self-service has been built in the right place.
A few questions worth asking:
- Where do end users actually go when something breaks, and is that where your self-service lives?
- What percentage of inbound requests are routine, and how many require a technician to action them?
- If structured intake captured those requests at the source, what would your service desk capacity look like in three months?
The MSPs that are answering these questions honestly are the ones reshaping their service delivery model. The ones still treating the portal as the endpoint, rather than as the foundation for something better, are the ones leaving capacity on the table.
If self-service has been on your roadmap, this is the conversation to have now. Book a 20-minute call, and we'll walk through what restructuring intake could look like in your environment.
