You also need to consider the possibility that there may be no clear distinction between theresponsibilities of the help desk and those of IS. This needs to be taken into account byestablishing guidelines for what to do in those cases when the clear line cannot be drawn. Onthe other hand, the clear separation of responsibilities is possible provided they are used for reference. For example, it is perfectly reasonable to give the help desk the responsibility for receiving and processing all problem reports. In addition, the help desk can also be responsible for solving application-related problems. For example, how to connect to a network printer may be the job of the help desk, whereas figuring out why he you can’t print to that same printer is a responsibility of IS.

Also, keep in mind that continuity in problem solving is a benefit for everyone concerned.

When problems are passed from help desk to IS, information can be lost. Therefore, you might want to consider having the help desk be the first line of support and have IS be the one to solve harder problems.

For me, the most efficient solution is to have a clearly defined separation of responsibilities while maintaining the attitude that no one should pass the buck. This means that both sides should try to solve problems to the best of their ability. In support of this, I feel it is important to identify the cases where problems should be passed to the other team, not so much passing the buck as ensuring the problem is not immediately passed back to the first group and wastes everybody’s time.

The problem of defining responsibility and keeping people from passing the buck also showsitself if you have more than one support group working on the help desk. In many companies, one group would be responsible for network and system issues, for example, and another group is responsible for applications problems.

What do you do when a user cannot print from a specific application? If it is a network problem, it should be solved by the network group. If it is an application problem, it should be solved by the applications group. How do you know where the problem lies until you start working on it? Here is an example of clearly defining your goal as being to help the user. This means trying to solve a problem no matter what group you’re in. If during the course of evaluating the problem, the applications group determines that it is a network problem, one alternative would be to have them query the network group themselves and not have the user do it. This provides continuity for the user and at the same time saves time by not passing the problem back and forth.