At what point does an incident become a problem? That is a question that unfortunately may have multiple answers. After all, in ITIL, an incident is something that happens. If it continues to happen, or if multiple people have it happen to them, it can become problematic. But a problem? As much as I detest ‘squishy’ answers, the answer to this conundrum is, it depends upon your organization.
Some organizations take a lot of pain before assigning a problem. Some almost immediately assign incidents a problem depending on the length of time the incident is open, or the number of people calling in who do not want to follow instructions in the knowledge base. It really does depend. There’s the squish.
However, there is a good rule of thumb. First, you need to know the severity of the incident. Is this almost all of your customers or just a handful? If this is something that is happening to just some people, then is there a knowledge-based article about it? If not, there needs to be. If you do have a KBA out there, are people using it and what are their reactions to it? Is it perceived as an easy fix or do they need to perform a voodoo ritual in order for it to work? Trust me, your customers will let you know.
Then you need to assess the incidents, your customers and the fix itself. As this is still an incident, it has passed through all of the levels of support, so you will have some general idea as to what needs to happen to fix it. And by now, you know about how many people this incident affects. The next question is, how much pain is you organization capable of enduring? No one like to hear the same complaint over and over. But sometimes, the fix is more than the disease. Sometimes, however, a fix easily can be found and there you are. Problem it is and soon to be problem solved.
But sometimes, problems cannot be solved by marrying them off to well known Austrian war heroes. More about that in the next post.