1. Service Level Agreement Considerations
2014

2. Topics Purpose and Main Considerations Metrics and Reporting
Enforcing Obligations
All about asking the right questions.

3. Purpose of a Service Level Agreement
Topic
Summary
Example
Structure
Defines clear expectations and sets obligations for when expectations are not met
All reported high severity issues will be responded to within 1 hour and resolved within 4 hours
Rationale
Without an SLA in writing, it may be harder to enforce obligations if the service is not performing as expected
Your cloud service provider is up and running, but your messages are delayed by 4 hours. Recourse?
Use and Application
SLAs should be used anytime there is maintenance, support and/or hosting services provided
Add SLA terms to the maintenance and support agreement, or have a standalone SLA
Code quality language

4. Issue Severity Level Setting
Make issue severity level setting as objective as possible
Provide examples where you are comfortable (examples may need to be updated as needs change)
Issues fixed for free…no additional development charges
Operating hours and holidays (define them)
Frequency of communications/updates while issue is being resolved
If issues cannot be readily identified at a particular severity level, ensure level setting is mutually agreed to

5. Notification Process and Escalation Example
Immediate Notification (to you) –
of an issue that the Provider is aware
of or should be aware of
Distribution List – Create one
address that provider will use
Cloud/SaaS Providers –
Notification before all releases and ability to “opt-out”
Monitoring and automated alerts
Escalation Contacts and Process
1 – Account Representative
2 – Senior Account Representative
3 – Regional Sales/Support Manager
4 – VP Sales/Support
5 - CEO/COO
Immediate notification of an issue that the Provider is aware of or should be aware of
Network outage
Bug found by another client
Monitoring and Automated Alerts
Content load ping test
Third party tools
List of Key Contacts for Escalation
Includes clear escalation path
Includes and mobile numbers
Once has to look up BoD, since did not have list of escalation contacts readily available and known by all.
Maintenance window?
DR scenario
Standard Operating Hours
Note: Some provider’s help desks require that only trained users or your help desk personnel are allowed to submit a ticket for support

6. Who's on the Supplier's Bench and in the Cloud?
Do you know who you are calling and where they are located?
Are they a third party to the software/SaaS provider?
How deep is their bench?
Do you know who you are calling and where they are located?
Do you call an internal IT support number first?
If in the cloud, you may be calling the provider directly.
Ensure your support contract is not limited to a # calls/month
Are they a third party to the software/SaaS provider?
If so,
Does the SLA expand to them?
How will they be updated on your versions, use, etc.?
Are they allowed access to your environment(s)/instance(s) to troubleshoot (what information can they see)?
How deep is their bench?
Did you sign up for the “A” team, a dedicated team, etc.?
Are they relying on 1-2 persons to service your account?
Payment limited to cost of maintenance and support…limited to insurance coverage.. Ensure they are aware of the versions you are running, any other software integration points (hybrid telephony environment), and customizations. Knowledge transfer and documentation. Change mgmt process. Hours of operation.

7. Don’t want to be left with this feeling…
Payment limited to cost of maintenance and support…limited to insurance coverage. Ensure they are aware of the versions you are running, any other software integration points, and customizations. Knowledge transfer and documentation. Change mgmt process. Sales lifecycle (get “A” team and solution engineers during business development phase (pre-sales) and then the “C” team post the sale) - Are they going to continue to date you…or treat you bad once they marry you…

8. Quantifying Uptime for Hosting or SaaS Providers
Based on 90 rolling days with 3 releases of allowable, planned downtime (each release totaling 6 hours)
95.00% =
98.00% =
99.00% =
99.90% =
99.96% =
107 hours of downtime
43 hours of downtime
21 hours of downtime
2 hours of downtime
51 minutes of downtime
Ask audience for difference between planned and unplanned downtime.
Formula for this in Appendix
Define uptime calculation and planned maintenance
What qualifies for a day?
Identify the provider’s standard maintenance window
Request at least 48 hours’ notice for unplanned maintenance where possible
Watch for additional language provider may insert to lessen the teeth of your SLA metric – E.g. Falls below 80% of the SLA…then they’ll give credits (one asp).

9. Metrics and Reporting When does the clock start? Phone call Email
Documentation process
Where are they stored?
Ticketing system
What if that goes down?
Reporting process for SLAs
Provider’s reporting
Your reporting
What is reasonable network latency…who’s network, (isp carveout) flow down of liability and maturity of provider
Your reporting - Internally to validate provider’s information
Supplier may require your technical team to be trained (only x persons can call)
How many maintenance calls make a year…have a team to try and fix it first and maybe find their bugs (code quality)
Ensure the resolution timeframe is
not contingent on remote access into your environment

10. Provider’s Skin in the Game
Define remedies for failed turnaround times and uptime
Response times and resolution times
Uptime for hosting and SaaS providers
Calculations for failed metrics should not be based on ending calendar time periods
Ensure rolling time periods
Identify how the refund or credit must be claimed and when it will be applied
Normally limited to a percentage of the annual maintenance and support fees
If you don’t call them a lot (do you get $ back)…they get all of the benefit.
Be careful Liquidated Damages do not limit your ability to seek other remedies, including termination and release

11. Enforcing SLA Obligations
Engaged IT supplier management program
Dedicated person/team that works with the internal technical support team and provider to understand the ongoing working relationship
Two-way street mentality
Drives to resolution quicker
The Enforcer - Discussion of credit/refunds when owed
If in the cloud, maybe only works with the internal network team.
Two-way street mentality for a successful ongoing relationship.
Sometimes there are requirements for who can call the provider’s technical support team (maybe only a certain group of users that had training, only the technical team, etc.)
Drives to resolution quicker and know escalation path alongside the technical support team.
The Enforcer - Handles the tough conversation with the provider and seeks refunds/credits when owed.
“May” enforce (part of negotiation talking points).

12. Material Breach and Termination Language
Include “material breach” language to allow for termination for occurrences such as:
More than 6 unexpected downtime hours resulting from 3 or more non-consecutive service interruption events during any rolling 30 calendar day period; or
More than 24 consecutive unexpected downtime hours due to any single event.
If the preceding occurs, Customer shall be allowed to immediately terminate the Agreement and any Order Forms with Provider, and shall not be liable for any future committed fees beyond the termination date.
Used for cloud or application service providers
Concept can also be used if provider cannot fix a critical bug in their code

13. Key Attributes of SLAs and Ongoing Management
Mutually agreed to issue severity level setting
Clearly defined response, resolution and uptime expectations
Repeatable and reliable tracking mechanisms
Skin in the game
Simple formulas for credit/refund obligations
Engaged IT supplier management function
Material breach language to allow for termination
Questions
Gretchen Kwashnik
IT Supplier Management and Risk
Phone:

14. Appendix – Uptime SLA Metric Quantification
Criteria
Measurement
Comments
Minutes in a 30 day month
43,200 minutes
Planned down time (assume 6 hours)
360 minutes
This is a standard amount of time for monthly system maintenance
Remaining minutes for scheduled up-time
42,840 minutes
SLA
99.9%
This is a moderate standard; 5 nines (99.999%) is high
Minutes of expected up time
42, minutes
Allowable minutes of unplanned downtime
42.84 minutes
Little time for unplanned down time
Remedies
Varies
Usually a credit is given for missing the SLA