How managed IT services actually work — and what to look for in a provider
What a managed service actually covers, and the questions that separate a partner from a ticket queue.
Most organisations buy managed IT twice. The first time they buy a phone number to call when something breaks. The second time — usually after an outage that the phone number did not prevent — they buy the thing they needed in the first place.
The difference is not the size of the contract. It is whether anyone is accountable for the system continuing to work when nobody has reported a problem.
Break/fix is not a managed service
Under a break/fix arrangement you pay for time after something has gone wrong. The incentives are honest but unhelpful: the provider earns when your systems fail. Nobody is paid to notice that a backup has been silently failing for six weeks, or that a certificate expires on a Saturday.
A managed service inverts that. You pay a predictable fee for an agreed outcome, and the provider carries the cost of the work required to hold it. If they are inefficient, that is their problem. If they let a preventable incident happen, it is their problem twice — once to fix it, once because it eats the margin they priced.
That inversion only works if the scope is written down properly. This is where most contracts fall apart.
What is actually in scope
A managed service worth the name covers, at minimum:
- Monitoring and alerting — on infrastructure, applications and the network paths between them, with someone rostered to act on an alert at the hour it fires, not the next working morning.
- Patch and vulnerability management — a stated cadence, a stated emergency path for a critical CVE, and a record of what was patched when.
- Backup and restore — including a tested restore. An untested backup is a belief, not a control.
- Identity and access — joiners, movers and leavers handled as a process, because a leaver with live credentials is the most common way a small organisation loses data.
- Endpoint management — device enrolment, disk encryption, and the ability to wipe a stolen laptop.
- Service desk — a route for humans with a problem, staffed by people who can actually resolve rather than escalate.
- Vendor management — someone who owns the argument with your ISP, your hosting provider and your line-of-business software supplier, so you do not have to referee it.
If a proposal is vague about any of these, it is vague on purpose.
Read the SLA properly
Almost every SLA quotes a response time. Response time is the least interesting number in the document. It tells you how quickly someone will acknowledge that you have a problem, not how quickly you will stop having one.
Ask instead:
- What is the resolution target, by severity, and what happens when it is missed?
- How is severity assigned, and who decides? If the provider grades their own homework, every incident is a P3.
- What are the service hours, in your timezone, on your public holidays?
- What is explicitly out of scope — and what does the hourly rate become when you cross that line?
- What is the exit? Who holds the credentials, the documentation and the configuration when the relationship ends? A provider who cannot answer this cleanly is relying on lock-in rather than performance.
Questions that separate a partner from a ticket queue
Anyone can answer a question about uptime. These are harder, and the quality of the answer tells you what you are buying:
“Show me a post-incident review you have written.” Not a summary — the actual document, redacted. You are looking for a real root cause, an honest account of what was missed, and actions with owners. A provider who has never written one has either never had an incident or never learned from one.
“What will you tell me I am doing wrong?” A partner has opinions about your architecture and will state them before you ask. A ticket queue has no view, because having a view creates work.
“Who, specifically, will be on our account?” Managed services are sold by the firm and delivered by a person. Ask for names, and ask what happens to your service when that person is on leave.
“What have you automated on your other accounts?” A provider whose margin comes from automation gets cheaper to serve over time and passes some of that back. A provider whose margin comes from billing hours has no reason to improve.
What changes in an African operating context
Three things that generic advice tends to skip:
Connectivity is not a given. Systems have to degrade sensibly on a poor link, and remote support cannot assume a stable session. Designing for the median connection rather than the best one is a technical decision made early, not a support decision made later.
Power is an availability problem. Uptime targets that ignore utility supply and generator changeover are targets nobody has thought about. Ask how the provider’s own monitoring survives an outage at your site.
In-region matters. A follow-the-sun desk in another timezone will meet its response SLA at three in the morning and still leave you waiting until people who understand your business wake up. Support hours that overlap your working day are worth more than a faster number on paper.
The short version
The contract you want is one where the provider is measurably worse off when your systems fail, has written down exactly what they own, and is willing to tell you something you would rather not hear. Everything else is a phone number.