Understanding IT Service Level Agreements in Nigeria
Your email system has been down for three hours. Your sales team can’t access customer records. Your IT vendor keeps saying, “We’re working on it.” You’re losing money by the hour. When you ask, “When will this be fixed?” the answer is vague: “Soon.”
This is what happens when you don’t have a clear Service Level Agreement.
As Nigerian businesses become more dependent on technology, from cloud accounting to e-commerce platforms to remote work tools, the stakes for IT reliability keep rising. Businesses that rely heavily on digital systems often work with IT consulting services in Nigeria to establish a solid foundation for reliability and uptime. Downtime doesn’t just inconvenience staff. It stops revenue, damages customer relationships, and can trigger compliance issues under the Nigeria Data Protection Act.
Yet many Nigerian businesses still run on handshake IT agreements. “My guy handles our IT.” It works fine until something breaks, and suddenly there’s no clear answer: How fast should they respond? When will it be fixed? What happens if they don’t deliver?
This guide explains what Service Level Agreements (SLAs) are, why Nigerian businesses need them, what realistic SLAs look like, and how to evaluate vendor promises.
This is Part 1 of our IT Support Contracts series for Nigerian businesses. In the coming weeks, we’ll cover what should be in your complete IT support contract, how to measure vendor performance, and help desk best practices.
What Is a Service Level Agreement (SLA)?
A Service Level Agreement is a documented promise from your IT vendor about what they’ll do, when they’ll do it, and what happens if they don’t. Not complicated legal language. Just clear commitments about service performance.
Your contract says “we’ll provide IT support for ₦500,000 monthly.” Your SLA says “we’ll respond to critical issues within 30 minutes and resolve them within 4 hours.”
Every IT vendor claims they’re “reliable” and “responsive.” An SLA transforms vague promises into measurable commitments:
- “We’re very responsive” becomes “We respond to urgent requests within 1 hour.”
- “We keep your systems running” becomes “We guarantee 99.5% uptime.”
- “We’re here when you need us” becomes “We provide support Monday-Friday, 8 AM – 6 PM.”
SLAs cover response times (how fast they acknowledge your request), resolution times (how long to fix), system availability (uptime percentage), support hours (when you can reach them), escalation procedures (what happens when first-level support can’t help), and performance metrics (how they measure success).
A written SLA protects both parties. When your “IT guy” is reliable, everything works. But things change. People travel, fall sick, or remember promises differently. Written SLAs create a clear, mutual understanding.
Why Nigerian Businesses Need SLAs
The informal IT support costing ₦50,000 monthly seems great until your accounting system crashes during month-end closing, and your contact is handling another client’s emergency. No documented commitment about response speed, availability, what’s included, or how performance gets measured.
Revenue Loss: An e-commerce site down for 4 hours during evening shopping doesn’t just lose those sales. Customers don’t return. Google ranking drops. Ad spend is wasted. Strong hosting and support frameworks are part of proper web development services in Nigeria and shouldn’t be treated as afterthoughts.
Productivity Cost: When 20 staff can’t access email for 3 hours, you’ve lost 60 person-hours. At ₦5,000 per hour, that’s ₦300,000 from a single incident.
Customer Trust: Customers are calling but getting voicemail. Clients are getting errors when paying invoices. Partners are unable to access your “always available” portal. These aren’t technical failures, they’re trust failures.
Compliance Risks: The Nigeria Data Protection Regulation requires “appropriate technical and organizational measures” to protect data. Frequent downtime or slow security responses could trigger regulatory action. If you manage customer data, our Nigeria Data Protection Act guide explains what your responsibilities involve.
SLAs become critical when you have employees depending on IT systems, process online transactions, handle sensitive data, need predictable costs, or are growing and need scalable support.
Core SLA Components
Service Availability
Service availability is the percentage of time your systems are expected to be operational. But percentages hide real impact:
| Uptime Percentage | Downtime Per Month | Acceptable For |
|---|---|---|
| 99.9% | 43 minutes | International cloud services (AWS, Azure, Google Cloud) |
| 99.5% | 3.6 hours | Nigerian hosting with generator and UPS backup |
| 99% | 7.2 hours | Basic shared hosting |
| 95% | 36 hours | Not recommended. Unreliable services |
That 0.4% difference between 99.5% and 99.9% represents over 3 hours of additional reliability monthly.
Nigerian Reality: Can a local hosting provider deliver 99.9% uptime when power supply is inconsistent and data centers depend on diesel generators? European or US-based cloud providers with redundant power and multiple internet connections might deliver better uptime than Nigerian providers claiming higher numbers. Infrastructure realities matter.
Realistic expectations:
- International cloud services (AWS, Azure, Google Cloud): 99.9% achievable
- Nigerian hosting with generator and UPS backup: 99.5% honest and achievable
- Basic shared hosting: 99% more realistic than inflated claims
Many businesses handle uptime reliability by using proper managed IT services instead of ad-hoc support.
What Gets Excluded
Pay attention to exclusions in uptime calculations:
Scheduled Maintenance: Most SLAs exclude planned maintenance windows. If your vendor schedules 4 hours of maintenance monthly, that doesn’t count against their 99.5% commitment. Make sure maintenance happens during low-traffic hours.
Force Majeure: Major disasters, wars, government actions. Reasonable to exclude, but some vendors use this too broadly.
Internet Provider Failures: If your internet connection fails, your hosted services might be fine, but you can’t access them. Some SLAs exclude this. Others include it as their responsibility to have redundant connections.
User-Caused Issues: If someone in your office accidentally deletes critical files or changes configurations incorrectly, that’s not the vendor’s fault. But make sure the definition of “user-caused” is clear.
Third-Party Service Dependencies: If your system depends on a payment gateway and that gateway fails, is it excluded from your vendor’s SLA? This should be explicit.
Response Times
Response time is how quickly your vendor acknowledges your request and starts working.
| Priority Level | Response Time | What It Covers |
|---|---|---|
| Critical (P1) | 15-30 minutes | Business stopped: Email server down, website offline, payment system not working |
| High (P2) | 1-2 hours | Major impact: Major feature broken, multiple users affected |
| Medium (P3) | 4-8 business hours | Minor issues: Single-user problems, minor bugs |
| Low (P4) | 24-48 hours | Questions: How-to questions, feature requests |
The Lagos Reality: A vendor promising “30-minute onsite response anywhere in Lagos” hasn’t thought about peak hours. Better: “Remote support within 30 minutes; onsite within 3 hours, subject to traffic.”
Resolution Times
Resolution time is the time it takes to fix your problem. This is what matters most.
A vendor might respond in 15 minutes but take 6 hours to resolve. The resolution time is 6 hours.
Realistic targets:
- P1 Critical: 4-8 hours for resolution or workaround
- P2 High: 1 business day
- P3 Medium: 3 business days
- P4 Low: 5 business days or by agreement
Fast acknowledgment is reassuring, but you need solutions. A vendor who responds in 10 minutes but takes 3 days to fix is worse than one who responds in 1 hour but fixes in 4 hours.
Nigerian Factors Affecting Resolution Time
Several local realities affect how quickly issues get resolved:
Equipment Availability: If your server needs a replacement part, it may need to be ordered from abroad. A 4-hour resolution target becomes unrealistic if the vendor needs to import components.
Vendor Access to Your Location: Security protocols, traffic, and access restrictions all affect how quickly vendors can get on-site when needed.
Third-Party Dependencies: Many solutions depend on other vendors, such as internet providers, power companies, and hardware manufacturers. Your IT vendor can’t control MTN’s network issues or fix NEPA’s power problems.
Internet Speed for Remote Fixes: Uploading fixes, accessing your systems remotely, and downloading updates all require adequate internet connectivity. Slow connections extend resolution times.
Well-written SLAs acknowledge these realities: “Resolution times assume availability of necessary parts and third-party service availability.”
Support Hours
| Coverage Type | Hours | Best For |
|---|---|---|
| 8×5 | Monday-Friday, 8 AM – 5 PM | Standard SME support |
| 12×5 | Monday-Friday, 7 AM – 7 PM | Extended business hours |
| 16×5 | Monday-Friday, 6 AM – 10 PM | Retail, restaurants, shift work |
| 24×7 | Always available | Critical operations (expensive, rarely necessary) |
Even 8×5 contracts usually include emergency escalation: “For P1 issues outside support hours, contact the emergency hotline. Response within 1 hour. Additional charges apply.”
Be explicit about public holidays.
Performance Metrics
Your SLA should specify what is tracked: ticket volume by priority, average response/resolution times, SLA target achievement, uptime percentage, first-call resolution rate, and customer satisfaction.
Monthly reports keep everyone honest. When vendors consistently miss targets, the data shows it clearly.
Penalties and Service Credits
Service Credits: “For each 0.1% below 99.5% uptime target, customer receives 5% service credit.”
If the vendor delivers 99.1% (0.4% below the target), you get a 20% credit next month.
Termination Rights: “If vendor fails P1 response targets 3 consecutive months, customer may terminate with 30 days’ notice.”
Most Nigerian SME contracts don’t include meaningful penalties. Enterprise contracts do. At a minimum, get service credits for major violations and clear termination rights.
Setting Realistic Expectations
Well-written SLAs acknowledge constraints honestly. Nigerian IT services operate in challenging infrastructure conditions.
Power: Generators need maintenance, fuel, and rest periods. UPS batteries eventually fail. Fuel scarcity affects even prepared vendors.
Honest language: “Uptime targets assume fuel availability. Extended outages requiring generator operation beyond 72 consecutive hours may affect guarantees.”
Internet: Responsible vendors use multiple ISPs, but all Nigerian providers can experience simultaneous regional issues. 4G/5G failover helps but shares infrastructure challenges. International bandwidth costs more, creating constraints during high traffic.
Access: Morning and evening rush hours, bridge closures, VIP movements, and flooding all affect the vendor’s ability to reach your location in Lagos. Security protocols at corporate facilities take time to implement. Remote areas face longer everything—parts delivery, technician travel, connectivity.
Equipment: Parts often need importing. Even locally available items might not be in immediate inventory. Specialized skills might require consultants from abroad.
What “World-Class” SLAs Mean in the Nigerian Context
You can absolutely have world-class service levels in Nigeria. But understanding what that means is important.
Global Vendor SLAs
Microsoft 365, Google Workspace, AWS, and Azure—these services offer the same SLAs globally, including Nigeria. Their 99.9% uptime commitment applies whether you’re accessing from Lagos or London. These services achieve high reliability through massive infrastructure investment and global redundancy. For example, our Zoho Workplace solutions in Nigeria follow a similar SLA structure for cloud email and collaboration tools.
Local Implementation Reality
But here’s the nuance: while Microsoft guarantees 99.9% uptime for Microsoft 365, your experience depends on:
- Your internet connectivity (local ISP, not Microsoft)
- Your local IT support for setup and troubleshooting (local vendor, not Microsoft)
- Your hardware and local network (your responsibility or your vendor’s)
So your local implementation partner’s SLA will be constrained by Nigerian realities even while the core service achieves global standards.
Realistic Example
A Nigerian business uses Microsoft 365 (99.9% uptime SLA from Microsoft) with local IT support from a Lagos vendor.
The local vendor’s SLA might say:
- “We guarantee Microsoft 365 service availability of 99.9% (per Microsoft SLA).”
- “We guarantee local internet connectivity of 99.5% during business hours.”
- “We respond to Microsoft 365 access issues within 1 hour during business hours.”
- “We resolve internet connectivity issues within 4 hours, subject to ISP cooperation.”
This is honest and realistic. The vendor is clear about what they control (their response time, local connectivity) versus what they don’t (Microsoft’s global infrastructure).
Questions to Ask Vendors
When evaluating vendor SLA promises, ask these specific questions:
About Power: “How do power outages affect your SLA commitments? How long can you maintain services on generator power? What happens during extended power outages?”
About Internet: “Do you have redundant internet connections? What happens when all ISPs in Lagos experience issues? How does MTN or Airtel downtime affect your service to me?”
About Staffing: “Do you have backup staff for absences? What happens when key technicians are sick or traveling? How do you handle vacation coverage?”
About Parts: “Can you get replacement parts locally? How long does it typically take? What happens if you need to import specialized components?”
About Dependencies: “What third-party services do you depend on? What are their SLAs? How do their failures affect your commitments to me?”
About Geography: “Where are your technicians based? How does distance from my location affect response times? Do you have local presence in my city?”
Building Realistic SLAs
Begin with what vendors can deliver, not what you wish they could. Factor in known constraints.
Build in buffer time—if the typical resolution is 2 hours, the SLA target should be 4 hours. This provides a buffer for complications, traffic, and parts availability—the reality of operations in Nigeria.
Define clear exclusions. Be explicit: “SLA response and resolution times assume: business hours coverage, client internet connectivity is functioning, client systems are accessible, and necessary parts are locally available. Extended times may apply when these conditions aren’t met.”
Review and adjust quarterly. When vendors consistently exceed targets, maybe better SLAs are possible. When they consistently miss, either adjust to realistic levels or change vendors. When your needs change, SLAs should change too.
What SLAs Should Not Contain
Watch for these red flags:
Hidden Fees: “Additional charges may apply for complex issues” means every P1 becomes “complex.”
Better: “Onsite visits ₦15,000. Hardware procurement cost plus 15%. All other support included.”
Vague Escalations: “Issues escalated as needed” tells you nothing.
Better: “P1 escalates to senior engineer after 2 hours. Service manager after 4 hours.”
Overly Broad Exclusions: “SLA doesn’t apply during power outages, internet disruptions, weekends, holidays, high demand…” defeats the purpose.
Better: “Excludes planned maintenance (max 4 hours monthly, weekends) and force majeure.”
Blame-the-Client: “Not responsible for client environment, user actions, third-party software, network conditions…” tries to make everything your fault.
“Commercially Reasonable Effort”: Lawyer-speak for “we’ll try but not commit.”
Your SLA needs firm commitments: “Respond within 30 minutes,” not “use reasonable efforts to respond promptly.”
Unilateral Changes: “Vendor may modify SLA with 30 days’ notice” lets them reduce service levels.
Better: “Modifications require mutual written agreement.”
Measurement Loopholes: “Uptime measured by vendor’s internal systems” with no client access means you can’t verify.
Better: “Measured via third-party monitoring. Client has dashboard access.”
Evaluating Vendor Promises
Red Flags
- 99.99% uptime without Tier 3/4 infrastructure
- 15-minute onsite response across Lagos
- 24/7 support from a 2-person company
- Unlimited support flat fee
- “Best effort” language
- “As soon as possible” commitments
- No specific metrics
- Missing priority definitions
- No exclusions listed
- Unclear support hours
- No escalation process
What Good SLAs Include
Specificity: Exact times, clear definitions, defined scope, measurement methodology
Honesty: Realistic targets, clear exclusions, acknowledged limitations, reasonable penalties
Practicality: Achievable with vendor resources, appropriate for business size, aligned with needs, flexible for adjustments
Making SLAs Work
Document Everything
Use ticketing systems, not just WhatsApp. Tickets document when you submitted, what priority, when the vendor responded, and when it was resolved. Without tickets, SLA tracking is impossible.
Keep SLA accessible. Track performance monthly. Save all communications.
Regular Reviews
Monthly: Were targets met? What caused misses? Any patterns?
Quarterly: Review 3-month trend, persistent issues, and whether targets need adjustment. Keep it collaborative.
Annual: Is the SLA still appropriate? Has your business grown? Has vendor performance been consistently good or poor?
Ongoing: Address issues as they occur. Work together. Good vendors welcome feedback.
When SLAs Aren’t Met
One miss isn’t a crisis. Three P1 misses in one month is a pattern:
- Document: date, ticket, target, performance, impact
- Raise it: “You missed SLA three times. What’s causing this?”
- Reference the SLA: “Section 4.2 requires a 30-minute response. We saw 2 hours.”
- Escalate if needed
- Consider termination for persistent problems
Your SLA should specify termination rights for repeated violations.
Adjustment Triggers
Consider adjustments when business grows, technology changes, vendor consistently misses or exceeds targets, needs change, or infrastructure improves.
What’s Next in This Series
Understanding SLAs is just the foundation. In our next article, “What Should Be in Your IT Support Contract: A Nigerian Business Guide”, we’ll cover the complete contract framework: pricing structures, data ownership, intellectual property rights, termination clauses, and the legal protections every Nigerian business needs beyond just service levels.
We’ll show you what to negotiate, what red flags to watch for, and how to structure contracts that protect your business while maintaining good vendor relationships.
Conclusion
Service Level Agreements transform vague vendor promises into measurable commitments. For Nigerian businesses increasingly dependent on technology, SLAs provide essential protection by creating clear service performance expectations.
SLAs create accountability. Specific commitments mean both parties know what success looks like.
Nigerian context requires realistic SLAs. Infrastructure challenges affect what vendors can deliver. Good SLAs acknowledge constraints.
Good SLAs balance capabilities with needs. The best SLA is one that vendors can consistently meet while still covering your requirements.
Regular monitoring keeps SLAs relevant. Monthly tracking, quarterly reviews, and annual adjustments ensure evolution with your business.
Get Expert Help
If you’re reviewing an existing SLA or creating one for a new vendor, PlanetWeb can help you define realistic terms that match your operations and protect your business. We understand both the technical requirements and the realities of Nigerian infrastructure that affect service delivery.
Whether evaluating vendor proposals, negotiating better terms, or setting up performance tracking, our team brings practical experience from working with businesses across Lagos, Abuja, and beyond. You can discuss your IT support needs with our team to review or create your SLA.
Understanding SLAs is just one part of a complete IT support agreement. Learn what else should be in your IT support contract to fully protect your business—from pricing structures to data ownership to termination clauses and more.
