who to close the trouble ticket?

[supertooth]

I'm very new to ITIL. In incident management, is there some critieria that says that the person who raises the incident should be the one who closes the incident ticket. It sounds odd to me.
If I take a real life scenario, Company A raises a trouble ticket to Company B. Company B rectifies the problem but has to wait for Company A to close the ticket.
Anyone can advise on me if this is the correct flow? I always have this impression that the person who rectifies the problem (Company B) should be the one closing the ticket. thanks

[ClaireAgutter]

Hi supertooth

The ITIL principles state that incidents can only be closed with the customer's permission. The Service Desk should contact the customer before closing the incident to check that everything is okay. This can increase customer satisfaction and make sure that technical teams aren't closing incidents because they've got bored of them.

In the real world, there may not be enough resources on the Service Desk to contact every customer, or customers may not want this. Many organisations have automated the closure process and send an email to the customer instead. The email will state that IT believe the incident is complete, and unless they hear from the customer in xx number of days, it will be closed.

Claire

[UKVIKING]

The underlyign object of asking the customer / user is to find out whether their service is running as required -- ie the incident is no longer there

how that is done is up to the company .. but clair has it right for a lot of them
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[supertooth]

Thanks John and Claire. Your inputs really helped to clarify my question! the problem with my environment is that there are SLGs if the ticket is not resolved. In spite of that, we still have to check with the customer. Sure need to automate this portion to reduce workload.

Cheers.

[ClaireAgutter]

Hi supertooth

It's normal to report on incident closure and have targets associated with this. However, it would also be normal to filter out incidents that took a long time to close because the customer didn't get back to you.

If customers aren't responding to requests to close incidents, the service provider shouldn't be punished or deemed to have failed the target. It may well be an indication the customer doesn't want that level of service and would be happy with an automated solution.

Claire

[Sunny60in]

Hi Supertooth

Some best practices that I have experienced:

Configure your SLGs (ticketing tool) so that SLG clock stops when action is not with your team. It might be the status of the incident ticket which is set to 'on-Hold' or 'Pending'. I have seen service providers using these status when some information is expected from the user.

There is another popular practice and that is to 'Resolve' the incident and wait for user confirmation before you 'Close' the incident ticket. In such case service provider agrees for SLG for 'Resolving' and not for the 'Closer'.

Ticket is close when:
- User approves the closer
- There isn't any response from the user (criteria for this is usually agreed with the customer. Example: 3 strick process - 3 follow up (every 24 hours) on 'no response' before closer)
With these 2 points as base, there shouldn't be much fuss about WHO closes the ticket.... service desk or L2 or L3...

but then... life isn't that easy.. management tragets, STATS & reports force these teams argue on their 'right to close the ticket' and one can be party to all the best possible arguments and logic...

[Boydness]