How to define the scope for outsourced IT support
Deciding where the external team's job should stop is difficult before they have handled any actual tickets. Without a clear boundary, the external team will blindly escalate technical issues, leaving the internal team overwhelmed with the exact same workload.
What people tried
Every workaround mentioned in the threads below. We haven’t tested any of them — and nobody here is claiming they worked.
- 1Starting with a very narrow scope of repetitive tasks and widening it over time
- 2Defining clear lists of what the external team can investigate before escalation
- 3Hiring providers that offer dedicated teams with deeper product knowledge
In their words
Unedited, most upvoted first, each linked to the thread it came from.
“I'm getting closer to outsourcing some of our support and the part I keep changing my mind about is where the external team's job should stop.”source ↗
“I don't want an external team blindly escalating anything remotely technical because then we've just added another inbox in front of the same internal workload.”source ↗
“Trying to design the perfect scope before they had handled a ticket was impossible.”source ↗
Where this came up
People with this problem also raised
- 3How to handle client support when you're a solo freelancer on vacation
- 3How to find reliable on-demand onsite IT support
- 3Why is working at an MSP so soul crushing?
- 4How to manage remote IT infrastructure without a dedicated team
- 3How to handle being the only IT person at a company
- 2Starting a first sole sysadmin job with no documentation