Every managed IT provider gives you the same non-answer: it depends. That is technically true and completely useless. What follows is the honest version — the specific things that move your number up or down, why they do, and roughly where your environment is likely to sit.
We are not going to print a per-user rate on this page. Any provider who does is quoting a different business than yours. What we will do is show you the math behind the quote so that when you get one — from us or anyone else — you can tell whether it is serious.
Change any one of these and the quote changes. That is why a single published rate would be a guess.
A per-user rate means nothing until the scope behind it is fixed. Two companies with forty staff can sit several-fold apart once you account for servers, sites, compliance obligations and the condition of what they are handing over. The rate on the page is identical in both quotes. The work behind it is not.
Low headline rates are usually low because something has been carved out of them. The most common exclusions are after-hours work, project work, on-site attendance, hardware, software licensing, and remediation of whatever was inherited on day one. None of that disappears. It arrives later, as separate invoices, at a moment you did not plan for.
The number that matters is the total annual cost of being supported — everything you will actually pay across a year — not the sticker rate on the front page of the proposal. A higher rate attached to a wider scope frequently ends up being the smaller of the two totals.
What is explicitly out of scope? And what happens the first time something is? A serious answer is written into the agreement. A vague one is an invoice you have not received yet.
None of these is a secret. They are simply the things a provider has to know before a number means anything — and the things a headcount-only quote quietly ignores.
Users drive volume, not complexity. Each additional person generates tickets, devices, accounts and onboarding, and that scales fairly predictably. Doubling your staff on one clean network is close to a linear change. Doubling them across new sites or new systems is not. What reduces it: standard hardware, a single identity platform, and a real joiner-mover-leaver process, so growth adds people rather than exceptions.
Every physical location carries its own network, its own circuit, its own failure modes and its own need for someone to physically attend. Three small branches cost more to support than one office with the same total headcount, because each one fails independently. Remote-first teams are cheaper to support than distributed offices. What reduces it: consistent equipment across sites, and cloud services in place of site-to-site dependencies.
On-premises servers bring patching, backup verification, hardware that eventually fails, and maintenance windows that land outside business hours. They also make the building itself a dependency. Moving to cloud does not automatically reduce what you spend — it changes what you are paying for, shifting hardware and after-hours labour into licensing and monitoring. What reduces it: fewer servers, current hardware under warranty, and workloads that do not need a room.
The practice management system, the ERP, the CAD platform, the EMR, the plant control system — whatever you cannot switch off. Specialist and legacy applications drive escalation time more than anything else on this list, because they fail in ways no generic runbook covers and they often need the vendor in the room. What reduces it: supported versions, a working relationship with that vendor, and documentation of how the application is actually deployed.
Evidence has to be produced as the work happens, not reconstructed the week before an audit. Regulated environments carry a separate change process, retention rules and access reviews, and all of that is genuine recurring effort rather than paperwork someone completes once. What reduces it: deciding early which framework actually applies to you, and not carrying controls you are not obliged to carry.
Business-hours support and a genuinely staffed overnight service are different products, not the same product with longer opening hours. A second shift, a weekend operation or an overnight plant floor changes the shape of the agreement and who has to be awake for it. Our own helpdesk is staffed 24/7, so for us this is a scoping question rather than a capability one. What reduces it: being honest about which systems truly need cover overnight and which can wait until morning.
The largest variable on this list, and the least discussed. Undocumented environments, expired warranties, unpatched servers, orphaned accounts and backups nobody has ever restored from all mean remediation before anyone reaches steady state. That is usually a one-off rather than a permanent addition, but it is real work and it belongs in the conversation before you sign. What reduces it: an honest inventory, and a provider willing to write remediation down as a discrete piece of work rather than absorb it quietly and spread it across everything else.
Seven questions, about a minute. What comes out is a complexity profile: how much scoping your environment needs, and which parts of it are doing the work. It is not a price, and nothing is sent anywhere unless you choose to send it.
Answer all seven questions above and your scope profile will appear here.
Your environment is close to a standard build. Scoping should be quick, and you should expect a written quote after a single conversation. Be skeptical of anyone who needs weeks to price this.
There are two or three things here that a generic quote would miss. Make sure whoever quotes you has asked about them specifically, and that they appear in the agreement rather than in a conversation you had once.
This needs a proper scoping exercise. Several factors here interact — a quote produced from a headcount alone would be wrong, probably in your favour initially and against you later.
Do not accept a quote from anyone who has not been on site or done a detailed remote assessment. There is enough here that the honest answer is ‘we need to look first’, and any provider saying otherwise is guessing.
Users drive volume, not complexity. Doubling staff on one clean network is close to linear; adding sites or systems is not.
Each physical location carries its own network, its own failure modes and its own need for someone to attend in person.
On-premises servers carry patching, backup, hardware failure and maintenance windows outside business hours.
Specialist and legacy applications drive escalation time more than anything else on this list.
Evidence has to be produced as work happens, not reconstructed later, and regulated change carries its own process.
Business hours and genuinely staffed overnight support are different products, not the same product for longer.
Undocumented environments, expired warranties and untested backups all mean remediation before steady state.
This is a scope profile, not a quote. The only way to get a real number is a short call where we look at what you actually have.
Scope varies between businesses. This list should not. If something here is missing from a proposal, that is not a cheaper service — it is a smaller one, and the difference will find you later.
Systems watched 24/7, not only while the office happens to be open.
Servers and workstations, on a schedule you are allowed to see.
A backup nobody has ever restored from is a hope, not a backup.
Tooling is the easy part. Somebody acting on the alerts is the point.
Direct access for the people with the problem, without a gatekeeper.
Written up, kept current, and handed to you on request.
Real people, named in the agreement, for when the first line cannot resolve it.
In the agreement itself, not in a conversation you had once.
Documentation and data returned on a defined timeline, without an argument.
We hold a SOC 2 Type 2 attestation and our helpdesk is staffed 24/7. Ask any provider — including us — to evidence claims like those rather than expect you to take them on trust.
Some businesses should not be buying fully managed IT, and pretending otherwise wastes everybody’s time.
With no compliance obligation and nothing shared beyond a chat app, a full managed agreement is more structure than you need. Buy help when something breaks and spend the difference elsewhere.
A full outsource often replaces someone who knows your business with someone who does not. Targeted co-managed support — overnight cover, security tooling, a second pair of hands on projects — is usually the better shape, and it keeps the person who understands your systems.
That vendor’s own support may cover more of your real problems than a generalist provider will. Check what you are already entitled to before you buy it a second time.
Because a published rate would be accurate for one specific environment and misleading for every other one. The drivers on this page change the work involved by a wide margin, and a rate that ignores them is a marketing exercise rather than a quote. We would rather spend twenty minutes understanding your setup and then put a real number in writing, which you can hold us to.
It genuinely depends on the drivers above: headcount, sites, on-premises servers, specialist software, compliance, hours of cover, and the condition of what you are handing over. We are not going to invent a range here, because a range wide enough to be honest would be useless to you, and a range narrow enough to be useful would be wrong. After a short scoping call we put the actual number in writing.
Most often: after-hours and weekend work, project work, on-site attendance, hardware, software licensing, and the remediation needed to get an inherited environment into a supportable state. Third-party vendor liaison and offboarding are commonly missing too. Ask for the exclusions in writing — a provider who will not put them in the agreement is telling you something.
That is a negotiation, not a given. Term length should reflect what is being invested up front: a heavy remediation project reasonably justifies a longer commitment than a straightforward takeover of a healthy environment. What matters more than the length is the exit. Make sure the agreement states that your documentation and your data come back to you, and on what timeline.
Discovery and stabilization, in that order. The environment gets documented, monitoring and backup are verified rather than assumed, and anything genuinely urgent is dealt with. What you should expect at the end of it is a written picture of what you have, what is wrong with it, and what needs doing before steady-state support means anything. A provider who cannot describe their first thirty days has not done many.
Answer the seven questions above, then send them to us. You will get a written quote based on your environment rather than a number aimed at an average that does not exist.
%20(1).webp){kind=logo}
%201.webp)
