COTS Software Licensing Service Level Agreement Considerations 2014

Topics 1.Purpose of a Service Level Agreement 2.Issue Severity Level Setting 3.Notification Process and Escalation 4.Who's on the Supplier's Bench and in the Cloud? 5.Quantifying Uptime for Hosting or SaaS Providers 6.Metrics and Reporting 7.Provider’s Skin in the Game 8.Enforcing SLA Obligations 9.Material Breach and Termination Language

Purpose of a Service Level Agreement Structure Conditions & Performance: Defines clear expectations between the Parties and sets obligations for when expectations are not met. E.g. All reported high severity issues will be responded to within 1 hour and resolved within 4 hours. Rationale Without a Service Level Agreement (SLA) in writing, it may be much harder to get out of the overall agreement if the service is not performing as expected. E.g. Your service provider in the cloud is up and running, but your messages are delayed by 4 hours. This happens for one entire week. Recourse? Use and Application SLAs should be used anytime there is maintenance, support and/or hosting services being provided E.g. Add SLA terms to the maintenance and support agreement, or have a standalone SLA (typical for a cloud or hosting provider)

Issue Severity Level Setting If issues cannot be readily identified at a particular severity level, ensure level setting is mutually agreed to

Notification Process and Escalation Immediate Notification – 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 ESCALATION CONTACTS 1 – Account Representative 2 – Senior Account Representative 3 – Regional Sales/Support Manager 4 – VP Sales/Support 5 - CEO/COO

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?

Don’t want to be left with this feeling…

Quantifying Uptime for Hosting or SaaS Providers 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 Based on 90 rolling days with 3 releases (allowable downtime) Each release totaling 6 hours

Metrics and Reporting When does the clock start? Phone call Documentation process Where are they stored? Ticketing system What if that goes down? Reporting process for SLAs Provider’s reporting Your reporting Ensure the resolution timeframe is not contingent on remote access into your environment

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

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

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.

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:

Appendix – Uptime SLA Metric Quantification CriteriaMeasurementComments Minutes in a 30 day month 43,200 minutes Planned down time (assume 6 hours) 360 minutesThis is a standard amount of time for monthly system maintenance Remaining minutes for scheduled up-time 42,840 minutes SLA99.9%This is a moderate standard; 5 nines (99.999%) is high Minutes of expected up time 42, minutes Allowable minutes of unplanned downtime minutesLittle time for unplanned down time RemediesVariesUsually a credit is given for missing the SLA