October 16, 2026
October 16, 2026
Most guidance on this subject is written by companies selling the service, which is why it tends to stop at a price list. The harder questions are how to compare an external provider against a salary on the same basis, which pricing model fits the shape of your business, and what actually goes wrong once the contract is signed. This guide covers those.
In short: compare the total cost, not just the monthly fee or salary. An internal hire comes with recruitment, training, software and hardware costs, leave and turnover. An outsourced provider may charge extra for work outside the agreed scope, while onboarding and escalation can also take time.
The right pricing model depends on how your IT support needs change as the business grows. The contract should also be clear about what is included, what is not, and how problems will be handled.
The four pricing models and what each one hides
These figures come from pricing guides published by vendors and managed service providers in the United States. Actual rates vary by country, provider and service scope, so use them as general benchmarks rather than expected prices.
When comparing providers, focus on which pricing model best matches the way your support needs change. The cheapest option on paper may not be the cheapest once you account for the support your business actually needs.
Most businesses start by comparing the provider's monthly fee with an employee's salary. That leaves out several costs on both sides.
There are two important differences to consider.
One internal IT person cannot provide continuous coverage on their own. Holidays, sick leave and resignations can all leave the business without support. An outsourced provider can spread the workload across a team, which can be more valuable than the cost saving itself.
There is a trade-off, though. An internal IT employee builds up detailed knowledge of your systems over time. A new provider has to learn that environment from scratch. This can take time and money, especially if your setup is unusual or heavily customised.
Published comparisons suggest outsourcing runs roughly 25 to 45 percent below equivalent internal provision, with one commonly cited illustration putting a two-person internal function near 185,000 US dollars a year against 60,000 to 84,000 for outsourced coverage of a 50-person company. These figures come from the US market and assume that the internal and outsourced teams provide the same level of coverage. That may not be true in practice, so use the figures as a reference rather than a direct comparison. Build the table above with your own numbers before trusting any ratio.
There is no single best pricing model. The right choice depends on what drives your support costs.
If support volume tracks headcount, because people mostly have one laptop and use standard applications. A per-user model usually works well as the business grows. If support volume tracks equipment, because you run shared terminals, production hardware or a lot of infrastructure. A per-device model may be a better fit. A per-user model could cost more than necessary in this situation.
If your systems are stable and incidents are rare, break-fix can be genuinely cheaper, but only if you accept that nobody is being paid to prevent anything. This can work for a small business with simple cloud-based systems and few incidents. It becomes harder to justify when downtime has a significant cost for the business.
If budget predictability matters more than unit efficiency, a fixed fee is worth paying for, provided the scope boundary is written precisely enough that both sides read it the same way.
A good starting point is to look at your support requests from the last quarter. Count how many support requests you generated last quarter and what they were about. Businesses that have never counted usually discover that most volume is access, onboarding and a small number of recurring faults, which is information that changes both the model and the negotiation.
Outsourcing is not the right choice for every business. There are situations where keeping some or all IT support in-house makes more sense.
Keep at least some IT support in-house when technology is central to your product or service. For example, a software company's engineering environment may require specialist knowledge that a general IT support provider does not have.
Keep it internal when response time requirements are tighter than any provider will contractually accept, and you genuinely need someone physically present within minutes. Manufacturing lines and clinical settings sometimes fall here.
Keep it internal when your environment is so unusual that knowledge transfer would cost more than the salary, which is rare but real in businesses running heavily customised legacy systems.
Be cautious if nobody inside the company will be responsible for managing the provider. Without an internal owner, priorities can become unclear. The provider can manage tickets, but someone inside the business still needs to decide what should be prioritised. Because the provider cannot set your priorities for you and will default to closing tickets.
The hybrid arrangement, one internal generalist plus an external team for depth and coverage, suits a large share of businesses between roughly 20 and 200 people, and is underused because it is not what either an MSP or a recruiter is selling.
Most IT support contracts include an SLA table. The problem is that these tables do not always measure what matters most to the business. They define response times by ticket category. A provider can meet the response target while the underlying problem is still affecting the business.
A better approach is to set priority levels based on business impact, not just the type of technical issue.
Calibrate the numbers to your own tolerance rather than adopting these, and note that a provider quoting tighter figures is not necessarily better.
The SLA should also cover four practical points. First, define the support hours clearly, including how public holidays are handled. Second, separate response time from resolution time. Third, agree who decides the priority of each ticket. Finally, agree what happens if the provider repeatedly misses the agreed targets.
One further term is worth requesting and is often omitted. Ask that the provider report the proportion of tickets that were resolved within target alongside the raw volume, over a rolling period. A single month can be explained away. A rolling figure cannot.
Outsourcing IT support does not remove your responsibility for security. You still need clear rules around access, system ownership and incident response.
These responsibilities should be agreed before the contract starts.
Identity and access. The provider will hold privileged credentials to your systems. Agree how those are issued, how they are logged, and how they are revoked when one of their staff leaves. Also ask how you would be notified when a provider employee leaves your account or no longer needs access.
Asset ownership. Domains, cloud tenancies, licences and certificates should be registered to your company with the provider granted administrative access. Giving the provider ownership may be convenient when the relationship starts, but it can create problems when you leave.
Incident responsibility. Decide in advance who declares an incident, who informs customers, and who holds the obligation to notify a regulator if one applies to your sector. The provider may detect and respond to an incident, but the business may still be responsible for notifying customers or regulators. Agree on these responsibilities before an incident happens.
Backup deserves separate treatment because it fails quietly. Agreeing that a provider performs backups is not the same as agreeing that restoration is tested. Request a restore test at a defined interval, with evidence, and treat an untested backup as absent.
None of this requires a large security programme. It requires four or five sentences in a contract, written before anything goes wrong, and a provider who answers these questions without hesitating.
These problems are easy to overlook during procurement. It is worth asking about them before you sign the contract.
Scope boundary disputes. The contract covers support but not projects, and nobody agreed where a large change stops being supported. Include practical examples in the contract. It should be clear which types of work are included in support and which are treated as separate projects.
First line that cannot resolve anything. A ticket may be logged quickly but immediately passed to another team. That can make response times look good while the issue is simply moving through the queue. Ask for the first contact resolution rate, and ask what proportion of tickets are escalated beyond the first line. General background on where these tiers sit is covered in our guide to IT support levels.
Knowledge that never transfers. Over time, the provider builds up knowledge of your IT environment. If that knowledge is not documented in your systems, changing providers can mean starting the discovery process again. Two years later, changing providers means paying for that discovery again. Require documentation in your own systems as a deliverable, not as a courtesy.
Staff turnover on the provider side. You contracted with a company and are served by individuals. When they change, service quality changes. Ask about the account team's tenure and whether named people are committed contractually.
Performance measured only by the provider. A monthly summary is difficult to verify if you cannot access the underlying ticket data. Require access to the underlying ticket data, not only a monthly summary.
Creeping device and user counts. Costs can increase gradually as more users or devices are added. Schedule a quarterly reconciliation of what you are actually paying for, since nobody else will raise it.
No regular service reviews. If everything is working, regular communication can easily drop off. Over time, the provider may lose sight of your plans and upcoming projects. Then a project lands with no preparation. A short quarterly review prevents this at almost no cost.
Each of these has a contract term that prevents it, and asking about them during procurement tells you quickly whether a provider has encountered them before.
The transition period often takes more time than businesses expect. The monthly fee usually reflects ongoing support, but the first few months involve additional discovery and setup work. A provider quoting a monthly fee is quoting steady state, and the first quarter is not steady state.
During this period, the provider will need to document your systems and understand how your team works. Ticket volume may also increase temporarily as employees start using the new support channel. Your own team will need to spend time answering questions and providing access to systems.
Three decisions make this shorter. Give the provider an accurate asset and access inventory before day one, rather than letting them discover it. Name an internal owner with enough authority to make decisions during the transition. And agree explicitly what happens to in-flight issues at the handover point, since these are what fall through.
For that reason, it is better to assess the provider from month four onward rather than judging the relationship based on the first month alone.
Pay attention to how a provider responds to questions about service failures and contract exit. A provider that is willing to discuss both openly is generally easier to work with.
Conclusion
Start with your support requests from the last quarter. Group them into access and onboarding issues, recurring problems and one-off requests. This gives you a clearer picture of the support your business actually needs. It can also help you choose a pricing model, estimate support volume and identify recurring issues that a provider should help prevent over time. It is also the baseline you will need later to judge whether the arrangement worked. Cost benchmarks by service type are covered further in our IT support cost guide.
Serdao provides technical support from its French headquarters, with delivery in Ho Chi Minh City. We are also members of CCI France Vietnam and French Tech. Our helpdesk support and technical support pages set out scope and process in detail, and you can contact our team to work through the comparison above against your own numbers.
1. At what size does outsourcing usually make sense?
There is no fixed headcount at which outsourcing becomes the right choice. Smaller businesses may not need a full-time IT specialist, while larger businesses often benefit from having some IT capability in-house. For many SMBs, the decision depends more on support volume, system complexity and the level of internal expertise than headcount alone.
2. Is outsourced support cheaper than hiring?
Often, but not for the reason usually given. The saving rarely comes from the hourly rate. It comes from not paying for coverage you only need occasionally, such as specialist security or network expertise, and from not carrying a single person's leave, training and turnover. If you need one competent generalist full time and nothing else, hiring can be cheaper.
3. What should the contract length be?
The contract should give the provider enough time to recover its transition costs without locking your business into a long commitment. Twelve months with a defined exit process is a common landing point. Be wary of long minimum terms paired with vague exit assistance, because that combination is where the cost of leaving is hidden.
4. How do we keep control of our own systems?
Insist that accounts, domains, licences and cloud tenancies are owned by your company with the provider granted access, never the reverse. This sounds obvious and is one of the most common problems discovered at exit, when the business finds that critical assets are registered to the provider.
5. Can we outsource part of it?
Yes, and it is frequently the better answer. Splitting by tier, keeping first line internal for immediacy while outsourcing depth and after-hours coverage, works well. So does splitting by domain, keeping user support internal while outsourcing infrastructure and security. Decide the split by where your internal knowledge is genuinely valuable.
6. What is the single best predictor of a good outcome?
An internal owner with authority and time. Businesses that appoint one tend to get value from average providers, and businesses that do not tend to be disappointed by good ones.