How to Organise Help Desk?

Question

I have to organize the help desk. I have some thoughts and ideas. The project for which I have to do is a Web application. It has 5 servers in different time zones. We have something about 25 instances of our Web application and 8 entry points. The help desk is going to be split into different levels.

1. Key users - Normal users can report issues only to key users. Only key users can proceed issue to help desk.
2. Help desk - people with handbooks and defined "know how" workarounds and other solutions. They should also be able to get full knowledge about the issue from our users.
3. Support team - They should resolve some simple code bugs and configuration bugs.
4. The last part is development team. If some issue needs new feature development or it's a huge bug then this team should schedule it and resolve the problem.

I've got some concerns about 3rd point and the support team. What is the border between simple bug which should be left for support team, and which should be proceeded to development team? What do you think? For example if something will take 1 day/person it stays in support team otherwise it goes to development team? (If the task is longer).

And the second question: Who should be responsible for prioritizing tasks for support team? This is something what I don't know what to think of. :( Is the same Manager should/can be responsible for daily prioritization of support team tasks and development team tasks?

Answer 1

I'd leave much of that to self-organization. It seems you have 4 lines of support: key users, help desk, support and development team.

My idea: set people a goal that they should solve any issues they can investing reasonable amount of time -- you don't want help desk guys to learn programming. The let them pass the case to another line of support if they believe they won't handle with it.

Assuming people want to their best you should actually find some balance in terms of what should be escalated deeper in organization. Also support team should get some insight what kind of code-related issues they should fix by themselves and which they should pass to development team.

In case your teams don't do their best you will probably want to store issues with people who dealt with them, when they were escalated etc. If something doesn't work smoothly you will quickly see some red flags, e.g. support team complaining that help desk pass them issues which should be easily solvable by help desk guys.

Then it's leader's job to find out what's wrong. The reason may be some guys are trying to test the system verifying how far they can go, but it's also possible that they lack some training or information or are just overburdened. Specific solutions will depend on specific issues here but leader will definitely see whenever some problems pop up.

In terms of task prioritization I'd use similar approach. I'd let the previous group decide what is the priority, e.g. help desk sets/adjusts priority when they pass the issue to support. Then if something goes wrong you need some kind of escalation path from key users up to the leader so they might point something important gets ignored, so the leader gets warnings.

Answer 2

The development team is naturally going to have more knowledge of the core systems involved in the application since they were the people who built the features in the first place. The support team, on the other hand, sound like programmers who may not have been involved in the actual development of the application. Therefore, the support team is likely to have less domain knowledge of the actual architecture.

It's difficult to classify a bug as something that involves domain knowledge and something that can be resolved by any developer.

My suggestion is to use your escalation process. The support team should likely spend some time investigating each issue and only escalate bugs that they've spent some time on and know they won't be able to resolve on their own.

Also, certain issues, like new feature requests, can be escalated to development right away. In this case, the support team shouldn't spend any time at all on this.

Finally, you may want to consider that the developer who built the feature should probably be the developer who fixes the bug. This type of structure, where maintenance is kept separate from new development, may encourage sloppy development practices, as developers know that they can simply leave a poorly-written feature for someone else to clean up.

Of course, if this structure was dictated to you, then perhaps you could make sure each new feature is properly tested and code reviewed by the support team. Not only will this keep people in check, but the support engineers will also gain some useful knowledge about what part of the code to go to for each feature. They'll feel more in control of their destiny by participating in quality control, and they'll also gain the necessary domain knowledge to be effective when an issue is escalated to the support team.

Answer 3

Your aim, in this case, is to bother the development team as less as possible. They are actually not part of the helpdesk, but only some kind of last resort. They have other projects to deal with.

So if a problem is not crashing the whole system or blocking the users or something of the same severity, you should not escalate it to the development team.

Prioritizing the tasks of the support team can be done by 2 means: either you put somebody at the head of the support team to manage these questions or you let the team organize itself, using bugtracking tools, for example.