1) A user calls the SD because he cannot access an application page.
2) A second user calls for the same reason
3) Then a third
….

After a rapid investigation Production states that there was an issue with the DNS server, everything will be fine by 4pm.

What should be the SD behaviour in this case?

It opens an incident record, after a rapid look assigns it to a Production specialist
Then it logs each call on the same incident record
Then the production specialist resolves the incident

OR:

It opens an incident record per call
After a rapid look (the incidents are so similar) it opens a problem records and links the incidents to the problem and assigns the problem to the Production specialist
Then the Production specialist resolves the problem record and this resolves the incidents
Then SD closes the incident records one by one once sure it is fine for each user that has called the SD.

I prefer the second solution; in my view each call is a different incident even if related to the same shortage. Even if it produces an overload in Incident Management.

What’s your opinion? What would you consider the incident? Each interruption of service raised directly by a user (customer point of view) or the single Production shortage?

-The SD receives the first call and opens an Incident record.
-The SD receives subsequent calls and opens additional records.
-The SD recognizes that there is a Problem and notifies the PM team that there is an issue that needs investigation (a SD analyst could open the Problem ticket directly, but at that point they would be performing an activity of Problem Management).
-Every subsequent call is a new Incident linked to the Problem ticket.
-Problem Management investigates the issue and discovers a Workaround (if available).
-Every subsequent Incident is resolved to the Workaround. If you have the manpower, you can look at unresolved Incidents associated with the Problem and apply the Workaround to them as well.
-When Problem Management has progressed to the Known Error phase, a Change request is opened.
-The Change is approved and Release management implements the Change.
-A successful PIR determines closes the Change, which closes the Problem, which resolves any open, linked Incidents (hopefully the tool does this auto-magically).
-Any Incidents that had Workarounds applied may need to be reviewed to see if the Workarounds need to be undone.

Hi dboylan, thanks for your detailed reply, but now, after the perfect world case, can you tell me how you’d behave in a similar situation? I ask you this question because I’d tend to act in the ideal way you described but I fear it could produce too much overload on the service desk. I discussed this topic with a colleague from production and from his point of view there is just one incident: the server shortage.

I still think that from a service point of view each disruption encountered (and notified) by a user should be considered as an incident.

I think that administering all calls gives the advantage of getting insight in your workload. This will help prove to management the burden of everyday' work, justifying the number of FTE you have in operation.

At the other hand, in the case of a flood of calls (I agree with SKinnera using the IVR when possible) this might give you too much administration. What about your tooling (apart from IVT). I know that several tools have options like 'register similar call' where you can use an already registered call to (very quickly) register a new one. This way, you only have to fill in a subset of all requiered info per call. Would this be an option for you?

Hi dboylan, thanks for your detailed reply, but now, after the perfect world case, can you tell me how you’d behave in a similar situation? I ask you this question because I’d tend to act in the ideal way you described but I fear it could produce too much overload on the service desk. I discussed this topic with a colleague from production and from his point of view there is just one incident: the server shortage.

I still think that from a service point of view each disruption encountered (and notified) by a user should be considered as an incident.

You opinion?

Yes, I would open a separate ticket for each reported occurrence of the issue. That way you can go back after the fact and get a feel for the disruption to the business.

A note about using the IVRU to announce an outage. I have done this in a previous position and we would add the Call Abandons to the count of Incidents reported related to the issue on the assumption that the majority of them hung up after hearing the announced message.

on the same topic, what does ITIL say should happen to all the slave calls that have been attached to the Problem record, should they go into pending or remain open with the problem record until the solution or workaround is identified.

ITIL is not that prescriptive. If you keep them open, what will you do with them? If you close them, will you lose anything?

On the other hand, I'm not sure I would open a problem that quickly in the scenario described. It is really an incident with effect on more than one user. you can tie yourself up in to much management if you jump too soon.

If it happened again and then again within a few days or weeks, then it could go to Problem status to find why it was happening.

My slant on the original question is this:

1. It might be important to be able to contact each affected user
2. It might be important to know haw many have been affected
3. If it does eventually need PM then it might be useful to know which users were affected each time.

So

record this information. If that is easiest to do by opening individual incident records, then make sure you document the link between them.

Of course this is a bit simple. For example, if you get hundreds of calls the information on each is less usable and less useful and the effort of recording them all is excessive._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

As I understand this, if we had an ongoing Problem that for some reason there was no fix, until Problem management completed their RCA, then any further calls logged by the users, should be linked to the Problem in order to monitor impact, however these calls should be placed either in pending or should closed as repeat calls simply because the issue still remains one issue (ie Server down) and for analysis one could count the linked calls or/and call back the pending calls to ensure that they were related to the original fault, before individual closure.

However the account I support argues that, "fine, there maybe only one issue as the root cause, but for each person reporting the fault they are all individually experiancing a separate incdent".
Though I cant get to grips fully with this concept of that thought, I was hoping to find something in ITIL to refer back to.

A Mail server is constantly slow,
-Reported to Service desk and Incident process followed, which turns into a MASTER with additional slave calls linked to it. The Server was Identified as slow but no luck in finding out why.
- So because no fault could be identified. Problem Management process and the PM team were brought in to identify the underlyning issues of this server.
- PM investigation finaly makes recomendation to add an additiional server to share the load balance, for this RFC is raised, change, release and implentation being carried out.
- however until this is completed the users will continue to see the delays in sending and recieving.

Now would you agree that irrespective of the PM team getting involved this is still an outstanding incident (that would easily breach SLA) and additional calls logged should be linked to the MASTER Incident. Or would you argue that service is slow but not stopped hence not a direct impact of service but more an adverse affect and should be Part of a Problem investigation and not part of any Incident SLA, if the latter, then should the new calls be linked to the Problem Record directly.