Multiple problem tickets for one Incident?

[rjp]

Yes, assigning child parent relationships within incidents is a valid approach, and is a fairly common practice.

The purpose of the relationship between incidents is slightly different to the relationship between incidents and problems. The former is a process efficiency measure and simplifies and reduces the admin overhead, and helps prevent unecessary duplication of effort. It is based (as you indicated) on fairly straightforward attribute matching, and known information. The later is as much a creative application of experience and anaylsis as it is the application of 'rules'. Incidents will only be linked to problems when the assumption is made that they share a common root cause. But bear in mind, the assumption is that the root cause is not know, otherwise problem management isn't really required. So the situation of the 'known' error is actually the exception to the process, not the norm. And general process architecture should not be determined by the exceptions.

It is, however, only necessary to apply a relationship between a parent incident and the problem record, where strong (and accurate) incident duplicate identification is in place - and where you have systems to handle it.

On the issue of classifying an incident as a 'known error' I would not recommend it. (Unless you mean record it in a resolution code somewhere on the record - which is a good idea.) Incident classifications should show where your services are being disrupted. Because classifiaction answers the question 'what' first and foremost. And 'what' an incident is, is a disruption to a service. So Incident classification should show what the disruption was. Classifying an incident as a known error labels a process outcome, not an attribute of the incident. It will mess up your reporting and metrics.

[Jphuff]

Interestingly, we're facing a similar type of quandry at my work. What about the instance in which one reported incident gets multiple queries? For example; A customer calls for a software installation with an SLA of 5 days, and calls several times over the next two days to check status (when will I get the software?) until it is installed on the third day, ahead of SLA.

Now, do those status calls get logged on the original ticket or do they each generate another ticket? There is no way in the system being used to link the tickets together, by the way. A consultant is saying that ITIL would dictate that this generate multiple tickets which would all be closed on resolution? I would like to see if there is any documentation or "best practice" information on this? Doesn't seem to make sense and more like you are inflating volume (assuming you CANNOT link the tickets) but then again, even if you COULD link them, they are for the same issue, same root cause, same customer so why would you? Need some guidance here please!

One other issue while I'm here. Call systems for most businesses use selections to route calls and tell the call center what you are calling for. This can provide some useful correlation to the call center (for example, 300 outage report calls this week to correlate to 10 actual outages, or 40 password reset issues routed priority to agents which correspond to only 9 password reset 'tickets'). It allows getting the customer perspective on the issue they're calling for, routing certain calls to certain agents, and also gives SOME correlation of calls/types to tickets opened/types.

Is anyone aware of any documentation regarding this? I'm aware this is a 'best practice' type of setup and it's used by almost every business/call center out there, but how about documentation as to WHY or HOW this should be setup? I can't find anything other than vague mentions of call type routing being 'best practice' and not in a completely direct manner. Any golden documents out there?

BTW, this is a GREAT forum and the activity and input here is always thought provoking! Thanks!

J

[itilimp]

[rjp]

I concur with itilimp.

If it's the same customer it's a progress report.

If there a multiple customers calling then it is a matter of correctly reflecting impact - that may warrant additional incident reports.