How Should the SLA (Service Level Agreement) Be Managed in Managed Services?
How Does the SLA Process Work in Managed Services?
1. Scope and Measurement Criteria
The SLA definition process must first begin with the Scope. At ODYA Teknoloji, the most important step is defining the scope. The foundation of an SLA must clearly define what is managed (which servers, which software) and what is excluded (e.g., outages caused by the customer’s own internet service provider or physical damage). If the boundaries are not clear, measuring success is impossible.
So, what are the Criteria (Metrics) that measure success within this scope? Two frequently confused concepts in Managed Services SLA processes are:
- Response Time: The time confirmed for our engineer to acknowledge the issue and begin work on it. (E.g., “We received your ticket and are reviewing it.”)
- Resolution Time: The time until the issue is completely fixed and the system returns to normal.
The reason for this distinction is easily predictable. Inherent uncertainty exists in the nature of technical issues. The cause of a server error might be solved with a simple restart, or it might be a complex failure requiring hardware replacement. Therefore, clear distinctions are seen between Response Time and Resolution Time.
- Response Time (15 min): Control is ours, meaning ODYA Teknoloji’s. This is the part where we say, “We are here, we saw the problem.” We provide confidence to our customers through prompt notification.
- Resolution Time (x hours): The resolution time varies depending on the complexity of the issue. IT is an ecosystem where many complex, interconnected services and devices work together. Resolution time can vary for every event. If the solution cannot be guaranteed (e.g., an unknown software bug), the timeframe should be kept longer, and the customer must be continuously updated throughout the resolution process. This is the approach we prefer at ODYA Teknoloji.
For this reason, the concepts of ”Best Effort” and ”Guaranteed” are separated in an SLA.
2. Penalties and Service Credits
Good intentions and diligence can sometimes hit the wall of technical reality. Even if the MSP does an excellent job, targets can be missed due to “force majeure” or “technical debt.” An MSP might not meet the promised uptime (e.g., 99.9% Uptime/Availability)…
Third-party dependencies, legacy systems, technical debt, cybersecurity incidents, and change management errors can affect MSP resolution processes. At this point, Service Credits come into play, which serves as the driving force compelling the MSP to work quickly.
3. Prioritization
Not every problem is critical enough to breach an SLA! ODYA Teknoloji uses a “Matrix” when managing SLAs in Managed Services to determine which issue to prioritize. One axis of this matrix is ”Impact.” How many people? How many services? How many departments were affected? These are the first questions to ask.
“Which service” is affected determines how much the problem halts business operations. In SLA terminology, we call this Urgency.
- Impact: How many people/departments does the issue affect? (This is where your assessment of “whether it affects the customer” comes in.)
- Urgency: How critical is the affected service to the business? (E.g., Is it a sales system generating revenue, or the office music system?)
The ODYA Teknoloji Managed Services team determines the Priority Level by multiplying these two factors.
Let’s proceed with an example to clarify everything…
A single printer in the accounting department of an e-commerce company is broken. However, today is not the billing cut-off day. Which priority level does this situation fall into?
- Impact: Only a single device is broken. (Low Impact)
- Urgency: It is not the billing day. This means business operations are not halted; invoices can wait until tomorrow or be issued digitally. (Low Urgency)
In the ODYA Teknoloji matrix, this corresponds to the intersection of “Low Impact” and “Low Urgency.”
If today were the “Billing Cut-Off Day” and trucks were waiting at the gate, then Urgency would skyrocket, and the intersection would rightly be higher. This distinction ensures the ODYA Teknoloji technical team directs resources to where the real fire is (P1 – The entire system is down!).
4. Reporting
Every MSP provides reports filled with figures like “99.9% Uptime” every month. While this information is important, years of experience have shown us that a good SLA report is not just for saying, “Look how great we are!”
For ODYA Teknoloji, SLA reports are not just a “report card” of what happened in the past but a strategic tool that ”X-rays” the institution.
These reports expose ”Chronic Problems”:
- Investment Need: If a server consistently gives a 95% RAM usage warning every month, the report tells you, “There’s a problem here; you should stop patching and upgrade the hardware.”
- Training Deficiencies: If reports consistently show an increase in “User forgot password” calls, this is not a technical problem but a situation where personnel need training.
- Service Improvement Plan (SIP): Based on this data, the ODYA Teknoloji Managed Services team and the customer sit down and discuss, “Instead of constantly fixing what’s broken, how do we solve the root cause?”