Multiple Requests during a call

[Blanco24]

Example: User calls for a password reset (which is successfully performed by the help desk) and then proceeds to ask questions which requires help from level two support.

Should the help desk create:
1) one ticket - mention the password reset in the body of the ticket - and assign the ticket to level 2 support with additional information
2) Create a quick close record for the password reset and create a ticket for level 2 support

What's the ITIL way?

[inrepose]

If they call with two incidents or service requests, I would log one and tell them to call back later because we can't do more than one thing at once! Or transfer them to another agent! Only joking...

Officially if you did a password reset and then they asked for general help/advice, I would raised the ticket for the password reset (which should be a quick raise/close item in your service desk tool) then I would raise another service request for the other help.

Or - If you have a service portal I would reset the password close the ticket and ask the user to raise a service request on your web based portal. That depends very much on your process.

On my service desk we ask for non-urgent service requests to be raised on our web portal. But we can still log tickets on their behalf if required.
_________________
Robin Fitton.

[Diarmid]

sounds like you have a software tool issue.

Obviously you process each item separately if you want to ensure management control of the processes and if you want useful data recorded about requests and incidents.

I cannot imagine how telling a user/customer to call back later constitutes good service. If you are given too much to cope with at that moment, then the very least you must do is promise (and keep it!) to call them back once you are straightened out.

Better still, you cope. You open - fix - close the password reset and then you open the other request and leave the caller expecting action.
_________________
"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

[dboylan]

You really should be opening separate tickets for each request. If only because other service management processes rely on accurate Incident Management's database to enable their processes.

If you had a lot of people calling to reset a password and following up with a procedural question, but only opened one ticket, Problem Management may not realize that their is a issue with documentation that isn't clear. If you have users calling saying that they have a question about Excel and then mentioning that the procurement system has been down for the last 10 minutes, Availability Management may not realize that their have been issues with up-time. Etc., etc., etc.

Don Boylan

[viv121]

To cut the long story short the tickets should be CI based and not user based. If a user calls up for application ( CI) A,B,C,D and E not working then you should open 5 tickets for the user. CMDB tracks the CI while AD tracks the users. Ticket logging should be CI based only. We you get 100 calls, you might as well as 150 tickets because users made multiple requests.

Regards

Viv121

[Diarmid]

I don't think it is that simple. An incident (or request) may not comfortably map to a single CI either.
_________________
"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