No matter what organization you choose, one of the first steps is to identify what skills you have and which are missing. This has two goals. First, you identify in what areas you need to train or hire more people. Second, it’s the first step in any other kind of organization. I think you should include not only people on the help desk but also anyone you can draw on to help solve problems.

Make a table with the skills along the side and the person along the top. Fill in each cell of the table with some indication of the skill level. Regardless of how many people are in your organization, you should create the table. Even with 10 people in our system administration, we had such a table. The group was small enough that we all had a general idea of the areas in which each person was proficient. However, there was always the problem when someone was sick or on vacation. That brought up the question of who was in the best position to solve the problem.

Once you have your table, you will quickly notice that there are holes in this table. There are certain areas where there is either no one who is really good in a particular area or just one or two. This will tell you where you need to concentrate your training (maybe hire some new people). It also serves as a guide for assigning problems. Note that I said "guide." Don’t assign calls strictly according to this table: How you do that, we’ll get to in a moment.

There is one problem with this. You may end up with dozens of different skills. When I listed all the applications and aspects of our system, there were over 100 different entries! When trying to determine who had each of these skills, I noticed patterns. The MS Word expert was also the MS Excel expert and the DHCP expert was also the WINS expert. It was then easy (as well as logical) to combine different groups so that their labels were more generic, such as "office applications" or "Windows networking." However, be careful that you do not make them too general.

In addition, it may not always be possible to break the skills into general areas. When I was in support for a software manufacturer we had to break down skills into the more-specific units. This is necessary if you have a large number of calls. It is easy to get the call to the expert. How you do it will depend on the number of users you support, the people supporting the users, and the skills you need to have.

On the one hand, this seems like a contradiction of what I said earlier. However, I suggest that at the beginning you have as many categories as possible (at least during the planning). Oncepatterns develop you can begin to merge the categories. However, what happens when a new person comes into the group? They may only know MS Word, but not MS Excel. Do you create more groups or train the MS Word experts so they know MS Excel as well?

You might want to consider having a smaller number of categories that you still assign analysts to. You can then say that it is expected that when someone knows one area in that category, they should learn the others. With this in mind, you can immediately plan training.

Another aspect is the person’s skill level: Maybe skill levels of 0-10 is too many, but you should at least have four levels: none, beginner, proficient, expert (or something similar). These levels are easier to categorize than 10, because most people would be hard pressed to find a difference between someone at level 7 and someone else at level 8.

Normally, the person who first takes the call will have enough experience to determine the complexity of the call (assuming there is no dedicated receptionist, secretary, or similar).He or she can then determine if the problem requires an expert or not and assign it appropriately.

The table with the skill levels needs to always be available to anyone assigning calls. It must be used to make the assignments. In one support organization that I worked for, we had one analyst who was an expert in a large number of areas. When he decided to learn about other areas and got himself listed in certain categories as knowing "a little," he was assigned calls in that area as if he were an expert! The people making the assignments simply assumed that he was an expert in every area.