ITS & Campus Service Level Agreement 2019/2021

1. General Overview

This is a Service Level Agreement (SLA) between the campus community and Information Technology Services Division (ITS) to document:
  • The technology services ITS provides to the campus.
  • The general levels of response, availability, and maintenance associated with these services.
  • The responsibilities of ITS as a provider of these services and of customers receiving services.
  • Processes for requesting services.

This Agreement is valid from 7/31/19. Review is every two years, or as otherwise needed.

2. Service Description

2.1  Service Scope

The ITS and Campus SLA
  • Defines a general level of predictability for ITS communication and services.
  • Reflects how ITS does business today and the direction ITS is heading.
  • References the ITS Service Catalog for clear service level descriptions.
  • Describes how work will be prioritized, response times for service requests, and outage notification process.
  • Includes reporting on service levels.

2.2  Assumptions

  • Services, access to services and accountability measures provided by ITS are clearly documented in the ITS Service Catalog. The ITS Service Catalog is continually updated to provide service information regarding what services are offered, how to request services, how to get help for services and how much services cost.
  • Outages to services are communicated and documented to all stakeholders via the Change Management process.
  • Services are provided in adherence to any related policies, processes and procedures. See the ITS Service Catalog for policies related to a service.

3. Roles and Responsibilities

3.1  Parties

The following Principal Officers are parties to the Agreement

Vice Chancellor, Information Technology
Campus Provost, Executive Vice Chancellor

3.2  ITS Responsibilities

Responsibilities and/or requirements of ITS in support of this Agreement include:
  • Meeting service delivery commitments outlined in the ITS Service Catalog.
  • Meeting response times associated with the priority assigned to incidents and due dates of service requests.
  • ITS implements defined processes to meet service level commitments.
  • Generating quarterly reports on service level performance.
  • Appropriately notifying clients of all scheduled maintenance via the Maintenance Calendar, Service Catalog web page and/or a communication to campus via the ITS Communication Manager.

3.3  Customer Responsibilities

Customer responsibilities and/or requirements in support of this Agreement include:

  • Using the defined processes for requesting help and services.
  • Monitoring the ITS Maintenance Calendar and notifying ITS of forthcoming local events with ITS dependencies. Customers can use the phone (831-459-4357) email ( or online ticket system (SlugHub) to contact ITS with IT related dependencies for local events.
  • Responding to inquiries from ITS staff who are resolving incidents and handling service requests.
  • Complying with campus and UC security policies, available at Additional security requirements may be included on individual Service Catalog pages.

4. Requesting Help and Service

A customer may request help or service from ITS for a service published in the ITS Service Catalog. There are six methods of contacting ITS for help or service requests.

4.1  Online / SlugHub (

By utilizing the web, your help or service request will be automatically associated with your division and visible to technicians. Using SlugHub via the web interface is the most efficient method to log and process help or service requests.

4.2  Phone (459-4357 / 459-HELP)

Phone service is available during regular business hours of operation, M-F 8AM to 5PM. Messages left during off hours will be processed the next business day.

4.3  Email (

Email or service requests sent to will be processed during regular business hours, M-F 8AM to 5PM. The SlugHub ticket system tracks inquiries, incidents, and service requests emailed to

4.4  In-Person

Individual service pages may indicate additional in-person locations or hours for that specific service.

4.5  Work orders

Services that utilize work order or web forms will be processed from date of receipt of the completed form.

4.6  Your Divisional Liaison

Contact your Divisional Liaison (DL) for services not listed in the ITS Service Catalog. The contact information for each DL is located at

5. Hours of Coverage, Response Times and Escalation

For all help requests, the ITS goal is to have a staff member assigned and acknowledge requests within 4 business hours of receipt. Campus priorities may require exceptions to this goal during certain times of the academic year.

5.1  Hours of Coverage

  • The Support Center business hours are M-F 8AM to 5PM, excluding federal holiday, university holidays, and campus closures. Customers may use any of the methods of contact as stated in Section 4.
  • Tickets can be entered via the web interface or sent via email 24 hours a day, 7 days a week, and are processed on the next business day. Using SlugHub via the web interface is the most efficient method to log and process service requests and incidents.
  • See the ITS Service Catalog for specific hours of coverage for individual services or your DL for local hours of coverage for local services.

5.2  Response

For all help requests, the ITS goal is to assign and acknowledge them within 4 business hours of receipt. Service requests have varying response times and due dates. Please refer to the service catalog page for individual response times. 

5.3  Prioritization

If you consider your help or service request urgent, contact ITS at 459-4357. An urgent example includes reporting a service outage or reporting an impact to instruction.

For reference, ITS has a set of criteria to prioritize an incident as urgent based on a global campus view of IT needs. ITS prioritizes incoming incidents as “urgent” priority if it meets any one of the following criteria:

  • Significant risk to life and safety.
  • Significant impact on the delivery of instruction.
  • Significant or lasting impact on student academic performance.
  • Significant risk to law, rule, or policy compliance.
  • Academic and Administrative Calendar deadlines.
  • Significant number of people affected.
    • Organizational structure is a multiplier for number of people affected.
  • Percentage of total tasks that can no longer be performed by individuals.

5.4  Escalation

If you are not satisfied with the level of service on a help or service request, contact your Divisional Liaison (DL) or Melanie Douglas, interim director of ITS Client Services and Support (CSS). They will categorize and process your input as appropriate and respond to you with the action taken.

5.5  More Information

If you have a question, contact the ITS Support Center via phone (831-459-4357), email (, or online ticket system (SlugHub). The Support Center will route your ticket to the appropriate area. 

6. Maintenance and Change Management Process

The goal of the Change Management process within the ITS Division is to align changes to the business and academic environment by minimizing impact and reducing the risk of unintended disruptions to production environments and software. ITS does this by monitoring, managing, and evaluating changes to maximize availability while minimizing the risks involved in making those changes.The change process should provide high visibility and open lines of communication between product and functional teams and the business.

Changes are classified by the urgency of the change and the potential customer impact, and approved based on their classification.

Normal Change: A Normal change follows the change management approval process, and requires a review by the ITS Change Manager before the change is implemented. High and Very High risk changes may also be reviewed by the Change Advisory Board (CAB).

  • The Change Manager will review and approve changes Monday through Friday at 8am (excluding holidays)
  • The Change Manager expects that Change Requests submitted for approval meet the following criteria:
    • Change Requests are submitted in SlugHub;
    • The required fields in the Change Record are complete.
  • Approved Changes will automatically be added to the ITS Maintenance Calendar and an email sent to sc.update.
  • After the change is implemented, or if canceled or rescheduled, a Post Implementation Review (PIR) is documented before closing the Change Request.

Pre-approved Standard: A Standard change is a change to a production environment or software for which the approach is pre-authorized, has an accepted and documented procedure, and is well understood and low risk.

  • Standard Changes are not to be used if the planned start and end dates fall on a change restriction day, nor to avoid the approval step for changes that are high or very high risk.
  • Standard Changes require one time approval by the Change Manager to be classified as a standard change:
    • Create and complete the standard change template in SlugHub;
    • Submit the template for one time approval;
    • Once the template is approved, it can be used to submit a standard change request that does not need to be individually approved by the Change Manager every time it is scheduled.
  • After the change is implemented, or if canceled or rescheduled, a Post Implementation Review (PIR) is documented before closing the Change Request.
  • The Change Manager may determine if a Standard Change Request was unwarranted, and will coordinate with the Product Manager to use a Normal change request for similar scenarios in the future.

Emergency Change: An Emergency change is in response to a critically-failing, high-urgency incident related to a product or service failure, and resolves that incident (temporarily or permanently). An Emergency change does not flow through the full lifecycle, but must have an ITS Product Manager approval before work is performed.

  • Change Requestor submits Emergency change request (via ITR) and includes justification for the emergency change
  • Product or Functional Manager authorizes the work to occur based on assessment of impact, risk, and urgency and communicates to sc.update
  • After the change is implemented, or if canceled or rescheduled, a Post Implementation Review (PIR) is documented before closing the Change Request. The Product Manager initiates a Post Implementation Review (PIR) with the Product Team, and includes the Functional Manager and the Change Manager.
  • The Change Manager may determine that an Emergency Change Request was not justified, and will coordinate with the Product Manager to use a Normal change request for similar scenarios in the future.

6.1  ITS Maintenance Calendar

The ITS Maintenance Calendar currently serves as the official outage and maintenance schedule for ITS. Scheduled maintenance is not included in the calculation of availability metrics.

IT-related service outages, and planned maintenance, are published in the ITS Maintenance Calendar.

Campus units are responsible for monitoring the ITS Maintenance Calendar to notify ITS of forthcoming local or UC-wide events with ITS dependencies. In most cases, the ITS Communication Manager is responsible for communicating product or service outages and changes to the ITS Division, service groups, and campus as necessary. Off-hours product or service failures are communicated the following business day.

There are two categories of service outages:

  • Planned Outages: A planned outage is work that is planned and scheduled. The ITS Communication Manager communicates (as needed) to the appropriate audience.
  • Unplanned Outages: An unplanned outage is work that is unplanned due to an unforeseen event or urgent repair to prevent failure. Unplanned outages are given priority (and communicated immediately) on a case-by-case basis depending on the type and urgency of the failure. ITS responds to off-hours unplanned outages of an urgent nature using an escalation process.

6.2  Guidelines for ITS Maintenance Windows

A Maintenance Window is a regularly recurring event during which planned outages and changes to production systems and software may occur. The purpose of defining recurring maintenance windows is to provide clients with predictable periods of disruption to products and services upon which they rely.

Recurring maintenance windows are negotiated with clients by ITS Product Managers, and documented on the ITS Maintenance Calendar.

If a product or service does not have a negotiated maintenance window (via a product/service-specific SLA or equivalent) the following guidelines apply:

  • Planned outages should be performed between 7PM and 7AM on any day of the week. Work scheduled outside of this window should have explicit sign-off from the Proprietor or Unit Head, or designated client representative.
  • Planned outages and changes should not be scheduled during the first day of instruction, the last day of instruction through finals, the day grades are due for the academic quarters, student orientation week, fiscal year end close, during Commencements, or other significant campus events. The ITS Division considers these to be change restricted days.

7. Pricing

In 2007-08, the campus adopted the Information User (IU) funding model. The Information User (IU) funding model allocates the cost of certain central IT infrastructure services to campus units based on a Full Time Equivalent (FTE) assessment of defined information user populations with associated weightings. See for more information and which services are IU funded.

All ITS rates and recharges are subject to the campus recharge process. For more information about the campus recharge rate-setting process, go to Services are charged individually. Refer to the service page in the ITS Service Catalog for charges, if any.

8. Reviewing and Reporting

8.1  System Performance and Availability Reporting

Quarterly performance and availability reports will be published for review.

  • First-contact response to incidents and service request is based on information from the SlugHub ticket system.
  • Target: 80% response time in less than 4 business hours.
  • Resolution of help tickets is based on information from the SlugHub ticket system. Hours are counted as clock hours, weekends excepted.
    Target: 80% of tickets closed by due date.
  • Outage metrics measure Planned vs. Unplanned Outages and their associated root causes; Change Management metric is the ratio of unplanned outages caused by failed changes to total outages.
    Target: Ratio of unplanned to total maintenance events: 20%; Unplanned Outages due to failed changes <9 per quarter.

8.2  SLA Reviews

The Designated Review Owner (“Document Owner”) is responsible for facilitating regular reviews of this document. Contents of this document may be amended as required, provided mutual agreement is obtained from the primary stakeholders and communicated to all affected parties. The Document Owner will incorporate all subsequent revisions and obtain mutual agreements / approvals as required. Next Review Date: 7/31/2021

This Agreement is posted to the following location and made accessible to everyone at: