Another organizational consideration is whether or not to separate the analysts by products or by customers. If you have separate queues like we discussed earlier, you have already begun to organize your help desk by products.
Even if you are dealing with internal users, you can still break down support by customers. For example, you might have separate groups who are responsible for the support of specific divisions or departments within your company. This develops a strong relationship between members of the department and their respective help desk team. You learn what their strengths and weaknesses are as well as how they do their job. This enables you to provide much better support than if you were expected to handle the entire company.
The drawback of customer-based support becomes pronounced when the products vary dramatically. If the department you support does not use a particular product, analysts probably do not get the exposure they need. For example, in one company where I worked, support was broken down by our major business application/database, technical applications, and everything else. I was in the "everything else" group, and we had to deal with the standard office applications, the servers, hardware, the network, and so forth. When people called me with issues dealing then be technical applications, I could not even begin to work on the problem, because I had neither the experience nor the training to deal with the problem. In many cases, it was difficult to determine just exactly where the problem was because there was extremely little overlap of knowledge. The result ws that problems often sat around waiting for the expert to get around to it.
On the other hand, product-based support gives analysts the ability to become masters in a particular area rather than a jack-of-all-trades. This can actually become a very important issue for long-term customer satisfaction. The experts are in a much better position to solve problems quickly, especially if they involve very-complex issues. On the other hand, just as customer-based support leads to a good relationship between specific customers and specific analysts, product-based support is not really conducive to building such relationships.
In general, the easier the call in general, the more you should consider customer-based support, especially for an internal help desk, if you decide to have separate groups. If the problems require any basic knowledge of the products or the solutions are easily accessible, most of your help desk staff should be able to handle the greatest range of problems. The result is that the average scale level is consistent across the different customer groups.
If the needs of the customer vary dramatically, this is another strong reason for choosing customer-based support. Just as you need to spend the time working with a particular application or other aspect of the system in order to become proficient, you need to make considerable effort to become proficient in understanding the needs of the different customer groups. Therefore, breaking the support team into groups based on the customers allows them to get a better understanding of the customer needs.
Depending on the size of your organization, its structure, and the needs of the individual departments or customers, you may want to consider dedicated support analysts in specific cases. Here, the customer has a single point of contact within the support organization; all calls from the customer are directed to that specific support analyst, who knows the details of the department.
On the other hand, if your organization does not lend itself to dedicate support analysts, it may still be necessary. Either the customer must be willing to pay for it (assuming that support is in some way fee based), or there is some pressing need to have the dedicated support analyst. In one company where I worked, I was the dedicated analyst for all technical applications in the production halls. We were a manufacturer of industrial machinery, and there were a number of special applications that were used nowhere else in the company. Since the production halls could only tolerate a much shorter downtime than the other departments, it was decided that a dedicated support analyst would be assigned to address all their problems. (Note that I did have someone who could take over for me when I was on vacation or out sick.)
Choosing the appropriate model is not always and "either-or" issue. Depending on your organization, it is conceivable that you have a combination of both, in that the groupings are just a logical separation. That is, you have elements of both a customer-based and a product-based support. This is useful if applications are concentrated by department. For example, teams can be created that support specific products and other groups created whose responsibility is to look after the needs of different departments. These groups do not need to be distinct, but rather all of the team members are drawn from the same pool of analysts.
Problems with a specific applications or other aspects of the system would be dealt with by the appropriate specialists. However, certain individuals would be responsible to ensure that the needs of the different departments are met. Keep in mind that having separate groups for products and customers can become a dangerous problem in cases where the types of applications areas dramatically between departments.
When trying to design an appropriate model, scheduling becomes a real problem with small groups. Therefore, you should only create the groups that are absolutely necessary. On the other hand, if scheduling is not an issue, "virtual groups" can be helpful. For example, in one company where I worked, different skill sets were broken into OUs. These units were the back line in the company’s FL/BL model. When calls came in and could not be handled by the front line, they were assigned to the appropriate OU. Scheduling was done by including everyone and was only done for the hotline (front line). In addition, OUs were established to care for the needs of the different departments.