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.

[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.

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)

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)

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

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.

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)

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.