\nAnother organizational consideration is whether or not to separate the analysts by products or by\ncustomers. If you have separate queues like we discussed earlier, you have already begun to organize\nyour help desk by products. <\/p>
Even if you are dealing with internal users, you can still\nbreak down support by customers. For example, you might have separate groups who are responsible for\nthe support of specific divisions or departments within your company. This develops a strong\nrelationship between members of the department and their respective help desk team. You learn what\ntheir strengths and weaknesses are as well as how they do their job. This enables you to provide\nmuch better support than if you were expected to handle the entire company.<\/p>
The drawback of\ncustomer-based support becomes pronounced when the products vary dramatically. If the department you\nsupport does not use a particular product, analysts probably do not get the exposure they need. For\nexample, in one company where I worked, support was broken down by our major business\napplication\/database, technical applications, and everything else. I was in the "everything\nelse" group, and we had to deal with the standard office applications, the servers, hardware,\nthe network, and so forth. When people called me with issues dealing then be technical applications,\nI could not even begin to work on the problem, because I had neither the experience nor the training\nto deal with the problem. In many cases, it was difficult to determine just exactly where the\nproblem was because there was extremely little overlap of knowledge. The result ws that problems\noften sat around waiting for the expert to get around to it. <\/p>
On the other hand,\nproduct-based support gives analysts the ability to become masters in a particular area rather than\na jack-of-all-trades. This can actually become a very important issue for long-term customer\nsatisfaction. The experts are in a much better position to solve problems quickly, especially if\nthey involve very-complex issues. On the other hand, just as customer-based support leads to a good\nrelationship between specific customers and specific analysts, product-based support is not really\nconducive to building such relationships.<\/p>
In general, the easier the call in general, the\nmore you should consider customer-based support, especially for an internal help desk, if you decide\nto have separate groups. If the problems require any basic knowledge of the products or the\nsolutions are easily accessible, most of your help desk staff should be able to handle the greatest\nrange of problems. The result is that the average scale level is consistent across the different\ncustomer groups.<\/p>
If the needs of the customer vary dramatically, this is another strong\nreason for choosing customer-based support. Just as you need to spend the time working with a\nparticular application or other aspect of the system in order to become proficient, you need to make\nconsiderable effort to become proficient in understanding the needs of the different customer\ngroups. Therefore, breaking the support team into groups based on the customers allows them to get a\nbetter understanding of the customer needs.<\/p>
Depending on the size of your organization, its\nstructure, and the needs of the individual departments or customers, you may want to consider\ndedicated support analysts in specific cases. Here, the customer has a single point of contact\nwithin the support organization; all calls from the customer are directed to that specific support\nanalyst, who knows the details of the department.<\/p>
On the other hand, if your organization\ndoes not lend itself to dedicate support analysts, it may still be necessary. Either the customer\nmust be willing to pay for it (assuming that support is in some way fee based), or there is some\npressing need to have the dedicated support analyst. In one company where I worked, I was the\ndedicated analyst for all technical applications in the production halls. We were a manufacturer of\nindustrial machinery, and there were a number of special applications that were used nowhere else in\nthe company. Since the production halls could only tolerate a much shorter downtime than the other\ndepartments, it was decided that a dedicated support analyst would be assigned to address all their\nproblems. (Note that I did have someone who could take over for me when I was on vacation or out\nsick.)<\/p>
Choosing the appropriate model is not always and "either-or" issue.\nDepending on your organization, it is conceivable that you have a combination of both, in that the\ngroupings are just a logical separation. That is, you have elements of both a customer-based and a\nproduct-based support. This is useful if applications are concentrated by department. For example,\nteams can be created that support specific products and other groups created whose responsibility is\nto look after the needs of different departments. These groups do not need to be distinct, but\nrather all of the team members are drawn from the same pool of analysts. <\/p>
Problems with a\nspecific applications or other aspects of the system would be dealt with by the appropriate\nspecialists. However, certain individuals would be responsible to ensure that the needs of the\ndifferent departments are met. Keep in mind that having separate groups for products and customers\ncan become a dangerous problem in cases where the types of applications areas dramatically between\ndepartments.<\/p>
When trying to design an appropriate model, scheduling becomes a real problem\nwith small groups. Therefore, you should only create the groups that are absolutely necessary. On\nthe other hand, if scheduling is not an issue, "virtual groups" can be helpful. For\nexample, in one company where I worked, different skill sets were broken into OUs. These units were\nthe back line in the company\u2019s FL\/BL model. When calls came in and could not be handled by the front\nline, they were assigned to the appropriate OU. Scheduling was done by including everyone and was\nonly done for the hotline (front line). In addition, OUs were established to care for the needs of\nthe different departments.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Continue reading