A knowledge base article about Incident Prioritization Guidelines for Data Networking Services provided by the UC Berkeley IT Service Hub - Knowledge Portal
Incidents in Berkeley's ITSM Service Now are prioritized on a 5 level scale from P5 (lowest) to P1 (highest). These priorities are derived from two components; the impact of the incident, and the urgency with which it must be resolved. Each of these components is ranked on a low - medium - high scale. The matrix used to determine the priority based on the value of impact and urgency is documented in KB0010891.
This document maps impacts to common types and scales of network service disruption, with the aim of providing a guide to the accurate prioritization of network service related incidents.
Incidents impacting a single, or small group of campus users. Common examples include an individual switch port issue or other configuration concern, the failure of a single switch or module, the failure of a small number of Wi-Fi access points in a location. Issues with campus wide network services where there is minimal disruption to the activities of the University, and/or where a workaround is easily implemented by impacted users.
Incidents impacting a moderately large group of campus users, for example an entire campus building. Common examples include root switch failures and metro ethernet service outages, firewall issues impacting an entire department. Issues with campus wide network services where there is moderate disruption to the activities of the University and no simple work around is available.
Incidents with campus wide implications or impact to other campus wide IT services. Common examples include a failure of core network connectivity, serious Wi-Fi service disruption, DNS outages. Issues with campus wide network service where there is major disruption to the activities of the University and other dependent IT services.
Urgency may be set by the end user, service desk, or the responding network engineer based on the perceived nature of the incident. Generally it is expected that most high impact incidents will have a high or at least medium urgency. Medium impacts may have lower urgency, for example a building which is offline, but is not used during the weekend. Low impact incidents would rarely have a high urgency, but this is possible, for example where a single connection to the network has an unusual importance, or where the impact may increase over time if the incident is not resolved. Urgencies set by end users will often require review as the incident proceeds through the system. It is expected that urgencies set by Client Services would be more reliable, and urgencies set by members of the network team would be very reliable measures of the accurate status of an incident.