It is part of the nature of IT service and support that you will, from time to time, be called upon to handle a high priority, high urgency incident. In most production systems these are mercifully rare, but it is still important that you understand how to identify them.
The key to identification is prior planning. In designing ones implementation of ITIL, a core part is to prioritize which services have what urgency. For example, the core systems that the business relies on to do its business will typically be High urgency, while a Skype outage may only be a nuisance, and be classified as a Low urgency. The scale is simply High-Medium-Low, and that is all that is really needed.
When planning this, what you are basically doing, is dividing your services into three levels:
- High: Must have
- Medium: Need to have
- Low: Nice to have
What you can’t plan for, and what should be your foremost priority when initially troubleshooting a high urgency incident, is to identify the impact of the incident. This, too, falls into the same three levels, but this time, we are looking at how many users are affected. Again, what your tolerances for impact are, and what impact triggers which level, depends on how you have defined this. One way to handle it is:
- High: Entire organization
- Medium: Department
- Low: Ten users or less
What these two lists give us, is a matrix that looks as follows:
| Impact/Urgency | High | Medium | Low |
| High | 1 | 2 | 3 |
| Medium | 2 | 3 | 4 |
| Low | 3 | 4 | 5 |
The final thing you need to plan beforehand, is how each priority level should be handled. Here is one example:
| Priority Code | Description | Target Response Time | Target Resolution Time |
| 1 | Critical | Immediate | 1 hour |
| 2 | High | 10 minutes | 4 hours |
| 3 | Medium | 1 hour | 8 hours |
| 4 | Low | 4 hours | 24 hours |
| 5 | Very Low | 1 day | 1 week |
By posting a comment, you consent to our collecting the information you enter. See privacy policy for more information.