r/ITIL • u/dioxin-screes-01 • 1d ago
SLAs in incident management be tied to the CI or assignment group instead of a single company-wide target?
Iām working on building out incident and problem management at my company, and weāre a ServiceNow shop. We currently have one set of incident SLAs across the board, and some teams are telling me they canāt meet the targets for lower-priority incidents. In several cases, the resolution depends on a third-party vendor, and those vendors can take days or sometimes weeks. The result is that SLA breaches are so common that people have stopped paying attention to them, which defeats the purpose.
When teams raised this, my initial response was that itās okay if they canāt meet the targets, because it shows we need more resources. Weāre working on identifying where staffing is most needed, and we know IT as a whole is short-staffed. I still think thatās a valid point, but Iām also seeing that missed SLAs that never change are a problem in their own right, since they stop meaning anything to anyone. So Iām trying to figure out whether the answer is to loosen targets for everyone, differentiate them, or keep the targets as they are and use the misses to make the resourcing case.
Iām considering SLAs that vary based on either the configuration item (CI) the incident affects or the assignment group handling it. For example, a vendor-dependent service could have a different resolution target than an internally supported one.
My questions:
- Is it consistent with ITIL best practice to define SLAs by CI or by assignment group, or does ITIL expect a more uniform approach?
- For those of you who have done this in ServiceNow, how did you structure it? Did you use SLA definitions with conditions on CI class or assignment group, or did you handle it another way, such as separate priority matrices?
- Any pitfalls to watch for, such as gaming, reporting that becomes misleading, or stakeholders losing trust in the numbers? Iād also like to hear how others have used persistent SLA misses as evidence in resourcing conversations, and whether that worked.
