Difference between incident vs. problem


10 Kommentare

  • Langston

    I don't know if I can do this from a simplistic view for your users, but from a workflow standpoint, a problem is a source ticket. Incidents are tickets that are linked to the problem.

    When you answer and solve a problem with a public reply, that response will go out to tickets that are linked as incidents.

    I suppose you can tell your users that when they are linked as an incident, it's a indication that you are aware of the "problem"..

  • Andy

    Zendesk adheres to the "ITIL" standard when it comes to these two terms.

    The Information Technology Infrastructure Library (ITIL) is a set of concepts and practices for Information Technology Services Management (ITSM), Information Technology (IT) development and IT operations.

    ITIL defines an INCIDENT as follows:  Incident (ITILv2):    An event which is not part of the standard operation of a service and which causes or may cause disruption to or a reduction in the quality of services and **customer productivity.  whereas;

    ITIL defines a PROBLEM as follows: **Problem (ITILv2):    **The unknown root cause of one or more existing or potential Incidents. Problems may sometimes be identified because of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown. Occasionally Problems will be identified well before any related Incidents occur.

     **An example of this would be if a Web Store stopped allowing customers to order online.  Once you were alerted to this PROBLEM, we would log a case in Zendesk and designate it as a PROBLEM.  As new calls/emails (INCIDENTS) come in from customers related to the original PROBLEM, we would link them to that PROBLEM NUMBER.  Once we ascertain the root cause of the problem and rectify it, we'd SOLVE the PROBLEM and this in turn SOLVES all the linked INCIDENTS in one foul swoop.

    Zendesk has a tutorial on its use here:  https://support.zendesk.com/entries/203710-use-problem-and-incidents-to-organize-and-speed-up-your-support

    Hope this helps.

  • StaffordVaughan

    I tend to simplify this to say that the Incident is the obvious symptom (e.g., "I can't login the website", "I can't order a product") and the Problem is the thing that is causing that symptom to occur (extending the example, it would be "The user table in the database is corrupted" and "The credit card server is down" respectively). I disagree with the above example, in that the first report of the problem should still be marked as an Incident, and in Zendesk I recommend that Problems are only ever reported by your agents. Once the Problem has been created in Zendesk, all Incidents reported by your customers can be linked back to that Problem, and they will be automatically solved when the Problem is solved.

  • Johan Danielsson

    That explanation doesn't hold up either. The thing that is causing the issue might also be an Incident in that case.

    The user has an issue, its caused by a "Problem". But how do you define that as a "Problem" and not an Incident? If the user calls in and say "The database is corrupted". Then you solve the issue. That example is still an Incident and not a Problem.

  • Justin

    It's up to you! If the database is corrupt and it's an isolated report, maybe it doesn't qualify to be added as an incident. If you get multiple calls for a corrupt database, you'll want to make one of them a problem and the rest incidents to link them together. You don't have to utilize the problem-incident relationship. You can also make a custom status field. 

  • StaffordVaughan

    Hi Johan,

    My point is that, in the standard situation, the user would never call in and say "The database is corrupted". How would they know? They would know the symptoms of the problem, in other words the impact of the database corruption. They would typically not know that the database was corrupted.

    There'll always be edge cases, but my explanation is around the standard accepted use of the terms, and also the use inside the product.

    I do disagree with Justin's comment though "If you get multiple calls for a corrupt database, you'll want to make one of them a problem and the rest incidents to link them together". You should never make a ticket submitted by a customer into a Problem. It introduces too much risk into the process. My best practice advice is that Problems should always be created by agents.

    Hope that helps,

  • Kiran Mehta

    I agree, if a problem occur again and again it  means it is an incident. So at first attempt the problem can not be consider as incident.

  • Emily

    Hi Everyone, 

    This is a great discussion! Check out our documentation on Problem and Incident tickets for a more formal explanation of how the workflow was intended.

  • DennisWurster

    "...all the linked INCIDENTS in one foul swoop." should be "one fell swoop".


  • Bake Creative

    Emily is absolutely right, and it's how we handle problem vs incident. If it's an isolated issue, we use the incident option. If it's an issue that has been reported more than once or by more than one end-user then it's a problem. We also use problem if the incident is critical even if it's just one incident.


Post ist für Kommentare geschlossen.

Powered by Zendesk