We are in the process of implementing ITIL with a new service desk.
We are having discussions on ownership of an incident.
We don't have a central help desk answering phones yet, we have a general number the users call, the policy is the person who answers the phone creates an incident, and then assigns the incident to the correct group (tech,apps,admin etc).

But the question is, who should close that incident once a resolution is reached? the person that originated the incident, or the person that accepted the incident and did the work?

Firstly I'm sure you're aware that in theory the Service Desk should always open all incidents but realistically that is not always possible, there's always 'leakage'.

Closure, however, can always be done from the Service Desk as a formal procedure - once agreement to close has be received from the user. If there is no direct end user it must surely be whoever requested the change or a project sponsor.

A simple process:
An incident is logged and assigned. The analyst who actually did the piece of work resolves and the incident should then reassign to the Service Desk. I personally like to have reassignment to a 'Closure' work queue from which the Service Desk contact the end user to seek closure.

This method reinforces the customer service experience and also means you have data to back up the age old moan that users don't respond and therefore contribute to poorer performance.

Think of the people side of the question: there is a difference between Service Delivery and customer satisfaction - you can actually be delivering your services and getting good KPIs for your various processes and still have a client base that hates you.

Also bear in mind that while Incidents and the root cause may be resolved simultaneously, for example, in the case of replacing a faulty monitor on a desktop system, in may cases the resolution is 'work around' not a fix.

Do you trust all your technical support staff to have the people skills required to get back to an end-user or customer with a resolution (a way of getting the business capability going again) that requires them to do something a little differently, or accept a minor degradation in capability, and manage to sell it in a look-how-quickly-we-got-your-ability-to-operate-back positive.

Closure after resolution - especially in the case of a work around - requires real people-skills, and an understanding of what the affected party is really trying to do as a productive member of their own department. That requires a good knowledge of the business.

I think if anyone wants to say, technical support should be able to close incidents, the onus is on them to show that those staff have sufficient business knowledge and customer relations skills to carry out the negotiation effectively - ie., with no avoidable degradation of customer satisfaction.

Wanting to streamline processes is fine, and reducing administrative overheads is important, but not to the detriment of customer service - it is after all about them, not us

One option we use is to have the tech who does the work mark the ticket "Resolved". The system actually closes the ticket and the Help Desk is the one with the final responsibility to close the ticket. Any ticket in the "Resolved" status can be reopened if the customer is not satisfied. There is a two week delay between the time a ticket is resolved and the system marks it as closed._________________Stockwell

One option we use is to have the tech who does the work mark the ticket "Resolved". The system actually closes the ticket and the Help Desk is the one with the final responsibility to close the ticket. Any ticket in the "Resolved" status can be reopened if the customer is not satisfied. There is a two week delay between the time a ticket is resolved and the system marks it as closed.

I do have a problem with Service Desk staying owner. Look at it like this. Service Desk stays owner, even after escalation. It is providing the 'us them' mentality, something we want to avoid. So that is were we have a coordinator and a waiting - or coordinator pool. The second line can put out a call or coordinator can take a call himself. Responsibility and ownership are transferred to the second liner. This is because of controling Change management, SLM, SCM, CM and escalation in a proper way.
A service desk with 100 - 150 calls a day per operator is not capable to stay owner and followup all calls.
ITIL is wrong to use in this way. Probably created by people which never manned a Service Desk.

I think it's more likely to do with the difference between a Call Centre approach and a more highly skilled Service Desk.

Eg., we have two levels of skills on our Service Desk. One skill set is more at the Call Centre level, mostly call logging, script diagnostics and resolution, and pro-forma Service Request handling. The second set is more senior analyst level, whom are not available by phone to the end-user community, and whom perform a very important incident control, and process coordination role. They are also responsible for representing the SD on various CABs, managing communications with the community, developing and improving processes, coordinating and undertaken the Problem Management process, and assessing Service level acievements.

They are given the time, resources, training and sponsorship to carry out these duties.

The advantage of having a highly skilled service desk is that you don't put a layer of low-skilled staff between IT and the user-community who do not have the clout to be effective customer advocates to the rest of IT.

It also means that customer facing processes and activities are owned by those people most skilled to ensure high levels of customer satisfaction.

One option we use is to have the tech who does the work mark the ticket "Resolved". The system actually closes the ticket and the Help Desk is the one with the final responsibility to close the ticket. Any ticket in the "Resolved" status can be reopened if the customer is not satisfied. There is a two week delay between the time a ticket is resolved and the system marks it as closed.

I do have a problem with Service Desk staying owner. Look at it like this. Service Desk stays owner, even after escalation. It is providing the 'us them' mentality, something we want to avoid. So that is were we have a coordinator and a waiting - or coordinator pool. The second line can put out a call or coordinator can take a call himself. Responsibility and ownership are transferred to the second liner. This is because of controling Change management, SLM, SCM, CM and escalation in a proper way.
A service desk with 100 - 150 calls a day per operator is not capable to stay owner and followup all calls.
ITIL is wrong to use in this way. Probably created by people which never manned a Service Desk.

ITIL is not wrong in this case, you are confusing owning the lifecycle of the incident vs owning the work needing to be done to bring the service back to normal.

The Service Desk Certainly does Own the ticket. They need to ensure that the customer is being constantly notified of the status according to the SLA. The 2nd level/3rd level/technician work on incidents do not necisarrily know or understand the impact or know the SLA.

In any case, if you have 100-150 per agent per day and are not getting resolution quickly on most of these or are constantly escalating most incidents. You most likely have some issues in your Problem and Change management areas.