Is Incident Closure always customer decision?

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
OoOPS
Itiler
Itiler
Posts: 8
Joined: Mon Aug 06, 2012 8:00 pm
Location: London

Sun Oct 21, 2012 7:44 am

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.

Cheers!!


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Sun Oct 21, 2012 11:27 am

What
does
your
company
Incident
management
process
state
about
closing
incidents ?

That
should
be
your
only
guide.
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
OoOPS
Itiler
Itiler
Posts: 8
Joined: Mon Aug 06, 2012 8:00 pm
Location: London

Sun Oct 21, 2012 12:54 pm

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.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Oct 22, 2012 1:50 am

Then
define
it.

ITIL
does
not
care.

ITIL
is
a
set
of
common
sense
not
rules.

These are not the droids that you are seeking
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
OoOPS
Itiler
Itiler
Posts: 8
Joined: Mon Aug 06, 2012 8:00 pm
Location: London

Mon Oct 22, 2012 4:42 am

Not sure what makes you so upset about me asking for shared experience...

I know ITIL is not a set of rules, I was just asking what the members of the board are doing regarding that, so I can see what fit the best for us.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Oct 22, 2012 5:28 am

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
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Oct 22, 2012 5:38 am

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
User avatar
danatwork
Itiler
Itiler
Posts: 8
Joined: Sun May 08, 2011 8:00 pm

Mon Nov 05, 2012 12:16 pm

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)

Thanks,
Dan
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Mon Nov 05, 2012 1:15 pm

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
User avatar
OoOPS
Itiler
Itiler
Posts: 8
Joined: Mon Aug 06, 2012 8:00 pm
Location: London

Fri Nov 09, 2012 11:30 am

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.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Fri Nov 09, 2012 1:46 pm

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
User avatar
KenLuo
Senior Itiler
Senior Itiler
Posts: 55
Joined: Fri Nov 02, 2012 8:00 pm
Location: Singapore

Sat Nov 17, 2012 10:07 am

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

ITIL Expert Certified
User avatar
Shortallio
Newbie
Newbie
Posts: 1
Joined: Sun Jun 30, 2013 8:00 pm

Sat Aug 09, 2014 11:04 am

KenLuo wrote: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.
Post Reply