Service Level Agreement Considerations 2014

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

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 email 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

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

Notification Process and Escalation Example Immediate Notification (to you) – of an issue that the Provider is aware of or should be aware of Email Distribution List – Create one email 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 email 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

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.

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…

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).

Metrics and Reporting When does the clock start? Phone call Email Documentation process Email 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

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

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).

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

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 Email: gretchenkwashnik@aol.com Phone: 302-650-3932

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,797.16 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