Choosing between 24×7 and 13×5 support is not a “technical” debate. It’s a business decision: it affects your operational continuity, your risks (including cybersecurity), and the real cost of every incident.
The problem is that many companies buy “support hours” or sign a generic SLA… and discover too late that this SLA doesn’t cover what their day-to-day operations actually need. The result: longer outages, improvised fixes, stressed teams, and losses that don’t show up on the provider’s invoice, but do show up on your P&L.
In this article, we break down how to define a realistic SLA (without overpaying), when 24×7 makes sense, and how to quantify the cost of not having it, with a practical approach for SMEs and organisations with 50+ employees.
24×7 vs 13×5: what it really means (and what it doesn’t)
When people talk about 24×7 (24 hours, 7 days) and 13×5 (typically 13 hours a day, 5 working days), they often think “someone is available”. But a serious SLA isn’t only about availability: it defines timings, priorities, channels, and responsibilities.
In practice:
- 13×5: extended coverage during business hours (for example, 08:00–21:00 Monday to Friday). It’s ideal when the impact outside those hours is low or acceptable.
- 24×7: continuous coverage (including nights, weekends, and public holidays). It makes sense when there are critical systems or a business that doesn’t stop.
Important: an SLA does not guarantee that “everything will be fixed in X hours”. It usually commits to response times and target resolution times by severity, and sets the collaboration framework (escalations, access, approvals, etc.). This matches how SLAs are described in service desk best practices and service level agreements.
A “real” SLA vs a “paper” SLA: the 6 points you should demand
A useful SLA is one that reduces total incident time and prevents arguments when everything goes wrong. To achieve that, the agreement must specify at least these points.
1) Scope: what’s included and what isn’t
This is where you decide whether support covers only users and PCs, or also servers, network, Wi-Fi, firewall, Microsoft 365, backups, cloud services, etc. Without this, the provider and the customer can interpret things differently.
Examples of a well-defined scope:
- Workstations, printing, corporate applications
- Infrastructure (virtualisation, storage, networks, Wi-Fi)
- Security (EDR/XDR, firewall, VPN, filtering, MFA)
- Cloud services (M365, Azure/AWS, critical SaaS)
- Backups and restores
2) Clear severities (P1–P4) with examples
If everything is “urgent”, nothing is. You should agree severities with examples everyone can understand:
- P1 Critical: business stopped (ERP down, total network outage, active cyber incident).
- P2 High: business degraded (very poor performance, partial outage, many users affected).
- P3 Medium: functional issue with a temporary workaround.
- P4 Low / request: queries, onboarding, planned changes.
This prevents a “can’t print” from competing with “can’t invoice”.
3) Measurable times: response, restoration and resolution
A serious SLA distinguishes:
- Response time: when the team takes ownership and starts diagnosis.
- Restoration time (workaround): when you can operate again, even partially.
- Resolution time: when the root cause is fixed or the service is stabilised.
In many organisations, “restoration time” delivers the most value. From a continuity perspective, it’s key.
4) Windows and exclusions: maintenance, holidays and changes
If your business works Saturdays, or closes at 18:00, the SLA must reflect it. It should also clarify:
- Planned maintenance (and notice periods)
- Public holidays and closures (if applicable)
- Critical changes (who authorises, how it’s coordinated)
5) Channels and escalation: how “urgent” is triggered
“Open a ticket” is not the same as “we have a P1”. The SLA should specify:
- Emergency phone / priority channel for P1
- Escalation rules if there’s no response
- Customer contacts (owners, approvers)
6) Shared responsibilities (this avoids 80% of blockers)
An SLA fails when the provider can’t act due to lack of access, permissions, or decisions. Agree on:
- Remote access, credentials and MFA
- Minimum inventory and documentation
- Customer response time for P1/P2
- Approvals for urgent changes
This aligns with the SLA approach as a document that sets objectives and obligations for both parties.
When 13×5 makes sense and when 24×7 does (no dogma)
There’s no universal “right answer” here. The key is mapping your processes and dependencies.
13×5 is usually enough if…
- Your business operates mainly during working hours.
- If there’s an outage overnight, the impact is low or acceptable until the morning.
- You have clear contingency plans (e.g., operating manually for a few hours).
- Your critical systems don’t process orders, production, or customer support out of hours.
24×7 is usually necessary if…
- You sell online or support customers out of hours.
- You run production, logistics, or “always-on” services.
- You depend on system integrations (ERP–WMS–ecommerce–carriers).
- A security incident can’t wait (ransomware, intrusion, account compromise).
- Your recovery window (RTO) is short and downtime is penalised.
Often, the best decision is a hybrid model: 13×5 for most requests, and 24×7 only for P1/P2 covering systems defined as critical.
“What it costs not to have it”: how to calculate the real cost of downtime
Talking about downtime cost without numbers leads to decisions made “by gut feel”. If you quantify it, the SLA becomes an easy-to-justify investment.
Reference studies cite very high average costs per hour (especially in large organisations), and stress that many organisations don’t measure impact well. Use it as a signal: if you don’t measure it, you’re underestimating it.
A practical formula (for SMEs) that works
First define the scenario: “ERP + email + remote access down” for X hours.
Then calculate:
- Hourly cost of idle staff
- (number of affected people) × (average cost/hour) × (inefficiency factor)
- Hourly cost of unprocessed sales/orders
- lost margin or deferred sales (if recovered later, it’s not always 0)
- Operational costs
- overtime to recover, rescheduled logistics, penalties
- Reputational / customer service cost
- hard to measure, but can be estimated from tickets/complaints
- Security risk and cost (if applicable)
- incident response, forensics, restoration, notifications, etc.
Quick (conservative) example:
- 25 people affected, £25/hour cost, 0.7 factor (not 100% unproductive)
→ 25 × 25 × 0.7 = 437.5/hour - Margin from unprocessed orders: 300/hour
- Recovery and overtime: 150/hour
Total estimated: ~887/hour
A 6-hour incident: ~5,322.
If that happens twice a year, you’re already at ~10,000 of “soft” impact. And in sectors with total dependency (manufacturing, logistics, healthcare), the true cost can skyrocket.
This ties into continuity logic: identifying the consequences of outages and setting realistic recovery objectives.
Why “having support” is not the same as having an SLA
This is where many organisations get confused:
- An hours-based contract gives you capacity, but no time commitments.
- An SLA gives you priority, a response framework, and severity-based targets.
- A managed service (well defined) also includes prevention: monitoring, maintenance, patching, and reviews.
In other words: an SLA reduces the risk of an incident dragging on exactly when it hurts most.
If what you want is continuity, the logical path is usually:
- Define criticality and dependencies
- Agree SLAs by severity (not “everything 24×7”)
- Add prevention (monitoring, patching, security)
How to design a tailored SLA: a 30-minute checklist
If you need a quick way to pin it down internally, use this checklist.
Minimum criticality inventory
- Critical systems (ERP, email, network, VPN, telephony, ecommerce, backup)
- Real operating hours (including peaks: month-end, campaigns, closings)
- External dependencies (carriers, cloud, SaaS vendors)
- Internal on-call people (if any) and decision owners
Service objectives (what you’ll sign)
- P1–P4 severities with examples
- Response, restoration and resolution by severity
- 13×5 / 24×7 coverage by severity and by system
- Channels and escalation
- What is measured and how it’s reported (monthly/quarterly)
Conditions for it to work
- Access, documentation, inventory
- Maintenance windows
- Contingency plan (even a basic one)
This prevents you from paying 24×7 for “everything”, while still guaranteeing it where it matters.
Pricing: why 24×7 costs more (and how to optimise it)
It’s normal for 24×7 to be more expensive: it involves on-call rotas, staffing, out-of-hours response capability and, often, a more mature operation.
However, you can optimise it a lot if you:
- Clearly define what falls under 24×7 (only P1/P2 and critical systems).
- Keep 13×5 for P3/P4 and requests.
- Ensure prevention (fewer P1s = fewer “burnt” on-call shifts).
- Agree customer responsibilities so diagnosis isn’t blocked.
In practice, the biggest waste is buying 24×7 “for everything” and using it as a night-time helpdesk. The biggest risk is the opposite: buying 13×5 with no contingency plan for systems that can’t afford downtime.
SME recommendation: the model that usually fits best
If you want a balance between cost and continuity, this model works very well for organisations with 50–200 employees:
- 13×5 for general support and requests (P3/P4).
- 24×7 only for:
- P1/P2 incidents
- Previously defined critical systems
- Monitoring and preventive maintenance to reduce real P1s.
This approach aligns with a maintenance and support strategy focused on continuity and real operations, not just “closing tickets”.
CTA: if you want to define your SLA without overpaying
If you’re reassessing your support (or you’ve suffered outages and want to reduce them), the most cost-effective step is to review criticality and agree a severity-based SLA.
You can start with our maintenance and support services:
24/7 IT maintenance for businesses
24/7 monitoring to prevent failures
IT maintenance: how to ensure operational continuity
If you need it tailored to your situation (hours, critical systems and response targets), we can help you define it and document it properly so the SLA becomes a continuity tool, not a decorative document.
Frequently asked questions about 24×7 and 13×5 support
Is 13×5 the same as 8×5?
Not necessarily. 8×5 usually refers to standard business hours (8 hours, 5 days). 13×5 is typically a wider coverage window across working days. The important thing is that the SLA states exact hours, time zone and public holidays.
Does an SLA guarantee everything will be resolved within the agreed time?
It usually guarantees response times and restoration/resolution targets by severity, but it can depend on third parties, access, approvals or parts. That’s why shared responsibilities and escalation paths are essential.
Can I buy 24×7 only for critical incidents?
Yes, and it’s often the most efficient approach. You define which systems are included, which severities trigger 24×7, and which channel is used for P1/P2. That way you’re not paying on-call cover for requests that can wait until the next business day.
How do I know whether 24×7 is worth the cost?
Calculate your downtime cost with a simple formula (idle staff + lost margin + recovery + penalties) and multiply it by the likely number of incidents per year. If a single “serious” outage exceeds the cost difference between 13×5 and 24×7, you have your answer.
