Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Sun Oct 21, 2012 9:44 pm Post subject: Is Incident Closure always customer decision?
When a customer report an issue or ask a question; do you always wait for the customer to confirm if this is resolved and can be closed, or do you mark incident as resolved and close it if you know that you've provided the answer?
This is when the customer is responsive.
Case scenario:
Customer: How do I do that?
Helpdesk: Follow the following procedure: 1> 2> 3 (and you resolve and close the incident)
I've found a lot of documentation about what need to be recorded when closing an incident, but not who's decision it is.
That's why I'm asking... I need to set up process management around that
Right now we have nothing defined around this part of the incident life-cycle.
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Mon Oct 22, 2012 7:28 pm Post subject:
OoOps
Where exactly did you ask for other people's experience ?
[i]do you always wait for the customer to confirm if this is resolved and can be closed, or do you mark incident as resolved and close it if you know that you've provided the answer? [/i]
You asked a question and answered it yourself
So I ask you the following questions
1 - If you have no process or a point in a process where the process workflow ends, are all of your tickets raised by the customer or by internal support staff still open ?
2 - If #1 is true, how can you report anything of value to your customers
3 - When writing a process, surely, the individual writing it would be intelligent enough to have a starting points, logic gates and a closure point, condition or logic gate !
4 - Ask your self this simple question,
you go to a store, pick up a candy bar, walk to the cashier, the cashier scans the item, tells you the cost and then you pay the amount either exactly or over and get change. Then the entire situation terminates.
Does the cashier keep the transaction open or it is completed ?
Apply common sense to the IT SM Processes. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Mon Oct 22, 2012 7:38 pm Post subject:
And to explicitly answer your implied question.
It depends
If a customer contact raised an fault (incident) with the SD, as part of the closure of the incident ticket - after the fault (incident) is resolved, the SD would contact to confirm that there is no fault (incident) any more. However, the SD does not wait forever, there usually is some sort of time delay.. # of business days.. where if the customer contact does not confirm the service is up nor that the service is still down... then the SD team closes the ticket w/appropriate closure code and resolution code
The same thing would apply to Service Requests as well
This is NOT really ITIL but basic Service Management ( not even IT ) or more pointed - Customer Service Management.
This is done in business - between businesses and customers - for years.
IT aint something new
Am I paying for the abuse or is it part of the service ? _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Tue Nov 06, 2012 3:16 am Post subject: Re: Is Incident Closure always customer decision?
OoOPS wrote:
When a customer report an issue or ask a question; do you always wait for the customer to confirm if this is resolved and can be closed, or do you mark incident as resolved and close it if you know that you've provided the answer?
We have the tech to set it as resolved and the customer then can
- agree, and it moves to resolved
- disagree, and it goes back to assigned state
- do nothing, and it will close itself after 5 business days.
(on a side note, ignore the troll, it is the cost of an unmoderated board)
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Tue Nov 06, 2012 4:15 am Post subject:
OoOOPS
The concept of Incident Management is for the Service Provider to manage the incidents that occur
As part of managing the incidents, the service provider would write a policy document on how and when ticket opened, worked on, updated, and closed - whether closed completely or as in some tools - move to a completed before closing.
This is Incident Management. It was there in IM during the 80s when I worked doing ticket faults for Arpanet and it is there now.
ITIL helped define the IT processes that were in practice during the 70s, 80s and 90s and document them.
-----------------------------------------------
As a service provider, how you deal with the tickets in your own system is your own business - that and your customers that is.
I would advise using common sense to set or initially set the policy, process, procedures and work instructions.
You can always change them. That is the beauty of it. If what you wrote does not fit as you expected change them
Danatwork: ... _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Sat Nov 10, 2012 2:30 am Post subject: Re: Is Incident Closure always customer decision?
danatwork wrote:
We have the tech to set it as resolved and the customer then can
- agree, and it moves to resolved
- disagree, and it goes back to assigned state
- do nothing, and it will close itself after 5 business days.
(on a side note, ignore the troll, it is the cost of an unmoderated board)
Thanks,
Dan
I guess you mean closed, right?
So in case of a responsive customer (not closing itself) this is always customer decision to close a ticket.
Thank you, this really helps.
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Sat Nov 10, 2012 4:46 am Post subject:
OoOPs
He did mean close and not resolve
However, you missed two other points
1 - what if the customer while satisfied that the incident or service request is dealt with but wants the ticket open for some reason..
2 - what if the customer comes back two weeks later and does not want it closed
As I stated before.. you need to have a process for dealing with this - as it will occur - if you have multiple customers
You need it in place and shared with the customers, service managers and mgmt so you dont get custom er processes for each customer - which is hell _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Nov 03, 2012 Posts: 55 Location: Singapore
Posted: Sun Nov 18, 2012 1:07 am Post subject:
my experience, never assume your clients would come to you and close the ticket.
actually i never do that.
so the best practice is to set the incident resolved, and then tell your client to verify and reply within N days, if no reply is received, you'll consider the tickets can be closed.
now clients may say what should i do if i find the issue is not resolved after N days? well, a new ticket, right? _________________ Luo, Tian-Hong (Ken)
Regional Operation Lead
my experience, never assume your clients would come to you and close the ticket.
actually i never do that.
so the best practice is to set the incident resolved, and then tell your client to verify and reply within N days, if no reply is received, you'll consider the tickets can be closed.
now clients may say what should i do if i find the issue is not resolved after N days? well, a new ticket, right?
^
This.
I've been following the principle of auto-close after N days, for about 2 years. Less than 1% of tickets get questioned, because by the time the ticket gets to this stage, the issue has a 99% chance of being resolved, recognised by the customer, leading to said customer systematically and willfully ignoring each and every request for confirmation.
Let the less than 1% complain that their ticket got closed unjustly - If it happens, be professional, re-open the ticket. Their minor and incredibly rare frustration is just the cost of having a squeaky clean ticketing system.
Or, you could have one that is bloated with thousands (or in the case when I started) tens of thousands of open but completely dormant tickets, dating back more than 4 years.
You have to make the decision that is right for your environment - The call I've made is based on an understanding of our users, their demographics and daily pressures, and a wealth of past experience.
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