Four things, in writing: response times per severity level, defined coverage hours, proactive monitoring, and monthly reporting. Our own contracts commit to 2 hours for remote support, 4 hours on-site and 1 hour for critical incidents — and I can tell you from experience that if a provider will not put numbers like these in a signed contract, you do not have an SLA. You have a promise, and promises are what you find yourself arguing about at 7am on the day the server is down.
The heart of an SLA is boring and precise: what counts as critical (systems down, business stopped), what counts as normal, and how fast the provider responds to each — remotely and on-site. We write ours as 2h remote / 4h on-site / 1h critical, weekdays 08:00 to 18:00 plus Saturday mornings. The exact numbers can vary by contract; the point is that they exist, on paper, with consequences when missed.
Most disputes I have seen between companies and their IT providers come down to a gap nobody defined: it is 9pm, something broke, and each side has a different assumption about whose problem that is. A proper SLA states the covered window and the after-hours rules — is there an emergency channel, at what cost, for what kind of incident. Ambiguity here is expensive.
Modern support runs an agent on every workstation and server — the industry calls it RMM — watching disks, backups, updates and failures in real time. We run it across every contract we hold, and the practical difference is stark: most issues get fixed before anyone calls us. Without monitoring, every problem starts with a phone call, which means every problem starts late. Ask any prospective provider two questions: what exactly do you monitor, and what alerts did you act on last month?
Who applies security updates, and how often? Who verifies the backups — and actually tests a restore, rather than admiring a green tick? What happens when one of your staff reports a phishing email? If the answers are "available as an additional service", the contract is protecting the provider, not you.
Every month our clients get a report: tickets resolved, response times achieved, system health, what we recommend next. It is not marketing — it is how the client verifies the SLA without taking anyone's word for it. A provider who resists reporting is asking you to pay on faith.
Generic SLA advice misses three local realities. Power: outages are the single most common cause of incidents here, so UPS monitoring and clean-shutdown procedures belong in the contract. Connectivity: remote support is only as good as the link, so there must be a real on-site commitment behind it. And presence: "4 hours on-site" means nothing from a provider whose nearest technician is in another country. Ask where the team actually sits.
If you want to see how we structure ours — the same terms described above — the details are on the managed IT page.
For business support in Maputo: within 2 hours remotely and 4 hours on-site during coverage hours, and within 1 hour for critical incidents. Faster commitments exist, but verify the provider actually has local technicians to honour them.
Remote Monitoring and Management: an agent installed on every computer and server that reports health — disks, backups, updates, failures — in real time, so the provider fixes most issues before they interrupt your team.
Yes. Even a 10-person company depends on email, files and invoicing. A basic written SLA with monitoring typically costs less than the downtime of a single bad incident.
Free initial conversation · proposal within 48 hours · no obligation
talk to us