Inscrivez-vous ou connectez-vous pour rejoindre votre communauté professionnelle.
Typically, you would consider what level of support you need - most software support SLAs are measured in annual uptime, or for user support, time to response based on the priority of the support case.
For example, you may need a piece of critical software to be running as close to100% as possible, so you may opt for a99.99% SLA, which means a total cumulative downtime of about53 minutes per year.
Use http://uptime.is/ to help determine what level your stakeholders need for this case. Pricing for this support tends to increase exponentially with the level of uptime, so it should be a balance between business criticality, cost of downtime, and cost of support.
In user support cases, its typical to have various priority levels based on the number of users an issue affects and the severity, e.g P1 - all users affected, business critical systems - typical SLA:1 hour to resolution. P4 - a few users affected, non-critical systems - typical SLA:8 hours to resolution. With a sliding scale in between.
These are just guidelines and obviously have to be catered for the type of software, users, stakeholders, and business criticality of the systems. Most suppliers will have a boiler plate SLA schema which you can usually adjust to suit your business needs.
