I went through my years in IT support never knowing the difference between incidents and problems. My colleagues and I would use them interchangeably when it came to logging faults and I’d say many support analysts are the same. Within Zendesk, the incident and problem ticket types are functionally different, and within IT Service Management (ITSM) practices the purposes of those ticket types are delineated, though often debated amongst ITSM professionals. Even within the ITIL framework, the definitions of problem and incident vary slightly depending on which version you read.
It’s easy to see why working with Incident Management and Problem Management as two separate processes can be confusing, but its worth persevering for the workflow efficiencies that can come out of it. With a large IT support desk, you may even have a dedicated Problem Management group. We’ll get to the benefits later, though. Lets deal with the difference between incidents and problems first.
To put it simply, incidents are interruptions to a customer’s service and problems are causes. Incident Management requires us to return service to the customer as quickly as possible. In an IT support environment, an incident could be as basic as a staff member needing an application password reset. To continue with that example, if you had a number of staff members need that same password reset you might suspect there’s something else at playan underlying problem. So, as the support analyst, you create a problem ticket in Zendesk to investigate why several staff members are suddenly having login failures. Solving that problem may just involve some user education or maybe it’s something to do with the application or infrastructure. But having that investigation captured in one ticket enables efficient working and easy assignment of responsibility.
Problem tickets should only be opened by agents in your Zendesk. It takes any murkiness out of your reporting and means that by linking related incidents to the appropriate problem, you can update a single ticket and have that comment appear in all those incidents automatically. And when a problem is solved, all associated incidents are, too.
But problems aren’t only reactive searches for root causes; they can also be proactive fixes to potential service interruptions. Take the example of a failed server disk. The server is still up and providing service because of redundancy, but if other disks fail we may well start receiving incident tickets. So open a problem ticket to look into why that disk failed and have it replaced before your customers feel any effects.
As I mentioned earlier, there are several benefits to separating your incident and problem management processes. Given the purpose of Incident Management is to get your customer up and running again as soon as possible, it’s good practice to escalate problems to a dedicated Problem Manager or group. The Problem Group can take the time that’s needed to investigate causes without blowing out your incident reports, or distracting those who need to focus more immediately on restoring service. A good Problem Management process can also drive a well-accounted change management process, too.
Not every IT service desk can acquire dedicated resources but at least with a clear understanding of the different purposes of incidents and problems you can define clearer escalation paths and reports for your organization, to achieve more customer-focused IT support.
Learn more about Zendesk for IT
