Correct me if I am wrong a service desk is a level 1 team who logs in incident and try to diagnose it, they assigned to level 2 to troubleshoot further if they are not able to resolve or provide quick fix

Now the ticket is not with the level 1 team, it’s with L2/L3 team...shouldn’t they be responsible, accountable for the incident rather than L1

what if the incident cross the SLA is there any time limit to out of SLA incident, how to handle 1000 of incidents of this kind

These backlogs of tickets is not because of service desk (L1), it is coz of L2/L3 or may be no solution found to these kind of individual incident…if so should Incident Ownership remains with the Service Desk or should it be owned by the team who has the incident

But do they really have to manage things which is out of their control and understanding

I think you have a misapprehension as to what they manage and what ownership entails.

Managing the incident does not require understanding any of the technical complexities involved in its solution. It does require knowing that the correct technical specialists are assigned to it; ensuring that they give it the correct priority among their tasks; extracting progress information from them both to pass on to the users/customer and to have confidence that the resolution will be timely; ensuring that the incident is properly documented at all stages; determining whether it relates to other incidents; determining whether there is an underlying problem to be addressed; ensuring that closure is properly achieved; liaise with users/customer over urgency, contingency and other issues; spot when escalation is required; and other stuff.

To make sure all this happens someone has got to keep their eye on the ball (that is ownership). The techies with their heads in the sand (sorry, silicon) are neither well placed nor (normally) well designed for this task. Also, it is always risky to keep passing the baton during an incident. Far better if someone manages the call from the interface (Service Desk) because they can then speak authoritatively to users/customer. In effect that person will delegate both the doing and managing of technical tasks, but will retain overall responsibility for the incident._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Think of the Service Desk as a router. It gets the information from the internet and passes the information to the machines hidden behind it.

As others mentioned they are the first point of contact and such as a router it will learn the path. So when getting requests that needs to be escalated to a higher level support they would know who exactly to assign it to. If they are not sure they can refer back to the line manager and this process shouldn't take long as you are expecting, it is done in minutes.

As far as issues being resolved at the first line, 1st line only deal with easy requests that come in on daily bases. They shouldn't be rocket scientist. example on those requests would be: password reset, Software installation, Creating new accounts etc. Service Desk staff should be trained for such requests or they can check their knowledge base/Training document or what I call the Monkey See Monkey do document, for more information if god perhaps they forgot the process to fix such requests.

Speaking of Microsoft Support I was very impressed that they spend hours waiting with you on the phone until they get your incident resolved from the first time 3.5hours in my scenario that's a lot of patience. Though that doesn't mean that vista is not Sh*ty

Looking through the conversation, I just wonder if I see it correct or not, and thus could help make it clearer so here it goes.
As usual, I will give an illustration.

First,
Somebody goes to the police office to report burglary. He goes to the front office, meet the officer and report the case.
Later he will be informed by the officer that "from now on his case will be handled by Sgt. X". From that time the one he will be dealing with is Sgt. X.
In this case, the report AND that somebody are escalated to Sgt. X by the front officer.

Second,
A woman goes to a hospital to check her condition. First, she will look for a general physician. After checkup, the physician came to a conclusion that her condition must be handled by an internist. She will then be informed that form now on you will be handled by Dr. Y". From that time she will deal with Dr. Y and not with the general physician anymore.
She and her disease are said to be escalated by the physician.

Both illustration are not the case with ITSM, especially ITIL. The Service Desk functions as the Single Point of Contact. This would interpret as "I don't care who's fixing the problem, the only one I want clarification and solution is the one I contacted first".
So, besides receiving and logging incident reports, the SD is responsible of tracking the incident resolution UNTIL service is restored and even more, confirming with the user that it is restored.

Thanks guys, I get the picture ....one question though how should a incident with no solution be handled .....no solution in the sense not yet found and no workaround.....let say incident is very old ...no urgency from user...can business say to its user that after x days a case can be closed..?

Json, only if the user agrees. In this case, the workaround is that your user has to work around it.

That said, if you choose to close incidents without consent, be sure it's in the SLA. Maybe you say that incidents will be closed after n documented attempts to confirm satisfaction with no responses. Watch out for that one unconfirmed-but-closed incident that creates an upset customer (and I mean Customer not just user)._________________Ruth Mason
USA

Incident ownership should remain with the service desk as normally the service desk is fat and in a position to seek answers for the end users. This is what appears from outside. Internally, the complete ownership lies with the support team working on the incident and the service desk is empowered to seek updates as and when required. The service desk has a bunch of people who can answer queries and if they don't have the end to end ownership the end users will start calling the vital few support staff making their lives difficult and taking the recording and tracking mechanism to a toss. Regarding your question of no solutions around, the incident management ( read Service desk) should get hold of the person who commissioned the application or the service. We can very well say to one user that there is an alternate but what happens if the said application or service has multitude of users. The guy who commissioned the service should brought into picture and should do RCA and if required raise a change order. If the application is not used by many and the owner is missing, the CAB should have the authority to decommission it after the consent of the business. The CAB must be informed about such instances by the IM.

simply put, all incidents should go through service desk who is the owner of the incident even though a 1 min resolved incident since service desk is the 'interface' between end user and service provider.

for those incident without solution or workaround, what we are doing is that we open a problem ticket and assign it to relevant technicians to deal with, how long time will be spent on such problem is based on the SLA pre-defined. Frankly speaking, we never defined such SLA with customers so lack of experience to talk about it in depth.

for those incident without solution or workaround, what we are doing is that we open a problem ticket and assign it to relevant technicians to deal with, how long time will be spent on such problem is based on the SLA pre-defined. Frankly speaking, we never defined such SLA with customers so lack of experience to talk about it in depth.

There are several threads that discuss this, but an incident does not become a problem under any circumstances and problem resolution is best kept outside the scope of SLAs because it is too difficult to predict how much time and resource is involved and because Problem Management is only indirectly related to Service Delivery, being more to do with the long-term health of the services. Are you using problem tickets as an interface to second or third line for incident resolution? If so, do you have a separate kind of ticket for invoking Problem Management.

If you meant how much time is applied to resolving incidents, then it is better if that is the time it takes to resolve them rather than some SLA figure which should only be about priorities and averages and general commitments about down-time._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718