Is Incident Closure always customer decision?

[OoOPS]

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!!

[UKVIKING]

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

[OoOPS]

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.

[UKVIKING]

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

[OoOPS]

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.

[UKVIKING]

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

[UKVIKING]

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

[danatwork]

[UKVIKING]

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

[OoOPS]

[UKVIKING]

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

[KenLuo]

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