System SLA Metrics
System SLA’s are defined by both severity of the issue and also the cause of the issue. For e.g. An issue may be severe, but if the cause of the issue is very difficult to solve, then it may take longer to resolve.
Definitions
Item | Definition |
P1 | Software system is inaccessible or disruption of service as a result of bug, system configuration issues, data inconsistency issue |
P2 | Minor usability fixes or feature requests which take less than 2 weeks to implement |
P3 | Major usability fixes or feature requests which take 2 weeks to 4 months to implement |
MAT | Mutually agreed timeline |
RCA | Root cause analysis |
TTR | Time to respond |
TTF | Time to fix |
SLA (In Hours)
P1 SLA includes 12 business hours x 6 days (i.e. excluding Sundays and public holidays)
P2, P3 SLA includes business days only (i.e. excluding weekends and public holidays)
Priority | RCA | TTR | TTF | Total |
P1 | System inaccessible due to networking, operating system, cloud related issues | 4 | 4 | 8 |
P1 | Minor Bug which takes less than 1 day to fix | 8 | 8 | 16 |
P1 | Major Bug which takes more than 1 day to fix | 8 | 24 | 32 |
P1 | Software scalability issues | 8 | 40 | 48 |
P1 | Data inconsistency issues (if any) | 8 | 40 | 48 |
P2 | Minor usability fixes or feature requests which take less than 2 weeks to implement | 80 | MAT | MAT |
P3 | Major usability fixes or feature requests which take 2 weeks to 2 months to implement | 160 | MAT | MAT |
...
Notes
P2 and P3 will be taken only if the request makes sense as part of the product (feature wise or architecturally) and can be accommodated in the road-map
In case the Service Provider needs some data / responses from the client to fix the P1 issue, then SLAs will be affected by the response times of the client.
SLAs can also get affected because of ecosystem related issues. Please read the assumptions carefully.