Incident Response Times. An Incident is any disruption to the normal operation of a service. UTS will accept and resolve incidents as defined in the UTS Incident Management process included in Attachment E. The standard UTS Incident Response Service Level Agreement targets apply to services provided within this agreement. The response time targets are based on the priority assigned to the incident in the UTS IT Service Management System. Contact Points & Escalation The primary contact points for the service are listed in the table below. These contacts will be notified by the UTS Service Desk as depicted in the Escalation Procedure when responding to service outages or other critical service impacts. UTS Escalation Contacts Role Contact Phone (Office & Mobile) Email Service Owner/ Mgr Xxx Xxxxxxxx O: 000-000-0000 xxxxxxx@xxxxx.xxx Director Xxxx Xxxxxxxx O: 000-000-0000 xxxx.xxxxxxxx@xxxxx.xxx Escalation Procedure The escalation process is managed by the UTS Service Desk. The customer may also escalate as needed by contacting the Service Desk or Service Owner as listed in the UTS Contacts to provide the necessary visibility and management attention to critical issues. The following flow diagram depicts the workflow used when a service incident is not following the standard guidelines for resolution according to service tier and priority. The Service Desk monitors incidents for timelines and milestones and may escalate the priority of any incident as warranted. Cost of Service The costs of many UTS services are met through the University allocation model. Some services with a delimited user base also have an additional cost. All costs paid through the standard University allocation model Additional costs are assessed for this service (details included in Attachment F) Approval Name Title Date Signature Xxx Xxxxxxxx Service Owner Xxxxxx Xxxxx Business Relationship Manager Xxxx Xxxxxxxx Director, Infrastructure Xxxxx Xxxxxxx Deputy CIO Document Version: 1.1 Effective Date: September 1, 2009 Attachment A – Availability The availability target of this service is a measure based on SIR (Service Impact Report) data. Unplanned Downtime for each service is captured as part of the standard SIR process. Regularly scheduled maintenance and incidents that do not impact service availability are excluded from the Downtime calculation. The formula used to calculate availability is: Availability = (365-Unplanned Downtime)/365 Attachment B - Change Management The UTS Change Management procedure ...
Incident Response Times. An Incident is any disruption to the normal operation of the service. UTS will accept and resolve incidents as defined in the UTS Incident Management process included in Attachment F. The standard UTS Incident Response Service Level Agreement targets apply to services provided within this agreement. The response time targets are based on the priority assigned to the incident in the UTS IT Management software, Remedy. Specific priority examples for desktop support are listed below: Critical Generally reserved for a full service outage of an enterprise or departmental service affecting the entire campus or numerous customers. In the case of desktop support, an example is a complete desktop failure for one of the executives. High An issue, which completely impacts the user’s ability to do work, such as a desktop or business application failure. Additionally, an issue that partially affects an executive is also a high priority. Medium This priority is used when the user’s ability to do work is only partially impacted or one in which a work around exists. Examples of medium priority are either performance issues or a problem printing to the user’s primary printer (alternate printer is available). Low This type of incident has no impact on the user’s ability to do work such as the failure of a spare port. Contact Points & Escalation The primary contact points for the service are listed in the table below. These contacts will be notified as depicted in the Escalation Procedure when responding to service outages or other critical service impacts. UTS Contacts Role Contact Phone Email Service Owner / Manager Xxxxxxx Xxxxxxx 000-000-0000 (o) 000-000-0000 (m) xxxxxxx.xxxxxxx@xxxxx.xxx Director, Enterprise Services Xxxxxxx Xxxxx 000-000-0000 (o) 000-000-0000 (m) xxxxxxx.xxxxx@xxxxx.xxx Director, IT Service Management Xxxxx Xxxxxxx 000-000-0000 (o) 000-000-0000 (m) xxxxx.xxxxxxx@xxxxx.xxx Customer Contacts Role Contact Phone Email Advisory Committee Member Vice President Escalation Procedure 2nd Page to Service Owner When there are critical service-impacting events, there is an escalation procedure in place to provide the necessary visibility and management attention. Begin Critical Priority? Yes 10 Minute response? No No Yes Yes 10 Minute response? Yes No 10 Minute response? No Esclate to Service Manager Escalate to Service Director End Cost of Service The costs of many UTS services are met through the University allocation model. Some services with a delimited user b...
Incident Response Times. The supplier must acknowledge to the customer, receipt of all problems within thirty minutes of the call being assigned to the supplier. Incident Resolution & Feedback Times Problems will be prioritised according to the severity rating listed in the following table and must be resolved within the associated timescales. However, the frequency of communication between the supplier and the customer will be dependent upon individual circumstances. Priority Category Guidelines/Description P1 Critical fault Whole service or critical part of system is unusable / unavailable causing major business impact. (e.g.: distributed server down, whole site unable to operate, potential to cause severe financial loss to the Customer) P2 Severe fault A major component failure affecting at least one user, and with potential to impact a significant number of users. May have some financial impact on the Customer P3 Routine fault Problem causing inconvenience to a user, not immediately critical. (e.g.: single user unable to send or receive emails) P4 Minor Fault/Request Non-urgent problems, or workaround available. User agrees low priority. Enquiries or requests for advice. Low business impact. (e.g.: requests for standard user access) Feedback performance can be rated and discussed at performance reviews if the customer requires. Examples of when the supplier will provide feedback to the customer are as follows: • When an incident is likely to transgress the agreed SLA. • An incident needs to be passed to another Team/Group or Supplier. • A decision is made that a site visit is required. • The support team has arrived on site. • The problem is resolved – in this case details of the fix should be logged. • Estimated fix time will not be met. Note, where a fault cannot be resolved within the agreed timescale, the customer should be informed of the problem and informed as to the proposed steps to be taken to provide a resolution. (In the event of a dispute, all parties will follow the escalation procedure as detailed in the associated Schedule(s)).
Incident Response Times. Threat Xxxxx will use commercially reasonable efforts to respond and resolve Severity Level incident with the Service in accordance with the target time periods below: Severity Level Error State Description Response Time Target Resolution Within 1 Critical Priority Renders the Service inoperative, or causes to fail catastrophically 2 High Priority Affects the operation of the Service and materially degrades Clients use thereof 30 minutes 4 Hours 2 hours 12 hours 3 Medium Priority Affects the operation of the Services but does not materially degrades Clients use thereof 24 hours 48 hours Supplier will provide Client with a permanent correction as part of 4 Low Priority Causes only a minor impact on the operation of the Service 48 hours
Incident Response Times. Digital MGA will respond to each reported incident and provide the following corrective services in accordance with the following priority: Severity Level Description Response Time Activity 1 One or more mission critical features of the System are unavailable or unusable, and the situation is considered an emergency, or the System as a whole is inoperable. A workaround is not immediately available. 1 Support Hour Digital MGA will use all reasonable efforts both during and outside of Support Hours to resolve the reported incident as expediently as possible.
Incident Response Times. An Incident is any disruption to the normal operation of a service. OIT will accept and resolve incidents as defined at xxxx://xxxx.xxxxx.xxx/itsm_process/incident/incident_process_guidelines.html. The standard OIT Incident Response Service Level Agreement targets apply to services provided within this agreement. The response time targets are based on the priority assigned to the incident in the OIT IT Service Management System. Contact Points & Escalation The primary contact points for the service are listed in the table below. These contacts will be notified by the University Service Desk as depicted in the Escalation Procedure when responding to service outages or other critical service impacts. OIT Escalation Contacts Role Contact Phone (Office, Mobile) Email Desktop Supervisor O: M: @xxxxx.xxx Client Services Manager/ Service Owner O: M: @xxxxx.xxx Director O: M: @xxxxx.xxx Escalation Procedure The escalation process is managed by the University Service Desk. The customer may also escalate as needed by contacting the Service Desk, Technician or Service Owner as listed in the OIT Contacts to provide the necessary visibility and management attention to critical issues. Client Services management monitors incidents for timelines and service levels and may escalate an incident when it is in jeopardy of exceeding its SLA for response time or resolution time. Cost of Service The costs of many OIT services are met through the University allocation model. Some services with a delimited user base also have an additional cost. 🗹 All costs paid through the standard University recharge model ❑ Additional costs are assessed for this service (details included in Attachment B) Approval Name Title Date Signature Deputy CIO SpeedType: Document Version: 2.0 Effective Date: TBD Attachment A – Service Requests Service Request Target* In Scope Out of Scope New software package** 2 days Order new software Application training Deploy software to desktop Installation on non-Emory owned equip. Test and validate New hardware rollout** 5 days Order new equipment according to standard Hardware and software costs Configure with standard image Non-standard hardware or peripherals Setup Windows and other accounts Requesting NetID or email account Add non-image applications Setup and test network connectivity Map network drives/printers Install standard peripherals Replacement rollout** 5 days Configure new system (New rollout tasks) Manage/coordinate surplus of old system Delivery...
