You may find below a list of fields that could compose the “perfect incident record” straight from the ITIL blue book V2
But keep in mind: the data filled by the user is pretty different from the data that should be in the “perfect” incident record.
First of all you should offer to the user the simplest possible form, to make it easy to fill in it.
Second, to make an example a good incident record contains priority information. I recommend you not to give the user the possibility to choice the priority (say: low, medium, high), this is up to the service desk. Instead it is interesting to ask the user to give some details about the impact and urgency (nobody can work, a department cannot send email, etc…)
So asses what should be in your incident record and what information should be provided by the user in two different actions.
Annex 5C: Data requirements for service Incident records
The following data should be recorded during the Incident life-cycle:
unique reference number
name/id of the person and/or group recording the Incident
name/department/phone/location of User calling
call-back method (telephone, mail etc.)
description of symptoms
category (often a main category and a subcategory)
Incident status (active, waiting, closed etc.)
related Configuration Item
support group/person to which the Incident is allocated
related Problem/Known Error
resolution date and time
closure date and time.
To have control during the complete Incident life-cycle, for every action is recorded:
name/id of the support group or person recording the action
type of action (routing, diagnose, recovery, resolving, closing etc.)
date/time of action
description and outcome of action.
keep the web forms as simple as possible and have the ServiceDesk and / or automation complete the rest of the ticket. The less the users have to fill in the more accurate the recorded information (believe it or not). _________________ Mark O'Loughlin
ITSM / ITIL Consultant
yes it should be used to capture the low priority calls and not be a replacement for all calls. Also users should have the ability to view calls submitted but not to update them - this is a catch 22 but once assigned they should call in with any updates - once they have viewed the call.
Agreed that H/D should "touch" the tickets to ensure that they are assigned corectly and any issues that would casue the ticke tot be rejected are addressed. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum