Branimir Valentic The Incident Record is a record about all activities and details related to an incident. Very often, the wording “Incident Ticket” is used. We are talking about the recording of all activities and details related to an incident, so it must be important, isn’t it? Yes, it’s very important. Just imagine a situation where the Service Desk gets dozen(s) of incidents reported in one day or maybe a week. Without recording those incidents and all further activities related to them – I don’t see how such a system could be productive. (To learn more about incidents click here: Incident Management in ITIL – solid foundations of operational processes.)
Recording Incident Records
The worst scenario is that there are no records. I have seen such situations and I have to admit – it’s quite chaotic without a trace of professionalism. Everything else is better than that. When saying “everything else,” I mean that you have to consider the size of your organization (i.e., number of supporting staff), number of users who are reporting incidents, number of incidents (e.g., daily, weekly, monthly), need for reporting… etc. and then you will get an idea of what is the most suitable way to record incidents.
Here are three options for recording incidents, i.e. Incident Records, which I found while working with various IT organizations:
- Paper form – it’s the simplest method, maybe odd, but it could work. I have seen this work with a single-man support organization with a single customer and few incidents in one month. Although feasible, I wouldn’t recommend it.
- Spreadsheet form – it’s a slightly more sophisticated method and includes a lot of freedom while defining Incident Record. Define required information (i.e., columns) and insert a new row for every incident as well as every recorded step during incident resolution. Sounds implementable, but it has limitations.
- Tool – this is most reliable and most used method. Incident Records are recorded in a database (behind every tool there is a database), end-users can access it (most of the tools provide such functionality), reporting exists… etc. But, be careful – it could be costly.
Incident Records can be created by end-users, IT staff or tools (e.g., events of a certain category automatically create new Incident Records).
Layout and content
There is no prescribed content, i.e., layout, of an Incident Record. Content is important for several reasons:
- Speed-up incident resolution – when all data that are needed for incident resolution are present (e.g., by declaring related Configuration Item and incident description as mandatory fields), support teams can work much faster than if they have to collect them subsequently.
- Knowledge of the organization – or not “reinventing the wheel.” When one type of incident is resolved and all relevant data recorded, then there is no need to start from the beginning (e.g., diagnosis) when the same incident occurs again. Remember the situation when a technician who is heavily involved in incident resolution leaves the company – if incidents are recorded, know-how related to the incident remains and can be reused.
- Reporting and improvements – sometimes we want to know how efficient we are, or a customer is asking that we prove that Service Level Agreement (SLA) requirements (e.g., are Priority 1 incidents resolved in agreed time) are met. This means we need a report. An additional benefit to maintaining Incident Records is that we can define weak points (of the service or of our own staff) and start the improvements. Improvement could be, e.g., that our support team needs know-how in networking because the benchmark (for which we need a report) shows that we are 20% slower than average. Learn more about reporting here…
Content of the record can vary, but there are some fields which are considered as mandatory like in the following table:
Definition criteria
Depending on the situation, there are more data that can be included in the Incident Record. The logical question is – how do you know when there are enough data inside the record? It’s hard to say, but I use two criteria:
- If there is no use for the information inside the record – it’s obsolete.
- When recording of certain information requires significant effort and usability is low.
Figure: Example of simple Incident Record
Usually, the customer or end-user will see just a portion of an Incident Record’s data. End-users are interested in seeing that the incident is resolved (in agreed time – which is the concern of the Service Level Manager on the customer side) and not about all the details during incident resolution (i.e., historical data inside the record). The internal support team will have access to all fields of the record.
You can’t live without records
There is no doubt that incidents will occur. This creates demand for Incident Records, which means –> you can’t live without them. Since they (Incidents Records) are here, make the most of them. Create records that are detailed enough and use them consistently with no excuses. Satisfied and informed customers, an organized support team and increased know-how are just some of the benefits.
Download a free sample of the Incident Record to see an example of an incident record in simpler form.
